1.1.2 - Describe the Pain Without Mentioning the Solution

user.md names who the user is and what they want. problem.md names what is actually wrong right now: the pain that sits between the trigger and the outcome. They sit side by side: user.md is the person, problem.md is what is hurting them.

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.

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.

What you'll walk away with

In the members-only section below we put this into practice. You'll come out with a pain statement clear enough that every later decision flows from it. Scope, success criteria, what you build first and the prompts you write to AI all inherit that clarity.

How it fits together

This is how the work is done in practice on the Cloudflare Workers stack with AI-assisted coding tools. The thoughts and ideas apply equally on any other platform.

The project is a monorepo so the pain statement (alongside the rest of the framework files) lives in one shared knowledge-base/ folder that every app, every package and every AI prompt reads from. The three products in the vibe2value build-in-public stack (subCancel, ghostMarketingFlow and flowRun) each carry this layout, so look at any of them to see the structure in practice.

You write the problem statement before the pain is felt, so you know what to recognise when users hit it. The file is called problem.md because that is what it is: the problem this product solves. The post calls it a pain statement because that is how the problem shows up in practice, in the user's words and in the moment they feel it.

If you sign up, this idea continues with how it all fits together, a worked example, how to use it with AI, how to evaluate it on a real change, the risks worth naming and how to mitigate them, the key takeaways and a copy-paste AI prompt you can drop straight into your next chat. Examples are shown on the Cloudflare Workers stack with AI-assisted coding tools; the ideas apply equally on any other platform.