The Three Loops: Discover, Build, Distribute

Three Full Days, No Product Decision

On Monday, a founder interviews two potential customers. On Tuesday and Wednesday, they improve onboarding and clear a backlog of small bugs. On Thursday, they rewrite the landing page and send forty emails. By Friday, each activity has produced something visible: notes, code, copy, and a reply count.

Yet the founder cannot say whether the product should change.

The interviews concerned reporting pain. The code improved a general dashboard. The outreach promised AI-assisted recruiting. These were not three parts of one investigation. They were three respectable ways to avoid choosing what the company most needed to learn.

A solo founder has no product, engineering, and go-to-market departments to reconcile these streams later. The same person must learn who has the pain, make something that tests or delivers value, and bring it to the right people. The work becomes useful when those activities correct one another.

Run them as three loops:

1. Discover the customer, the painful moment, the current alternative, and the change in behavior that would count as progress.
2. Build the smallest product behavior, manual service, instrumented path, or operational support that can test or deliver the outcome honestly.
3. Distribute the promise or product to a specific market, then learn who responds, who acts, and who returns.

The loops do not deserve equal hours. They need a shared question and a decision at the end. A cycle may contain three days of building and one customer call. Another may contain ten interviews and a spreadsheet delivered by hand. Synchronization means that evidence crosses the boundaries: discovery changes the build; the build changes what the market can do; market contact changes whom the founder studies next.

Each Loop Must Hand Something Over

Discovery owes the build loop a constraint, not a feature list. A founder should leave a useful conversation knowing more about the workflow in which the problem occurs: what the customer does now, where trust breaks, who approves change, what must remain under human control, and what event creates urgency. “They want automation” is weak. “Every Friday, the agency owner assembles a client update from three inconsistent sources and refuses to send unreviewed text” can shape a product.

Build owes the other loops observable behavior. Code is one way to create it, but so are a clickable prototype, a manual service, a script, an import template, a payment link, or an admin screen. A founder-operated workflow can reveal whether customers provide real data, accept the result, return at the next natural interval, and create exceptions that would make the product unbearable to run. The build is sufficient when it creates an honest encounter with value and burden. It need not resemble the eventual system.

Distribution owes the company qualified contact with the market. Early distribution may be twenty careful emails, five demos, a useful post in a narrow community, a partnership conversation, or a referral request. Its first job is not scale. It is to discover whether a recognizable segment understands the promise and takes the next costly step. Traffic from the wrong people can decorate a dashboard while leaving the product untouched.

The handover is the unit of progress. A repeated objection may become a trust requirement. A failed activation may send the founder back to the customer’s real workflow. A referral from one retained user may sharpen both the segment and the language used in outreach. If one loop finishes without changing the question asked of another, inspect whether it produced evidence or merely output.

Follow One Product Through the Loops

Consider a founder exploring “AI tools for boutique recruiting agencies.” The idea easily expands into candidate sourcing, ranking, outreach, CRM synchronization, team analytics, and client reporting. Any one of those could occupy months.

The founder begins by asking agency owners about recent weeks rather than presenting the suite. Sourcing is difficult, but the conversations become specific when Friday client meetings come up. Recruiters have activity scattered across an applicant tracking system, email, spreadsheets, and private notes. Before the meeting, someone assembles an account of candidates contacted, responses, blockers, and next actions. Thin updates make clients suspect that nothing is happening.

That painful moment supplies three constraints. The useful output is a credible client update, not more candidate suggestions. It must be editable because the agency owns the client relationship. And the first version can accept an export; a live integration is not yet necessary.

The build loop now has a narrow job. For three agencies, the founder accepts one CSV format, produces a draft update with a small script, and reviews it before returning it to the recruiter. The workflow is partly software and partly service. That is an advantage at this stage: the founder sees inconsistent fields, missing next actions, and the judgment required to turn activity into a client-facing narrative.

The product encounter changes the question. All three agencies use the report, but data cleanup consumes most of the founder’s time. Recruiters edit the narrative more often than the activity counts. They care less about automatic prose than about seeing where claims came from and correcting them quickly. The next build is therefore not a second integration or an AI sourcing feature. It is a review screen with visible source fields, along with instrumentation for accepted and corrected sections.

Build evidence also changes distribution. “AI recruiting analytics” had attracted curiosity from many kinds of agencies. “Stop the Friday client-update scramble” earns replies from owners who recognize the moment. When the founder offers a manual report cycle to agencies with five to thirty recruiters, retained-search firms respond more seriously than contingency firms. Their client relationships make a weak weekly update more consequential.

The next cycle can now be smaller: retained boutique agencies, one export format, one editable report, one Friday workflow. Discovery will examine how those agencies preserve client trust. Build will test whether a review screen reduces corrections and founder cleanup. Distribution will use the Friday problem to reach more agencies of the same kind. The combined evidence has produced a decision: narrow.

Notice what did not happen. The founder did not complete discovery, then complete the product, then begin marketing. Distribution helped locate the segment during discovery. Manual delivery exposed the engineering boundary. The engineering boundary made the promise more credible. Each pass altered the next.

Find the Loop With the Weakest Evidence

Most founders have a comfort loop. Engineers can make code cleaner long after the main uncertainty has moved elsewhere. Consultants can hold perceptive conversations without asking anyone to change behavior. Marketers can keep testing messages against people who will never become customers. Competence makes the comfort loop especially convincing.

Look for the missing evidence rather than the least active calendar column.

Discovery is weak when you cannot name a narrow customer, a recent painful event, the current workaround, or the reason to change now. More scope will not repair that. Return to observed past behavior, including who felt the cost and what they did about it.

Build is weak when you have rich notes or eager replies but no product behavior to interpret. Ask for a consequential action: provide real data, attempt the workflow, approve an output, pay for a cycle, install something, invite a colleague, or return when the problem recurs. If users sign up but never reach value, the promise may be sound while the product path is not.

Distribution is weak when the product works for people the founder already knows but has no repeatable path to similar users. General attention does not repair this. Test a specific message, list, community, partner, or referral path against the segment you mean to serve. If every sale still depends on a long personal explanation, distribution has not yet learned how to carry the promise.

Sometimes the weak loop is hidden by volume. Twenty interviews can avoid price and switching. Six weeks of shipping can avoid instrumentation. Daily posting can avoid qualified conversations. Count the evidence capable of changing a decision, not the activity.

Change the Emphasis as the Product Matures

At the idea stage, discovery and distribution often touch the same people. The founder is learning whether a painful situation exists and whether those who feel it can be reached. Build may be a sketch, a spreadsheet, a mock workflow, or a manual promise. Heavy engineering is justified only when technical feasibility is itself the early risk.

At the prototype stage, build should turn interest into an action the founder can observe. The user might upload a file, choose between workflows, approve an output, or commit to a next meeting. Distribution remains narrow because qualified reactions are more useful than volume.

At the MVP stage, all three loops should be alive. Customer conversations explain behavior, instrumentation shows whether users reach and repeat value, and distribution supplies enough suitable users to separate a real pattern from one accommodating design partner.

When pull begins, build may legitimately take more of the cycle. The workflow people depend on has earned reliability, permissions, billing, backup, support tooling, and operational visibility. Hardening should follow that path of use. Building infrastructure around the imagined future product still weakens learning, even when some early users love the current one.

After product-market fit, the names survive but their work changes. Discovery includes churn, support patterns, account learning, and roadmap judgment. Build includes reliability, security, scale, and safe change. Distribution develops repeatable acquisition, onboarding, expansion, and trust. Synchronization still matters: acquisition that brings ill-fitting accounts can corrupt product priorities, while reliability failures can turn market pull into churn.

Write the Cycle Before Filling the Calendar

A Three-Loop Cycle Brief should fit on one page. Write it before choosing tasks.

• Primary uncertainty: the one question that most needs evidence now.
• Discovery action: whose recent behavior or workflow you will inspect.
• Build action: the smallest behavior, service, or system change that can make the uncertainty observable.
• Distribution action: how the intended customer will encounter the promise or product.
• Evidence threshold: what result would justify a different decision.
• Founder constraint: the limit on support, operations, cost, risk, or attention that the cycle must respect.

For the recruiting product, the uncertainty might be: Will retained boutique agencies pay for a better Friday client update before they care about sourcing automation? The founder will interview six owners about their most recent update, produce one manual report format from CSV exports for three agencies, and send twenty targeted emails using the language of the Friday scramble.

The threshold must make the result usable. Three agencies providing real data, using the report in a client call, or asking for a paid second cycle would justify continuing or narrowing. Replies centered on a different workflow would justify changing the product question. No custom integrations and no second report format protect the founder from turning one cycle into an agency-operations platform.

“Talk to users, improve onboarding, post online, and see what happens” is not a brief. It names tasks but leaves every assumption free to survive. A useful brief creates a way to say no before the week begins.

End With a Product Decision

At the end of the cycle, review the evidence together. What did customers reveal about pain, urgency, alternatives, language, trust, and switching? What did actual use reveal about activation, value, return, correction, failure, and founder effort? What did market contact reveal about reachability, qualification, price, and channel?

Then choose a verb:

• Continue when the same customer story survives contact, use, and return.
• Narrow when one segment, workflow, buyer, promise, or channel is markedly stronger.
• Change the product when the outcome matters but users cannot reach or trust it.
• Change the customer when the current audience is curious but lacks urgency, authority, budget, or retention.
• Change the channel when value exists but the route to suitable customers does not.
• Harden when repeated use makes reliability, data quality, security, support, or operations the binding constraint.
• Stop when honest cycles keep producing weak evidence and no sharper wedge appears.

Continue is not a polite name for doing more tasks. It means the evidence has earned another pass along the same line of inquiry.

Do not overcorrect from a single symptom. A failed email batch can indict the list or message rather than the product. Confusing onboarding can hide strong value. A successful manual service can reveal a service business, an unmanageable exception factory, or a product worth narrowing. The loops help because they provide more than one view of the failure.

They also prevent the opposite mistake: running five segments, three features, and two channels at once in the name of learning. That produces many observations with no shared cause. Synchronization is a discipline of connection, not a license for more experiments.

Run the Next Cycle

Audit the last two weeks of meaningful work. Label each activity Discover, Build, or Distribute, then cross out anything that produced no evidence you could use in a decision. A shipped feature with no observed use, an interview that changed nothing, and a post that attracted only unqualified attention may have been necessary work. They are not yet a learning cycle.

Name the loop with the weakest evidence. Write a one-page brief that strengthens it while handing something useful to the other two. If discovery is weak, study a real workflow and specify the behavior that would test what you hear. If build is weak, create the smallest honest encounter with the outcome. If distribution is weak, put one precise promise in front of one reachable segment and observe the next behavior, not merely the impression.

Finish the brief with the decision you expect to make. The purpose of the three loops is not to keep every founder function busy. It is to make the product answerable to the market once each cycle.