Product discovery and scoping
The most expensive decisions on a software project are made in the first three weeks, usually by people who don't yet know enough to make them. Discovery is a short, deliberate engagement that replaces those guesses with a plan you can budget against.
Quotes for a thing nobody has defined
Ask three agencies to price an undefined idea and you get three unrelated numbers, because each has silently assumed a different product. You then pick one — often the cheapest — and spend the build discovering what was left out. The scope grows, the relationship sours, and both sides are convinced the other moved the goalposts.
You’ll recognise this if
- You have quotes that differ by more than a factor of two
- You can describe the idea but not what version one contains
- Requirements arrive as a feature list with no ordering
- You need a number for a board or an investor and are guessing
What we actually deliver
A defined version one
An explicit list of what is in the first release and, just as importantly, what is deliberately not. The second list is what protects the budget once building starts.
A technical architecture
The shape of the system, the major components, the third parties it depends on, and the decisions that would be expensive to reverse later. Enough for any competent team to build from.
A costed, sequenced roadmap
Phases with effort and cost against each, ordered so something usable exists early rather than everything landing at the end.
The risk register
The handful of things that could genuinely derail this — an integration that may not permit what you need, a data source that may not exist, a regulatory question nobody has asked. Named early, while they are still cheap.
The way we approach it
Understand the work, not the wish list
We spend time with the people whose job this software will change. A feature list describes what someone wants; watching the work shows what the product actually has to do.
Prototype the contentious parts
Where a screen or a flow is being argued about, we make it clickable. Ten minutes with a prototype settles debates that survive weeks of documents.
Prove the risky integration now
If the project depends on a system nobody has connected to yet, we make a real call to it during discovery. Finding out that the API cannot do what you assumed is a discovery finding, not a build crisis.
What changes
- A version one you can describe in a sentence and defend in a meeting
- A cost estimate grounded in a defined scope rather than a guess
- The expensive unknowns identified while they are still cheap to handle
- A document any capable team could build from, ours or not
Asked often enough to answer here
How long does discovery take?
One to three weeks for most projects. Longer than that usually means the scope is too broad and should be split, and we would rather tell you that than bill for a longer study.
Do we have to build with you afterwards?
No. The roadmap is written to be handed to anyone — your own team, another agency, whoever offers you the best price on a now clearly-defined scope. Plenty of clients do continue with us, but nothing in the engagement is structured to trap you.
We already have a spec. Do we still need this?
Maybe not. Send it over and we will tell you honestly whether it is buildable as written. Sometimes it is and we go straight to a quote; more often there are two or three unanswered questions worth a short focused engagement rather than a full one.
Related
Wherever you’re starting from, let’s figure out the next step.
Tell us what you’re building — we’ll tell you honestly whether we’re the right team for it.