I’ve written before how product strategy is nothing arcane only masters understand, but is in fact quite simple. It revolves around a structured set of answers to the questions of “Where are we? Where do we want to be? How do we get there?”
While I expounded there on how to set it and what’s the difference between a plan and a strategy (and why declaring a strategy is simple, but the devil’s in execution), and even gave some generally applicable tips, I thought I’d detail here a more concrete example of how to go about it.
Now, before we lose our heads about frameworks and formats that must be followed, please bear in mind that this represents my idealised version. I’ve done variations over the years and learned what worked and what didn’t, and like most things in product management it is context dependent. So the below represents how I aim to approach building a strategy for the next product or portfolio I manage, but I’ve been around the block enough times to know that this too is a plan — and reality will likely punch me in the face and force me to adapt it 🤪
What is a product strategy
As a quick recap, a strategy is the answer to the three questions above.
Where are we is all that market and user research, the data analytics, the distinctive capabilities of your company, etc.
Where we need to be is the vision, the long-term result you are striving towards.
As for how to get there, it comes in two parts: a set of principles and a set of steps.
So you need to immerse yourself in the product and its market space (duh), formulate an idea of the potential it could achieve in the long term, and then construct a set of possible next steps and a set of principles to aid decision making.
Let’s delve into the steps and how-to it takes to build this up.
How to build a product strategy
I’ll skip the immersion in the product space bits, even though it’s absolutely critical. You can’t create a strategy based on a product vision without a deep grasp of the people and the problems they are facing. So I’ll assume you speak with users regularly, follow industry pundits, have the data from instrumentation — all the things you know you should be doing (and probably know you could be doing better; just keep at it). It’s these repeated conversations that sink in to your subconscious and lead developing to product sense and the ability to identify problems and potential general solutions.
Vision statements
Visions tend to emerge from that immersion and reflection. If you’re in a startup, the founders likely have it in their heads (or in the pitch deck to investors). In a bigger corp, there will be more people up and across the chain that will have ideas. In all cases, it will be up to you to distill it and write it down, and then socialise that vision.
Sometimes it’s easier to come up with the long-term vision first. This is what the product could be in 10 years, if we fully realise all the potential. Sometimes it’s easier to start with a shorter time-frame (this year we’ll focus on that segment), and then extrapolate to the longer term.
But the important idea is that you need both the long term idea of what it could be and the short term vision of where you want to end up as the next step.
I like creative writing, so I like to write my visions as a narrative from the user’s perspective. It’s a visceral description of how their world looks like when the problem — the job to be done — has been solved, without getting to hung up on the details of the solutions.
Another way way could be a short, “explainer” animated video. If you have a graphic designer that’s great, but even if you DIY it no matter how amateurish it feels it will still do a good job of conveying that vision internally. Again, focus on the user and how their world looks like with the problem solved by your offering.
Mission vs Vision: I often see these used interchangeably (or mistaking a mission statement for a vision), but to me there’s a difference. Mission is the reason why we’re getting up in the morning, the change in the world we want to create. Vision is a detailed description of the world once the problem is solved, our main solution to deliver on the mission.
For example, if our mission is to “empower all healthcare providers to provide easy, affordable service” there could be many ways we could go about solving it. Our vision details the life of the provider when they have a SaaS platform to manage the tedious tasks, giving them more time to focus on the patient. We could have addressed our mission in a completely different way, but this is the path (not an individual solution, but an approach) we’ve chosen.
Pre-Mortem
Now that you got all excited it’s time for an ice bucket 🥶 Our cognitive biases tend to lead us to be overly optimistic about positive outcomes and discount negative ones. We rationalise to ourselves how things will go well, and that will make us not prepared for when they inevitably go wrong. It’s only by facing the brutal truth that we can make better judgement calls.
A good format of a premorten is Shreyas Doshi’s zoo analogy: what are the tigers - the obvious threats you need to address; the snakes - lurking and hidden but will come back bite you if you ignore them; and the elephants - the things no one is talking about but can crush you.
Another good option is assumption mapping (you can do both!). Anything that lets you, your team, and stakeholders dig in and identify what risks are there that if they materialise might derail your vision.
Invite everyone, and use a format that makes it safe and encourages people to point out anything and everything that could go wrong. List them out, so you can prepare.
Principles
These are guides and guardrails, to aid making quick decisions in the field. Things like “API-first”, or “Smooth user experience over optionality”. These principles keep the team focused not just on what they are trying to solve right now, but also on preserving a long-term approach.
For example, on a desktop product I once worked the rule was to keep document processing under 1 second. It allowed us to beat and stay ahead of the slower competitors for a long while. It guided the solutions and choices we made throughout the life of the product, and it was always easy to know when we’re getting off track and need to stop and improve things rather than tack on new features.
The principles should be phrased in short and memorable phrases. Either direct (API-first) or a this-over-that (like in the Agile manifesto). Depending on your market, you’ll find certain principles are almost universally expected - eg data security, or user privacy. It’s still worth listing them out with the others, to help remind yourself and the team that these are a bedrock of the solution.
Steps
This is where we’re approaching road-map land, but in a big picture way. Our long-term vision will likely have far more potential complexity than the fledgling product we have in our hands right now. We make certain broad decisions about prioritisation. Eg, this year we’ll focus our Sally the Sailor’s persona as we build our shipping solution, rather than Alice the Accountant’s needs. Or, we’ll focus on the Australian market, and only expand internationally later.
If you’ve done a pre-mortem, you can add the riskiest assumptions to test early, and have a list of options on preventing or mitigating some of the dangerous animals you might encounter.
It’s a perfect place to put those Now/Next/Later maps into good use. You can show case what you’re working on right now, what you think you’ll work on next, and all sort of possible items for the future you can discuss to gauge interest. These steps aren’t plans or delivery dates. They are a realisation that under current understanding, we’d need to build the Salesforce integration before adding Analytics dashboards will make any sense. It might change, but right now these are the stepping stones across the river to get us to where we’re aiming for (the vision).
While the principles tend to be fairly stable for a long time, the steps can change in response to shifting market demands.
How to deploy a strategy for use
It’s as simple as writing it down and telling everybody…
First, write down the above in clear sections. It could be one main document, a set of wiki pages, or whatever you use for collaboration of semi-stable content. Writing it out long-form will help you clarify your own thinking around it.
Then you need to tell people in your company about it. This is far from a once-and-done effort, but something you’ll do ad nauseam. And then some more. It’s why product management is at once the most exhilarating and frustrating profession. Exhilarating, because you spend three months dreaming up this bright future. Frustrating, because you’ll then spend three years explaining it to people over and over again.
At least you’ll get a chance to vary yourself. CEOs want a different version than the engineering team, and customers consume information different to investors. Having that long-form content in one place will help you top keep adapting it to your audience, testing various metaphors and formats to see how your messages land best. Just don’t forget to listen as much as you talk about it — others will spot areas you fluffed or missed entirely. That’s why a product strategy is a continually evolving thing, not a static picture. You need to know what’s the value you’re delivering to whom and what’s your best guess as to how to go about it, but be flexible enough to change the how without damaging the long-term why.
Hope this helps! This isn’t in any way a “prescriptive framework”, just the way I would approach building a strategy in order to help me make sense and communicate it later. It helps me think through the next few years of a product: forwards to where it could be when fully realised, and then backwards to how to get there. Having this knowledge written and reviewed helps communicate every aspect as needed at a moment’s notice, without losing my head.
I’d love to know what you think!