Product Strategy
A prioritised direction your whole team can act on — not a deck that gathers dust.
Strategy is only useful if it leads to a decision someone can act on next Monday. We run structured discovery to understand what your users actually need and what your business can realistically build, then synthesise that into a prioritised roadmap with explicit trade-offs — not an optimistic wishlist. The output is a written plan your engineering team, your stakeholders and your investors can all read and align on.
Because we also build products, our strategy work is grounded in what is actually shippable. We will tell you when an idea requires a capability your current team does not have, when a third-party tool is genuinely better than building it, and when the technically elegant solution is the wrong business decision. The goal is a direction that saves money, not one that justifies a larger build.
What this covers
Product discovery: user interviews, competitive analysis and jobs-to-be-done synthesis
Opportunity mapping: problem prioritisation by user pain, business value and technical feasibility
Roadmap development: sequenced, effort-weighted with explicit dependencies and trade-offs
Build-vs-buy analysis for key capabilities with documented reasoning
Technical strategy: architecture recommendations, technology selection and scalability considerations
Success metrics and OKR framework aligned to business outcomes, not output metrics
Stakeholder workshop facilitation to surface disagreements before they become expensive
Deliverables
- A written product roadmap with priorities, sequencing, effort estimates and open trade-offs
- A discovery research summary covering key user insights and validated hypotheses
- A technical strategy document and a follow-up session to pressure-test the assumptions
- A metrics framework with definitions, data sources and targets agreed across stakeholders
What we build with
Product strategy
Product strategy is the discipline of deciding what not to build. It answers the question that a backlog and a sprint process cannot answer on their own: which of the many things we could build will most reliably move the outcome that matters, for the users who matter, in the sequence that our team can actually execute?
A useful strategy document is not a prioritised feature list. It is a reasoned argument: here is the user behaviour we observed, here is the opportunity it implies, here is the sequence of bets we are making, here is the assumption each bet rests on, and here is the signal that will tell us whether the bet paid off. That argument forces clarity before engineering begins and gives the team a decision framework that survives the first contact with reality.
How we approach product strategy
These principles govern how we run discovery, structure a roadmap and define success. They are not aspirational — each one reflects a specific failure mode we have observed in real products.
Start with the job, not the feature
Users do not want features; they want to make progress on something that matters to them. Jobs-to-be-done framing forces the question: what is the user trying to accomplish, and why is the current solution failing them? An insight framed as a job (users need to close their books before a board meeting and cannot trust the numbers they have) is more useful than one framed as a feature request, because it leaves the design space open and identifies the real success criterion.
Make the opportunity-solution tree explicit
Opportunities (user needs with no good current solution) are distinct from solutions (specific product responses to those opportunities). Mixing the two in a backlog produces a roadmap where teams debate implementations rather than needs. We structure discovery as a tree: one north-star outcome at the root, a layer of product areas beneath it, specific user opportunities at the next level, and candidate solutions as leaves. Prioritisation happens at the opportunity level, not the solution level — which means the solution can change as evidence comes in without the strategy changing.
Define the north-star metric before writing a single user story
A north-star metric is the single number that best represents the value the product delivers to users and correlates with sustainable business growth. Defining it before design begins forces clarity on what the product is actually for. It also surfaces internal misalignments early: if one stakeholder thinks success is daily active users and another thinks it is revenue per user, that disagreement needs to be resolved in a workshop, not discovered when the quarterly review produces contradictory conclusions.
Sequence by risk, not by enthusiasm
The first items on a roadmap should be the ones that resolve the largest risks to the strategy, not the ones that are most exciting or most visible to customers. Time-to-first-value — how quickly a new user reaches the moment where the product delivers on its core promise — is almost always both the most impactful and the most neglected metric. We sequence roadmaps to reduce the highest-risk assumptions first and to get real users to the value moment before investing in expansion.
Write down the trade-offs, not just the decisions
A roadmap document that only records what was decided is useful for about a month. One that records what was considered and explicitly rejected — and why — is useful every time a stakeholder raises the same idea six months later, or every time an engineer asks why something was built the way it was. We document trade-offs as first-class citizens of the strategy output, not as verbal context that lives only in the memory of the person who was in the room.
How we'd choose
There's rarely one right answer — these are the trade-offs we weigh before recommending an approach.
Capability: Build vs Buy vs Partner
The build-vs-buy decision is made badly when it is made on instinct. These criteria apply to any capability the product needs — authentication, notifications, search, billing, analytics, AI inference — and make the reasoning explicit enough to revisit when the context changes.
| Criterion | Build | Buy (SaaS / off-the-shelf) | Partner (integration / white-label) |
|---|---|---|---|
| Differentiation value | High — this capability is a core part of the value proposition users pay for, and doing it better than alternatives is a strategic advantage | Low — this is table-stakes infrastructure (auth, email delivery, billing) where differentiation adds no user value | Medium — a partner's capability covers the requirement adequately and the integration surface is narrow enough to maintain |
| Time to deliver | Slowest — building requires design, engineering, testing and ongoing maintenance at full internal cost | Fastest — SaaS tools are live in hours to days; configuration replaces engineering | Moderate — integration work is faster than a build but slower than pure SaaS adoption; quality depends on the partner API |
| Total cost of ownership (3-year horizon) | High upfront, potentially lower at scale — but maintenance, security updates and technical debt are ongoing internal costs that are routinely underestimated | Predictable SaaS cost that scales with usage; avoid vendor lock-in by ensuring data portability before signing | Partner fee plus integration maintenance; renegotiation risk at contract renewal |
| Data control and compliance | Full control — data stays in your infrastructure, audit logs are yours, compliance posture is internally owned | Data lives with the vendor; acceptable for most use cases but must be evaluated against GDPR, SOC 2 or sector-specific requirements | Shared data model; review data processing agreements before committing — partner breach is your breach in the eyes of a regulator |
| When to choose this path | When the capability is core to your differentiation, your team has the expertise to build it well, and you have the runway to absorb the lead time without losing the market window | The default for non-differentiating capabilities — auth, transactional email, billing, observability. The engineering time saved almost always outweighs the SaaS cost at early and mid-stage scale | When a partner already has the distribution, the data, or the regulatory approval that would take years to acquire independently — and the commercial terms protect your ability to exit |
Anti-patterns we actively prevent
These are the failure modes that convert a strategy process into a document that nobody reads after the kickoff presentation.
Roadmap as a commitment list, not a hypothesis list
Teams present roadmaps to stakeholders as promises: feature X will ship in Q3, feature Y in Q4. When user feedback, technical reality or market conditions change, updating the roadmap feels like breaking a commitment. The rational response — freezing the roadmap and building the wrong things rather than have a difficult conversation — compounds into a product that no longer fits the user it was designed for.
Roadmaps are structured as hypotheses with explicit confidence levels and stated assumptions. Each item records the user problem it addresses, the bet being made about the solution, and the signal that will confirm or refute the bet. Stakeholders are aligned on the problem and the prioritisation logic, not on a delivery date for a specific feature. When evidence changes, updating the roadmap is updating a hypothesis, not breaking a promise.
Output metrics mistaken for outcome metrics
Teams measure velocity (story points, features shipped, pull requests merged) and report those numbers as evidence of progress. Output metrics are easy to move and easy to optimise without delivering any user value — a team can ship twenty features in a quarter and have zero improvement in retention, task-completion rate or time-to-first-value. Leadership sees green dashboards; users see a cluttered product with no improvement in the thing they actually care about.
Define outcome metrics before the roadmap is written: retention at day 30, task-completion rate on the primary flow, time-to-first-value for new users, and the north-star metric the product is optimising for. Output metrics (story points, features) are internal efficiency signals for the team, not evidence of value for the business. Every roadmap item should be traceable to the outcome metric it is intended to move.
Discovery as a one-time event at project start
A research sprint is run at the beginning of the project, findings are presented in a document, and the product is designed and built against those findings for the next six months with no further user contact. By the time the product ships, the findings are six months old, the competitive landscape has shifted, and the assumptions baked into the roadmap have not been validated against real user behaviour in production.
Continuous discovery is a recurring practice, not a phase. Automated in-product feedback mechanisms, bi-weekly user interviews during active development, and post-launch usability testing feed directly into the prioritisation queue. The opportunity-solution tree is a living document that is updated as evidence arrives, not a snapshot of what was believed at kickoff.
Common questions
We already have a product — can strategy help us decide what to build next?
That is the most common use case. We look at your usage data, talk to your users and work through your backlog with you to separate the things that will meaningfully move retention or revenue from the things that feel urgent but are not. The output is a prioritised next six months your team can commit to.
Is this just a discovery phase before a build, or can it be a standalone engagement?
Either. Strategy and discovery work well as a standalone engagement that ends with a plan you take to any engineering team — including ours. Many clients run a strategy phase first to validate direction before committing to an engineering budget.
Related capabilities
Have something in mind?
Tell us what you're building or stuck on. The first consultation is free — no obligation, no hard sell.