What discovery is actually for
Discovery is not a ritual and not a sales device. It exists to establish whether the thing a client wants to build is the thing they need.
Clients arrive with a solution, not a problem. “We need a new website.” “We need an app.” Occasionally they are right. More often the stated solution is a proxy for something they have not yet named, and two weeks of work will surface it.
What we actually do in two weeks#
Six to ten interviews, weighted toward the people who handle exceptions: support, operations, the sales engineer who answers the awkward questions. A review of analytics and the support queue, which usually contains the answer already. A technical audit of what exists, including what it costs to run.
Then we write down the problem in one paragraph and circulate it. If the people we interviewed recognise their situation in that paragraph, the rest of the project is comparatively straightforward.
The output is a decision, not a document#
A discovery sprint ends with a prioritised scope, effort ranges, and an explicit statement of what we recommend not doing. That last part is where the value is. A client who arrives asking for thirty-one features and leaves with a costed plan for four has saved more money than any efficiency we could find later in delivery.
When it is a waste of money#
If the decision is already made and the budget already committed, discovery becomes theatre. If the problem is genuinely well understood, which happens perhaps one time in five, we say so and go straight to design.
We charge a fixed fee for it, and the deliverable is written so it can be taken to another studio. That is deliberate. A discovery report that only works if you hire us is a sales document, not analysis.
