Discovery Synthesis for Solo Founders

The Moment Notes Become Expensive

After a few good discovery conversations, a solo founder can feel rich with insight and still be unable to decide what to do on Monday.

The notes contain strong quotes, polite encouragement, screenshots of ugly spreadsheets, complaints about incumbents, confusing buying comments, feature requests, and one or two ideas that make the founder want to open the editor immediately. The danger is not a lack of information. The danger is letting the most vivid information become the decision.

Discovery synthesis turns customer evidence into a written operating choice: who to serve first, which problem to test, where to enter the workflow, what to build, what to fake, what to defer, and what evidence would change the decision.

For a solo founder, this work must be lighter than a research program and stricter than memory. It should fit into a short session after each discovery cycle. The result is not a cleaner archive. It is a one-page decision memo that can feed the product thesis in the next chapter.

Begin With Evidence That Can Resist You

Consider a fictional composite. A founder has spoken with freelance operations consultants, small bookkeeping firms, and boutique legal support agencies about client follow-up work. The broad idea is an automated follow-up platform. The notes seem to support it: people dislike chasing clients, reminders fall through, and several interviewees call automation useful.

That summary is already too smooth. It combines what happened with what the founder hopes it means.

Preserve each useful piece of raw evidence before explaining it. A small evidence card is enough:

Raw evidence: “At month-end I check the spreadsheet, search the inbox, and ask the account manager which clients still owe records.”

Context: Owner of a six-person bookkeeping firm, describing last Thursday.

Interpretation: Missing-document status may be a repeated coordination problem.

Tags: bookkeeping; month-end; document chase; spreadsheet plus email; owner oversight.

Strength: recent behavior.

Could change: segment, workflow entry point, next test.

The quotation is evidence. The claim about coordination is interpretation. Keeping both is useful; keeping them distinct makes the claim challengeable.

Write cards for what customers said, did, paid for, avoided, repeated, showed, or granted access to. “They hate reporting” is not raw evidence. “I stayed late three Fridays this month turning exports into client notes” is. A compliment is evidence too, but only of a compliment.

Tag only what can change a choice you expect to make. Segment and role affect whom you approach. Pain, frequency, urgency, and workflow stage affect the wedge. The current alternative reveals the benchmark. Budget and authority shape the buying test. Data access, integration, trust, and support constraints shape the first technical system. Add a contradiction tag whenever a card weakens the idea you prefer.

Anything else can remain searchable prose. A solo founder does not need a perfect taxonomy; the founder needs to recover the evidence when a decision is under pressure.

Weight What People Risk

Warmth is easy to remember and weak as a foundation for building. The useful question is what the customer risked or spent because the problem was real.

Move from low-cost signals toward costly ones:

• Curiosity: the customer says the idea sounds useful or asks to hear when it launches.
• Recent pain: the customer can reconstruct a particular delay, workaround, error, or complaint.
• Repeated pain: similar episodes recur for this customer or across comparable customers.
• Costly workaround: the customer spends time, money, staff attention, political capital, or reputation managing the problem.
• Access: the customer shares an artifact, sample data, a workflow owner, or a second meeting.
• Commitment: the customer agrees to a trial, introduces a buyer, changes a process, or discusses payment.

These are not points on a universal scoring system. They are different kinds of claim. Strong evidence that users dislike a workflow does not prove that a buyer can approve a replacement. Strong buyer interest does not prove that daily use will repeat. Keep the gaps visible.

In the follow-up notes, freelance consultants describe real frustration, but every client has a different cadence and much of the work depends on personal judgment. Legal support agencies describe urgent document chasing, yet they will not share examples without a confidentiality agreement and mistakes could damage client trust. Bookkeeping firms show month-end spreadsheets, forward redacted request emails, and describe similar missing-document loops.

The broad idea now has friction. That is progress.

Build the Pattern From Repeated Episodes

Cluster cards around a precise episode, not a category label. “Follow-up” is too broad to support a product decision. “At month-end, bookkeeping staff reconstruct which client records are missing before sending the next request” has a trigger, a workflow, an alternative, and a consequence.

For each possible pattern, ask:

• Did comparable customers describe it without being led there?
• What event starts the work, and how often does it happen?
• Where do delay, rework, embarrassment, risk, or lost revenue appear?
• What workaround has the customer already accepted?
• Which part of that workaround is frustrating, and which part is trusted?
• Can the founder reach the inputs, workflow owner, and buyer again?

Then look for the exception capable of breaking the pattern. Bookkeeping staff want fewer repetitive emails, but they insist on reviewing messages because a request may need client history that is not in the spreadsheet. That contradiction does not erase the opportunity. It rules out autonomous sending as the first product.

Other contradictions should be allowed to do more damage. Users may complain about an incumbent and renew every year because its history and permissions matter more than its awkwardness. A buyer may call a problem strategic while no operator will schedule a second conversation. People may love a mock-up but refuse to share samples, try it, introduce a colleague, or discuss money. Synthesis becomes honest when such evidence changes the decision rather than becoming a footnote to it.

Compare Segments as Operating Systems

The loudest pain does not automatically identify the best first customer. The first segment also determines what one person must build, sell, support, monitor, and repair.

Here a side-by-side view earns its space because the choice depends on several shared attributes at once:

The bookkeeping firms do not necessarily have the largest theoretical market or the most severe pain. They offer the clearest repeated workflow, the safest access to real examples, and a useful result that can be tested without pretending the founder already runs a reliable communications platform.

This is sequencing, not timidity. A harder segment may become viable after the founder has evidence, revenue, references, and a sturdier product. Starting there now could turn discovery into bespoke consulting or permanent on-call work.

Make Engineering Answer to the Evidence

Once a segment and workflow begin to separate from the rest, trace the smallest system that can test the claim. Count both construction and operation.

Build difficulty rises with stored data, states, roles, payments, scheduled work, integrations, permissions, sensitive inputs, migration, and reliability expectations. Support difficulty rises with customer-specific setup, exception handling, monitoring, urgent questions, and mistakes that create visible harm. A technically small product can still be an operationally large one.

For the bookkeeping workflow, a full automation platform would need inbox access, accounting-system integrations, client identity, permissions, templates, scheduling, delivery state, audit history, and failure handling. It would also make the founder responsible for messages sent in the firm’s name.

The evidence has not earned that system. It has earned a smaller test:

1. Accept a copy of the firm’s existing status spreadsheet and redacted examples.
2. Produce a missing-document digest and draft reminders manually.
3. Let staff review every draft and preserve their corrections.
4. Deliver the next digest through the firm’s existing workflow.
5. Observe whether staff use it again and whether the work saves senior review time.

This choice still creates support work: normalizing a spreadsheet, resolving ambiguous client names, and incorporating firm-specific wording. Record the time and exceptions. If each firm needs a different miniature operating system, the pilot is discovering a service business, not validating a repeatable product.

Build only the capability essential to the learning. Buy commodity infrastructure that teaches nothing. Borrow templates and existing tools where they are sufficient. Fake automation when careful manual work answers the question sooner. Defer surface area whose underlying assumption has not been tested.

Write the Discovery-to-Build Decision Memo

End the synthesis session by completing one page. Write in operational language and link the important claims back to evidence cards.

Decision

Choose one verb: continue, narrow, change segment, change problem, prototype, price-test, or stop. Add one sentence naming what the decision excludes.

For the example:

Narrow to the month-end missing-document loop in small bookkeeping firms. Do not pursue general client follow-up or autonomous sending.

Evidence and contradiction

Name the segment, role, recent workflow, trigger, repeated pain, current alternative, and strongest behavior or commitment. State how many comparable episodes support the pattern, but do not let a count hide weak similarity.

Then write the evidence most likely to defeat the choice:

Three firms showed similar spreadsheets and supplied redacted request examples. Two owners described senior review as the costly step. Staff still require human approval because the right wording depends on client history that the spreadsheet may not contain.

Product and engineering implication

State where the test enters the workflow, what outcome it must improve, and what the current alternative does well enough to preserve. Then name what will be built, bought, borrowed, faked, and deferred.

Run a founder-assisted month-end digest for five firms using their existing spreadsheet and redacted email examples. Produce reviewable reminder drafts; do not send them. Use a simple intake and template, perform normalization manually, and defer accounting integrations, inbox access, permissions, billing, dashboards, and automated delivery.

Founder burden

Name what the founder will personally handle and the condition that would make the approach unsustainable.

Track setup time, ambiguous records, wording corrections, review time, and urgent support. Narrow or stop if each firm needs custom data repair or specialist message writing before the digest is useful.

Next risky assumption and test

Choose the assumption most likely to break the decision if false. Do not choose the easiest thing to test.

The risky assumption is that a reviewed digest saves enough senior time to change repeated behavior. Test four month-end cycles; ask firms to use the digest in live work and discuss a paid pilot after the second useful cycle.

Stop or change rule

Write the rule before more code or emotional investment makes it negotiable.

Change the workflow or stop if target firms will not provide usable inputs, use the digest twice, involve the owner of month-end review, or consider paying for continued delivery.

The memo forces verbs rather than adjectives. “Promising” is not a decision. “Narrow to small bookkeeping firms and run a reviewed missing-document digest” is.

It should also refuse work. Deferred features are not forgotten; they are work that has not earned the right to exist.

Know When Synthesis Is Finished

Synthesis is complete when another careful reader can trace the decision back to raw evidence, see the contradiction that could overturn it, and understand the product and operating burden of the next test. The strongest pattern names a customer, trigger, workflow slice, current alternative, and consequence. The memo names the risky assumption and a behavior test capable of changing the choice.

Continue discovery when the evidence is too thin or incompatible to select a wedge. Narrow when one segment, role, trigger, or workflow slice is materially stronger. Change segment when pain is real but reach, trust, build, or support burden defeats a credible trial. Prototype when conversation cannot answer the next question. Price-test when the pain is clear but the buyer or budget is not. Stop when further work would mostly defend the idea.

Stopping protects the founder’s attention budget. So does refusing to turn every useful conversation into software.

Exercise

Take five to ten pieces of evidence from your latest discovery cycle. Make one evidence card for each, separating the raw event from your interpretation. Tag only the decisions the card could change, and mark the strongest contradiction to your preferred idea.

Cluster the cards by comparable customer and workflow episode. If several segments remain plausible, compare their repeated workflow, current alternative, reach, first useful slice, trust burden, and founder burden side by side.

Then write the one-page memo: decision, evidence, contradiction, product and engineering implication, founder burden, next risky assumption, next test, and stop or change rule. Carry that memo into the next chapter. The product thesis should begin from evidence you are willing to bet founder time on, not from the idea that survived only because you never made it face the notes.