Leave discovery with decisions, not a backlog
Discovery workshops fail in a predictable way: the room fills a backlog, everyone feels productive, and the hard choices are deferred to "later in the build." Later never comes cleanly. The artifact worth leaving with is not a longer list of features — it is a short package of named decisions, explicit outs, open questions with owners, and the few risks that can actually move the schedule.
A backlog is a parking lot
Backlogs are useful once the shape of the work is settled. In discovery they become a polite way to avoid saying no. Every idea gets a card, every card feels like progress, and the workshop ends with dozens of items that still have not been sequenced against a first release.
The tell is language. If the whiteboard is full of verbs without seams — "add reporting," "support offline," "integrate payments" — you have captured ambition, not discovery. Those phrases do not tell an engineer what to spike, what to buy, or what to refuse.
Treat the backlog as a side product at most. The session is successful when fewer options remain, not when more tickets exist.
Name the decisions, not the vibes
A decision has a sentence form: we will do X, we will not do Y, and Z is deferred until a named condition. Write those sentences before the workshop ends. "We are leaning toward Shopify for checkout" is not a decision. "Checkout stays on Shopify; we own content before the cart and fulfillment after the order" is.
The same standard applies to architecture. "Probably a monorepo" is a vibe. "Four surfaces, four repos, shared API contract published from the system of record" is a decision someone can implement against — and challenge with a concrete counter-proposal.
If two plausible paths are still open at the end of the day, record both with the criterion that will settle them. An open fork with a settling test is still useful. An open fork with no owner and no deadline is just unfinished work wearing a sticky note.
What we actually walk out holding
The package we aim for is short enough to read in one sitting. A one-page system sketch with the seams labeled. A V1 in / V1 out list written in plain language. An open-questions log with an owner and a date for each item. A risk list capped at the three to five things most likely to blow the schedule — integrations with uncertain APIs, compliance surfaces, data migrations, device constraints.
We also write the kill criteria for anything we still call a spike: what evidence would make us stop, and what evidence would promote the spike into the build. Without that, spikes become unpaid prototypes that quietly expand scope.
None of this needs a forty-slide deck. A shared doc with headings everyone can find again next week beats a polished presentation that nobody opens after the call.
Owners beat "we should figure that out"
Open questions are fine. Unowned open questions are how discovery leaks into week six of delivery. Every unresolved item needs a name and a next action — who talks to the vendor, who confirms the data export exists, who decides whether the field app shares the same identity as the dashboard.
When the client cannot answer in the room, that is still a result. Capture it as a dependency: build path A assumes the export includes line-item photos; if it does not, path B is a manual upload flow and the estimate changes. The workshop's job is to make that fork visible, not to pretend the answer is already known.
We will not invent certainty to look decisive. We will refuse to leave ambiguity without a person attached to closing it.
How this differs from quoting and bake-offs
The five questions we ask before a quote surface whether a project is even worth scoping. A discovery workshop assumes that bar is cleared and digs into the seams of a build that is going to happen. Different altitude, different artifact.
A vendor bake-off settles a purchase with the client's real content. Discovery settles the shape of work we will do ourselves — what we build, what we buy, what we explicitly will not touch in V1. Confusing those sessions produces either a feature matrix where a decision log was needed, or a vague architecture sketch where a timed bake-off would have killed a bad vendor in two days.
When the workshop is over, the test is simple: could a competent engineer who was not in the room start the first spike from the write-up without a follow-up meeting? If not, you still have a backlog. You do not yet have discovery.
Questions
- What should a discovery workshop produce?
- Named decisions with explicit outs, a short system sketch with seams labeled, an open-questions log with owners and dates, and a capped risk list. A longer backlog without those decisions is not discovery.
- How is discovery different from pre-quote questions?
- Pre-quote questions decide whether a project is worth scoping. Discovery assumes the build is happening and settles seams, V1 boundaries, owned unknowns, and the risks that can move the schedule.
- When is a discovery workshop done?
- When an engineer who was not in the room can start the first spike from the write-up without another meeting — and every remaining open question has a named owner.
Sources
- SVPG — product discovery basics — Discovery as decision-making before commitment.
- Fathom Notes — The five questions we ask before we quote anything
- Fathom Notes — A feature matrix is not a bake-off