Write the decision before the solution
Describe a particular user, the situation that triggers their problem and their current workaround. “Businesses need an app” is too broad to test. A more useful hypothesis is that a dispatcher cannot spot unassigned jobs before the next dispatch window. Observe the existing process before deciding that a new dashboard is the right intervention.
Discovery should leave room to stop or change direction. GOV.UK’s discovery guidance treats proceeding as a decision based on what has been learned, rather than an automatic next stage. Apply that discipline to your own context without implying government approval of your project.
A concise decision framework
Illustrative planning framework
| Question | Evidence | Next decision |
|---|---|---|
| Is the problem recurring? | Observe recent real examples and workarounds | Investigate or stop |
| Can the proposed change help? | Test a prototype on the critical task | Revise the interaction or proceed |
| Can it operate safely? | Review data, integration and support constraints | Reduce scope or plan an MVP |
| Who can deliver it? | Compare skills, availability and responsibilities | Choose an engagement model |
Keep product culture practical
Name one person accountable for each product decision.
Record assumptions separately from observed facts.
Review evidence and blocked decisions at an agreed cadence.
Make objections testable: identify what would change the decision.
Keep a change log so new requests do not quietly replace the original experiment.
Choose a partnership around responsibility
A fixed-scope supplier needs clear acceptance criteria. A dedicated team needs an accessible product owner and an evolving backlog. An individual contributor needs direction and review within your existing engineering process. Ask who owns architecture, testing, release approval and operations rather than comparing a list of job titles.
Agree repository access, confidentiality, decision rights and an exit plan. Relevant work can support a skills discussion only when its attribution is permitted; a recognizable client logo is not a substitute for evidence.
End with a one-page experiment brief
Summarize the user problem, highest-risk assumption, smallest test, owner, exclusions and a review point. Write continuation and stopping criteria before seeing the result. This creates a useful next step whether you choose research, a prototype, an MVP or no build at all.
Frequently asked questions
When should we choose a development partner?
When the experiment and required responsibilities are clear enough to evaluate fit. A partner can help discovery, but implementation scope should remain a separate decision.
Does a strong team culture guarantee success?
No. It improves how decisions are surfaced and reviewed; demand and feasibility still need evidence.