Product Strategy and Planning
What we've learned so far
Planning is what stops you spending a quarter on the wrong thing. Its value is not the document, it is the order: which decision gets made first, what each release is meant to prove, and what the business will know afterwards that it does not know now. Done well it removes the single largest cost in product work, which is building something defensible that nobody needed.
Roadmaps fail less often on the answer than on the sequence. We have been handed plans where every item was reasonable and the order guaranteed nothing would be learned until the expensive part was finished. Our position is that the first release exists to remove the largest uncertainty, whether that is technical, commercial or about whether anyone wants it, and that is a different question from which feature is most requested. The other thing worth stating plainly is that a plan is only as good as its access to reality. Built from opinion it is a wish. Built from the numbers, the support queue and a conversation with whoever owns the revenue, it is a decision.
The economics have shifted. When a build takes weeks rather than quarters, being wrong about scope is cheap and being wrong about direction is not, so effort has moved away from estimating and towards deciding what to stop doing. Models will generate a roadmap in seconds and it will read plausibly, which is exactly the risk. Plausible plans are now free. Correct ones still require someone who understands your market, your constraints and what your team can actually absorb.
What this can involve
Fractional Product Leadership
Roadmap Support
Value Proposition Development
Channel Strategy
Positioning and Pricing
Product Launch Strategy
Go-to-Market Consulting
Validation and Experiment Design
KPI Framework Design
OKR Consulting
Backlog Definition
Release Planning
Feature Prioritisation
Product Roadmap Consulting
Concept Definition
Business Case Development
Opportunity Assessment
Product Strategy Consulting
Product Discovery
Stakeholder Interviews
Design Sprints
Service Blueprint Design
Messaging and Tone of Voice
Brand Positioning
How we work
Get to the numbers and the people
Analytics, the support queue, the sales pipeline and whoever owns the revenue. A plan built from opinion is a wish. Built from these, it is a decision.
Name the uncertainties honestly
What the business does not yet know: whether anyone wants it, whether it can be built at a sensible cost, whether it can be sold at the price assumed. Most roadmaps quietly skip this and then discover the answer late.
Sequence releases to remove the biggest one first
Each release exists to settle a question, and the first should settle the largest. That is frequently not the most requested feature, and saying so is part of the work.
Decide what to stop
Every plan is also a list of things not being done. Naming them explicitly is what stops the roadmap quietly expanding back to everything.
Set what would change the plan
The signals that would mean the sequence was wrong, agreed in advance. A roadmap nobody is willing to revise is a commitment rather than a strategy.
Where this isn't the right fit
If the decision is already made and what you need is the document that justifies it, a model will produce something plausible in seconds and it will cost you nothing. Plausible plans are now free. We are only worth paying for where the answer is genuinely open.
If nobody can give us access to the numbers, the support queue or the person accountable for revenue, we will be planning from the same assumptions you already have. And if the organisation cannot say no to anything, sequencing will not survive contact with the first stakeholder who objects. That is a different problem and it is worth solving before this one.
