How to Write a One-Page Problem Brief
A one-page problem brief is a single-page document you write before a PRD or a pitch deck. It has six sections — problem, audience, current alternatives, insight, evidence, and what would change your mind — and it forces something neither a PRD nor a deck forces: proof you're building on what you've observed, not what you've assumed.
Quick Answer: A one-page problem brief has six sections — problem, audience, current alternatives, insight, evidence, and what-would-change-your-mind — each filled from what you've observed, not what you've guessed. Write it before a PRD locks you into one specific solution, and before a pitch deck asks you to sound more certain than you are. A field you can't fill isn't a formatting gap; it's telling you exactly where your problem discovery work is still thin.
The one-page problem brief template
Copy the six fields below. Each one should read as a single sentence or a short paragraph — if a field is running past four or five sentences, it's either doing the job of two fields at once, or you're padding a section you haven't actually done the legwork for yet.
Problem: [One sentence naming the specific problem — phrased so a stranger could go verify or refute it]
Audience: [The specific slice of people who have this problem — a role, a company stage, a life situation, not a broad demographic]
Current alternatives: [What this audience does about the problem today, however clumsy — "nothing, they just live with it" counts, and is itself a finding]
Insight: [Why this problem is solvable now, and why you specifically are positioned to solve it]
Evidence: [What you've actually observed — conversations, direct experience, a pattern across accounts you've watched — that backs everything above]
What would change my mind: [The specific finding that would make you drop this idea, or rework it substantially]
The first field is doing the same job as a problem statement template — naming the audience, the obstacle, and the workaround in one sentence. A problem brief just gives that sentence five neighbors: a sharper audience definition, a record of what people already do about it, a stated reason you think you can do better, the receipts behind the whole thing, and a built-in kill switch.
The six sections, and the quality bar for each
Every field above has a way of failing that still looks like success from a distance — a sentence that reads fine on the page but hasn't actually done its job. Here's the bar each one has to clear.
Problem
A problem statement passes the bar when a stranger could go find the person it describes and confirm or refute it just by watching them work. "Small business owners struggle with accounting" fails — it's too broad to verify and too broad to disprove. "Independent contractors who invoice five or more clients a month lose track of which invoices are still unpaid" passes, because you could go check.
Watch for problems phrased as the absence of your solution ("there's no easy way to do X") — that's solution-shaped thinking wearing a problem's clothing. Name the actual pain, not the gap where your product would go.
Audience
The audience field fails when it's a demographic instead of a definition you could recruit from. "Freelancers" is a demographic. "Freelance graphic designers who've been in business under two years and bill hourly rather than by project" is a definition — you could post in three specific communities and find ten of them by next week.
If you can't name where you'd go find five real examples of this audience today, the field isn't specific enough yet.
Current alternatives
This field fails silently when it's left blank or filled with "there isn't one." There is always something people do — even if it's tolerating the pain, using a spreadsheet, or asking a friend. Naming the real alternative, however unimpressive, tells you what you're actually competing against, and it's the single fastest gut check for whether the pain is urgent: if nobody has bothered to cope with it yet, it probably isn't urgent enough to fund a business around.
Insight
The insight field is the one most brief-writers fill with hope instead of a reason. "I think this could work" is hope. "Every workaround I've seen depends on someone manually re-entering data, and that step disappears if the two systems can talk to each other directly" is an insight — it names the specific mechanism you believe changes the outcome, not just your confidence that it will.
Evidence
Evidence fails the bar when it's actually inference wearing evidence's clothing — "everyone I know complains about this" is a claim about your social circle, not about the audience you named two fields up. The bar is a direct observation: a quote from a real conversation, a number you watched happen, a workaround you watched someone build with your own eyes.
This is where a framework like the one in Testing Business Ideas earns its keep — it treats every claim in a brief as an assumption to be tested rather than a fact to be asserted, and pushes you to rank which assumption is riskiest to leave unchecked. If your evidence field is thin, that's a signal to go run the kind of structured customer research that produces evidence instead of confirmation.
What would change my mind
This is the field people skip, and the one that matters most, because it's the only one that admits the brief could be wrong. A good answer names a specific, checkable finding — "if fewer than half the people I talk to have tried any workaround at all, I'll assume the pain isn't urgent enough" — not a vague hedge like "if it turns out this isn't a real problem." A brief with no kill switch isn't a brief; it's a pitch that hasn't been asked a hard question yet.
Filled example: a complete brief for a sample idea
Here's a hypothetical brief, filled in end to end, for an idea aimed at the kind of reader who's stepping out of a product role inside a company to found something of their own: internal IT teams struggling with password-reset volume.
Problem: IT support staff at mid-size companies (roughly 300–1,000 employees) spend a disproportionate share of their week manually resetting employee passwords across a dozen disconnected SaaS tools, because no single sign-on has been rolled out.
Audience: IT support leads and helpdesk managers at companies in the 300–1,000 employee range that have adopted more than eight SaaS tools but haven't yet standardized identity management — a gap that tends to open up right after a company outgrows its first handful of tools.
Current alternatives: Most teams handle this the same clumsy way today: a shared password-reset inbox or ticket queue, worked manually, tool by tool, by whichever support staffer is free. A few have bought a partial single sign-on product but only rolled it out to two or three of their most-used tools, leaving the rest unchanged.
Insight: The bottleneck isn't a missing product category — mature single sign-on tools already exist. It's that most of them price and package for companies far larger than 300–1,000 employees, so this segment is stuck choosing between an enterprise tool it can't justify and doing the work by hand.
Evidence: In conversations with a handful of IT leads at companies this size, the reset queue came up unprompted as their support team's single largest recurring time cost, and none of them had a rollout plan for single sign-on within the next year — cost, not lack of desire, was the reason every time.
What would change my mind: If, after actually pricing out the leading single sign-on tools for this segment, the gap turns out to be a sales-and-packaging problem rather than a real product gap — meaning an existing vendor could close it with a new price tier — that's a strong signal to abandon a new build in favor of a channel partnership instead.
Notice what the evidence field is actually doing: it doesn't just support the problem statement, it reveals a specific hypothesis — this is a pricing and packaging gap, not a product gap — that the "what would change my mind" field is built to stress-test directly. That link between the two fields is what separates a real brief from six sentences that happen to sit on the same page.
Problem brief vs PRD vs pitch deck
All three documents describe the same underlying idea at different points in its life, for different readers who need different things from it. Confusing their jobs is what produces a "problem brief" that reads like a pitch, or a PRD written before anyone has confirmed the problem is real.
| Document | Answers | Written before | Primary audience | Commits to a solution? |
|---|---|---|---|---|
| Problem brief | Is this problem real and worth solving? | Any specification work begins | Yourself, a co-founder, an early stakeholder | No — a strong brief can leave the solution completely open |
| PRD | What exactly are we building, and how will we know it works? | Engineering or design work begins | Engineers, designers, product stakeholders | Yes — it describes one specific solution in detail |
| Pitch deck | Why should you fund or free up time for this? | You need budget, buy-in, or investment | Investors, an internal budget owner, an accelerator | Partially — it names a solution, but its job is persuasion, not specification |
The practical takeaway: write the brief first, and resist the urge to let it drift into either of the other two. A brief that starts describing screens has quietly become a PRD; a brief that starts making the problem sound bigger than your evidence supports has quietly become a pitch. Keep it honest, and let the other two documents do their own jobs later.
Key Takeaways
- Six sections, not more — problem, audience, current alternatives, insight, evidence, and what-would-change-your-mind; anything longer starts turning into a PRD.
- An empty field is information, not a gap to paper over — it points directly at which piece of discovery work you haven't done yet.
- "Nothing" is a valid answer for current alternatives — people tolerating a problem unaddressed is itself evidence about how urgent it really is.
- Evidence has to be something you observed, not something you inferred for your own convenience — a hunch stays a hunch until a real conversation or number backs it.
- The kill-switch field is the one people skip, and the one that matters most — a brief with no stated way to disprove itself is a pitch that hasn't been asked a hard question yet.
- A problem brief doesn't compete with a PRD or a pitch deck — it comes before both, and a solid one makes either faster to write because the thinking is already done.
- Rewriting the brief as you learn more is expected, not a sign you got it wrong the first time.
Frequently Asked Questions
How long should writing a one-page problem brief take?
Usually a single sitting — well under two hours — once you already have a few real conversations or direct experience of the problem behind you. The brief itself is fast to write; what actually takes time is the discovery work that has to happen first, so you're filling six fields with observations instead of guesses.
What's the difference between a problem brief and a problem statement?
A problem statement is one sentence — the audience, the obstacle, and the current workaround. A problem brief is that sentence plus five more fields: a sharper audience definition, the evidence behind the claim, your insight into why it's solvable, and a stated way to prove yourself wrong. The problem statement becomes the brief's first field, not a separate document.
Do I need finished customer interviews before I write a problem brief?
No — a first draft can run ahead of your evidence, as long as every unproven field is marked as a guess rather than written with false confidence. What you shouldn't do is treat that first draft as finished. Go run the research the evidence field is actually asking for, then rewrite the brief once you have real answers instead of assumptions.