How to run an honest discovery week

Most software projects that slip do not slip because someone coded slowly. They slip because you started with a list everyone nodded at, and which meant three different products. A forty-page specification can still be that list — just with more words. "The system shall support invoicing" is not a requirement. It is a category. Until you have decided who invoices whom, what happens on failure, and whether it is Stripe, an ERP or a PDF, nobody can honestly say what should be built.

That is why serious agencies ask for discovery before build. It is not a sales trick, and it is not the same as "getting to know you". It is forcing the expensive assumptions into the open while they are still cheap. A week with the right people costs time. A quarter's delay because checkout and roles were never talked through costs a project.

This is also what you need to tell apart when you choose a partner. An agency that promises to start Monday without having seen your data, your users or your "must not happen", is selling you a guess. An agency that will spend five days cutting, and that leaves with something you can say no to, is selling you a scope. The two proposals can look the same on a slide. They are not.

We write this because you should not confuse workshop facilitation with a product. Sticky notes on a whiteboard are a tool. The decision that v1 has no native apps, that admin is one screen, and that you will live with a weekly CSV until the integration is worth building — that is the product of the week.

The classic specification is written to be complete. That is its first failure. Complete means everything is mentioned, so nobody can blame the author for a gap. Estimable means the opposite: what is in is concrete enough to build, and what is out is written down. A complete list is a catalogue. A scope is a cut.

The second failure is that it describes the system as if it already exists. "The user can export to Excel." Which user? Which columns? What happens with 40,000 rows? May the export take two minutes? Should it run overnight? Without those answers the sentence is true and useless at the same time. One developer will fill the holes. Two developers will fill them differently.

The third failure is mixing wishes, policy and edge cases in the same chapter. "Must comply with GDPR" next to "must have a dark theme" next to "must handle bankruptcy estates." The first is a constraint. The second is polish. The third is a domain you may not need to build in v1 at all. When everything sits as shall-statements, you cannot cut. Then reality cuts for you — mid-sprint.

We also see specs written by someone who will not use the system, and approved by someone who will not build it. That is a document, not a conversation. The discovery week is that conversation, with an output you can point at next Monday.

We do not measure a discovery week on whether everyone left inspired. We measure it on four things you can take out of the room. First: an out-list. Things you said no to, with a sentence about why. Without that list the wishes come back in week three as "that was implicit." Second: the two or three flows a person must be able to complete in v1 — not as user stories in a tool, but as screens and states you drew together.

Third: the interfaces. What comes in from outside (ERP, payments, login, a spreadsheet), what goes out, and what you temporarily do by hand. A CSV every Friday is an honest v1 cut. A "full integration" you have not seen data from is a hope. Fourth: the three risks you must not ignore — data you do not own, a decision that sits with someone who was not in the room, a compliance assumption you have not checked.

That is also what you should demand to have delivered: not a thirty-page inception deck, but something another team can build from. Wireframes or HTML sketches. A list of open questions with an owner and a date. A proposal for the first iteration — typically 1–2 weeks — with a demo you can say no to. If the output only lives in the facilitator's head, you bought a week, not a clarification.

On a Next.js MVP that often means: which roles, which login, which lists and details, and whether you even need a public site in the same repo. On a customer portal: who invites whom, and what happens when a contract expires. On a marketing site: which pages are in, and which campaigns wait. The shape is the same. The content is yours.

You need the person who can say no to a market, an integration or a date. Without that person the week is an interview. You need the person who knows the real users — not the one who knows an org chart. And you need the person who knows the data: where customers actually live, what is a mess in Excel, what the ERP cannot do. Three to five people. Not twelve.

You do not need the whole leadership as an audience. You do not need the vendor who is only there to defend the existing system, unless you have explicitly asked them to map interfaces. And you do not need a design team that only arrives once "scope is locked" — because then they design a different product from the one you cut.

The facilitator — us or you — must be able to stop a conversation that has become a feature wish-list, and pull it back to the flow. An agency that can only run a Miro board, but cannot challenge a shall-statement, is a meeting host. That is a different job from discovery.

If the real decision-maker can only give two hours, put those two hours on Wednesday and Friday. Not Monday. Monday you can prepare. Wednesday someone has to cut. Friday someone has to approve the out-list. Anything else is calendar optimisation that kills the week.