Your Mom Is Not Product-Market Fit

Your mom thinks your app is wonderful. This is valuable information about your mom and almost no information about your market.

Compliments are cheap because they cost the giver nothing. Buying, switching tools, inviting a colleague, or returning next week costs something. Your job is to find that behavior, not win a popularity contest with a demo.

First, describe a problem small enough to recognize

“Small businesses need better productivity” is a fog machine. “Independent bookkeepers spend Friday reconciling invoices that clients send in five different formats” gives you someone to talk to and a workflow to observe.

Write three things before writing another line of code:

• Person: a specific role, situation, and constraint.
• Moment: the event that makes the problem matter.
• Current workaround: what they do today, including doing nothing.

If you cannot name a workaround, the problem might be aspirational. A wish is not automatically a purchasing decision.

Ask about the last time, not the imaginary future

In a 20-minute conversation, postpone the demo. Ask:

1. “Walk me through the last time this happened.”
2. “What did you do, step by step?”
3. “What made that annoying or expensive?”
4. “What have you tried instead? Why didn’t it stick?”
5. “Who decides whether to change the process?”

Do not ask “Would you use my amazing solution?” You have supplied the answer and made politeness the easiest exit. Ask to see a real artifact when appropriate, with private information removed: a spreadsheet, a checklist, an anonymized support ticket. Evidence beats nodding.

Keep a record of the person’s actual words, the observed workaround, its frequency, and the consequences. Separate facts from your interpretation. “They said it was annoying” and “they lose two paid hours every Friday” are different kinds of evidence.

Make a test that can disappoint you

Suppose you want to automate invoice reconciliation. Instead of building a platform, offer to reconcile one anonymized batch manually for three bookkeepers. Agree on what a useful result looks like before doing the work.

A useful test statement might be:

Within two weeks, three of eight bookkeepers who recently experienced this problem will agree to try one batch, and at least two will ask to use the result again.

Those numbers are an example, not a universal standard. Pick thresholds that fit your access to customers, price, and sales cycle. Write them down before results arrive; otherwise your brain will move the goalposts with Olympic confidence.

A landing page can test whether a message earns a response. It cannot prove retention. A payment can test willingness to pay. It cannot prove that your product solves the problem well enough to keep paying. Label what each experiment actually measures.

Look for pull, not just permission

Early positive signals include people bringing a second real task, asking when they can use the product again, introducing a colleague with the same problem, or spending time to overcome an inconvenient onboarding step.

None is a magic product-market-fit certificate. Track behavior across a few cycles of the workflow. A weekly tool needs evidence next week, not just ten minutes after launch.

When someone stops, ask what they did instead. “Too busy” may mean your product was less urgent than the workaround. Don’t argue them into becoming evidence.

Your next seven days

Choose one narrow customer situation. Find five people who recently lived it. Run conversations without a pitch. Sort the evidence by frequency and consequence. Then offer one small, real test to the people with the clearest pain.

At the end, decide whether to continue, narrow the customer, change the problem, or stop. Stopping an unsupported idea is progress; building six months of infrastructure for it is a very elaborate coping mechanism.

Call your mom afterward. She can be proud of you without joining your validation spreadsheet.