Weekly newsletter

Templates and how-tos to help you fulfil your potential

How to write a great product strategy

What is a product strategy

A product strategy explains what your product teams will focus on, and why. Teams never have a shortage of ideas of what they should be building. Assessed on its own merits, each idea might make sense to work on, but some will offer better returns than others. Product teams are always resource constrained at some level however, so you don’t want to waste effort on areas with low returns when you could spend that effort on areas that will deliver much higher returns.

Progress is inversely proportional to the number of priorities we have

A strategy provides a rationale for concentrating on some things at the expense of others. This allows you to make as much progress as possible where it will be most effective, without having to assess everything individually. Think of this as applying pressure to something – the same force applied over a smaller surface area generates a higher pressure.

Strategy must result in action to be effective

The test of a strategy is whether it results in high impact work in line with the declared areas of focus. Without connecting the thinking about what to work on with actual action, strategy is just navel-gazing and a waste of time.

Here’s a dummy strategy deck to get you started. Here are some worked examples from leadership interviews.

Strategy stack

Because a product strategy is only as good as the work it results in, the connection between the strategy and day-to-day work of the teams needs to be very clear. Let’s define a few terms, and then see how they fit together.

  • Mission – The change in the world we want to create. Why are we here? Why is our work important?
  • Vision – An inspiring description of what we think the world looks like in the future as a result of our work
  • Strategy – The pillars, or areas of focus for us to deliver the vision and why they are the right ones to focus on
  • Opportunities – A theme of work for a team that contributes to a strategic pillar
  • Features – Shippable pieces of work that exploit an opportunity
  • Goals – How we measure progress towards our vision and the success of our strategy, opportunities and features
  • Roadmap – A visual description of what the team plans to work on over time
Product strategy stack
Strategy stack links teams day-to-day work with mission and vision

If multiple squads are working on the same product, then each squad’s strategy stack resembles a zoomed in view of the overall product strategy. Each squad will inherit a lot of its strategy from the overall product strategy, and at the same time, the overall product strategy is just the aggregation of every squad’s strategy. There should be two-way feedback, so squads adapt their strategy as the product strategy shifts to exploit new macro opportunities and the product strategy adapts as squads generate new insights from working on their piece of the puzzle.

Squad strategy is the same structure as the overall product strategy, and component of it

How to develop a strategy

There are eight steps to creating a really effective product strategy. For squads, the process is slightly simpler, as the powers, growth engine and staffing will be tackled at the overall product level.

Eight steps to developing and implementing a product strategy

In both cases, as with product development itself, this is not a purely linear process. You will find that as you get to the later steps, you need to double back and update the earlier ones. This fits naturally with the fact that creating a strategy is a continuous process, not a once-and-done task. However much research you do, there will always be uncertainty. Whenever you ship things, you will generate fresh insights that should feed back into the next iteration of the strategy.

For these reasons, it’s worth generating a strawman strategy (a draft designed for criticism and feedback) as fast as possible, and then updating this as you progress and gather more insights. A strawman makes it easier to get feedback from others and focuses where to conduct research first. Try developing a strawman in a day, aiming to validate the main assumptions in a couple of weeks, and then continually updating your strategy based on ongoing discovery.

Example 2 week plan for creating a working strategy

As you can see, creating a strategy has three main activities:

  1. Analysis to generate insights
  2. Interviews and meetings to challenge our thinking and create buy in
  3. Consolidating strategy into a coherent narrative


In order to justify focusing on a small number of things, you’ll need to make a compelling argument based on a broad range of insights. Think about collecting insights from as broad a range of sources as possible:

  • Funnel analysis – understanding the core journeys users go through and where they drop off
  • Behavioural metrics – how users engage with and use the product
  • User research – what users tell you about the product and the problems you are trying to solve with it
  • Customer service touch points – what customers talk about when they reach out for help
  • Sales and marketing touch points – what teams with direct interactions with users understand about them
  • Competitor insights – how other products are positioning the benefits they offer and delivering on these

A broader range of insights will give you a richer understanding of the problem space to make sure you don’t have blind spots.

Interviews and meetings

As you do this analysis, it’s a good idea to share your thinking with as many people as possible. By exposing your thinking early, you can invite challenge from others and make sure your reasoning is as tight as possible. It’s also important to do this, so that you take people along with you. If people around you don’t buy into the strategy, then it won’t result in the focused action that you are looking for and your efforts will be for nothing. Think about speaking regularly with:

  • Leadership
  • Stakeholders from other disciplines
  • Your team
  • Peers working in both related and unrelated areas

Consolidating strategy

As you bring together more data, you should be able to spot emerging themes, and synthesise everything together into a coherent narrative. The trick here is to include as much analysis as you need to convince people that the strategy is the right one, without anything extra that would dilute the message. You don’t want to bore people with 100 slides if they are convinced in 5.

Be hypothesis driven
Have a hypothesis about what the strategy should be from the start, and then try to build a case for this, and see if any evidence contradicts it. It will save you huge amounts of time, and often your initial view will be 80% correct

Proactively tackle difficult stakeholders
Senior stakeholders that don’t buy into your strategy will derail it sooner or later. Work out who is most likely to do this, and if possible co-create the strategy with them to make sure they are on your side early.

Hunt down the killer slides
Great strategies often have 2-3 slides that are instantly memorable and define how people view the problem. Lean heavily on these to create soundbites that people will refer back to

Verify surprising results
If you find something really surprising, double check it. 9 times out of 10 it will be a problem with tracking or data definition. Knowing you can rely on your numbers gives you credibility for the remaining 1 time in 10 that you uncover something genuinely unexpected.

Ok, let’s run through each of the steps in a bit more detail.


Everything starts with the mission. This is the reason the business exists, its purpose, the why. It is also the most durable element of the strategy stack. While the objectives and tasks might vary on a quarterly basis, the strategy might change annually, and the vision every 2-3 years, a mission is likely to endure 10 years or more and provide an anchor to why the product exists for that whole time.

Having a clear motivation behind what you are doing is important because it inspires people. Those working in the tech industry are highly skilled and have lots of options so having a reason behind why they come into work every day makes a big difference in being able to recruit and retain the best talent. Some examples of missions are:

  • Shopify – Arm the rebels; make it easier to start, run, and grow a business
  • Tesla – Accelerate the world’s transition to sustainable energy
  • Stripe – Increase the GDP of the internet
  • Slack – Make work life simpler, more pleasant, and more productive
  • Google – Organise the world’s information and make it universally accessible and useful
  • Etsy – Keep human connection at the heart of commerce

Where do missions come from? Usually they are deeply ingrained in a company’s culture, stemming from the original motivation the founders had to start the company or from a widely recognised need in the world. If it’s not clear what your mission is, then talk it through with the company leadership to reach a consensus. Because missions are so qualitative, this is often an emotional rather than data-driven process.

Some squads like to have missions as well, though this isn’t always necessary. What is important is that the squad understands why its work is important and can connect this directly back to the product’s overall mission. For example, a growth squad might have a mission as simple as “connect as many people as possible to the product”. If you believe that the overall product mission is important, and the product is helping address that mission, then allowing more people to use the product follows naturally as a good thing.


The vision is the description of the future you are trying to build. This might be a short paragraph that explains what the product looks like in 3-5 years, a few mock ups that highlight key benefits users get, or a clickable prototype that people can play around with. The goal isn’t to define exactly what the product will look like but to inspire teams with a general direction of travel.

Having a vision saves huge amounts of time and effort in aligning everyone around what they are meant to be doing, because anyone can ask: “Does this fit with the vision?”. Whilst a mission provides an answer to why we come into work, a vision answers what we are trying to build.

Overall, product visions are usually owned by the product and design leadership and are created as they start to develop a sense of where they think the product might be in 3-5 years. This doesn’t mean they should develop it without input from anyone else though. As with other parts of the strategy, the vision should reflect the best insights and feedback from across the entire organisation. Each squad’s vision will be a more detailed view of what they think their part of the product will look like. The overall product vision is therefore like the greatest hits of every squad’s individual visions.

It’s worth mentioning that it’s not uncommon for the vision to come before the mission or after the users and needs are identified. Don’t worry about the order too much – start where it feels easiest, get something down, and come back and iterate as necessary.

Asana vision
SpaceX vision

Users and needs

A coherent product strategy relies on a clear definition of the target audience. All too often businesses find it difficult to align on opportunities and goals because senior stakeholders are focused on fundamentally different users, such as sales targeting enterprise customers, while marketing are going after small businesses. It’s impossible to create a good product strategy unless you are aligned on who your target users are and therefore who you are not targeting.

Users should always be defined by the needs they have. This gives you a clear direction on how you are going to generate value for the user; by addressing those needs. When thinking about this, always ask why users have this need once or twice more than you would normally. This follows the Jobs To Be Done (JTBD) framework – a user doesn’t “want” a nail in the wall, they “want” to hang their pictures or decorate their house. The Job To Be Done is decorating the house, not putting holes in the wall. Thinking this way uncovers fundamental needs that are stable over time and allows you to think of more radical solutions to users’ problems. It will also give you a better understanding of the benefits that you’re trying to create for users and how to frame the solutions you build for them.

Example user needs

A great way to map out user needs and the challenges they face is by creating a customer journey map. This allows you to plot the stages the user goes through as they complete their Jobs To Be Done. Often, these steps will correspond to screens on your website or in your app. For each stage, you can add insights from qualitative research and behavioural metrics to understand what the user needs are at this point. This helps you visualise where your users are getting stuck and where it’s worth focusing your efforts to make their lives easier. If this resonates with your team, you can also add competitor references, your vision, CRM touchpoints with the user, and the tech stack supporting this step of the experience.

Once you’ve defined the user needs, some organisations like to bring these alive with personas – descriptions of what a typical user might look like. This can be valuable as long as the needs are recognised as primary to the personas. Otherwise you run the risk of defining your users by demographics like age, gender, and location, which doesn’t provide you with a lot of insight into what you are trying to build and draws you into using unhelpful stereotypes.

What are our sources of power?

Having established what your user needs are, you need to have a view on how your company is uniquely positioned to solve this problem. Without this, the product you are providing can be easily copied by competitors, commoditising the market and destroying your margins. This is tackled at the product level and doesn’t need to be considered by PMs working on their squad’s strategy, though of course they should be aware of it and work within that context.

Create value at the intersection of what users want and what we can uniquely offer
We create value at the intersection of what users want and what we can uniquely offer

What makes it hard for companies to compete with you? Hamilton Helmer’s book, “7 Powers,” outlines seven hard-to-copy advantages.

  1. Network effects – Each user enjoys more value as new users join the network
  2. Scale economies – Unit costs decline as volume increases
  3. Switching costs – Switching to an alternate product would be costly or painful for users
  4. Counter positioning – Where a new product’s business model or value proposition cannot easily be copied by incumbents as it would damage their existing business
  5. Cornered resource – Unique access to a valuable asset
  6. Branding – An objectively identical offering has higher perceived value
  7. Process Power – Embedded company culture and process which enable lower costs and/or superior quality

It’s very difficult to pick a couple of the seven powers and then build a product to create these without considering user needs first. But if your solution to a customer’s needs doesn’t generate 2-3 of these powers then that’s a warning sign that your business will have difficulty maintaining its margins long term. This is one of the key aspects of any business that investors try to understand because it has such an important impact on the long term profitability of a company and therefore its value. So, if you’re presenting at board level, it’s even more important to reference the powers you are developing if you want to seem credible.

Examples of different types of power


With a clear vision and understanding of where you will create value for users, you’re in a good position to pick your strategic pillars. These are the 2-4 themes of work that will solve your users’ needs, deliver on the vision, and grow your sources of power. This is the heart of where you will focus, betting that by concentrating your resources in these pillars you can deliver a world class experience that users love and will pay for.

This can also be thought of as the value proposition: what are the key benefits that you want to deliver to users? There should be tight alignment between the marketing messages that you use to attract new users and the value your product teams are working to create.

The flip side to this focus is that you will limit your efforts in other areas, so you can devote as much time to what really matters. This can often be a contentious decision, as stakeholders realise that topics they thought would be given time and resources aren’t actually core to delivering the vision. It’s worth spending as much time here as necessary to get everyone aligned to ensure that the strategy isn’t derailed later on in execution.

Growth strategy

If you’re developing an overall product strategy, you’ll want to think about your growth strategy at this point, and how this complements the strategic pillars that you’ve chosen. Squads should obviously know what the product’s growth strategy is but shouldn’t have their own growth strategy independently.

While strategic pillars describe how you’ll increase the value you generate for each user, your growth strategy informs how you’ll get the product in front of as many users as possible. These are two different types of work, each with different goals, and it’s worth making an explicit decision about how to allocate resources between them. Developing a growth strategy is a huge topic in its own right, so this is just a reminder that growth needs to appear somewhere in your overall product strategy.

At a high level, there are four categories of growth:

  1. Performance – paid ads, TV, etc.
  2. Content – SEO, newsletters, blogs
  3. Virality – word of mouth, referrals
  4. Sales – inbound and outbound sales

Every product will be suited to some of these more than others, so the idea is not to try and cover everything but to focus on the categories that will be most effective for you. Once you’ve done that, you can scope out the amount of support that non-product teams will need to be effective and how you will work together.

CompanyGrowth strategy
UberVirality + Performance marketing
ZoomVirality + Sales
AirbnbVirality + Performance marketing
EventbriteContent + Virality


Once you have defined your strategic pillars and your growth strategy, you have a good idea of what you want to work on. To turn this into action, you now need to allocate people to do each piece of work that needs to be done.

This is a step that mostly applies at the overall product level. While squads should have an idea of what they could get done with more or fewer people, staffing is a question of resource allocation; it’s an investment decision and should be done at the product level. Individual squads will always be incentivised to ask for more resources and so a central decision maker needs to cap costs overall and allocate headcount to squads based on their importance to the overall product strategy.

A good sense check is that it should be obvious that each of the pillars has sufficient people assigned to it to make a real difference. You can’t make progress where you don’t have teams, and if it’s not clear how your teams are related to your strategic pillars, you run the risk that all the thinking up to this point is wasted.

How this looks at different organisations also depends on their size. A startup with just a few engineers might rotate between different pillars of work on a fairly fluid basis. A mid-sized scale up might have a single team for each pillar. A large organisation might have a whole tribe for each pillar.


Now that you have a strategy and teams allocated against it, all you need to do is execute it. Easy, right?! In practice, this means having two elements in place:

  1. Squads set up for success
  2. Product operating model to accelerate squads

Squad setup

To set teams up for success, they will need a clear sense of what they are meant to be doing and why. Ideally this is documented in a Squad Overview that is easy for stakeholders and new joiners to get up to speed on. Having this written down makes it really clear that everyone has the same expectations for what the squad will work on. This might include:

Squad nameHow you refer to this squad. Usually doubles as a shorthand for their objective, otherwise things get confusing
Squad membersWho is in the squad, and what are the roles they are playing
StakeholdersKey stakeholders that the squad works with, e.g. leadership, other functions, other product teams, specialists
ObjectiveA qualitative description of what the squad is trying to achieve
GoalA quantified target for the squad in the format: Move [metric] from [baseline] to [target] by [date]
StrategyLinks to the key insights the squad has, what they will focus on, and why. It’s useful to map out opportunities here as an opportunity solution tree
Backlog / roadmapA prioritised set of initiatives that the squad will work on, which can be displayed visually for stakeholders external to the squad.
Release historyA list of things the squad has release in the past, linking to their PRDs

Product operating model

A product operating model is the rhythm of working that helps squads translate strategy into value for users and the business. Usually this is a cadence of lightweight product check ins and documentation that concentrates the best thinking from around the organisation, and keeps everyone aligned. To ensure the squads are delivering effectively, it’s useful to address two sides of development:

  • Product reviews – check in on strategy and discovery
  • Delivery reviews – ensure delivery is proceeding as fast as possible

Product reviews

These meetings make sure the squad is working on the right things and that risk is being systematically removed as early as possible. Typically these are led by the PM and include stakeholders external to the squad. As always, these meetings should accelerate the squad by exposing their thinking to challenge while making sure they have cross-functional support for what they are doing. The highest quality discussions mirror the development cycle, with feedback focused at one of four stages:

  1. Kick off – do we know what problem we are trying to solve? Are we agreed on scope?
  2. Solution definition – do we know what the solution is?
  3. Launch readiness – is the feature set up for success when it goes live?
  4. Impact review – what have we learned as the feature has gone live?

Delivery reviews

Delivery reviews ensure that squads are running smoothly and have the support they need to ship high quality features quickly. Ideally these check-ins should be kept to an absolute minimum number of people, e.g. VP Product / VP Eng / PM / Tech Lead. This allows the group to discuss sensitive topics in a collaborative, non-confrontational way. These check-ins can be facilitated by burndown metrics or a breakdown of the work the squad has been doing, but it’s always the conversation that is most important. The PM and Tech Lead on a squad should be able to ask for support in an environment of psychological safety.

Communicating progress against the strategy

With the squads set up to deliver on the strategy, it’s worth considering how the organisation will be kept up to date with progress. Stakeholders generally want input and transparency from product teams. If you’ve created the strategy collaboratively with them then they should feel they have had input. You can work out how to give them transparency by considering:

  • Audience – Who are you trying to update?
  • Content – What level of detail do they need?
  • Format – How are you going to deliver the content?

What this translates to in practice will vary hugely on the scale of the business, but as a starting point consider:

Quarterly strategy updateAn update where you outline the progress you made last quarter and plans for the coming quarter. This could be an All Hands
Product trackerA public dashboard updated weekly with key initiatives that teams are working on, along with their expected delivery dates
Release notesAn email detailing what has been shipped and why, as it goes live
Example product tracker


A good product strategy, whether for an entire product or an individual squad, explains where you will focus and why. Based on robust research from different perspectives, it results in focused action which maximises the impact product teams have. Fundamentally, a strategy is a communication tool to guide people on where they work and helps you say “no” to inbound requests that are low value. Co-creating it with the teams that will be delivering it, and leadership stakeholders, positions them as champions of the strategy alongside yourself. This maximises your chances of the strategy delivering the results you want it to.


Further reading


Can vision come before mission?

Absolutely. Don’t worry about the order too much; strategy is a continuous process anyway. What is important is that everyone understands both why our work is important and what you are trying to achieve.

What’s the difference between vision and mission?

The mission describes why the work we do is important. It explains our motivation for coming to work. The vision is a description of the future we want to build. It gives us direction and allows multiple teams to build towards a coherent product long term.

What about projects that don’t fall under the strategic pillars?

Projects that don’t support the strategic pillars should be avoided or done with the least effort possible. By definition they offer lower returns than working on our core strategy. If stakeholders are still pushing for projects outside the pillars, this is a good indication that they have not fully bought into the strategy.

How do we know if our powers are strong enough?

You should be able to find references of other companies that have built a successful, durable business with similar advantages to you. Another good indicator is advice from experienced, independent people such as investors, board members, or industry experts. If they are not convinced, then you may have a problem.

No nonsense advice

Proven guides, templates and case studies for product managers into your inbox each week