Scaffold · Guides

How to build a product strategy: 6 steps and 8 real examples

Start from where the company is heading, then build two things: an honest picture of where your product stands (customers, competitors, industry trends) and a vision of where it should go. The strategy is how you link them: a short set of principles that say what you will and will not do. Present it before any roadmap.

By Cyril Le Roux · Updated 30 September 2026 · 11 min read

Disclosure: Produxity builds Scaffold, which appears below as a worked example. The guide stands without it.

It is Thursday, and the week has gone the way most weeks go. A customer issue took Monday. Sales needed a feature explained for a deal. The CEO forwarded an idea from a conference. You shipped, you fixed, you answered, and the strategy document you meant to write is where it was on Monday: a heading and a few bullet points.

If you are the only product manager on a small team, this is the normal shape of the job. You decide what gets built, you have to defend it, and you spend fifty hours a week doing everything except the thinking that would make those decisions easier to defend.

Why the strategy is always the thing that slips

Tactical work drowns strategy because it feels like progress. Tactical decisions are easy, and fixing a customer's problem makes you the hero. Meanwhile nobody is minding the strategy, and the cost arrives later, usually when you present the roadmap.

Stakeholders who are not aligned on a strategy ask for what suits them now. Sales wants what closes accounts before the period ends. Customer service wants the fixes that cut its costs. Marketing wants something worth a campaign. Each request is reasonable; together they are death by a thousand cuts. You become a feature factory worker, your line manager steps in with less knowledge of the domain than you have, and you end up delivering a strategy you do not believe in.

There is a second reason, less often said. Many product managers are not sure what a product strategy is. Popular books show what a good strategy looks like, often as a canvas to fill in, without explaining how you arrive at one. The canvas is the destination's photograph, not the route.

Strategy is a trip

Before any trip you need two things: where you are, and where you want to go. How you link the two is the strategy.

Where you are is domain knowledge. Knowing your own product inside out is necessary and not enough: you need to be the subject matter expert on the domain, which means your competitors' strategies, the economics of your industry, and an intimate understanding of your customers and their pains. That expertise takes years, which is one reason it pays to specialise in an industry and stay there.

Where you are going is the vision. In a company with several products, it cascades from the company's vision rather than appearing on its own. A good vision is one you can picture. Microsoft's early ambition, in paraphrase, was a computer on every desk and in every home: you could imagine that world at once. Be as clear about how your product makes its users' world better.

The strategy is the set of principles you follow at every decision point. The roadmap is those principles applied to particular circumstances. The roadmap can change without the strategy changing.

Good principles say what you will not do. On a trip, "get there first at any cost" and "keep the carbon footprint low" are both reasonable principles, and they cannot both win. Choosing one is the strategy. A principle that never rules anything out is a slogan.

Six steps, in order

  1. 01Understand the strategy you inheritBefore writing anything, learn the company's vision and strategy, and whatever product strategy already exists. Accept that it may be light. As the first product manager this is a handover that takes time, longer if the domain is new to you, so do not rush it.
  2. 02Establish where you areBecome the subject matter expert on your domain, not just your product: your customers and their pains, your competitors' strategies, and the trends shaping your industry. Knowing your own product well is necessary and not enough.
  3. 03Choose where you are goingWrite a product vision that cascades from the company's vision and that people can picture. Be clear how the product makes its users' world better.
  4. 04Link the two with principlesThe strategy is how you get from where you are to where you are going: a short set of principles you will follow at every decision point. Good principles rule things out.
  5. 05Test the principles on real requestsTake the last month of requests and run them through the principles. If nothing is filtered out, the principles are too vague to be a strategy.
  6. 06Present the strategy before any roadmapEvery time you show the roadmap, show the vision and strategy first. If the roadmap is challenged because the strategy is, stop and agree the strategy. Then turn "no" into "not right away".

1. Understand the strategy you inherit

Your first job is not to write a strategy but to understand the one that exists: the company's vision, what leadership believes the business is for, and why the product looks the way it does. Accept that it may be light. If you are the first product manager, this is a handover with nobody to hand over, so it takes time, and longer again if the domain is new to you. Take it gradually. A strategy written in your first month is written without the knowledge it needs.

2. Establish where you are

Three kinds of evidence, in an order that works:

3. Choose where you are going

Write the product vision down, check that it cascades from the company's, and read it aloud to someone outside the team. If they cannot picture the world it describes, it is not finished. If it could describe any product in your category, it is not yours.

4. Link the two with principles

Now the strategy itself: a short list of principles that get you from where you are to where you are going. It helps to see some that worked. Here are eight well-known patterns, each with a company that used it. Notice that none of the strategies names a feature. Each one decides, at every roadmap review, what comes out.

Scroll across, or use the arrows.

  • 01 / 08Come for the tool, stay for the networkThe problem: A marketplace is only worth joining if the other side is already there. Buyers leave when there is too little to choose from, and sellers leave when there are too few buyers, so supply and demand have to grow at the same rate or one side is let down and walks away.The strategy: Grow one side first, by giving it a tool that is useful on its own, and open the other side once that side reaches critical mass. Chris Dixon gave the pattern its name.Who did it: OpenTable began by installing its Electronic Reservation Book in restaurants, replacing the paper book at the host stand and subsidising the setup to win them. Diners came as the restaurant network grew.At every roadmap review: anything that does not grow the chosen side waits.Chris Dixon, Come for the tool, stay for the networkHarvard Digital Initiative: OpenTable
  • 02 / 08Stack features, do not spread peanut butterThe problem: Spread effort across everything customers ask for and every feature ends up thin: good enough to ship, never good enough to be the reason anyone chooses you.The strategy: Add features that make the ones you already have more valuable, so each release deepens the reason to use the product instead of widening it.Who did it: Apple's Continuity features, such as Handoff and Universal Clipboard, each make a second Apple device more useful, and several are built on Handoff. The opposite has a name. In 2006 Brad Garlinghouse, then a Yahoo senior vice president, described its strategy as spreading peanut butter: "a thin layer of investment spread across everything we do and thus we focus on nothing in particular".At every roadmap review: a feature that does not strengthen the ones you have waits, however easy it is to build.Apple: Continuity features and requirementsAllThingsD: the Peanut Butter Manifesto
  • 03 / 08Win a narrow market firstThe problem: A new product aimed at a whole market is nobody's first choice, and a small team cannot serve everyone well.The strategy: Pick a group small enough to serve exceptionally well, become its obvious choice, then move on to the next group along.Who did it: Facebook was at first only for Harvard students, a potential market of a few thousand people, before it opened to other universities.At every roadmap review: requests from outside the chosen group wait, however attractive the customer.Paul Graham, Do Things that Don't Scale
  • 04 / 08Do things that don't scale, then automate themThe problem: Early on you do not yet know which steps customers value most, and software built on guesses is slow and expensive to unwind.The strategy: Deliver the result by hand for the first customers, then automate only the steps that turn out to repeat. Paul Graham gave the pattern its name.Who did it: Airbnb's founders went door to door in New York, recruiting hosts and helping them improve their listings, long before any of that was part of the product.At every roadmap review: nothing is automated until it has been done by hand often enough to prove it repeats.Paul Graham, Do Things that Don't Scale
  • 05 / 08Win the user, then the organisationThe problem: Selling to a whole organisation up front is slow and expensive, and a small team cannot wait months for each deal.The strategy: Make the product easy for one person or team to adopt and pay for on their own, then grow each account as its value spreads. Atlassian calls it land and expand.Who did it: Atlassian chose a self-serve purchase experience over traditional sales, offers free versions of its products, and grows each customer by adding seats and products over time.Incidentally: this is Scaffold's strategy too. It sets out to win one product manager with their own workbook first, then the organisation, as product books are shared with colleagues and a head of product.At every roadmap review: anything that needs a sales conversation before someone gets value waits.Atlassian: how growth levers help your business go the distance
  • 06 / 08Serve the people nobody serves yetThe problem: Many people who need a result are nobody's customer, because the existing tools cost too much, need an expert or take too long to learn.The strategy: Remove whatever stops them, and compete with doing nothing rather than with the incumbents. Clayton Christensen called this competing with nonconsumption.Who did it: Canva's mission is to "empower everyone in the world to design anything and publish anywhere": everyone, not only designers.At every roadmap review: features that only an expert would miss wait.Canva: aboutChristensen Institute: disruptive innovation
  • 07 / 08Make every use show the product to someone newThe problem: A small team cannot outspend anyone on marketing, so it needs a way to be seen that costs nothing extra.The strategy: Design the core use of the product so that using it introduces it to the next customer.Who did it: Every email sent from Hotmail ended with "PS: I love you. Get your free email at Hotmail", so each user introduced the service to everyone they wrote to.At every roadmap review: anything that hides the product from the people on the receiving end waits.TechCrunch: PS: I love you. Get your free email at Hotmail
  • 08 / 08Give the tool away, earn from what it enablesThe problem: Charging for a tool slows its adoption, but a free tool on its own does not pay for itself.The strategy: Make the tool free, and earn from a related activity that the tool makes easier.Who did it: Wave gives away invoicing and bookkeeping, and earns a fee when customers take card payments on those invoices, and from paid extras such as payroll.At every roadmap review: a free feature that does not lead towards the paid activity waits.Wave: pricing

Yours will not look like any of these. It comes from where you are and where you are going. But it should pass the same test: if a principle never takes anything off the roadmap, it is a slogan, not a strategy.

5. Test the principles on real requests

Take the last month of requests from sales, customers and the CEO and run each one through the principles. Some will be in, some out. If nothing comes out, the principles are too vague. If everything comes out, either the principles are wrong or the business has been heading somewhere nobody wrote down, and that is a conversation to have with leadership now rather than at the next roadmap review.

6. Present the strategy before any roadmap

Every time you present the roadmap, present the vision and strategy first, so the discussion that follows is about solving the same problem. If the roadmap is challenged because the strategy is, there is no point discussing the roadmap: agree the strategy first. With the strategy accepted, most pushback changes shape. It is no longer "this is a bad idea" but "these other ideas get us to the destination faster". You are not saying no; you are saying not right away.

That also means you will talk about strategy a lot. That is the point. The more you talk about strategy, the better.

Where the time comes from

None of this happens in the gaps between tactical work, because there are no gaps. It happens when you take time back. AI gives you a way to do that. Keep asking of each task: is this a job for me, or something an AI could take care of? Sales enablement material and customer service training are examples that no longer deserve much of a product manager's time. Reinvest what you save in understanding your market, your customers and your competitors, and use AI there too, to move faster.

Two cautions. Never trust an AI completely: good domain knowledge is what lets you spot the claim that does not add up, so check the sources. And an AI can offer strategic options, but you are the one who has to explain the strategy you choose. Convince yourself it is the best option before you present it.

A worked example: the strategy narrative in Scaffold

Scaffold walks product managers through the research and analysis a strong product decision needs, on their own product. Its 48 activities declare what they build on, so each answer feeds the next. For the only product manager, the route through this guide's steps looks like this:

The homepage follows the first two steps for Vintum, a fictional company that rents furnished homes in Lisbon to people on work assignments: Company Foundations built from an uploaded strategy document, then a proposed product vision that the product manager tweaks and adopts.

Two limits, said plainly. Scaffold owns the judgement, never the backlog: the roadmap it ends in goes into whichever tool your team uses for delivery. And it does not choose the strategy for you. You still have to explain it, so you still have to believe it.

When this is not your job

One product manager should not write a separate strategy: the one in a very early startup whose CEO runs the strategy hands-on. There, the job is to execute that strategy faithfully. Everything in step 2 still helps: knowing where you are makes the execution better. But the principles are the CEO's to set.

In short

  1. Understand the strategy you inherit before writing your own, and do not rush it.
  2. Where you are is domain knowledge: customers, competitors' strategies, industry trends.
  3. Where you are going is a vision people can picture, cascading from the company's.
  4. The strategy is the principles that link them, and good principles rule things out.
  5. Present vision and strategy before every roadmap, and say "not right away" instead of no.
  6. Take the time from tactical work, with AI's help, and never adopt a strategy you cannot defend.

Look at the last roadmap you presented. Could you name the principle behind every item on it? If not, that is where to start this week.

Questions product managers ask

What is a product strategy, in plain terms?

A product strategy is how you get your product from where it is today to where you want it to be. Where it is today is your knowledge of the market, the customers and the competitors. Where you want it to be is the vision. The strategy is the set of principles that links the two, followed at every decision point.

What is the difference between a product strategy and a roadmap?

The strategy is the principles; the roadmap is those principles applied to particular circumstances. So the roadmap can change month to month while the strategy holds. If every change of plan feels like a change of strategy, you probably have a plan and no strategy. A useful test: can you explain why an item is on the roadmap without mentioning who asked for it?

Who owns the product strategy: the product manager or leadership?

Both, at different levels. Leadership owns the company strategy and vision; the product manager owns the product strategy that cascades from them. That ownership is earned, not granted: you sell your strategy to leadership, and where the company strategy is thin, yours may be absorbed into it. Being overruled on one roadmap item does not mean you have lost the strategy.

What should a product strategy document contain?

Five things, and one page is often enough: where the product is today (customers, competitors, trends), the vision it is heading for, the principles that link the two, what those principles rule out, and how you will know it is working. Leave the list of features out. That is the roadmap, and it belongs in a separate document that points back to this one.

What is a good example of a product strategy?

A marketplace that needs buyers and sellers at the same time. Supply and demand have to grow at the same rate or one side leaves disappointed, so the strategy grows one side first with a tool useful on its own, and opens the other side at critical mass: come for the tool, stay for the network. OpenTable did it with restaurants before diners. It names no features, but at every roadmap review it filters out anything that does not grow the chosen side. Other well-known patterns include winning a narrow market first, as Facebook did at Harvard, and stacking features that reinforce each other instead of spreading effort thinly, which a Yahoo executive once called spreading peanut butter.

How many goals or themes should a product strategy have?

Few enough that each one rules something out. Aha!'s guide to product strategy suggests three to five goals, and many guides say the same. The number matters less than the test: if a principle never stops you doing anything, it is a slogan. On a trip, "get there first at any cost" and "keep the carbon footprint low" cannot both win.

How long does it take to build a product strategy as the only product manager?

Longer than a sprint, and it should be. The slow part is understanding the strategy you inherit and learning the domain, and neither can be rushed; a product manager new to the industry needs longer again. Drafting the principles is quick once you know where you are and where you are going. Guides that promise a strategy in a week usually skip the first half.

How often should a product strategy be revisited?

Check it at every roadmap review and rewrite it only when where you are has changed: a competitor changes direction, the market shifts, or the company changes its vision. The roadmap should move often; the strategy should not. If you rewrite the strategy every quarter, it was probably a plan.

How do I find time for strategy when I am the only product manager?

Take it from tactical work. Tactical decisions are easy and feel like progress, and fixing customer issues makes you the hero, while nobody minds the strategy. Keep asking of every task: "is this a job for me or something an AI could take care of?" Sales enablement material and customer service training rarely deserve much of your time now.

What should a new product manager do first about strategy?

Understand the strategy that already exists before writing your own. Learn the company vision, what leadership believes, and why the product looks the way it does. As the first product manager this is a handover with nobody to hand over, so it takes a while. Do not rush it: a strategy written in your first month is written without the domain knowledge it needs.

What if leadership's vision cannot be delivered with the resources we have?

Then the gap is in the strategy, not the vision. A strategy starts from where you are, and where you are includes your team, your stack and your capacity. Show leadership the route the resources allow and what it rules out. For a distressed product, that may mean agreeing that up to 40% of capacity goes to technical debt before anything new.

How do I connect the strategy to the roadmap?

Make every roadmap item answer to a principle. At each roadmap review, ask of each item which principle it serves and how strongly; the items that serve it best go first. Grouping work into now, next and later rather than dates helps, because it keeps the roadmap flexible while the strategy stays fixed.

What do I point to when someone pushes back on the roadmap?

The strategy, and you point to it before the roadmap, not after. Present the vision and strategy at the start of every roadmap discussion. If the pushback is really about the strategy, stop discussing the roadmap and agree the strategy first. If it is about an item, the answer is rarely "no" and more often "not right away": other items get us there faster.

If AI makes building features cheap, do we still need a product strategy?

More than before. When engineers build faster, requests arrive faster and more of them get built, so the cost of building the wrong thing moves from engineering time to a product that pulls in several directions at once. Cheap building makes the filter more valuable, not less. "Let us launch and see" is a tactic, and it needs a strategy to say what to launch.

How do I stop being a feature factory worker?

Get a strategy agreed, then make it the thing requests are judged against. Without one, sales asks for what closes this quarter, customer service for what cuts tickets, and marketing for something worth a campaign, and the product suffers death by a thousand cuts. With one, you can say which requests move you towards the destination and which only feel urgent.

How do I know whether the product strategy is working?

Pick a small number of outcome measures that follow from the vision, set a baseline before you start, and review them at every roadmap review. Measure what customers do differently, not what you shipped. If the measures move but the product is not getting closer to the destination you described, the measures are wrong; if they do not move, question the principles before the team.

What inputs does a product strategy need?

Three sets of evidence, and the company's own direction. In our experience a good order is: a value proposition canvas (customers' jobs, pains and gains, and how well the product fits them), then competitor profiles that capture each rival's apparent strategy, then industry trends. Combine them with the company strategy and vision, and you have the ingredients of a product strategy.

What are the most common mistakes when building a product strategy?

Four come up again and again: copying a strategy canvas without doing the work that fills it; confusing the roadmap with the strategy; starting from the vision without an honest picture of where you are; and letting tactical work crowd strategy out until a stakeholder, or your line manager, writes it for you. The last one is the most common.

How do I present and defend a product strategy to the CEO?

Start from the CEO's own strategy and show how yours cascades from it. Then show where the product is, where it is going, and the principles linking them, with the evidence behind each. Only then show the roadmap. If the CEO challenges an item, go back to the principle it serves. The more you talk about strategy, the better.

Where does AI help with product strategy, and where does it not?

It helps most with research: competitor profiles, market signals and data analysis, which tends to be fairly reliable. Never trust it completely: domain knowledge lets you spot what does not add up, so check its sources. And an AI can offer strategic options, but you are the one who has to explain the chosen strategy, so never adopt one you cannot defend yourself.

When should a product manager not write a separate product strategy?

In a very early startup whose CEO runs the strategy hands-on. There, the product manager's job is to execute that strategy faithfully, not to write a competing one. The work in this guide still matters, because understanding where you are makes the execution better, but the principles are the CEO's to set.

How does Scaffold help a product manager build a product strategy?

It works as a sequence of activities on your own product, each building on the ones before: company foundations, then a product vision, research on competitors and the market, and a strategy narrative framed as a trip, which ends in a prioritised roadmap. Scaffold owns the judgement, never the backlog: the roadmap goes into whichever tool your team already uses.