Changing How You Decide Which Problems To Solve

By Jon Moore and Marty Cagan

This is the third of the three-article sequence diving into what is meant by meaningful transformation.

So far we’ve talked about the need to change how you build, and the need to change how you solve problems.  But we haven’t talked about how you decide which problems are the most important to solve.

OUTCOME-BASED ROADMAPS

It is not hard to simply take your existing product roadmaps, and for each feature or project, to determine what the underlying problem to solve is, and what the logical way to measure success would be.  That’s the simple and straightforward way to move from roadmaps of features, to roadmaps of outcomes (this is referred to as an outcome-based roadmap).

This is not a difficult step, but simply providing your empowered product teams with problems to solve, and clear measures of success, can go a long way towards generating better solutions to those problems for your customers.

But are those really the most important problems to be solved for your customers and for your company?

Every company has before it a set of opportunities, and faces a set of threats.  

But how rigorous is your company in selecting the best opportunities to pursue, and focusing on the threats that you should take seriously?

Changing how you decide which problems to solve is the third element of becoming a strong, product-led company.

CUSTOMER-DRIVEN PRODUCT VISION

So many companies spend their time reacting – reacting to new sales opportunities, reacting to competitor’s offerings, reacting to customer requests, and reacting to price pressure.  Yet in strong product companies, while they care about these factors, they are not driven by them.

What drives them is the pursuit of a product vision that can meaningfully improve the lives of their customers.

In fact, in a strong product company, a compelling and inspiring product vision is our single best tool for inspiring our product teams.  The people you want on your teams are precisely those that believe in your product vision.  They want to make a difference in the lives of your customers.

A strong product vision will inspire an organization for many years (most are 3-10 year product visions).

Note that the product vision is first and foremost about the customer.  How will it make the lives of your users and customers better?  

It is not about how you are going to make more money, or what your priorities should be for the quarter, or how you’ll structure your product teams. These other topics are important, but the purpose of the product vision is to describe the future that you are trying to create.  

You may have dozens or even hundreds of product teams, but the product vision is what unites the teams with the shared goal of making that vision a reality.

INSIGHT-DRIVEN PRODUCT STRATEGY

While the product vision describes the future, the product strategy is how we identify the most important problems to solve now.

The product strategy begins by focusing on the most critical areas for business success.  Most companies try to do too many things at once, and end up diluting their efforts and making too little progress on the true levers for the business.  

As Steve Jobs said, “People think focus means saying yes to the thing you’ve got to focus on. But that’s not what it means at all. It means saying no to the hundred other good ideas.”

Or, more simply: “If you chase two rabbits, you will not catch either one.” – Russian Proverb

Once we have identified the few key focus areas, we then need to select the insights that we will be betting on.

We are constantly investigating the quantitative insights, mainly derived from the data that’s generated; and also the qualitative insights, mainly resulting from talking directly to our customers.  We’re also continuously evaluating the potential of new enabling technologies, and the implications of relevant industry and technology trends.

This type of insight-driven product strategy usually requires developing new muscles for the company, but the reward for strong product strategy is to get the most out of your technology investment.  Good product strategy is a force-multiplier.

It’s important to understand that product strategy is distinct from both business strategy and go-to-market strategy.  Many companies have strong skills in business strategy and/or go-to-market strategy, but product strategy is often missing completely.  

In fact, in most feature-team companies, the product strategy is literally to try to deliver as many features as possible for the different stakeholders.  Which is to say, there really isn’t a product strategy at all.

TEAM OBJECTIVES

The product strategy identifies the most critical problems to solve in the quarter, and the product leaders assign those problems to the relevant product teams through team objectives.

Product teams are selected based on the areas they are responsible for, the skills on the team, the enabling technology used by that team, the data the team has access to, and the team’s ideas for pursuing this problem.

The product teams then work to discover a solution that solves the problem they’ve been assigned, and then they deliver that solution.

THE ROLE OF PRODUCT LEADERSHIP

Most companies that want to transform understand that they need to dial up the level of their product teams.  Hiring more senior engineers.  Hiring skilled product designers.  Hiring competent product managers.

But many companies are surprised to learn that they often have even larger gaps in their product leadership.  

In fact, in many feature-team companies, they really don’t have any product leadership to speak of.  Since they rarely have a product vision, and are even less likely to have a product strategy, the job of product leadership is essentially new.

More generally, the product leaders play the primary role in coaching and developing their people to have the skills to effectively and successfully discover and deliver solutions.

But the leaders of product management, product design, and engineering are absolutely essential to not only changing how you decide which problems to solve, but also to changing how you solve problems and changing how you build.