> For the complete documentation index, see [llms.txt](https://the-gtm-hq.gitbook.io/go-to-market-course/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://the-gtm-hq.gitbook.io/go-to-market-course/course/go-to-market-pmf-course/4.-identifying-a-problem-worth-solving.md).

# 4. Identifying a Problem Worth Solving

### Learning Objectives

By the end of this chapter you will be able to:

* Distinguish between painkiller problems and vitamin problems — and understand why only one reliably converts
* Apply four diagnostic tests to evaluate whether a problem is worth building around
* Identify the market signals that confirm a problem is real, urgent, and actively being addressed
* Write a sharp problem statement using only customer language that anchors your positioning
* Recognise the difference between a problem that is interesting and one that is premium-offer worthy

### Introduction

Having the right niche is necessary but not sufficient. Inside every niche are dozens of problems things people find annoying, inefficient, or expensive. Not all of those problems are worth building a business around. 

The ones that share a specific set of characteristics: they are painful enough that people are already spending time and money trying to fix them, urgent enough that the status quo feels unacceptable, and clear enough that the people experiencing them can articulate what a solution would look like, are worth looking into. 

This chapter is about developing the discipline to evaluate problems rigorously before committing to them. Most founders skip this step. They find a problem they can relate to, assume their experience is representative, and start building. 

Six months later they discover that the problem was real but not urgent, or urgent but not widespread, or widespread but not something people would pay to solve. The cost of that discovery is a fully built product with no market.

The framework in this chapter is designed to surface that information before you build through conversations, observation, and structured analysis. 

The goal is to arrive at a problem statement that is so sharp, so grounded in customer language, and so clearly connected to purchasing behaviour that it becomes the foundation of everything: your offer, your messaging, your positioning, and your GTM motion.

### Business Starts With Pain

The word 'pain' gets used loosely in startup discourse. Founders describe any problem however mild or abstract as a pain point. This dilutes the concept and leads to a fundamental mistake: building products that address inconveniences rather than problems that people are actively trying to escape.

Real pain in the context of building a business has a specific profile. It is not discomfort. It is not a minor inefficiency that people have learned to live with. Real business pain has three characteristics that are observable before you build anything:

* **People are already spending resources to manage it.** If your target customer is not currently spending time, money, or energy trying to address the problem through workarounds, manual processes, consultants, or competitor products the problem is probably not painful enough to drive purchasing behaviour. Spending is the most honest signal of prioritisation.
* **People can describe it clearly and consistently.** When you ask prospects about the problem, do they immediately know what you are talking about? Do they use similar language across different conversations? Problems that are genuinely painful are well-articulated because the person experiencing them has thought about them, complained about them, and looked for solutions. Vague or inconsistent descriptions signal a problem that has not risen to the level of urgency.
* **People feel the cost of not solving it.** This is the urgency dimension. A problem worth building around is one where the status quo is actively getting worse, not one where people are managing fine. Ask: what happens to this person if the problem is not solved in the next 90 days? If the answer is 'not much,' you have a vitamin. If the answer involves real financial, operational, or reputational cost, you have a painkiller.

The discipline of starting with pain that is real, observable, & costly is what separates founders who build products markets want from founders who build products they personally find interesting. The market does not reward interestingness. It rewards urgency.

### Painkiller vs Vitamin Problems

The painkiller versus vitamin distinction is one of the most practically useful frameworks in early-stage GTM. It is also one of the most misapplied. Founders consistently overestimate how much of a painkiller their product is partly because they believe in it, and partly because the distinction is genuinely harder to make from the inside.

| **Painkiller problems**                              | **Vitamin problems**                                         |
| ---------------------------------------------------- | ------------------------------------------------------------ |
| Urgent, people need a solution now                   | Nice to have, people would like a solution eventually        |
| Buyers allocate budget proactively                   | Buyers consider it when budget is available                  |
| People are already paying for imperfect solutions    | People are tolerating the status quo without paying          |
| The cost of not solving is visible and growing       | The cost of not solving is abstract or minor                 |
| Prospects can describe the problem without prompting | Prospects need to be educated that the problem exists        |
| Short sales cycle, urgency drives speed              | Long sales cycle, requires multiple convincing conversations |
| High willingness to pay, pain justifies price        | Low willingness to pay, value is theoretical, not felt       |

The critical test: would your target customer proactively search for a solution to this problem, or would they only consider it if someone brought it to their attention? 

Painkiller problems generate inbound intent, people are already searching for answers. 

Vitamin problems require you to create awareness before you can create demand. 

For a solo founder with limited resources, the economics of painkiller problems are dramatically more favourable.

This does not mean vitamin businesses cannot succeed. Some of the most valuable companies in the world started as vitamins that became habits, fitness apps, productivity tools, meditation software. But those companies had the resources and runway to build the habit before expecting the revenue. 

For early-stage founders operating lean, painkiller problems give you a much shorter path to validation, conversion, and cash flow.

### How to Spot a Real Market Problem

Spotting a real market problem requires you to look beyond your own assumptions and find external evidence. There are four sources of evidence that consistently surface genuine, market-wide pain and each requires a different kind of attention.<br>

1. **Customer and prospect conversations.** The most reliable source of real problem evidence is direct conversation with people who have the problem. Not surveys, conversations. Listen for emotional language: frustration, resignation, anxiety, embarrassment. Listen for specificity: people who have a real problem describe it in precise terms because they have lived with it. Listen for the workaround: if they are already doing something manual, expensive, or awkward to manage the problem, that is strong evidence it is real and worth solving. Aim for at least fifteen to twenty conversations before drawing conclusions about the problem.<br>
2. **Existing spend patterns.** Look at what your target segment is already paying for. Competitor products, consultants, internal hires, manual processes, all of these are proxy evidence of a problem that is real and being actively managed. If your target customers have no existing spend in the area you are addressing, that is a warning sign. It could mean the problem is not yet acute enough to drive purchasing or it could mean the market is genuinely underserved. Interview data will tell you which one.<br>
3. **Community and forum language.** Review forums, communities, LinkedIn posts, Reddit threads, and review sites in your target niche. What do people complain about most? What workarounds do they share? What competitor limitations generate the most frustration? This is unfiltered, unprompted language from people who are actively experiencing the problem and it is some of the most valuable market research available to a solo founder with no research budget.<br>
4. **Search behaviour.** Look at what the market is searching for. Google search volume, autocomplete suggestions, and keyword tools like Ahrefs or Semrush show you what your target segment is actively trying to solve. High search volume for problem-oriented queries 'how to fix,' 'alternative to,' 'why does X not work' is a leading indicator of market pain. This is particularly useful for validating the scale of a problem you have already identified through interviews.<br>

Use all four sources, not just one. A problem confirmed by interview data, existing spend, community frustration, and search behaviour is a problem you can build a business around with high confidence. A problem confirmed by only one source especially your own experience or intuition is a hypothesis that needs more testing.

### The Best Problems Create Fast, Clear Outcomes

There is a second dimension of problem quality that most founders overlook: the clarity and speed of the outcome when the problem is solved. The best problems are not just painful but they have a solution that produces a result the customer can see, measure, and feel quickly.

This matters for three specific reasons that directly affect your GTM:

* Fast outcomes accelerate word of mouth. When a customer solves a problem with your product and sees the result within days or weeks rather than months, they tell people. The shorter the time to visible outcome, the faster your referral loop operates.
* Clear outcomes make pricing easier. When the value of solving a problem is tangible and measurable like time saved, revenue recovered, errors eliminated, cost reduced, the pricing conversations become anchored in ROI rather than abstract value. Customers who can calculate what the solution is worth will pay significantly more than customers who are estimating.
* Visible outcomes reduce churn. Customers who can see and measure the value of your product are far less likely to cancel. They have a specific, felt reason to stay. Customers who cannot articulate what changed after using your product are the ones who churn when budget pressure arrives.

When evaluating problem candidates, ask this question explicitly: if this problem is solved, what is the first thing the customer will notice, and how quickly will they notice it? Problems where the answer is 'they will feel less stressed eventually' are vitamin territory.&#x20;

Problems where the answer is 'they will recover three hours per week starting in week one' or 'their error rate will drop from 12% to under 2% by month two' are painkiller territory with measurable outcomes and those are the problems worth building a premium offer around.

### Writing a Sharp Problem Statement

A problem statement is the single most important sentence in your early GTM toolkit. It is the foundation of your positioning, the anchor of your messaging, and the lens through which every product decision should be evaluated.&#x20;

A sharp problem statement is not a description of your product. It is a description of the customer's experience before your product exists.

Most founders write problem statements that are too abstract, too broad, or too product-adjacent. Here is the difference:

| **WEAK VS STRONG PROBLEM STATEMENTS**                                                                                                                                                                                    |
| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| WEAK: 'Businesses struggle with inefficient processes that slow down their growth.'                                                                                                                                      |
| Why it fails: Generic, abstract, applicable to almost any business. No customer recognises themselves specifically. No urgency. No cost.                                                                                 |
| WEAK: 'Our customers need a better way to manage their workflows.'                                                                                                                                                       |
| Why it fails: This is a solution description disguised as a problem statement. 'Better way' is relative and undefined. 'Workflows' is too broad.                                                                         |
| STRONG: 'Solo B2B founders spend 8 to 12 hours per week manually tracking outreach across spreadsheets and losing deals because they have no way to see which prospects are warm without digging through email threads.' |
| Why it works: Specific segment. Specific time cost. Specific behaviour. Specific consequence. A solo B2B founder reads this and immediately recognises their Tuesday afternoon.                                          |

The formula for a sharp problem statement has five components:

| **THE PROBLEM STATEMENT FORMULA**                                                                                                                                                                                        |
| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| \[Specific segment] spends \[specific resource — time, money, attention] on \[specific activity] and \[specific negative consequence] because \[specific root cause].                                                    |
| Example: Early-stage SaaS founders spend 6+ hours per week manually compiling investor update emails and miss follow-up windows because they have no centralised view of who they have spoken to and what was discussed. |
| Test: Can your ideal customer read this and immediately say 'that is exactly my situation'? If yes, it is sharp enough. If they need to interpret or translate it, it needs more specificity.                            |

The most important constraint on a problem statement is this: every word in it must come from something a real customer has said. Not something you inferred. Not something you assumed. Actual language from actual conversations. If you cannot source every element of your problem statement to a real customer interaction, you have not done enough discovery work yet.

When your problem statement stabilises is when you stop needing to rewrite it after each round of interviews because customers keeps confirming it. This is one of the earliest and most reliable signals that you are approaching Problem Solution Fit on the problem dimension.

### Case Example

| **LATTICE - WHEN PROBLEM SELECTION CHANGES EVERYTHING**                                                                                                                                                                                                                                                                                                                                                                                                                  |
| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| Lattice, the people management platform now valued at over one billion dollars, did not start with the product it is famous for. It started with a different problem entirely and the story of why they changed is one of the clearest illustrations of what it means to select the right problem.                                                                                                                                                                       |
| Lattice's first version was a goal-setting tool for teams. The problem it addressed was real: companies needed a way to set and track OKRs. The product worked. Customers used it. But traction was slow and the sales cycle was long because the problem, while genuine, was not urgent enough. Companies could and did manage OKRs through spreadsheets without significant pain.                                                                                      |
| The insight that changed the trajectory came from customer conversations. Users consistently mentioned, without being prompted, that their biggest source of stress was performance reviews. The process was manual, inconsistent, and dreaded by managers and employees alike. HR teams were spending weeks on something that produced little trust and even less useful data. This was a painkiller problem one with a clear cost in time, morale, and legal exposure. |
| Lattice pivoted to make performance management the core of the product. Same team, different problem. The shift changed the entire GTM motion: shorter sales cycles, higher urgency, a clear ROI story, and a buyer HR leaders with budget and authority. Within two years of the pivot, Lattice had crossed significant revenue milestones and established a clear category position.                                                                                   |
| The lesson: the problem you choose is not just a product decision. It is a GTM decision. Lattice's pivot was not driven by a technical breakthrough or a market shift. It was driven by listening carefully enough to identify which problem their market actually needed solved urgently and having the discipline to redirect toward it.                                                                                                                               |

### **Do This Before Moving To Chapter 05**

| **Step 1.**  Apply the painkiller test to your current problem. Ask yourself honestly: are my target customers already spending money or significant time trying to solve this? If the answer is no, that is your first warning sign.                                     |
| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Step 2.**  Go to one community, forum, or review site where your target ICP congregates. Spend 30 minutes reading. Write down the exact words people use to describe their biggest frustrations in your problem area. Do not paraphrase — copy their language verbatim. |
| **Step 3.**  Write your problem statement using the formula: \[specific segment] spends \[specific resource] on \[specific activity] and \[specific consequence] because \[specific root cause]. Use only language you have heard from real customers or prospects.       |
| **Step 4.**  Book 3 discovery calls this week. In each call, read your problem statement back to the prospect and ask: does this describe your experience? Watch for the moment of recognition or the moment of polite confusion. Both are data.                          |

### Key Takeaways

* Real business pain is observable before you build: people are already spending to manage it, they describe it clearly, and they feel the cost of not solving it.
* Painkiller problems drive urgency, shorter sales cycles, and higher willingness to pay. Vitamin problems require awareness creation, an expensive and slow process for solo founders.
* Confirm a problem using four sources: customer conversations, existing spend patterns, community language, and search behaviour. One source is a hypothesis. Four sources is a foundation.
* The best problems produce fast, clear, measurable outcomes which accelerates word of mouth, makes pricing easier, and reduces churn.
* A sharp problem statement uses only customer language, names a specific segment, a specific cost, a specific behaviour, and a specific consequence. When customers read it and immediately recognise themselves, it is ready to use.

### What is Next&#x20;

In Chapter 05, we move from the problem to the promise. Once you have identified a problem worth solving, the next challenge is articulating what you uniquely offer and doing it in a way that is differentiated, credible, and immediately understood by the people you are trying to reach.&#x20;

Chapter 05 introduces the Kano model as a practical tool for shaping your value proposition and shows you how to build a promise your niche can understand, remember, and repeat to others.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://the-gtm-hq.gitbook.io/go-to-market-course/course/go-to-market-pmf-course/4.-identifying-a-problem-worth-solving.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.