Where Product Strategy Actually Starts
Layla Foord
Most product strategy work starts too late. It begins at the roadmap, inside a set of assumptions that were never properly examined. The harder work sits earlier, at the level of the system the product is trying to move.
Most product strategy work starts too late.
It begins at the roadmap. Someone has already decided what the product is, who it is for, and roughly what needs to be built. The job, at that point, is prioritisation. Which features go first. What gets pushed to the next quarter. What the team can realistically deliver.
That work matters. But it is not strategy.
It is sequencing inside a set of assumptions that were never properly examined.
The real product strategy question is not: what should we build?
It is: what needs to become true for this product to create value that users want, the market understands, the organisation can capture, and the business can actually deliver?
That question sits earlier. Before the roadmap. Before the backlog. Before the prioritisation session.
It sits at the level of the system the product is trying to move.
Products do not succeed because they are well-featured.
They succeed when the product, market, organisation, and commercial model become coherent enough to create sustained value. That coherence is not accidental. It has to be designed. And designing it requires starting in the right place.
Starting at the roadmap is starting in the middle of the problem.
By the time you are choosing between features, the framing is already set. The target segment has been assumed. The commercial model is implied. The delivery constraint is already shaping what feels possible. You are making decisions inside a structure that may itself be the problem.
The harder strategic work happens before any of that.
When I enter a product situation, I start by looking at the system as it actually exists. Not the strategy deck. Not the product roadmap. Not the investor narrative.
The real system.
What are users actually trying to do? Where does the product fail them in practice? What did customers expect, and what did they experience? Where are teams compensating manually for gaps the product has not solved? Where is the commercial model unclear? Where has significant investment already gone? Where is trust being built or quietly lost?
That entry point changes the work.
Because what you find is almost never just a product problem. It is usually a pattern: product, commercial, and organisational assumptions that have drifted out of alignment with what reality is actually showing.
Customer feedback is not automatically strategy. Revenue ambition is not automatically market proof. A roadmap is not automatically a commercial plan.
The discipline is interpretation. What are these signals pointing to, underneath the surface request?
One of the most useful moves in product strategy is distinguishing the visible problem from the structural constraint beneath it.
A product team under pressure to ship more features is often pointing at a symptom. The real problem may be that the core proposition is not yet sharp enough for customers to understand why they should buy. Or that the product is trying to serve too many segments at once and has lost its edge in each of them. Or that the commercial expectations attached to the product are not yet matched by the evidence of market pull.
Responding to the surface request, in those situations, makes things worse. It adds more work to a product that needs clarity, not more capability.
A strong product strategy names the constraint beneath the complaint, and sequences the response to address what actually matters.
Commercial logic belongs inside the product strategy, not after it.
This is where a lot of product strategy falls short. Commercial considerations are treated as a separate layer. Something finance or sales adds later. The product team focuses on users, the commercial team focuses on revenue, and the two are stitched together at the end.
That structure creates strategies that are incoherent by design.
A product strategy is incomplete until it explains how value is created, how it is captured, how it is funded, and how it is sustained. That means asking who pays, who uses, who influences the purchase, what problem is commercially painful enough, what the cost to serve looks like, what evidence is needed to support the proposition, and what has to be true before further investment is justified.
Those questions are not a commercial layer added after the product thinking. They are part of the product thinking.
None of this means abandoning the roadmap.
It means building one from a better starting point. One where the commercial logic is explicit, the target user or market wedge is chosen deliberately, the strategic spine is clear enough to say no as well as yes, and the sequence of work is ordered around reducing the most important risks first.
The roadmap, built from that foundation, carries a different kind of authority. It is not a list of features someone wanted. It is a response to what the product actually needs to become.
I have been building and thinking about this approach for a long time, across products in commercial and mission-led organisations, in situations ranging from early-stage platform creation to turnaround and investor readiness to simplification for scale.
The repeating pattern is the same: products that struggle are almost never struggling because of individual failures. They are struggling because the product, market, organisation, and commercial model have drifted out of coherence with each other. And the fix is not more features or more process. It is strategy that starts earlier and connects those dimensions deliberately.
The work can be approached as a ground-up strategy build, or used selectively when the breakdown is more localised. It moves from entering the system and gathering signals, through naming the real problem and defining the commercial logic, to setting the strategic spine, choosing the first wedge, designing the target product system, sequencing the first-best moves, building the operating container, and creating the learning loops that keep the strategy honest as reality changes.
The operating model exists to serve the product strategy. It is not the strategy itself.
For a closer look at the operating model, read The Operating Model Is the Work.
The shift this produces is not dramatic. It is quiet.
Decisions become clearer because they are being made against something real. The team knows what they are trying to prove, not just what they are trying to build. Commercial confidence grows because the strategy is grounded in evidence, not assumption. Leadership can make better calls because the options are named, not just the default path.
That is what product strategy is supposed to do.
Not generate a roadmap. Generate a clearer decision environment for everyone who has to act inside it.
Starting earlier is what makes that possible.
The Pattern
New essays when there's something worth saying
Not on a schedule. Subscribe and get the next one when it's ready.
