---

name: tlc-discover description: 'Interviews an unshaped idea into a verdict and a design document - decisions, flows, schema, contracts - that anyone can plan from without having been in the room. Use when the user says "research this", "help me understand this problem", "should we build this", "discovery", "explore this problem", or "tlc-discover". Do NOT use to cut a finished design into tasks, or to implement.' license: CC-BY-4.0 metadata: author: Tech Leads Club - github.com/tech-leads-club version: 0.9.0

TLC Discover

Find out where this project actually is. Understand the problem. Decide whether to solve it. Then, and only then, decide how.

SITUATION ────→ PROBLEM ───────→ VERDICT ───────→ DECIDE
(where this     (no solution     (a stop, or a    (two shapes, costed
 project is)     proposed yet)    record)          against this repo)

These are not a script, they are the prerequisite order. What you run is an interview: ask whatever is answerable given what is settled, and stop when nothing answerable is left. The order falls out on its own, because how has whether as a prerequisite and whether has where we are. Marching them as four acts is how a discovery asks a project that never shipped what its problem costs today.

The failure that matters here is not inventing a fact, it is converging early: proposing a solution on turn two, hearing "sure", and manufacturing a decision that has all the authority of one and none of the examination. Everything below exists to make that harder.

The artifact is a design document that anyone - a person, a team, a planning tool - can plan from without having been in the conversation that produced it. It has to show the design, not only record that one was made: the decisions that are hard to reverse, the flow of the critical path, the states and who moves them, the schema as it will exist, the contracts callers will hold. Where relationship or order is the content, that is a diagram; a table of thirty literals is a spec wearing a design's clothes. And it is organised by vertical slice, so a reader who wants one piece of the work reads one section and finds its diff, its flow, its schema, its contract, its decisions and its open questions there. If Shape cannot tell a reader what the bet is, a slice cannot show them how its piece moves, or the Work index which slices are clear, it failed even with every decision recorded.

Critical rules

1. No technology is proposed before the verdict. Not a library, not a provider, not a pattern. If the problem section argues for one, the framing is already a solution. This bans proposing, never knowing: what the project already runs, already committed to and already has half-written is a constraint, and meeting it late is how a discovery reopens what the team closed last month.
2. The verdict is a stop wherever the decision is open. Present it and wait. Where Situation established that somebody already committed, it is a line on the record instead of a gate - manufacturing a gate whose answer you know is the approval theatre that teaches everyone to click through the one that mattered.
3. Never present an option you would not ship. Two shapes are considered every time; the second earns a section only when it is live. When it is not, it earns one sentence naming what would have to be true for it to win - which is the disqualifying property whoever plans this needs anyway.
4. Name the number that would change the decision before you go and get it. Data with no question attached is noise that costs context. And a missing number is not a finding about the problem - it is usually a finding about the instrumentation. Ask; never read size out of silence.
5. A decision without a concrete value is not decided. A shape, a bound, a status, a field. Everything downstream refuses vague input; catching it here is where it is cheap.
6. High impact plus low clarity does not get decided here. It becomes an RFC or a spike. Forcing it produces the most expensive artifact there is: a decision that reads settled and is not.
7. Solve for this context, not for the reference architecture. The recommendation is the smallest shape that answers the problem as measured, and anything heavier has to be bought with a condition that is true now or credibly close. Options that exist only to widen the reader's view are welcome and are marked as exactly that - a line each, never dressed as candidates.

The interview

Ask what is answerable now. Every question whose prerequisites are settled is fair; one whose prerequisite is still open is not, because the answer to it is a guess you will then treat as a finding. You are done when nothing answerable is left, not when the sections below have all been visited, and a question that matters in a section you have not reached still has to be asked.

Nothing here is owed a paragraph merely because it exists. A step with no input costs a line, and a section with no content does not appear at all - certainly not as a heading with "N/A" under it, the same ceremony wearing an apology. This governs the questions and the document equally, and it is what lets one skill serve a two-hour change and a quarter of work.

Every question carries your recommended answer and the reason, in a line. Agreeing then costs a word and disagreeing costs a sentence, where a blank question hands the user the work they came here to have done. A question you have no recommendation for is usually one to look up instead.

Facts you look up; decisions you ask. Anything the repository, the tracker or the docs can settle, go and settle - spending someone's attention on a fact you could have read is how a session earns the reputation of being a form. Product opinion, priority and appetite for risk are theirs alone.

Keep the delivery small even though the frontier is wide: one question when the answers depend on each other, two when they do not. The frontier decides what is askable and when you are finished, never how many arrive at once. Ten at a time is a form dump, and people answer form dumps by agreeing.

Some questions cannot be answered by talking at all. How it should feel, one page or three - these need something to react to, and grinding on them doubles a session's length and converges on nothing. Catch it in the moment and route it out: to a spike where only building answers it, to a designer where only seeing it does. That routing is a result, not a failed extraction.

Situation

Three facts decide which questions below are worth asking at all, and getting them wrong is what makes a discovery feel like it is interviewing somebody else's project.

Where this project is. A product in steady use has a today you can measure. One that has not shipped has no today at all - not a small one, none - and the cost-of-today questions return nothing four times, which then reads as a weak case. A project in active construction has something better than metrics anyway: a roadmap somebody wrote and code somebody is halfway through.

Whether the decision is open. Sometimes nobody has decided, and that is the whole reason this exists. Sometimes the roadmap, the quarter or somebody senior already committed, and the honest job is to record who and spend the session on shape. Ask rather than assume the first: the two barely share a question.

What is already in flight that this touches. Probe what is cheap and present - active branches, the open cycle in the issue tracker, the connected knowledge base, the design documents this skill already produced - and ask for the rest, because whoever is in the room knows what the team started last week and that beats every probe. Depend on none of them existing: a project with no tracker and no wiki is ordinary, and the repository plus the person answering is always enough.

What is at stake. Not how long the work takes - how expensive it is to be wrong about it. A change one person reverts in an afternoon and a change that migrates everybody's data are the same size on a roadmap and nothing alike here. This is the fact that decides how much of the rest runs.

Work in flight changes the answer and not merely the background. A capability half-built elsewhere turns this into an extension of it. A decision closed in an earlier design document is settled input, so reopening it is churn wearing the costume of thoroughness. And a file somebody is actively rewriting is a conflict you can still avoid while choosing a seam is free.

Record them in a line each, so a reader six weeks out can tell the problem section is thin because nothing had shipped rather than because nobody thought of it. In flight is one sentence for what this copies as precedent and one for what stays out - it is where commit hashes and method names leak into the document first, and neither belongs.

Some work does not need a discovery at all, and saying so is part of the job. Where little is at stake, the answer is reversible in an afternoon and nobody in the room disagrees, give the recommendation in a paragraph and stop: no document, no verdict, no sections. A discovery that cannot decline the feature is a rubber stamp, and one that cannot decline itself is paperwork people learn to route around - which is how it stops being run on the decision that needed it. The bar is all three at once: cheap to reverse, small blast radius, nobody disagreeing. Any one of them missing and the session runs.

Problem

Nothing technical happens in this phase. People arrive holding a solution - "we need a cache", "we should add Stripe" - and the first job is to recover the problem it was an answer to, because the solution they arrived with is usually the first one they thought of, not the one they compared.

Start by deciding which kind of problem this is, because the questions differ and running the wrong set is how a discovery arrives at a confident wrong answer. A problem of pain is something happening now that costs something - it has a today you can measure. A problem of absence is a capability missing from a product that exists: nobody is hurt by it, because nobody is doing it. A problem of construction is the next piece of something still being built - no today, no substitute and nobody to ask, because the product has not met anyone yet.

Most new features are the second kind, and read through the first kind's questions every one of them looks like a preference. Run either of the first two over the third and every question comes back empty, which then reads as a weak case for work that was never in question.

For pain: who hurts, named specifically enough that you could go and talk to them; what it costs today, in whatever unit the business actually feels - minutes, tickets, churn, refunds, on-call pages; what happens if nothing changes, which separates a real problem from a preference, because a problem that costs nothing to ignore is a preference with better vocabulary.

For absence: who cannot do this today, and then the question that carries the whole phase - what do they do instead. Nobody sits and waits for software. They use a spreadsheet, a manual process, a support ticket, a competitor, or they give up quietly and you never hear about it. The substitute is the evidence: it is observable, it exists before the feature does, and it is the honest analogue of "what it costs today". Then what stays impossible if this is never built, and who keeps leaving over it.

For construction: the anchor is the commitment rather than a user. What was this piece promised to make possible - in the roadmap, the pitch, the earlier design document. What stalls without it - not for a customer, for the thing being built: which blocks cannot start, what gets stubbed, what is written twice. Then the question keeping this kind honest, **why now rather t