Product Strategy and Discovery: decide what to build before you build it
We work out who the product is for, test the concept with those people and with whoever buys for them, and scope a first release whose job is to prove one claim right or wrong.
In brief
Product Strategy and Discovery decides what to build before building starts. Roadmaps go wrong when they record stakeholder opinions instead of evidence about the people who will use the product, so we learn from those people, frame the problem, test a concept, and scope a first release with the measures that will judge it.
On this page
Does this build need discovery first?
Discovery fits when
- The roadmap is a list of requests and nobody can say which user the first release serves
- The product changes how people do paid work
- The buyer and the user are different people with different tests of value
- You can reach users and whoever controls their budget
Go straight to building when
- The category is established and its users have already written down what they need
- Whether to enter this market at all is still open. That is Product Innovation, and it comes first
- Nobody who would use the product can be reached or recruited
You give up calendar time before any code exists, and the attention of the sponsor and product owner, who sit in the research and do not read a summary of it. You gain the right to refuse a feature with the reason on record.
What is the first release for?
The first release tests one claim: that a particular person will do a particular piece of work with your product instead of the way they do it now. It is not a small copy of the finished product. Everything that does not serve the claim goes into the scope as a named omission with the reason beside it, and the omissions are read out at kickoff, so a missing feature is a decision and not a surprise in the tenth week.
Before building starts the product owner signs what the release must show in its first full cycle of real use, and what would count as the claim failing. Without the second, a weak result is always read as a case for more features.
The stages, and what exists at the end of each
- 01
Frame
Sponsor and product owner write down who the product is for and what problem they have. Ends as a claims sheet.
- 02
Watch and ask
We interview users and buyers and watch the work the product would change. Ends as a research record.
- 03
Test the concept
Sketches and prototypes go to users and buyers before engineering starts. Ends as a log of what each test changed.
- 04
Cut
Product owner, engineering lead and we cut the list down to the release. Ends as the scope, its omissions and its measures.
- 05
Hand to build
Open questions are ranked with the evidence that would settle each, and the engineers get a walkthrough.
Which evidence from buyers counts?
Users are generous in interviews and easy to please with a prototype, so we rank what we hear by what it cost the person to say it. We test with the buyer as well as the user, since the person who approves the purchase applies a different test from the person who logs in daily. A security questionnaire can change the product as much as a usability finding, and costs far less to hear before the build.
| What the person did | What it tells you | What we do with it |
|---|---|---|
| Said they would use it | Politeness, mostly | Ask for something that costs them |
| Described today's workaround unprompted | The problem exists | Map it; the product has to beat it |
| Gave time, data or an introduction | Real interest | Count it and record who gave it |
| Brought in the budget holder | A route to purchase exists | Test the approval path with that person |
A pattern we are called into
A wish list from every venue
A hospitality group has funding for a guest app. The sponsor's list came from the chief executive, marketing and the venue managers: loyalty points, table booking, ordering from the table, a gift card wallet. Nobody has watched a guest or a floor manager do any of it today.
- Frame. The claim: regulars will book directly if it takes less effort than the aggregator they use now.
- Watch. We sit in venues during service and interview regulars, managers and the finance lead who reconciles gift cards.
- Test. In a booking prototype, managers object to how deposits work. Regulars skip the loyalty screen.
- Cut. The release becomes direct booking with deposits. The rest become open questions.
Where it endsThe build starts with one claim, a measure for the first full cycle of use, and a list of features the sponsor agreed to leave out.
What do you own when discovery ends?
The research record, prototype files, claims sheet, scope with its omissions, measures and ranked questions are yours, held in your systems. Engineers can read the reason behind each cut without us in the room.
Questions buyers ask
Can we skip discovery and go straight to building?
Yes, and some teams should. If you already hold strong evidence from users, we say so and shorten the work to what is still uncertain. The risk of skipping is paying for the build to learn what earlier conversations would have shown.
How do you find users to talk to?
We start with the people you can introduce: customers, prospects and colleagues who do the work. Where you have no access, we recruit with you, and the record tells you which findings rest on a narrow group of people.
Can the same team build the product afterward?
Yes, through Digital Product Engineering or AI Product Development, scoped separately. Discovery stays separate so its findings are written before anyone knows who will build.
Related
Is your first release based on what users do?
Describe what you are weighing in a few lines. A senior practitioner replies with a suggested first conversation.