Fictional example. No customers were interviewed and no source research was run. AI research, not verified demand. Read cited pages and test with actual customers before investing in a build. Buyer and channel suggestions are hypotheses.
Run a demand test first
Test whether leftover planning is painful enough to change an existing routine. A full app would be premature; a manually prepared plan can test the core value.
Who might buy?
Start with parents who already cook family dinners and pack school lunches most weekdays. Do not assume every parent has this problem or would pay to solve it.
Where could you reach them?
A local parent association could help recruit interviews if an organizer permits it. Permission, relevance and acquisition cost are unknown; no community is a guaranteed distribution channel.
Your smallest next test
Recruit 10 parents who packed at least four lunches last week. Ask about their most recent planning experience, then offer a clearly described manual one-week leftover lunch plan. Before recruiting, propose a threshold: at least 3 accept a concrete paid pilot offer and at least 2 actually use the plan. If not, change the customer/problem hypothesis before coding. This threshold is a planning hypothesis, not a validated success predictor.
Still unknown
Whether the difficulty is planning, picky eating or remembering leftovers; whether parents will switch from free routines; willingness to pay; food preference and safety constraints; time needed to deliver a useful plan.
Signals worth investigating
Illustrative finding · not real evidence
In this fictional example, a parent already repurposes dinner leftovers but finds the nightly decision tiring. That suggests a specific job to investigate.
What this does not prove: One invented account illustrates the report format. It establishes no real pain, prevalence or demand.
Inspect the evidence behind this claimFictional parent conversation
Fictional source for product demonstration
Invented example passage
I use leftovers already. Deciding what will work for lunch is the part I have to think about every night.
Reasons to hesitate
Illustrative finding · not real evidence
In this fictional example, another parent is satisfied with a reusable weekly list. A free routine may solve the problem well enough.
What this does not prove: An app must improve on an adequate free workaround. This invented counterexample is not market research.
Inspect the evidence behind this claimFictional satisfied-parent account
Fictional source for product demonstration
Invented example passage
We repeat a short list each week. I would not want another app to manage it.
PainMonkey · Before-you-build test record · illustrative-lunch-example
Leftover Lunch
FICTIONAL DEMO PRACTICE - not customer evidence.
Founder-entered record, not independently verified. Plan locked: Not started.
Eligible audience
Parents who pack school lunches at least four days a week
Recent problem
Planning school lunches around dinner leftovers without a second planning routine
Honest offer
Not yet recorded
Price and terms
Not yet recorded
Recruitment and permission
Not yet recorded
Buyer hypothesis — founder assumptions, not a validated ICP
Who would use it? Unknown — ask, do not guess
Who controls the budget? Unknown — ask, do not guess
What makes the problem urgent now? Unknown — ask, do not guess
What do they use or do today? Unknown — ask, do not guess
Ask for recent examples before sharing these assumptions. Record contradictions as well as support; a role description is not a contact list or permission to recruit.
Proposed rule - not locked
3 payments or attended trials and 2 uses among 10 eligible approaches. Proposed, not a calibrated benchmark. A person who pays and attends counts as one commitment.
No payment evidence recorded. Attendance and positive replies do not establish willingness to pay.
Keep declines and no replies in the record. Wait for your planned sample before interpreting the rule.
Convenience sample; founder-entered outcomes are not independently verified. Not a market conversion estimate or a business-success probability.
Outcome-window review: Not confirmed; outcomes may still be pending. Founder-declared, not independently verified.
Next decision: Make the test runnable
No customer behavior is recorded yet. The next investment is a clear offer, not app development.
Describe one result you can deliver manually, what is not included, the price or free-trial terms, and a realistic delivery date.
Choose a specific eligible group and a permitted way to reach them. Record the response and trial window in your recruitment plan.
Set the sample and screening rule before approaching people, then lock this plan.
Planning guidance, not a prediction. Let the same promised response and trial window pass for everyone before interpreting missing outcomes. Keep pending outcomes distinct in your notes; update them when known. Do not rewrite this test’s offer or rule after seeing results.
Cost scenario — estimates only
Cost scenario — founder estimates, not observed revenue or a forecast
Basis: one purchase
Price per customer ($): Not estimated
Delivery, AI, fees and expected refunds per customer ($): Not estimated
Cost to acquire one customer ($): Not estimated
Fixed costs for this period ($): Not estimated
Service and support hours per customer: Not estimated
Complete every estimate to calculate; missing costs are not assumed zero.
Excludes taxes, founder development time, unpaid acquisition effort and costs not entered. Deposits may not be earned revenue. This does not change the locked customer offer or prove people will pay.
Anonymous outcome log
No approaches recorded.
From research to a real-world test
Your before-you-build sprint
Turn a promising question into an honest offer. Record what people actually do—not whether they say your idea sounds good.
Practice with this fictional example. Nothing entered here is saved.
Three questions to ask before pitching
Tell me about the last time you dealt with “Planning school lunches around dinner leftovers without a second planning routine”. What happened?
What did you do instead? What did that cost in time, money or effort?
What works well about your current approach, and what have you actually tried changing?
Listen for recent examples and adequate workarounds. Do not count your own demo practice as customer evidence.
Set your offer and test ruleRecruitment kit: who to ask and what to say
DRAFTS ONLY. Personalize, check every statement and replace all bracketed placeholders before using. These drafts are not evidence of demand, channel permission or legal compliance. PainMonkey does not send messages or collect contacts.
Complete these plan fields to fill the drafts: offer, price, channel. Remaining bracketed details always need your review.
Before you recruit
Check current channel rules and obtain any required organizer permission before posting. An indexed forum page is not permission to recruit there.
Use one clear eligibility rule, offer and response window. Log every eligible approach, not just enthusiastic replies; organizer responses are not customer outcomes.
Keep interviews separate from the offer. Do not treat politeness, hypothetical willingness to pay or a booked-but-unattended call as payment or use.
Use anonymous labels in PainMonkey. Keep contact details and any necessary consent records in your own appropriate system; avoid sensitive details in this worksheet.
Do not accept payment until you can deliver and honor the terms. Honor declines; do not scrape contacts, send bulk unsolicited messages or invent scarcity.
Check the person, the problem and the buyer
Your buyer assumptions to check—not a script to read aloud
Buyer hypothesis — founder assumptions, not a validated ICP
Who would use it? Unknown — ask, do not guess
Who controls the budget? Unknown — ask, do not guess
What makes the problem urgent now? Unknown — ask, do not guess
What do they use or do today? Unknown — ask, do not guess
Ask for recent examples before sharing these assumptions. Record contradictions as well as support; a role description is not a contact list or permission to recruit.
What in your recent experience makes you part of “Parents who pack school lunches at least four days a week”?
Tell me about the last time you faced “Planning school lunches around dinner leftovers without a second planning routine”. When was it, and what did you actually do?
What works well about that approach? What time, money or effort did it actually take?
Who would use a solution, who would approve it, and who would pay? Are those different people?
What have you already tried changing, if anything? What happened?
These questions test your audience hypothesis; they do not identify a proven buyer automatically. Copy a draft and personalize it outside this app.
Ask the organizer firstInvite a willing participant to talkMake a separate, honest pilot offer
3. Read the outcome without inflating it
Approached
0
Replied
0
Attended
0
Paid / deposit (gross)
0
Fully refunded
0
Refund status unchecked
0
Checked: not fully refunded
0
Used
0
Plan not started
Keep declines and no replies in the record. Wait for your planned sample before interpreting the rule.
No payment evidence recorded. Attendance and positive replies do not establish willingness to pay.
Convenience sample; founder-entered outcomes are not independently verified. Not a market conversion estimate or a business-success probability.
4. Your next decision: Make the test runnable
No customer behavior is recorded yet. The next investment is a clear offer, not app development.
Describe one result you can deliver manually, what is not included, the price or free-trial terms, and a realistic delivery date.
Choose a specific eligible group and a permitted way to reach them. Record the response and trial window in your recruitment plan.
Set the sample and screening rule before approaching people, then lock this plan.
Planning guidance, not a prediction. Let the same promised response and trial window pass for everyone before interpreting missing outcomes. Keep pending outcomes distinct in your notes; update them when known. Do not rewrite this test’s offer or rule after seeing results.
Could a sale cover its costs? (optional estimate)
These are your assumptions, not customer results. Editing them does not change the locked offer or process any payment. Leave unknowns blank; do not quietly assume zero.
For a subscription, include the full acquisition cost in month one. This is not lifetime value or an estimate of retention.
Complete every estimate to calculate. Missing costs are not assumed zero.
Excludes taxes, founder development time, unpaid acquisition effort and costs you have not entered. Refundable deposits may not be earned revenue. Do not use this estimate as proof of profitable demand.