Solo Founder Product Engineering Handbook
GTM Test Plan
Design a small go-to-market test that shows where the path from reaching a prospect to earning customer action holds or breaks.
Distribution Is a Chain
A useful product can still be unreachable, difficult to explain, or impossible for one founder to sell repeatedly. Those are different failures. A burst of attention does not reveal which one occurred.
Use this plan to run one small distribution test before a launch, outreach sequence, community post, directory listing, partnership, referral request, content experiment, or founder-led demo. Return to it when a channel creates activity without qualified conversations, or when every new customer requires effort the founder cannot sustain.
Bring the ICP one-pager, positioning-to-scope map, pricing hypothesis, the strongest honest proof available, and a list of specific places where the intended customer already pays attention. The plan should fit on one working page and produce a decision within a short review window. It is an experiment in reach and response, not a miniature launch campaign.
Write One Testable Claim
Complete this sentence before preparing copy or buying a tool:
For [specific person] during [painful or timely moment], I can use [one channel] to present [promise] with [honest proof] and earn [one next action]. I will make [bounded number of attempts] by [review date], spend no more than [time and money boundary], and [continue, change, or stop] when [observed condition].
“Post about the product and see what happens” cannot fail clearly enough to teach. A bounded claim forces the founder to name the person, occasion, route, promise, proof, and behavior under test. It also protects the week: the test ends even if the founder still feels that one more post might work.
Do not combine several audiences, channels, or messages in the first run. When everything varies, every interpretation becomes a story.
Prepare the Working Page
Audience, moment, and reachable list
Name the role and segment narrowly enough that a real person can either belong or not belong. Add the event that makes the problem timely: a recurring report, a failed handoff, a compliance request, an approaching renewal, or another visible trigger. “Small businesses” is not a test audience.
Then assemble the actual reachable list or location. Record why each contact or community fits. A channel is not “email” or “social”; it is the particular source of qualified people the founder can reach without violating platform rules, community norms, privacy expectations, or an opt-out. If finding each suitable contact consumes an hour, that cost belongs to the result.
Message, proof, and one action
Write the message in the customer’s language: the moment, the current alternative, and the promised improvement. Show only proof the product has earned—a sample output, working demo, measured manual result, customer-approved quotation, or clearly labeled prototype. Do not borrow credibility from imagined customers or imply a mature service operation that does not exist.
Ask for one observable next action. A reply with a workflow sample, a booked problem call, a paid review, or a completed trial produces different evidence; choose the action that answers the present uncertainty. Multiple calls to action make hesitation impossible to interpret.
Attempts, review window, and founder budget
Choose a bounded set of qualified attempts and a date when every response will be reviewed. The first test is directional evidence, not a precise acquisition forecast. Twenty careful approaches can expose a broken list, incomprehensible promise, or repeated objection; they cannot establish a universal conversion rate.
Budget preparation, contact research, sending, follow-up, calls, onboarding, and delivery. Include cash and tool cost. A channel that produces customers only through unsustainable founder labor has revealed an operating constraint, not a repeatable motion.
Follow-up and learning record
Prepare the next step before creating interest. Decide who can be accepted, what the founder will send or schedule, how quickly to respond, and where the product’s current capacity ends. Demand that falls into an improvised demo, unclear pilot, or missing onboarding path cannot test conversion honestly.
A simple ledger is enough. Give every attempt a date, source, audience-fit note, message version, delivery result, response, stated objection, next action, outcome, and founder time. If links, forms, or booking pages are involved, preserve the source and message version without collecting data the decision does not require. Memory, page views, and a crowded inbox are not a learning record.
Modeled Test: A Client-Change Digest
This modeled example continues the fictional field-service product used in the preceding templates. It demonstrates the plan; it is not market evidence.
The founder wants to reach operations managers at small field-service companies when they are preparing recurring client updates. The proposed channel is a carefully researched email list drawn from public company and role information. The promise is a source-linked digest that identifies job records changed since the previous update. The proof is a labeled sample built from fictional records, and the requested action is a reply with a redacted export for one manual review.
The founder will send twenty individual messages over five business days, with one follow-up, and review the run two days later. Research, sending, replies, and sample reviews may consume no more than twelve founder hours. Each contact must match the chosen company size, role, and reporting moment. The founder can accept at most three manual reviews and has already written the data-handling and deletion boundary for them.
The first decision is not “email works.” If messages are delivered but qualified managers do not recognize the reporting problem, the pain or timing may be wrong. If they recognize it but cannot understand the digest, the message or sample needs work. If they reply and then refuse to share a redacted export, the proof and trust boundary need attention. If several request the review but each requires bespoke data repair, the channel has found interest while exposing a product and delivery problem.
Read the Break in the Chain
Review the attempts together, including silence. Separate delivery failure from lack of response, unqualified interest from target-customer interest, polite replies from the requested action, and conversion from successful delivery.
Continue the channel only when qualified people are reachable, understand the promise, take the next action, and can enter a follow-up path the founder can operate. Repeat with a new batch to see whether the result survives beyond the first list.
Change the message or proof when the right people are reached but misunderstand the offer or doubt the claim. Change the audience or timing when respondents understand the offer but lack the problem, urgency, authority, or budget. Change the channel when qualified people cannot be reached there without excessive cost or rule-breaking. Change the offer or delivery system when interest converts into work the product cannot absorb.
Do not answer every objection with a feature. An objection may locate the wrong customer, a weak promise, insufficient proof, a trust gap, or an uneconomic route to market. The test is complete when the founder can identify where the chain held, where it broke, and which single uncertainty deserves the next run.
Continue reading
Full table of contents