For the question that comes before the build question
Product Discovery
Most expensive product failures were never a build problem. They were a validation problem nobody paid attention to before the build started. This practice tests the idea against real users first, and delivers requirements and a recommendation before anyone commits budget to writing code.
How a go or no-go recommendation gets built
User research, requirements and the honest answer before a build starts.
90 secSample frame · video pending01Before skipping straight to a build
Discovery earns its cost when the answer is genuinely unknown.
Not every idea needs formal discovery, and skipping it when the answer is already clear wastes time. Four questions settle whether this stage is worth commissioning.
Has anyone actually talked to a real user yet?
If the idea rests entirely on internal assumptions, discovery earns its cost quickly by testing those assumptions against reality.
How much budget is about to be committed?
A small, reversible build tolerates skipping formal discovery. A large commitment justifies the smaller upfront cost of validating it first.
Do stakeholders already disagree about the direction?
Internal disagreement is often a sign that evidence, not more debate, is what will actually settle the question.
Is this a genuinely new problem, or a known one?
A well-understood problem with proven solutions elsewhere may not need fresh discovery. A genuinely novel one usually does.
| Skip discovery | Commission discovery | |
|---|---|---|
| Best when | The problem and users are already well understood | The idea rests on unvalidated assumptions |
| Risk carried | A build based on assumption | Time spent before any code is written |
| Typical buyer | A known, proven problem space | A genuinely new or disputed direction |
| Natural next step | Straight to MVP development | MVP development, once validated |
02Agreed before research starts
The ledger that keeps discovery honest
Discovery engagements go wrong when a predetermined answer gets dressed up as research. This ledger fixes what you bring, what we test, what comes back, and what stays under your decision.
- Your side
You bring
- The idea and the problem it is meant to solve
- Access to the people who would be real users
- Any budget or timeline constraints already in play
- Our side
We build
- User research against the actual problem, not the proposed solution
- Requirements definition based on what research actually surfaces
- A go or no-go recommendation with the reasoning behind it
- Your side
You receive
- A written recommendation, including a no-go answer where honest
- Validated requirements ready to hand to a build, if warranted
- Research findings your team can revisit later
Never leaves you
- The final decision on whether to proceed
- The product vision and every commercial decision around it
- The relationship with every person interviewed during research
Where the line sitsDiscovery answers whether to build and what, not how fast to build it. A confident no-go is as valuable an outcome as a validated yes.
03From an untested idea to a clear answer
Four stages, each closing on evidence
Discovery that produces only opinions has failed. This system closes each stage with something written down that a build decision can actually rest on.
Define the problem before the solution
Research starts from the actual problem users have, deliberately separated from whatever solution has already been assumed inside the organisation.
The real problem, not the proposed solutionTest assumptions with real users
Assumptions are tested directly with the people who would actually use the product, not with internal stakeholders standing in for them.
Real users, not internal proxiesDefine requirements from the findings
Requirements are written from what research actually surfaced, not from the original pitch, which research sometimes contradicts.
Requirements grounded in what was foundDeliver a go or no-go recommendation
The recommendation states plainly whether to proceed, including a no-go answer when the evidence does not support building.
An honest recommendation either way
04What actually moves the number
Four drivers, priced from the question
Discovery work is priced against the scope of the question being answered, because these four factors change effort by multiples.
Number of user segments to research
One clear user segment costs less to research thoroughly than several segments with potentially different needs.
How contested the direction already is
Resolving genuine internal disagreement often needs more rigorous, defensible research than confirming a direction few people doubt.
Access to real users for research
Easy access to willing users speeds research considerably. Recruiting a hard-to-reach user segment adds real time.
Depth of requirements definition needed
A recommendation alone costs less than a recommendation paired with detailed requirements ready to hand straight to a build team.
05Evidence and proof
Recommendations that held up once real users showed up.
Discovery proof is a recommendation that matched what actually happened after it was made. Every record here waits for written client approval before production.
Explore case studiesA confident no-go saved a year of engineering nobody needed to spend.
Aster North was ready to fund a new product line internally. Research with real prospective users found the actual demand was far smaller than assumed, and the budget was redirected before a build began.
- Engineering spend avoided
- Estimated one year
- Discovery duration
- Three weeks
Research settled a year-long internal disagreement in three weeks.
Pillar Learning's leadership had disagreed for a year about which feature to prioritise. Structured user research gave a clear, evidence-backed answer both camps accepted.
- Internal disagreement duration resolved
- One year, in three weeks
- Stakeholders aligned on the outcome
- Full leadership team
The recommendation was a no, and it was the most useful outcome we could have gotten at that stage.
Sample · pending client approval
06Read this first
When discovery is the wrong first step
Commissioning formal discovery for a well-understood problem delays a build that could have started already. The exits are marked plainly, so budget goes toward validation only where it is genuinely needed.
- MVP development
The problem and users are already well understood
If real user evidence already exists and the direction is not disputed, move straight to building a first version instead.
- Application development
The requirements are already validated and clear
When discovery has already happened elsewhere and requirements are solid, a scoped application build is the faster next step.
- Hire Product Designers
You need researchers on staff, not a one-off engagement
If ongoing product research is the actual need, hiring a designer or researcher into your team fits better than a discrete engagement.
| Shape | Best when | You direct | We carry |
|---|---|---|---|
| Focused discovery | One decision needs validating | What happens with the findings | Research and the recommendation |
| Discovery to MVP | Validation should feed straight into a build | Product direction throughout | Research, requirements and the first build |
| Embedded researcher | Discovery needs to become an ongoing capability | Research priorities | Named researcher and continuity |
07Straight answers
Asked before a build decision is made.
01What's included in a product discovery engagement?
User research, problem validation, requirements definition and a written go or no-go recommendation, all produced before any engineering work begins.
02How is this different from MVP development?
Discovery answers whether to build and what, based on user research. MVP development answers how small a first version can be to test the validated idea in the real world.
03What happens after discovery, do we automatically move to a build?
No, the recommendation may be a no-go. Where discovery validates the idea, requirements hand off directly to MVP development or a scoped application build.
04Can discovery settle an internal disagreement about direction?
Yes, that is one of the more common reasons clients commission it. Evidence from real users tends to resolve disagreement faster than more internal debate.
05What does product discovery cost?
Priced against the number of user segments, how contested the direction already is, and how much requirements definition follows. A focused question costs less than a multi-segment study.
06How long does a discovery engagement take?
A focused engagement typically runs two to four weeks, scoped against user access and the number of assumptions that need testing.
07Will you tell us if the idea should not be built?
Yes, and that answer is treated as a genuine success outcome here, not a failed engagement. A confident no-go can save far more than it costs.
08Do you also design and build the product once discovery validates it?
Yes, when needed. UI/UX design, MVP development and this practice share the same delivery discipline, so validated requirements do not require a separate vendor.