Skip to content
Back to Idea Validation

Problem Statement

Write a crisp, testable problem statement that names the who, the pain, and the frequency.

Why

A vague problem statement ("developers need better tools") produces a vague product. A crisp one ("solo devs waste 2+ hours per release manually writing changelogs from scattered commits") forces every feature decision to answer: does this reduce that specific waste? The problem statement is the anchor that prevents scope creep — when someone proposes a feature, you check it against the statement and reject what does not serve it. Without a written, specific statement, every feature feels equally valid and the product bloats into nothing-in-particular. The statement also makes the problem measurable, so you can later prove you solved it.

When

Before any validation testing, right after the idea. Takes 1-2 hours. Revise when validation reveals your problem was wrong.

How

1. Name the specific person
   - Not "developers" — "solo indie devs shipping to production weekly"
   - The more specific, the more testable

2. Name the specific pain
   - Not "wastes time" — "spends 2+ hours per release manually compiling changelogs"
   - Observable and measurable, not a feeling

3. Name the frequency and context
   - How often? (every release, daily, when onboarding)
   - Under what conditions? (solo, no QA team, using GitHub)

4. Name the current workaround
   - What do they do today? (skip changelogs, copy-paste from PRs, use a template)
   - The workaround proves the problem is real and shows what your solution replaces

5. Write the one-sentence statement
   - "[persona] [verb] [pain] [frequency], and currently [workaround]"
   - Example: "Solo indie devs spend 2+ hours per release manually compiling changelogs from scattered commits, and currently skip them or copy-paste from PR titles."

6. Pressure-test
   - Is this a problem worth solving? (frequency × pain × willingness-to-change)
   - Is it specific enough to reject features that do not serve it?
   - Can you measure whether you solved it? (define the before/after metric)

Example

Idea: a tool to auto-generate changelogs from git history.

Bad statement: "Developers need help writing changelogs."
  → vague, untestable, does not reject any feature

Good statement: "Solo indie devs who ship weekly spend 2+ hours per release manually compiling changelogs from scattered commits and PR titles, and currently either skip changelogs entirely (users complain) or copy-paste PR titles into a markdown file (inconsistent, misses fixes)."

Test:
  - Persona: solo indie devs shipping weekly ✓ (findable on r/IndieHackers)
  - Pain: 2+ hours per release ✓ (measurable — time before/after)
  - Frequency: weekly ✓ (high enough to matter)
  - Workaround: skip or copy-paste ✓ (proves the problem is real)
  - Metric: "time spent on changelog per release" → target: < 5 minutes

This statement rejects: "add Jira integration" (indie devs do not use Jira), "add AI tone adjustment" (not about time).

Common Problems

  • ⚠Writing a problem you cannot observe — "developers feel overwhelmed" is a feeling, not a problem; rephrase as an observable behavior.
  • ⚠Making the persona too broad — "developers" includes enterprise architects and hobbyist students with completely different problems.
  • ⚠Skipping the current workaround — if there is no workaround, the problem may not be urgent enough to solve; people live with non-urgent problems.
  • ⚠A statement that cannot reject features — if every feature "could help", the statement is too vague; it should make 50% of ideas clearly out of scope.

Best Practices

  • ✓Include the current workaround in the statement — it proves the problem is real and shows exactly what your solution must beat.
  • ✓Define the success metric in the statement — "reduce time from 2h to <5min" makes it measurable and prevents moving goalposts.
  • ✓Use the statement as a feature filter — write it on a sticky note; every proposed feature must serve it or be rejected.
  • ✓Validate the statement with 5 target users — read it to them and ask "is this your problem?"; if < 3 say yes, your problem is wrong.