Why "Our Pain Point Is Huge" Doesn't Work with Reviewers

#

Founders and reviewers read a business plan from completely different starting points. Founders have lived the problem firsthand, so the word 'huge' feels self-evident. Reviewers must evaluate an unfamiliar problem in a matter of minutes. If no evidence backs up the claim of 'huge,' they move on.

In a review context, 'our pain point is huge' is a claim. Claims only become evaluable when supported by evidence. Unsupported claims get skipped. Most founders don't understand this dynamic — they operate under the assumption that because they feel the pain, the reader will too.

The reason reviewers don't trust adjectives is simple: adjectives can't be verified. There's no way to check whether something is truly 'inefficient.' By contrast, '8 out of 10 people we interviewed brought up the same pain point unprompted' is a reproducible claim. Reviewers trust numbers and behaviors — not words that describe intensity.

#

Pain exists on a spectrum. Reviewers apply two implicit tests. First: how do people behave when they can't avoid this pain? Second: are they already spending money or time to deal with it? If the plan doesn't answer both questions, reviewers have no way to assess pain severity.

The key row in the table is workaround behavior. If the pain is truly business-stopping, people will do something about it — even if imperfect. They'll manually aggregate data in spreadsheets, cobble together multiple apps, or outsource the task. Those workarounds themselves prove the magnitude of the pain. If there are no workarounds, that's a signal the pain is still at the annoyance level.

When a reviewer asks 'How are you solving this today?' it's not an attack. They're checking whether workarounds exist and how complex they are. A founder who can answer with specific behaviors is in a completely different position from one who says 'People just put up with it.'

#

Quantifying pain means converting adjectives into behaviors, frequencies, and costs. If even one of the four methods below is absent from your plan, reviewers have no basis to conclude the pain is real.

1. Customer interviews — record mention frequency and emotional intensity. Note how many of your interviewees brought up the same pain unprompted, and distinguish between 'It's a bit annoying' and 'I stayed up all night because of this.' The unprompted mention rate and emotional intensity are your first tier of pain evidence.
2. Behavioral data — verify that workarounds exist and how complex they are. Document exactly what customers are doing today to address the problem. The number of spreadsheet files, outsourcing costs, and hours of manual work are all measurable inputs — those are your numbers.
3. Willingness to pay — start from current spending on alternatives. 'How much would you pay for this?' is a bad question. Instead, ask 'What are you currently spending to deal with this problem?' The mere existence of customers already paying for something proves the market is real.
4. Occurrence frequency — document how often the pain happens. Something that inconveniences people once a day is a very different business opportunity from something that triggers on every transaction. Pain frequency is also the foundation for your market size estimate.

You don't need all four. But if you have none, your claim that the pain is real simply doesn't hold up. At minimum, include one interview data point — how many people you spoke with, and how many of them mentioned the same pain.

#

The same problem can produce very different review outcomes depending on how it's written. Below are two ways to describe the same problem. Notice how the shift from adjective-driven to evidence-driven writing changes the reviewer's response.

The core of the rewrite is replacing adjectives with behaviors, numbers, and frequencies. 'Inefficient' becomes 'X hours per week spent on manual work.' 'Inconvenient' becomes 'X out of X people built their own workaround tool.' If the problem is real, this conversion isn't hard. If it is hard, that's a signal that customer validation isn't complete yet.

Before rewriting, audit your current problem definition using the checklist below. The fewer items you can check off, the more urgently you need to go back and re-interview customers.

1. Is the number of people interviewed and the rate at which they mentioned the pain stated in the plan?
2. Are the specific workarounds customers are currently using to deal with the pain clearly described?
3. Is the time or money invested in those workarounds expressed as a number?
4. Is the frequency of the pain (daily / weekly / monthly / per transaction) stated?
5. Is the cost of current alternative solutions or manual work recorded?
6. Is at least one instance of a customer volunteering the pain unprompted cited in the plan?

#

Q. I haven't done customer interviews yet. Can't I just make a logical case?

No. Arguing that pain logically should exist is still just a claim, not evidence. Until you've met with prospective customers directly, your entire problem definition is treated as an unverified hypothesis. Claims a reviewer can't independently verify are penalized.

Q. Won't a small sample size look weak? For example, '7 out of 10'?

A small number is still better than none. '7 out of 10 mentioned it unprompted' is more credible than 'lots of people find it inconvenient.' At the early stage, reviewers aren't asking for statistical perfection — they're asking for claims that have some basis in reality.

Q. What about a B2B idea where behavioral data is hard to get?

In B2B, track procurement processes, budget line items, and how much staff time the problem consumes. 'How much does your company spend — on outsourcing or internal headcount — to deal with this?' is a number that's relatively easy to surface in a conversation with the right person. If you can point to outsourcing contracts or software subscription costs as proof of existing spend, that's even stronger evidence.

Q. If I ask about willingness to pay, won't customers just say 'I'd use it if it were free'?

'How much would you pay for this?' is a bad question. Start from current spending instead: 'What are you currently paying to address this problem?' The fact that customers are already spending money proves the market exists, and those figures become the lower bound for your pricing.

#

The problem definition section is the first thing reviewers read and the first place they find grounds for rejection. Sentences that merely claim large pain are invisible to a reviewer. Only sentences that include interview findings, workaround behaviors, and alternative costs actually enter the evaluation.

If you've already written your problem definition section, an OpenSeed review report will show you exactly how the market reviewer and the product reviewer each read it. Sections with only adjectives immediately trigger penalty comments. The report also tells you which evidence is missing and what direction to take your rewrite.