Product Thesis Memo

Make One Bet Govern the Work

A promising product can fracture into several reasonable plans before the founder writes any code. One prospect wants an integration. Another belongs to a larger segment. A polished self-serve flow would make the demo easier. A partnership might create distribution later. Each idea can be defended; together they describe more product than one person can learn from or operate.

The Product Thesis Memo gives those decisions one argument to answer to. It joins what customers have done, the change they may adopt, the business that may support it, and the smallest delivery system that can test the claim. It also records what the founder will refuse while the claim remains uncertain.

Write it after a bounded discovery cycle has ended in a decision. Bring the source material, not only its conclusions: interview or observation notes, workflow episodes, the current alternative, the discovery-to-build memo, the ICP boundary, pricing and reachability evidence, and any data, trust, support, or operating constraint. If two customer types rely on different workflows or buyers, write two theses. Do not conceal the split inside a broad segment.

Put an owner, cycle date, and reconsideration date at the top. Keep the current thesis to one page. Supporting notes may be long; the bet should not be.

Begin Where the Evidence Has Edges

Name the narrow customer through a situation, not a market label. “Small businesses” cannot govern a product decision. “Operations managers at small field-service companies who reconstruct incomplete job outcomes before recurring client updates” identifies a role, a workflow, a trigger, and a consequence.

Under that boundary, write the two or three observations carrying the most decision weight. Point each one back to a note, recording, workflow observation, transaction, or product event that the founder is entitled to retain. Then complete four lines:

• Customer and costly moment: who encounters which recurring situation, and what does it cost in delay, effort, money, risk, or trust?
• Discovery insight: what does the observed behavior reveal that the category description misses?
• Current alternative: what do customers do now, and which advantage makes that method survive?
• Contradiction: what evidence most threatens this interpretation or limits the segment?

The insight should change the product. If customers complain about reporting but preserve manual review because exceptions require judgment, “reporting is slow” is not enough. The useful insight is that any first product must reduce reconstruction without removing the review customers trust.

Do not turn repetition into certainty. Repeated pain does not establish adoption, access, payment, or safe automation. The contradiction belongs beside the supporting evidence because it determines what the first test must leave unresolved.

Turn the Insight into a Narrow Exchange

Describe the smallest change in customer behavior that would create value. This is the wedge. Set it against the complete current alternative rather than against its weakest step.

Write the next part of the memo in this order:

1. Wedge: the first workflow moment the product will own and the behavior the customer must change.
2. Promise: the outcome the first version can credibly produce without implying a broader product.
3. Buyer and value unit: who can authorize payment and what recurring unit—account, review, case, location, transaction, or another concrete unit—makes the value legible.
4. Pricing hypothesis: the price or range to test and the customer cost, budget, or avoided work that makes the conversation rational.
5. Distribution hypothesis: where the founder can repeatedly find qualified prospects now, which message earns a response, and what action will count as more than interest.

These lines should describe an exchange, not a feature set. The customer changes a real workflow and accepts a meaningful cost; the founder delivers a bounded result and learns whether the exchange can recur. “Launch through content” is not yet distribution. “Contact operations leads in two field-service owner groups and ask them to bring one recent incomplete account review to a paid assisted trial” can be attempted and rejected.

Give the Bet an Operating Boundary

Now describe enough system to test the thesis honestly. Start from the riskiest claim. If the risk is trust, preserve review and source visibility. If the risk is data access, test the least durable intake method customers might actually use. If the risk is payment, collect payment before improving architecture.

Record four boundaries:

• Minimum system: the inputs, transformations, stored data, output, and human control required for the test.
• Manual operation: onboarding, mapping, review, delivery, exception handling, or support the founder will perform while learning.
• Trust and support: what must be secure, attributable, editable, recoverable, monitored, or explicitly unsupported from the first trial.
• Refusals: the customers, workflows, features, integrations, channels, automations, and promises that will not enter this cycle.

Manual work is not free merely because it avoids code. Estimate where the founder’s time will go and record it during the test. The thesis fails as an operating document if a technically small wedge quietly requires bespoke setup, constant correction, or urgent intervention for every customer.

Refusals should protect the learning question. “No native integration during the upload trial” preserves evidence about whether the result earns repeat use before integration reliability becomes the work. “No enterprise features” is too loose; it allows each attractive request to be renamed as essential.

Modeled Memo: A Gap Review before the Client Update

This modeled example continues the fictional field-service workflow used in the preceding templates. Its details demonstrate a completed artifact; they are not market claims.

Owner, cycle, and reconsideration: founder; three assisted weekly review cycles, reconsidered after the third delivery.

Customer and costly moment: Operations managers at small field-service companies prepare recurring updates for commercial clients. Near the deadline, they discover completed jobs with blank or contradictory outcomes and reconstruct events from technician messages and calls.

Evidence and insight: In the discovery cycle, incomplete outcomes repeatedly delayed observed account reviews, while managers preserved service-manager approval even when records were complete. The useful opening is therefore not automated client reporting. It is a source-linked gap review before drafting begins. The strongest contradiction is that companies with dispatchers checking every job at close-out rarely accumulate the same repair work, so the thesis excludes them.

Current alternative: A scheduling export, technician messages, phone calls, and manager judgment are awkward but flexible. They expose the original records and let a responsible person resolve exceptions before a client sees them.

Wedge and promise: The first service accepts one scheduling export, flags outcomes that cannot support the coming update, links each flag to its source row, and returns an editable review list. It promises earlier visibility of repair work while preserving manager approval; it does not promise a finished or automatically sent client update.

Commercial path: The likely buyer is the operations leader accountable for review time and communication quality. The first pricing conversation uses each recurring client-review cycle as the value unit. The founder will recruit directly from small field-service operator communities and referrals, using one recent review as the qualification event. A compliment or demo request is not evidence of the exchange; bringing real data to a paid assisted cycle is.

Delivery boundary: The test uses an encrypted upload, a customer-specific column map, deterministic completeness checks, source-linked flags, an editable review list, founder review, and manual delivery. The founder performs setup, inspects false flags, records correction and support time, and deletes source files on the agreed schedule. Customers retain approval and all external sending. Native scheduling integrations, generated client prose, automatic sending, multi-role administration, and support for ambiguous service decisions are refused.

Decision test: Continue only if qualified managers entrust real exports to the trial, use the review in successive weekly cycles, and choose to keep paying because reconstruction work visibly falls without weakening approval. Narrow if value appears only for one scheduling workflow, client type, or deadline pattern. Change the wedge if managers value earlier record repair but not a separate review artifact. Stop if consequential gaps are rare, the upload boundary prevents adoption, review effort merely moves to the founder, or no accountable buyer will fund another cycle.

The thesis holds one uncertainty open: whether a source-linked gap review is valuable enough to become a repeated exchange. An integration, dashboard, or writing assistant would make the product larger without making that uncertainty clearer.

Write the Thesis as an Argument

After completing the sections, compress them into one paragraph. Use this syntax only as a forcing device; rewrite it until it sounds like the actual business:

Because [specific customer] repeatedly [observed behavior with consequence], and the current alternative preserves [advantage customers will not surrender], we believe [narrow wedge] can deliver [credible promise]. [Buyer] will test paying [pricing hypothesis tied to a value unit], and we can reach similar customers through [repeatable path]. For this cycle, we will deliver with [minimum system and manual operation], preserve [trust or support boundary], and refuse [specific adjacent scope]. We will [continue, narrow, change, or stop] when [observable evidence] by [cycle boundary].

Read the paragraph against the evidence lines. Every causal word—because, therefore, will—should expose a claim the cycle can challenge. If the paragraph becomes crowded, the usual problem is not sentence length. The thesis is carrying incompatible customers, wedges, or business models.

Try to Defeat It before Building

Use five requests to test whether the memo can govern work:

1. A customer in an adjacent segment asks for the same outcome through a different workflow.
2. A prospect will trial the product only after a native integration exists.
3. A friendly user loves the result but the responsible buyer will not discuss payment.
4. The promised outcome requires the founder to review every exception indefinitely.
5. A broad channel offers attention from people outside the stated customer boundary.

For each request, identify the thesis claim it would test. Accept the work only when it is the smallest honest way to test a primary uncertainty. Otherwise apply a refusal or revise the thesis explicitly. Silent exceptions make the memo decorative.

Before the cycle begins, write separate conditions for continue, narrow, change, and stop. Avoid thresholds chosen merely to look rigorous. A threshold should correspond to the belief at risk: repeat behavior for recurring value, a real buying action for willingness to pay, source access for feasibility, correction and intervention time for operating burden, or retained approval for trust.

Keep One Page Current

Use these headings on the working page:

1. Owner, cycle, and reconsideration date
2. Customer and costly moment
3. Evidence, insight, and contradiction
4. Current alternative and the advantage it preserves
5. Wedge and credible promise
6. Buyer, value unit, and pricing hypothesis
7. Reachable distribution path and qualifying action
8. Minimum system and manual operation
9. Trust, support, and data boundary
10. Refusals
11. Evidence for continue, narrow, change, or stop
12. One-paragraph thesis

When evidence changes the bet, replace the current page and retain the earlier version beneath it with the date and the observations that forced the revision. A new feature idea, competitor announcement, or change in founder enthusiasm is not an evidence note.

The memo is usable when a founder can answer the next scope request by pointing to the claim it tests, the boundary it respects, and the result that would change the decision. At that point the thesis has done its work: it has made one bet clear enough for positioning to express and small enough for evidence to defeat.