Discovery-to-Build Decision Memo

Make the Cycle End in a Choice

Discovery has earned its cost only when it changes what the founder does. A folder of recordings can feel substantial while leaving the product untouched. Memory then supplies the decision: the vivid quote survives, the latest call outweighs the earlier ones, and evidence that supports the intended product feels more representative than evidence that resists it.

Write this memo at the end of a bounded discovery cycle: a batch of interviews, a manual workflow trial, early onboarding, churn conversations, a landing-page test, or a sequence of pricing conversations. Use one customer segment and one decision. If the evidence points to two different workflows or buyers, split the memo rather than averaging away the difference.

Keep the source material beside you: raw notes, permitted recordings or quotes, observed workflow steps, current alternatives, segment tags, behavior or payment signals, build estimates, and support or trust constraints. The memo should be brief enough to repeat, but not so brief that it hides the reasoning.

Establish What Actually Happened

Begin with a header that fixes the boundaries of the cycle:

• Decision owner and revisit date: who will act on the memo, and when will the decision be reconsidered?
• Cycle: what was tested, over what period, and by what method?
• Segment: which customers, users, or buyers supplied the evidence?
• Decision in question: what choice must this cycle inform?

Then write three to five evidence statements. Each should name an observed event or attributable report and point back to its source. “Customers need better reporting” is an interpretation. “In four of six weekly account reviews, the operations manager opened the scheduling export and then messaged technicians to fill missing outcomes” is evidence.

For each statement, add two short lines:

• This suggests: the interpretation the evidence supports.
• This does not establish: the tempting conclusion that remains unproved.

This small separation prevents a repeated complaint from quietly becoming proof of willingness to adopt, pay, change workflow, or trust an automated result. Evidence deserves more weight when it comes from the segment under consideration, appears in recent real behavior, carries a visible consequence, and costs the customer something to tolerate or repair. Eloquence and enthusiasm do not add weight by themselves.

Let the Contradiction Change the Decision

Record the strongest evidence against the emerging interpretation. Look for a customer who solved the problem differently, a workflow where the pain did not recur, a buyer who would not fund the fix, an input the first product cannot reach, or a trust requirement that changes the proposed boundary.

Do not resolve the contradiction with “needs more research.” State what it might mean and what it changes now. It may narrow the segment, move the wedge to another workflow step, require a manual trial before software, or make the opportunity unattractive to a solo operator. If one cheap question can distinguish two explanations, make that question the next experiment. If the contradiction already defeats the thesis, stop.

Write the Decision as a Commitment

Complete this paragraph only after the evidence and contradiction are visible:

Because [observed behavior and consequence], we will [continue, narrow, change segment, change problem, prototype, price-test, run manually, or stop] for [specific customer and workflow]. We will test [riskiest remaining assumption] by [smallest honest experiment]. We will not [build, automate, integrate, promise, or serve something outside this test]. We will reverse or revise the decision if [observable result] by [date or cycle boundary].

The verb matters. Continue means the present thesis still explains behavior and has a clear next test. Narrow keeps the problem but reduces the segment, workflow, or promise. Change admits that the current thesis no longer explains the evidence. Prototype tests interaction or comprehension without pretending to deliver the service. Price-test asks for a meaningful buying commitment. Run manually tests the value and operating burden before automating it. Stop releases the founder from a path whose evidence pace, reachability, economics, trust burden, or support load no longer justifies another cycle.

A decision to build must name less than a product roadmap. State the smallest behavior the system needs to enable, the input it can honestly obtain, what remains manual, and the trust control that cannot be removed. Anything else belongs in the refusal line.

Modeled Memo: Do Not Build the Integration Yet

The previous sheet used a fictional small field-service company whose operations manager prepares weekly client updates from scheduling exports and incomplete technician notes. The proposed wedge flags jobs whose records cannot yet support a trustworthy update.

Decision owner and revisit date: founder; after three assisted weekly cycles.

Cycle: six workflow interviews and two observed account-review sessions over three weeks.

Segment: operations managers at small field-service companies that send recurring updates to commercial clients.

Decision in question: whether to build a scheduling-system integration and automated update generator.

Evidence 1: In both observed reviews, the manager exported completed jobs, found blank or contradictory outcomes, and contacted technicians before drafting the update. Four interviewees described the same repair.

This suggests: identifying unsupported outcomes before drafting may remove a repeated delay.

This does not establish: that managers will upload real exports to a new service or that the pattern appears often enough to sustain use.

Evidence 2: Both observed managers kept service-manager approval before anything reached a client, including updates assembled from complete records.

This suggests: source visibility, editable wording, and human approval belong inside the first promise.

This does not establish: that the product should generate polished client language rather than only expose gaps.

Contradiction: Two companies rarely had missing outcomes because a dispatcher checked records at job close-out. The opportunity is therefore not “reporting for field-service companies.” It may belong only to teams where review is periodic and record repair accumulates near a client deadline.

Decision: Because missing outcomes repeatedly delay account review in the narrower segment, we will run a founder-assisted upload service for operations managers who repair records before recurring commercial-client updates. We will test whether source-linked gap flags reduce reconstruction work across three weekly cycles. We will not build a native scheduling integration, send client updates, or automate ambiguous decisions. We will abandon or revise the wedge if managers will not provide real exports, consequential gaps are rare, or review effort does not visibly fall without removing human approval.

The evidence supports a manual test, not the integration originally under consideration. That is a successful discovery decision: the next step became smaller because the uncertainty became more precise.

Reusable One-Page Memo

Use these headings on a blank page:

1. Decision owner and revisit date
2. Cycle, segment, and decision in question
3. Evidence: three to five sourced statements, each followed by “This suggests” and “This does not establish”
4. Contradiction: the strongest evidence against the emerging interpretation and what it changes
5. Current alternative: the behavior, spending, or workaround the customer already trusts
6. Product boundary: the workflow and promise that remain plausible
7. Engineering and operating boundary: the smallest system, manual work, support load, and trust control required for the test
8. Decision: one commitment paragraph with a next experiment, refusal, reversal condition, and date

Read the finished memo as a skeptical founder with only one month of attention left. Can that reader trace the move from evidence to interpretation to action? Is the next experiment cheaper than the uncertainty it resolves? Does the refusal prevent attractive adjacent work from entering the cycle? Would a contrary result actually change the decision?

If those answers are visible, close the notes and act on the memo. If they are not, the missing sentence identifies the next piece of discovery.