Solo Founder Product Engineering Handbook
MVP Experiment Card
Design a narrow MVP experiment with a target segment, value moment, activation event, retention expectation, support plan, and decision rule.
Give the MVP a Consequence
An MVP without a decision rule has a habit of becoming a permanent small product. Users arrive, requests accumulate, and ambiguous activity supplies a reason to keep maintaining it. The code may remain narrow while the founder’s obligations quietly expand.
Write this card before building or recruiting. Use it when the Code-to-Evidence Ladder has shown that the next question requires customer-facing use. Bring the product thesis, the evidence already earned, the customer’s current alternative, and an honest limit on the time available to build, operate, and support the test.
The card should govern one decision. If it needs several segments, value moments, or unrelated success measures, split the experiment.
Copy the Card
MVP EXPERIMENT CARD
Decision this experiment will change:
Question that customer-facing use must answer:
Evidence already earned:
PARTICIPANTS
Target segment and use context:
Include only:
Exclude:
Current alternative and why it survives:
VALUE PATH
Promise in the customer's language:
Activation event:
Value moment:
Repeat behavior and its natural interval:
Shortest product path that can make this behavior real:
EXPERIMENT BOUNDARY
MVP shape and what is deliberately absent:
Number of qualified participants or accounts:
Start, cutoff, and maximum founder capacity:
Payment, deposit, data access, or other commitment requested:
MANUAL WORK, TRUST, AND SUPPORT
Founder work behind each value moment:
Minutes, interventions, corrections, and reminders to record:
Data, safety, privacy, permission, and review boundary:
Failure and recovery path:
Support channel, response boundary, and out-of-scope requests:
EVIDENCE
Events or records that show activation, value, and return:
Payments, qualitative notes, failures, and support load to capture:
Evidence this MVP cannot produce:
DECISION RULES — WRITE BEFORE RECRUITING
Success means:
If the value moment occurs but repeat use does not, I will:
If use depends on excessive founder work, I will:
If the result is ambiguous at the cutoff, I will:
I will narrow, change direction, or stop when:
If the result supports the belief, the next decision is:
If it contradicts the belief, the next decision is:
The experiment boundary prevents a promising result from expanding the test halfway through. The manual-work lines prevent founder rescue from masquerading as product behavior. The final branches matter as much as the success threshold: a result becomes useful when it changes what happens next.
Make the Measures Belong to the Workflow
Activation is the first observable step onto the value path, not account creation by default. The value moment is the outcome the participant would notice losing. Retention is that behavior repeated at the natural rhythm of the work: the next weekly review, the next invoice run, or the next deployment—not an arbitrary return within seven or thirty days.
Record the denominator as carefully as the successes. “Three users returned” is hard to interpret without knowing how many qualified people began, who needed reminders, and who never reached value. Keep acquisition, activation, value, and return separate so enthusiasm at the top of the path cannot hide failure lower down.
Put Founder Work Inside the Result
Founder effort belongs in the result. Time the work, name the judgment applied, and record corrections, reminders, exceptions, and support. A concierge experiment may succeed with substantial human effort; a self-serve claim may not. The card must say which is being tested.
A Worked Card
The architecture-studio example from Chapter 31 asks whether a project lead will trust an AI-assisted weekly summary enough to use it in client work. A compact card might read:
Decision: whether to keep investing in the weekly-summary workflow.
Question: will a project lead send a reviewed summary to a real client and
repeat the workflow after the next project meeting?
Evidence earned: studios already prepare weekly updates; manual summaries have
been judged useful. Self-serve use and repeat demand remain unproved.
Participants: five-to-twenty-person architecture studios that already send
weekly client summaries. Exclude studios without a weekly meeting rhythm.
Current alternative: a project lead rewrites meeting notes by hand because the
process is familiar and keeps responsibility for client-facing claims visible.
Value path: upload notes -> review draft -> correct and approve -> export and
send. Activation is a completed upload. The value moment is sending an approved
summary to a real client. The first return signal is beginning a second weekly
cycle without a founder reminder.
Boundary: eight qualified studios, one project lead and two meeting cycles per
studio. One upload path, one summary format, review and correction, and export.
No client portal, calendar sync, task tracking, template library, or archive
search.
Manual work: founder reviews every generated claim before the lead sees it.
Record review minutes, corrections, upload repairs, reminders, and support.
The lead must approve the text before export; failures remain visible and raw
notes are handled only under the test's stated data boundary.
Success: three studios complete two cycles, send at least one summary to a real
client, begin the second cycle without a reminder, and require no more than
thirty minutes of founder review per summary by that cycle.
Change path: if leads approve but do not send, investigate trust and output
quality. If they send once but do not return, revisit segment, frequency, and
activation friction. If corrections remain bespoke, narrow the segment or stay
manual. Stop summary automation if fewer than two of the eight project leads
send a summary after onboarding.
The thresholds are choices made for this bounded example, not universal MVP benchmarks. Their value comes from being declared before the founder knows the result and from pointing to different actions when behavior breaks at different places.
Close the Experiment Before Extending It
Do not change the segment, cutoff, or threshold to rescue a weak result. Close the card at the agreed boundary, compare what happened with the written branches, and use the Experiment Results Memo to preserve the interpretation. A successful MVP earns a next decision; it does not prove the whole product, distribution channel, or scalable system.
If manual delivery is itself the next source of evidence, carry the boundary into the Concierge MVP Plan. If the card still cannot name the behavior, burden, cutoff, and consequence, return to the cheaper evidence rung. The experiment is not ready to consume customers or founder capacity.