1.1.2 - Describe the Pain Without Mentioning the Solution

Pain statement

Can we describe the pain clearly before naming a solution?

The call

Describe the pain first. Otherwise AI generates solutions for a problem nobody has confirmed.

Why it matters

If the pain stays vague, every solution sounds reasonable. Scope grows, features multiply and AI produces fast drafts that solve the wrong problem. Human judgement matters here because it keeps the work anchored to a real pain rather than a plausible feature.

Explainer

A pain statement is not a feature request. It is a clear description of what is going wrong for one user before solution ideas enter the room. Until you can name who is affected, what triggers the pain and what it costs, the brief is too soft. AI can generate options, but it cannot choose the right boundary without a clear pain.

Make the pain statement concrete

Compare the broad version with a version you can actually test.

• Too vague: Users struggle to get useful results from AI search.
• Concrete enough to test: A content creator searches for what to write next but gets generic suggestions because the tool does not know what they have already published. They waste time filtering irrelevant results instead of writing.

The second version lets two people frame the same problem from it.

Check the pain statement

• Pass: You can say who is affected, what happens right before the pain appears and what it costs the user.
• Fail: The statement still sounds like a feature gap or a general frustration.

Do not move into solution, scope or prototype work until this passes.

How to use AI for the pain statement

• AI chat: Rewrite the pain statement until you can state all three parts clearly.
• vibeCoding: Build the thinnest flow that tests this pain statement in practice before broader build work.
• AI-assisted coding: Carry the same pain statement into implementation and review so the live system keeps the same decision.

Sharpen the pain statement

Copy this prompt into AI chat, replace the bracketed lines with your real pain statement and keep the instruction exactly as visible here.

You are checking whether this pain statement is clear enough before you move forward.

Constraint:
The pain statement must be specific enough that two people would frame the same problem from it.

Working draft:
Affected user: [who is affected]
Trigger: [what happens right before the pain appears]
Visible cost: [what it costs the user]

Task:
Decide whether this pain statement is specific enough to guide the next decision. If it is vague, rewrite it so two people would make the same decision from this pain statement.

Check:
- Would two people interpret this the same way?
- Does it stay concrete enough to guide the next step?
- Does it meet this bar: You can say who is affected, what happens right before the pain appears and what it costs the user.

Return:
- A corrected pain statement
- A short explanation of what was vague

Evaluation

Before accepting the result, check whether two people would frame the same problem from it.

Example

To help you work through this, here is a real example. StartWithYourContext is an AI search tool built as part of the vibe2value project. Here is how its pain statement was written using the three parts:

• Affected user: A content creator who manages a website and publishes regularly.
• Trigger: They search for what to write next but get generic suggestions because the tool does not know their existing content.
• Outcome cost: They waste time filtering irrelevant results instead of writing, and new pages overlap with what already exists.

This pain statement is specific enough that two people would frame the same problem from it.

When there is more than one side

Not every product has a single pain. When a system serves more than one side, each side experiences a different problem and naming only one leaves the other undiagnosed.

Multi-sided worked example

For example, StartWithYourContext has two distinct pains:

• Content creator: Wastes time on generic suggestions because the tool does not know their existing content.
• Developer: Hits friction when the AI search, database and auth layers do not fit together cleanly.

Both pains are real, but they show up in different parts of the system. If only one is described, the other gets solved by luck.

Risk and mitigation

• Risk: Jumping to solution language before the pain is clear, which creates scope growth and weak user outcomes.
• Mitigation: Require one validated pain statement and one measurable user-impact signal before discussing implementation choices.

Key takeaway

Do not move forward until you can say who is affected, what happens right before the pain appears and what it costs the user.

Work through this in a workshop

If your pain statement is still unclear, bring it to a free weekly workshop. Bring the messy part of your AI-assisted build and leave with a clearer next step. In some sessions, we walk through practical examples on the Cloudflare Workers stack to show how a rough idea turns into something that actually runs.

What do you think?

How are you describing pain before solutions in your work and how is AI helping you keep that focus clear?