A practical starting point
Twelve questions before you commission a product build.
You do not need a formal specification. Use these questions to separate the real problem from assumptions and turn an early idea into a useful first conversation.
01
Start with the problem
Describe the situation before describing the software.
- What happens today, from the first trigger to the finished work?
- Who feels the problem most directly, and what do they do instead?
- Why is this worth changing now rather than six months from now?
02
Find the evidence
Use real examples rather than an idealised process.
- Which recent cases show the problem clearly?
- What would improve if the product worked, and how could you tell?
- What must never happen because the cost of a wrong result is too high?
03
Define the first useful release
The first version needs a job, not an exhaustive feature list.
- What is the smallest complete outcome that would be useful to someone?
- Which systems, data or permissions must it work with?
- Where should a person review, approve or override the software?
04
Make delivery possible
Good product work still needs ownership and constraints.
- Who can answer questions and make priority decisions during the build?
- Are there deadlines, policies, budgets or technical constraints already in place?
- Who will own, support and improve the product after the first release?
How to use it
Write a few honest lines for each question. Leave gaps where you do not know the answer. Those gaps are often exactly what product discovery should investigate not something to hide behind confident language.
Talk to us
Ready to turn the answers into a first scope?
Send us what you know. We can help test the assumptions, identify the risky parts and decide what is worth building first.