Solo Founder Product Engineering Handbook
PMF Survey Kit
Run a product-market-fit survey that identifies who would miss the product, why, and whether their behavior agrees.
Ask About Loss, Then Look for It in Behavior
A customer can like a product, praise the founder, and still leave without much inconvenience. A product-market-fit survey asks a harder question: who would feel the product’s absence, and what would they lose?
Run this survey after a defined group has experienced the product’s core value. Use it to find a segment and benefit worth investigating, not to award the business a PMF certificate. The answers remain claims until retention, use, payment, referrals, or replacement behavior support them.
Before sending anything, write the decision the survey must inform:
PMF SURVEY — [DATE]
Decision this survey must inform:
Product and version:
Core value moment:
Eligible user definition:
Recent-use window:
Segments declared before analysis:
Behavioral evidence available:
Response window:
Next review date:
The eligibility rule is part of the result. “Everyone who signed up” mixes people who received value with people who met an empty screen. A useful rule might require two completed reporting cycles in the last month, or two successful API calls in the last two weeks. Match the rule to the product’s natural value cycle. Exclude the founder’s friends, test accounts, employees, and users who never reached the value moment; record the exclusions rather than quietly cleaning the sample later.
The Survey
Keep the form short enough to answer while the experience is still specific. Send the same wording to the whole eligible cohort.
1. How would you feel if you could no longer use [PRODUCT]?
[ ] Very disappointed
[ ] Somewhat disappointed
[ ] Not disappointed
[ ] I no longer use the product
2. What type of person or team do you think would benefit most from
[PRODUCT]?
3. What is the main benefit you receive from [PRODUCT]?
4. What would you use instead if [PRODUCT] were unavailable?
5. What is the main thing that would make [PRODUCT] more useful to you?
6. May I contact you for a 20-minute follow-up?
[ ] Yes
[ ] No
Do not turn the improvement question into a roadmap vote. A requested feature may describe a real obstacle, a preference, or an attempt to turn a narrow product into the respondent’s private tool. The main benefit and alternative usually reveal more about the product’s position than a frequency count of feature requests.
If the product serves several roles or jobs, attach known account and behavior data rather than asking the respondent to reconstruct facts you already have. Collect only data needed for the decision, restrict access to identifiable answers, and honor the promised use of the response.
Build a Response Ledger
Keep raw answers intact. Add interpretation in separate fields so a vivid quote does not silently become a finding.
response_id | user_or_account_id | received_at | eligibility_evidence
declared_segment | actual_role_or_job | disappointment_answer
main_benefit_verbatim | beneficiary_verbatim | alternative_verbatim
improvement_verbatim | follow_up_allowed | recent_value_events
retention_or_renewal_state | payment_state | founder_assigned_theme | notes
Survey each person once per study. Repeatedly asking the happiest customers creates a trend out of duplicate enthusiasm. Preserve the cohort definition, wording, response window, and raw counts so a later survey can be compared honestly.
Read Counts Before Percentages
Start with the four answer counts. For the commonly used PMF score, divide eligible “very disappointed” responses by the eligible responses that chose very, somewhat, or not disappointed. Declare that denominator before reading the result. Report “I no longer use the product” separately rather than silently discarding it; those answers may expose a stale eligibility rule or a retention problem.
eligible people invited:
valid responses:
very disappointed:
somewhat disappointed:
not disappointed:
no longer use:
response rate:
very-disappointed share:
The often-cited 40 percent line is a heuristic derived from comparisons among startups, not a statistical law. Crossing it is a reason to investigate a concentration of dependency. Missing it is a reason to learn, not an order to pivot. With twelve responses, five “very disappointed” answers produce 42 percent, but the evidence is still five people. Keep the count visible and do not let a decimal imply certainty the sample cannot support.
Next, read the words of the “very disappointed” respondents together. Look for a shared job, role, trigger, benefit, or abandoned alternative. Then read the “somewhat disappointed” answers: they may reveal adjacent users who value the same core benefit but face one repeated obstacle. Do not merge unrelated segments to improve the headline, or slice the data repeatedly until one tiny group clears a threshold.
For each credible segment, complete this record:
SEGMENT READING
Segment and qualifying behavior:
Respondent count and answer counts:
Shared job or trigger:
Benefit described in the respondents' language:
Current alternative:
Behavior that supports dependency:
Behavior that contradicts dependency:
Repeated obstacle among somewhat-disappointed users:
What remains unknown:
Make the Survey Argue With the Product Data
Survey enthusiasm and behavior answer different questions. A respondent may fear losing a product they use only when the founder reminds them. Another may understate attachment while renewing, inviting coworkers, and completing the core workflow every week.
Cross-check each promising segment against the natural value cycle:
- Did users return without a rescue message?
- Did they complete the value-producing action, not merely log in?
- Did paid users renew at ordinary terms?
- Did adoption spread to another person or workflow?
- Did support and manual delivery remain sustainable for one founder?
- Did churned users choose the alternative named in the survey?
Do not average these into a second magic score. Write the agreement or contradiction in plain language. Strong stated dependency with weak retention may mean the product promises an important outcome but delivers it unreliably. Strong retention with weak stated dependency may mean habit, switching cost, or a useful but replaceable utility. Each diagnosis calls for a different test.
Finish With One Segment and One Test
PMF SURVEY DECISION
Segment worth serving more deliberately:
Core benefit to protect:
Evidence that makes this segment credible:
Contradiction that prevents a stronger claim:
User to interview next and why:
One acquisition, activation, product, or reliability test:
Founder effort allowed for the test:
Behavior expected by the next value cycle:
Result that would reject this interpretation:
What will not be built or scaled yet:
Review date:
When stated dependency clusters in one segment and agrees with retained, repeatable, product-delivered value, recruit more people like that segment and test whether the pattern survives. When answers are diffuse, return to the customer and job before adding features. When one obstacle repeatedly blocks otherwise committed users, run the smallest change that can remove it and observe another value cycle.
The survey is complete when it narrows the founder’s attention. It should name whose loss matters, what they would lose, what their behavior confirms, and the next piece of evidence the product must earn.
Continue reading
Full table of contents