Now That I Have A Product Strategy, What Do I Do With It?
Now that I have a Product Strategy,What Do I Do With It?
A really interesting question – let’s start by talking about how the product strategy fits into our world view. As product managers, our most important deliverable is the product, but with an asterisk. We can’t just deliver “any product.” Let’s also set aside the fact that we aren’t physically delivering a product – our team is building a product based on guidance from us – we technically deliver “guidance.” The asterisk is the important part – let’s unpack it a little bit.
As product managers, our most important deliverable is a product that manifests our product strategy.
You can visualize product management as a spiral or a cycle or a loop, or someone playing hopscotch on today’s hot canvas. You can even still imagine product managers unearthing requirements and throwing them over a wall. Those are all views of the process – how we go through the motions. But what about the type of thinking, and the kind of work we do – can that be visualized?
Imagine a bow tie. On the left is a large mass of ideas, which get synthesized and compressed down into a “product strategy” that is the knot. From that knot issues forth to the right, and expanding set of customers and markets, themes and stories; guidance for why the product should become what it should become.
A product manager will spend half her time pulling from the market, distilling and developing insights to create a product strategy. She will spend the other half of her time developing the plan* – a thematic roadmap, a go-to-market strategy, user stories and acceptance criteria. [* Feel free to say “chartering a mission” in your head if “plan” is a hot-button word for you.] Every team, product manager, and product is a little bit different – each product manager may spend different proportions of her time developing the plan vs. applying the plan.
Three Key Ways to Apply the Plan
There are probably many powerful ways to affect your product through the application of product strategy. Three of them jump out at me as providing clarity that can immediately improve your product.
1. The Focus Filter
One of many great quotes from Rich Mironov is this – “Development can never build as fast as we can dream up new things.”
There’s a lesson from agile development teams, around backlog grooming, that product managers need to ignore. Prioritizing your backlog based on value (or relative value, or proportional value) is really good within a sprint. It is also really good within a release* – as long as the release is thematically organized. But without focus, doing the “most valuable things” can make your product less valuable for your customers.
Here’s how – stick with me. You have to believe – as I do – that Rich’s quote is essentially a law of physics. Therefore, you have more good ideas than the team can do. This is the justification for prioritizing the “best ideas” first. That way, you maximize the value you realize. The problem is, you’ve done the thing customer A believes is most valuable to him, the thing customer B believes is most valuable to her, and the thing customer C believes is the most valuable to her. You didn’t deliver anything sufficiently valuable for any of your customers. Because you lack focus.
In my example, by not making decisions within the context of a product strategy, you have made unaligned investment decisions. Your strategy could have been (should have been) to deliver the minimum viable product for customer A. Which requires you to deliver the three most important things to customer A. Instead of doing that, you delivered one desired capability while squandering the timeliness of your team’s efforts on two things of little interest to customer A. You go to market with a product that is inadequate for every customer – instead of the MVP for customer A.
Here’s another example of the same effect. Your team identifies a bunch of really potentially valuable capabilities. Some of those capabilities resonate with your current customers (and prospects in the same market). Some of those capabilities would be fantastic for expanding your product line into an adjacent market (imagine expanding from health care providers to health care payers). Your product strategy will specify that you are focusing on either gaining market share in your current market (same problem, same market); gaining share of waller with existing customers (new problem, same customers within same market); expanding into adjacencies (roughly same problem, different market). If you pick the “most valuable” things to do, you will be spreading your efforts across each market – and not maximizing your potential ability to execute.
Your product strategy provides you with a filtering mechanism to drive focus – only consider those investments that solve the selected problems for the target customers in the target markets, in a given time frame.
2. The Alignment Angle
The classic challenge of getting teams to work together, and all running in the same direction, is so pervasive and broadly acknowledged as to feel like another law of physics. Getting teams aligned is part of what product managers do. Leading without authority is often stated – and often stated without explaining what that means. Part of leading is getting people to do what you need them to do. Part of leading is inspiring people to do their best – and to want to do their best. Part of leading is getting people to want to do what they don’t independently want to do.
Different stakeholders who have different objectives, will bring different priorities to the table. Driving a shared understanding and embracing of the product strategy is a way to get people aligned and focused on shared goals. A stakeholder needs to see why their particular pet project (ahem, priority) is happening third, or fifteenth, or never.
This example is a little bit of a cheat – because a well-created product strategy will already have incorporated the inputs of the stakeholders, who will have already reached an understanding and acceptance of the strategy. Effectively infusing their agreement into the strategy as it takes shape. Technically you are using product strategy – by leveraging the product strategy creation process – to drive alignment.
Chronologically and procedurally, getting alignment with key stakeholders happens during the formulation of the strategy. That’s the angle.
3. The Tick-able Traceability
Product managers are trained to ask “why?” It may be frustrating for new product managers, reading articles online, because they always reference the “ask why” advice, or refer to the five why’s without explaining this idea. Because people who’ve been doing product management well for a long time have already committed it to muscle memory. Imagine trying to describe how to catch a ball to someone over the telephone. How tempted are you to say “like this – watch!” Writing about how to ask “why?” is like teaching catch over the phone.
You can imagine a dialog with a stakeholder. “I need a high-entropy-validating password entry field.” “Why?” “To prevent users from entering easily guessable passwords.” “Why enter passwords at all?” “To assure that the user is who we think they are.” “Why do you need this assurance?” “Because reasons.”
Now think about all of the things that product managers ask people to do, ostensibly in service of the “product strategy.” As you winnow out the unaligned initiatives and investments, and motivate and inspire a multi-disciplinary team, there’s still a key step remaining. Yes, everyone is working on building out the capabilities to help customer A solve problems X and Y. And nothing else.
But how do we know that reducing the size of the what’s-it flange by 20% is important? You can ask “why?” “Flange-reduction is integral to what’s-it costs meeting our profitability targets? Great. Go on about it.” “Flange-reduction would help us sell to custom B, who is needs tiny flanges – but we’re focusing on customer A. Stop.”
This is essentially traceability.
Traceability is the opposite of decomposition, and is key to assessing the correctness of requirements. Given a set of strategic goals (or capabilities to be delivered), what are all the things that need to be done? This is decomposition. Top-down. It’s part of validating requirements. It gives you a method for asking – “am I missing anything?”
Traceability works in the opposite direction. Given a set of things you’re doing – are they all required to achieve your product strategy? Anything you’re doing that isn’t in support of the strategy begs the question – “Can I stop doing this?”
Product strategy most certainly is devising an approach to product that is designed to succeed in the market. Product strategy is also the tool by which you assure that everyone on your team is focused on the right activities that help realize the strategy of solving specific problems for specific customers, strategically.