Validation: is the problem worth solving?

You may have heard the same complaint in three Reddit threads, an X post, and two customer conversations. That's enough to investigate, but is it enough to make your customers part with their cash? Before you build, you need to understand whether your solution solves a problem that feels urgent.

This is problem validationChecking whether a recognizable group experiences a problem often or painfully enough to spend time, effort, or money dealing with it.: checking that a recognizable group of people experiences the problem often or painfully enough to do something about it. Solution validationChecking whether your proposed way of solving a known problem works for the intended customer and creates enough value for a real commitment or payment. comes afterwards, when you test whether the way you propose to help works - and whether somebody will pay for it.

The output from this chapter is a one-page problem evidence record. It gives you enough evidence to make your next decision, while keeping any uncertainties visible.

Start with a person and an event

Your finished ideal customer profile comes later. For now, name a group that feels within reach, described specifically enough that five plausible people share the problem you want to solve.

“Small business owners” covers somebody selling ceramics at a market and a 150-person accountancy firm. So consider your starting group as specifically as, for example, “independent accountants who prepare monthly reports for several clients” - this gives you a shared situation to investigate.

Let's start with five to ten conversations as a practical first round. Some of those need to be with strangers. Friends, former colleagues, and people who already want you to succeed are easy to reach, but their kindness will skew your result: a stranger has less reason to protect the idea (or your ego).

The best questions are related to a real event:

• When did this last happen?
• What were you trying to do?
• What did you do when it went wrong or became difficult?
• How much time or money did that take?
• Who else became involved?
• What have you tried before?
• What happened when you left it alone?

Y Combinator's guidance on user observation makes a similar separation between the pain, the need, and the solution; it recommends choosing the right person, observing where the problem occurs, and listening before presenting an answer. (Y Combinator, 1 August 2016)

What people have done tells you everything

The Mom TestRob Fitzpatrick's method for customer conversations, built around past behavior, current problems, and money or effort already spent, so praise isn't mistaken for demand. moves the conversation away from your idea and toward the person's life before you arrived with it. Questions about past behavior, current workarounds, and money already spent give you events to consider; asking “Would you buy this?” gives an unproductive yes or no. (The Mom Test)

Strategyzer makes the same distinction in its testing guidance: facts about past behavior tell you more than opinions about what somebody might do, and a participant investing more time, effort, reputation, or money gives you more information. (Strategyzer, 6 May 2021)

Why encouraging answers are so easy to collect

Most people want to be helpful, whether they're a friend who wants to encourage you, a stranger avoiding an awkward conversation, or somebody imagining that a more organized future version of themselves would buy or use the product. Speaking to strangers reduces the kindness problem; it doesn't remove it.

You bring your own hopes into the conversation, too. Once you've spent weeks thinking about a product, a supportive and positive-seeming answer from one person can be easier to remember than four conversations where people described the problem and what happened next. Keep the customer's words, what they did, and what you think it means on separate lines; a complaint can give you a reason to investigate while the lack of action leaves the urgency unproven.

Conversations and public discussions help you find repeated, recent complaints across interviews, Reddit, X, reviews, support forums, or sales calls; they can show that the problem is shared and give you the words people use for it. A public post only shows what somebody chose to publish, and you can't usually ask what happened next or how much it cost them.

“I would buy that” stays under stated intentSomething a person says they plan or expect to do, such as trying, buying, or recommending a product; the action hasn't happened yet. until the person follows through. When payment is possible, money changing hands is the result you want. A waitlist signup, booked call, shared data set, or agreed pilot may still help, but each one answers a smaller question; record the exact action and the question it has answered.

Research the pain point across more than one model

I run the same research brief through GPTThe family of AI models and assistants made by OpenAI; this chapter uses GPT as one of three separate routes through the same research brief., ClaudeThe family of AI models and assistants made by Anthropic; this chapter uses Claude as one of three separate routes through the same research brief., and PerplexityAn AI search and research product that returns answers with linked web sources; this chapter uses it as one of three separate routes through the same brief.. In my own research, each finds a different mix of real conversations, anecdotes, forum threads, competitor pages, and pricing information; one may find a discussion the other two missed, while another traces a claim back to a better original source.

Each report is worth reading on its own because the differences show you where the evidence is thin or contested. Once you've read all three, a separate synthesisCombining several research reports into one account while preserving their sources, disagreements, one-off findings, and missing information. pass can combine the repeated findings, keep the disagreements visible, and remove duplicated sources.

The process has five parts:

1. Fill in the context fields in the prompt generator below.
2. Use the generated research brief in GPT, Claude, and Perplexity, with web or deep-research access switched on where your account offers it.
3. Save each report with the model, date, and original links intact.
4. Open the sources behind the claims and quotes you expect to rely on. A search snippet or a citation the model couldn't access isn't customer evidence.
5. Paste the three reports into the synthesis prompt, then keep both the individual reports and the combined version in your validationChecking whether your current view of the problem, customer, and proposed product is supported by what people have done, including the limits and missing evidence that remain. record.

Prompt 1: Generate the deep-research brief

Purpose: Create one consistent research prompt that can be run separately through GPT, Claude, and Perplexity.

When to use it: Once you have a provisional customer group and a suspected pain point, before deciding that the available complaints represent a market.

Create a deep-research prompt that I will run separately in GPT, Claude, and
Perplexity. The prompt you produce must investigate a customer pain point using
current, traceable sources and real first-person accounts.

My context
- Product or idea: [what I may build]
- Product stage: [idea / prototype / lightweight MVP / pre-launch]
- Provisional customer group: [the recognizable group I'm researching]
- Suspected pain point: [what I think happens and why it causes a problem]
- Geography: [countries or regions that matter]
- Business model: [subscription / one-off purchase / service / marketplace / other]
- Expected price or price range: [known, assumed, or unknown]
- Competitors or alternatives I already know: [include manual work and doing nothing]
- Evidence I already have: [interviews, posts, behavior, spend, or none]
- Time period that matters: [for example, the past 24 months]
- Decisions this research needs to inform: [continue / change / park, next test,
  likely price, customer group, or another decision]
- Subjects or sources to exclude: [list]

Your task
Write one complete deep-research prompt that can be used unchanged in each of
the three models. It must instruct the researcher to:

1. Define the customer group and pain point being investigated, keeping any
   assumptions from my context labeled as assumptions.
2. Find evidence of when the problem occurs, how often it appears, what causes
   it, the consequences, the language people use, and what happens if they leave
   it alone.
3. Find what people already do about it, including manual work, homemade
   systems, staff time, existing products, consultants, and money spent.
4. Research direct competitors, indirect competitors, and the option of doing
   nothing. For each named competitor, collect the intended customer, promise,
   core product, current public pricing, pricing date, geography, and direct
   source URL.
5. Find first-person accounts from forums, Reddit, X, review sites, support
   discussions, specialist communities, and other places where the customer
   group discusses the problem. Include short exact excerpts of no more than 20
   words from any one source, with the speaker's context where available, the
   platform, publication date, access date, and direct URL.
6. Separate repeated accounts from repeated reporting of the same original
   source. Don't count copied, syndicated, or quoted material as independent
   evidence.
7. Include evidence that weakens or contradicts the suspected pain point, such
   as low urgency, satisfaction with current methods, unwillingness to switch,
   or a price too low to support the proposed business.
8. State which sources or communities the model couldn't access, where a claim
   relies on a search snippet or secondary report, and what needs manual
   checking.
9. Distinguish sourced facts, first-person accounts, estimates, and the
   researcher's interpretation.
10. Finish with the questions that still need customer interviews or a
    behavior-based test.

Source rules
- Prefer original competitor and pricing pages for product and price claims.
- Prefer direct forum posts, reviews, and discussions for first-person accounts.
- Use current primary research or public datasets for market figures where
  available.
- Use secondary sources only when the original is unavailable, and say so.
- Link to the exact page, post, thread, pricing page, or report. Don't cite a
  search-results page.
- Never invent a quote, person, source, price, statistic, date, or URL.
- If a source can't be opened, identify the limit and exclude its claims from
  the confirmed findings.

The deep-research prompt must request these output sections
## Research scope and assumptions
## What happens to the customer
## Frequency, urgency, and consequences
## Current workarounds and spending
## Competitors and current pricing
## First-person accounts and exact excerpts
## Evidence against the pain point
## Differences between customer groups
## What appears repeatedly across independent sources
## Source and access limitations
## Questions still unanswered
## Source ledger

Return only the finished deep-research prompt. Don't perform the research.

Prompt 2: Synthesize the three research reports

Purpose: Combine the research without losing the sources, disagreements, or findings that appeared in only one model.

When to use it: After you have read and saved the complete reports from GPT, Claude, and Perplexity.

I have three deep-research reports about the same customer pain point. Review
each report separately before combining them.

My context
- Product or idea: [what I may build]
- Provisional customer group: [the group being researched]
- Suspected pain point: [the starting assumption]
- Geography: [countries or regions]
- Business model and expected price: [known figures and assumptions]
- Decision I need to make: [continue / change / park / choose the next test]

Research reports

## Report A: GPT
[Paste the complete report, including its source ledger]

## Report B: Claude
[Paste the complete report, including its source ledger]

## Report C: Perplexity
[Paste the complete report, including its source ledger]

Your task
1. Summarize each report separately, including its best evidence, unique
   findings, source limits, and evidence against my starting view.
2. Deduplicate sources. Treat three models citing the same post, article,
   dataset, or company page as one source.
3. Group the first-person accounts by customer type, situation, pain point,
   consequence, workaround, and action or money spent. Keep different customer
   groups separate.
4. Identify findings that repeat across independent people and sources, along
   with findings that appear in only one report.
5. Build one competitor table showing direct and indirect alternatives,
   intended customer, promise, current public price, pricing date, geography,
   and original source. Keep conflicting prices or product claims visible until
   they're checked.
6. Build a short excerpt bank using only exact excerpts already present in the
   reports. Keep each excerpt to no more than 20 words and retain its direct URL,
   publication date, platform, and speaker context where available.
7. Separate sourced facts, first-person accounts, estimates, assumptions, and
   your interpretation.
8. List inaccessible sources, broken links, search-snippet claims, missing
   dates, and any quote or price that still needs checking.
9. Assess what the combined research says about frequency, urgency,
   consequences, current action, spending, willingness to switch, pricing, and
   whether the customer group is too broad.
10. Recommend the next interview question or behavior-based test that would
    resolve the most important gap. Don't describe the problem as validated
    unless the reports contain direct evidence of action or payment.

Rules
- Never invent or repair a quote, source, URL, date, price, statistic, or
  customer detail.
- Don't decide by majority vote between the models; source quality and direct
  evidence decide which claims can be used.
- Preserve disagreements and negative findings.
- If a source isn't present in the reports and you can't access it directly,
  leave it out and say what needs checking.
- Keep each individual report available alongside the synthesis.

Return exactly these headings
## GPT report
## Claude report
## Perplexity report
## Findings repeated across independent sources
## Findings found by one model
## Customer pain, consequences, and current action
## Competitors and current pricing
## First-person excerpt bank
## Evidence against the starting view
## Conflicts and checks required
## What remains unknown
## Next interview question or behavior-based test
## Combined source ledger

Repeated complaints with no action need a faster test

Some solvable problems have no obvious paid tool or current workaround. The technology may have only recently made a solution possible, the problem may happen rarely, or people may have accepted an aggravation because the known alternatives feel too much like hard work.

Repeated complaints are enough to keep investigating in these cases. They also make a lightweight test more of a must-have than a nice-to-have, because another ten conversations might leave you with a well-researched complaint and still no paying customers.

The test might be a by-hand version of the proposed service, a narrow MVPMinimum viable product: the smallest usable version of an idea that lets you learn whether it creates value for real people., a paid pilot, a deposit, or a pre-launch offer with a meaningful commitment:

• A manual service can show whether the outcome helps.
• A paid pre-launch test can show whether somebody will accept the price and timing
• A prototypeAn early representation of how a product could work, created so you can learn from it before the full product is built. can show whether a person understands and can use the proposed approach.

This is also where you can find yourself losing months validating a solution that nobody asked for. A polished prototype can produce detailed feedback on UI, features, and wording while the root of your validation remains untouched. The first test needs to match that first important question: "Will anybody actually care?"

Check whether the problem leaves room for a business

A problem can be frequent, painful, and commercially awkward. There may be too few suitable buyers, the market may already be closing, or the cost of reaching and serving each customer may leave no room for the price they will accept.

A short set of working numbers is enough at this point, because the aim is to notice a commercial problem before building around it:

• roughly how many plausible buyers have this problem;
• how often it occurs and how much the consequences cost them;
• what they already pay for alternatives, including staff time or manual work;
• what you think they may pay, clearly marked as an assumption until tested;
• what it may cost you to reach, sell to, onboard, and serve one customer (and can you charge enough for your product above this number to make it all worthwhile?);
• whether the market is growing, settled, crowded, or likely to arrive later.

Your unit economicsThe revenue and direct costs associated with serving one customer or completing one transaction. are the revenue and direct cost attached to one customer or transaction. Early estimates will be rough, but the question still stands: if the likely price can't cover delivery and a believable route to acquiring the customer, the product, price, customer, or delivery method needs to change.

Stripe's guidance on new-product pricing recommends examining customer value, existing alternatives, delivery costs, break-even points, and margins together; its acquisition guidance defines customer acquisition cost as sales and marketing cost divided by new paying customers. (Stripe, new-product pricing; Stripe, customer acquisition cost)

These numbers belong in the evidence record as your core assumptions from which you'll eventually build a business plan or financial model.

Match the next test to the evidence you have

The evidence you have determines what it's reasonable to test next. Repeated complaints give you enough reason to investigate through a small trial; when people are already changing their behavior or spending money, you can ask whether they'll commit to your version of the solution.

When payment can't happen yet

Immediate payment is sometimes the wrong thing to test because the buying process, law, timing, or product structure prevents it. In those cases, ask for a concrete action involving time, budget, access, or reputation, and record the proof you still don't have.

Continue, change, or park

The same evidence won't produce the same answer for every business, and trying to put an arbitrary score or number on it hides the judgment you need to make. So, considering the above, let's look at making one of three decisions:

1. Continue building as you were when the same problem appears in recent, specific examples from a recognizable group and you have a credible next test. Existing action or spend gives you more confidence; a successful lightweight test may provide the first commitment where no workaround existed before. Your rough market and economics check still needs to be economically viable.

2. Change the problem or provisional audience when the evidence clusters around a different problem, a narrower group, or a different person in the buying process. Record what changed, otherwise your next interviews will be run against out-of-date information.

3. Park for now when the problem rarely repeats, nobody acts after a fair test, the available market is too small for the business you want, the economics don't work, or the timing is too early. “For now” needs a condition: a law changes, a technology becomes affordable, buyers begin using a workaround, or a new group starts describing the problem without being prompted.

Your problem validation record

The problem validation record holds the evidence in one place: who you spoke to, what happened to them, what they did, what it cost, what contradicts your view, the rough commercial math, and what evidence is still missing.

The record also gives each conversation or observation its own row. That stops three vivid comments being compressed into “customers often say,” and it makes disagreement visible when the notes point in different directions.

A prompt to review your validation evidence

Purpose: Review interviews, observations, and public examples without turning weak or mixed evidence into a confident market story.

When to use it: After each conversation, and again when you have a first batch of five to ten.

I need to decide whether a problem deserves the next stage of work.

My context
- Product stage: [idea / prototype / lightweight MVP / pre-launch]
- Provisional customer group: [the recognizable group I'm investigating]
- Problem as I currently understand it: [one or two sentences]
- Business model: [how I expect the product to make money]
- Likely price or price range: [mark this as tested or assumed]
- Likely cost to reach and serve one customer: [known figures and assumptions]
- Market information: [demand, approximate number of suitable buyers,
  alternatives, saturation, timing, and sources]
- Interviews and observations: [paste each item separately, with the source,
  date, exact words where needed, what happened, what the person did, and any
  money, time, effort, reputation, or access they committed]
- Limits: [buying cycle, regulation, sensitivity, rare timing, marketplace or
  network requirements, access, money, or technical limits]

Your task
1. Review every interview or observation separately before comparing them.
2. For each item, extract the real event, consequence, current action or
   workaround, money or effort spent, frequency, urgency, and evidence against
   my current view.
3. Mark hypothetical buying statements, compliments, leading questions, and
   claims with no follow-through. Don't treat them as payment or demand.
4. Compare the full batch. Identify repeated patterns, meaningful differences,
   and outliers without merging different customer groups or problems.
5. Assess the rough commercial case: plausible number of buyers, likely price,
   direct delivery cost, likely acquisition effort or cost, and market timing.
   Keep every untested number labeled as an assumption.
6. Recommend one current decision: continue, change the problem or provisional
   audience, or park for now.
7. Recommend the smallest next test that could change that decision. Where
   immediate payment is possible, include a payment or paid commitment. Where
   it isn't possible, explain why and ask for a concrete action involving time,
   budget, access, or reputation.
8. List the information that is missing.

Rules
- Don't invent customer behavior, quotations, market facts, payment, usage,
  costs, or results.
- Distinguish facts, assumptions, interpretations, and recommendations.
- Preserve disagreement and negative evidence.
- Don't turn repeated complaints into proof of willingness to pay.
- Don't treat a hypothetical “yes” as a purchase.
- Say when the evidence can't support a decision.
- Produce working material I can copy into my evidence record.

Return exactly these headings
## Individual evidence review
## Patterns across the batch
## Evidence against my current view
## Commercial assumptions
## Strongest evidence I have
## Evidence still missing
## Current decision
## Reason for the decision
## Next smallest test
## Reopening condition (only if the decision is park for now)
## Next review

Good enough for now

Your record is ready to use when you can describe a repeated problem for a recognizable group, show the recent examples behind it, separate complaints from action or payment, and explain the rough commercial assumptions you still need to test. The final line names one current decision and the next test or reopening condition.

The next chapter is Your first customer. It begins with the provisional group and problem you have recorded here, then helps you find that one person whose real use and buying behavior can teach you more than another round "yep, looks great!"

Sources

• Fitzpatrick, Rob. The Mom Test. Accessed 11 September 2026.
• Luo, Lucy. “Business Testing: Is Your Hypothesis Really Validated?” Strategyzer, 6 May 2021. Accessed 11 September 2026.
• U.S. Small Business Administration. “Plan Your Business: Market Research and Competitive Analysis.” Accessed 11 September 2026.
• Stripe. “CAC in SaaS: How to Calculate, Benchmark, and Improve Customer Acquisition Cost.” Updated 30 July 2025. Accessed 11 September 2026.
• Stripe. “Pricing Strategies for New Products.” Accessed 11 September 2026.
• Y Combinator. “Practical Design: User Observation.” 1 August 2016. Accessed 11 September 2026.