Discovery Theatre Is Costing You the Build

Most discovery phases end with a deck nobody builds from.\n\nThat's not cynicism — it's a pattern. A studio or internal team runs three weeks of stakeholder interviews, produces a 40-slide Figma prototype and a requirements document the length of a lease, and then hands it over for estimation. The estimate comes back too high, scope gets cut in a hurry, and the thing that gets built barely resembles the document that preceded it. Everybody was busy. Nobody made a decision.\n\nThat's discovery theatre. And it's more common in B2B product builds than most operators realise until they've paid for it once.\n\n## What Discovery Is Actually For\n\nA discovery phase has one job: produce a scope that a developer can price, a founder can defend, and a user can test. Everything else — the journey maps, the empathy exercises, the seventeen-slide synthesis decks — is scaffolding. Useful scaffolding, sometimes. But scaffolding that should come down before the build starts.\n\nThe test is blunt: at the end of your discovery phase, can you answer these four questions without reopening a slide?\n\n1. What does the system do in the first release?\n2. What does it explicitly not do?\n3. Who signs off on each acceptance criterion?\n4. What does success look like in the first 90 days?\n\nIf a discovery phase can't answer those four things, it didn't finish. It just stopped.\n\n## The Rituals That Eat the Budget\n\nDiscovery theatre has a recognisable shape. It usually involves one or more of the following:\n\nWorkshops that observe but don't decide. Running a session with six stakeholders to map the current state is reasonable. Running three more to map the future state, then another to align on priorities, then a retrospective on the alignment session — that's process inflation. Workshops should end with a written decision, not a photo of sticky notes.\n\nWireframes mistaken for scope. A wireframe shows what something might look like. It does not tell a developer how data moves, what the edge cases are, or what happens when a user does the wrong thing. Spending four weeks on high-fidelity Figma screens before the data model is settled is usually backwards. The screens feel like progress; they're actually debt.\n\nRequirements written for compliance, not construction. You've seen these documents. Every requirement starts with "The system shall…" and is written in the passive voice by someone who has never written an acceptance criterion. They exist so the project has documentation, not so the developer knows what to build. A well-written software development brief looks nothing like this — it names the user, the action, the outcome and the edge case.\n\nRounds of review that produce no changes. If stakeholders review a document or prototype and the only output is "looks good, a few minor comments", either the document was already right (in which case, why the review round?) or nobody actually read it. Useful review produces specific, actionable feedback with a named owner. Anything else is a sign-off ritual, not a decision.\n\n## Why Studios Let This Happen\n\nIt's worth being honest about the incentives. Discovery theatre is partly a client problem and partly a studio problem.\n\nSome studios — not all, but some — run long discoveries because it's billable time that doesn't require them to commit to anything. A six-week discovery at day rates is revenue with no delivery risk. The brief that comes out the other end can always be framed as "phase one", with the implication that more discovery might be needed before the build starts.\n\nSome clients create theatre because they're not ready to make decisions and discovery feels like a safe place to delay. Running another workshop is easier than telling your CFO what the system is going to cost.\n\nThe result is a mutual performance. Everyone's in the room, everyone's contributing, and nothing is getting built.\n\nTo avoid this, ask any prospective studio one direct question: what should your discovery phase actually deliver? If the answer is a list of artefacts — personas, journey maps, prototype — push harder. The answer should be a decision-ready scope.\n\n## What a Lean Discovery Looks Like\n\nA tight discovery phase for a B2B ops tool — a partner portal, an internal workflow system, an integration layer between two platforms — does not need to take six weeks. Three to four weeks is usually enough if the sessions are run to produce decisions, not documents.\n\nThe structure that tends to work:\n\nWeek one: current-state audit. One or two sessions with the people who actually do the work today. Not to map their feelings about the process — to understand exactly what they do, what breaks, and what they've bodged together with spreadsheets and email. The output is a list of pain points ranked by operational frequency, not emotional weight.\n\nWeek two: scope negotiation. Take the top pain points and work out which ones the first release should solve. This is where a good studio earns its keep — distinguishing between problems a piece of software can fix in three months and problems that will take a year and a redesign of your team's processes. The output is a prioritised feature list with explicit exclusions.\n\nWeek three: acceptance criteria and data model. For each feature in scope, write the acceptance criteria before anyone opens a design tool. What does "done" mean for this feature? What are the failure cases? Who approves it? Simultaneously, sketch the data model — not in a database tool, but on a whiteboard or in a shared doc. If you can't describe how data moves through the system, you can't build it.\n\nWeek four (if needed): architecture decision and estimation. With a data model and acceptance criteria in hand, a developer can give you a real estimate. Not a ballpark, not a range from £20k to £200k — an actual number with assumptions attached. If the estimate blows the budget, you now have enough information to make a cut without destroying the logic of the system.\n\nThis is also where buildable acceptance criteria matter most. Vague criteria produce padded estimates; specific criteria produce honest ones.\n\n## The AI Angle — Useful, Not Magic\n\nAI-assisted tooling can compress some of this, but only the parts that are already well-defined. Where it genuinely helps in discovery:\n\n- Drafting acceptance criteria from rough notes, which a product manager then edits rather than writes from scratch.\n- Identifying contradictions in a requirements document (does requirement 14 contradict requirement 27? An LLM will catch this faster than a human reading the same doc for the fourth time).\n- Generating edge cases for a given feature that a team might miss in a workshop.\n\nWhat it doesn't fix: a client who hasn't decided what they're building, or a studio that isn't asking the right questions. AI can produce a very polished set of user stories for a scope that was never actually agreed. That's theatre with better grammar.\n\nThe studios using AI to shorten build cycles are doing it by applying it to execution — generating boilerplate, scaffolding integrations, accelerating QA — not by using it to substitute for the human decisions that discovery is supposed to produce.\n\n## How to Tell a Studio's Discovery from Its Theatre\n\nBefore you sign a discovery contract, ask for examples of scopes that came out of their previous discovery phases. Not the decks. The scope documents. Look for:\n\n- Features described as user stories with clear acceptance criteria, not system capabilities in the abstract.\n- An explicit list of what's out of scope for the first release, with reasons.\n- A data model, even a rough one.\n- An estimate with stated assumptions.\n\nIf the studio can't show you examples like this, their discovery phase is producing artefacts, not decisions. That's worth knowing before you pay for it.\n\nFor a more detailed framework on evaluating development studios, the questions that matter most are the ones about what they hand over at the end of discovery — not how many workshops they run during it.\n\n## One More Cut Worth Making\n\nIf your discovery phase is running long and you're not sure why, look at the meeting-to-decision ratio. Count the number of sessions you've had. Count the number of written, agreed decisions that came out of them. If the ratio is worse than roughly one decision per session, you're probably in theatre.\n\nThe fix isn't always to fire the studio. Sometimes it's to change how you're showing up as a client. Come to each session with a written position, not an open mind. Make the decision in the room, not in a follow-up email thread three days later. Sign off on things that are good enough rather than waiting for perfect.\n\nDiscovery theatre is a two-actor play. You can walk off the stage.