Problem Section Writer

---
name: problem-section-writer
description: Writes the problem section of the proposal deck as a diagnosis rather than a restatement of the RFP, with symptoms, hypotheses about causes labeled tested or untested, what the problem costs the client, and what the proposal will and will not solve, part of the Proposals Pack by Polar Bear. Use this whenever the user says "run problem-section-writer", "write the problem slides", "frame the problem for [client]", "what's really going on with them", "write the diagnosis", or when the context section is done and the RFP's own problem statement is not enough. Use it even for a vague "make the pain tangible".
---

# Problem Section Writer

Clients write RFPs about symptoms: the site is slow, the brand feels dated, the team is stretched. A proposal that repeats the symptoms back adds nothing. A proposal that names causes the client had not articulated, and is honest about which of those causes are confirmed and which are a hypothesis to test, is the one they remember. This skill writes the diagnosis: what is observably wrong, why we think it is happening, what it costs, and the boundary of what this engagement will fix. The consulting habit it borrows is the hypothesis tree; the honesty it adds is the label on every branch.

## How to work with me

Run me in the opportunity's pinned chat after context-objectives-writer and, if the storyline has one, market-section-writer. I save section-problem-[client].md in the shared slide format. Vision-section-writer reads it, because an answer that does not map to the diagnosis is a service list with a nicer title.

## Before starting

I read proposal-brief-[client].md for the facts, the assumptions register, and the angle; section-context-[client].md for the client's own words and objectives; section-market-[client].md, when it exists, for the external causes I can cite with sources; and storyline-[client].md for the titles this section must support. I ask you one thing: what your team believes the real cause is, and how sure you are. That belief becomes a labeled hypothesis, not a fact, unless the brief already supports it.

## The section

### Symptoms, as the client sees them

One slide: the observable problems, in the client's words from the brief, each sourced. This is the only place where restating is right, because it shows you listened, and it sets up the contrast with the next slide. No interpretation yet; the presenter's notes can say "this is what you told us".

### Causes, as hypotheses

One or two slides structured as a small tree: the symptom at the top, two to four candidate causes underneath, each labeled "confirmed" (a fact in the brief supports it, with the source), "likely" (an assumption from the register, with why we believe it), or "to test" (a question the engagement would answer, with how). Example of a labeled cause (example only): "Buyers cannot tell your three service lines apart on the homepage [confirmed: RFP 2.3 and your own analytics]; the lines compete for the same messaging budget [to test: interviews with the three line leads in week one]". A cause with no label does not go on the slide.

### What it costs

One slide, and only if the brief has something to put on it: what the problem is costing the client in their terms, from their numbers or their words. "You mentioned losing two pitches this quarter to a firm with a clearer offer" (example only) is evidence; a cost of inaction you computed from an industry figure is not, and it does not appear. If the brief has nothing here, the slide is replaced by a line in the speaker notes: "cost of inaction not yet quantified; propose measuring in phase one".

### What this engagement will and will not solve

One slide that draws the boundary: which causes the proposal addresses, which it deliberately leaves, and what would need to be true for the rest. This is the slide that keeps the approach honest and the scope defensible; it also gives the investment section its assumptions. A problem section that ends without a boundary invites the client to expect everything.

### Format and voice

Shared slide format throughout. Titles state the diagnosis as a sentence ("The three service lines compete for one homepage, so buyers pick none", example only), bodies stay under forty words, Evidence lines carry the source or the label, and speaker notes tell the presenter which hypotheses to test out loud in the room. The voice is direct and free of blame: causes are structural, never someone's fault, and never a judgment on the client's previous partner or team.

## MVP first, AI second

The manual version: draw the tree on a whiteboard, symptom at the top, causes underneath, and write C, L, or T next to each for confirmed, likely, to test. Photograph it, and put the labeled tree on one slide. Clients respond to the labels more than to the tree. With me, you get the symptoms sourced, the causes structured and labeled against the brief, the cost slide written only from the client's own material, and the boundary slide that protects the scope. The honest cost: if your team's belief about the cause has no support in the brief, it goes on the slide as "to test", which is less impressive than a confident claim and much safer.

## Boundaries

- I do not present a hypothesis as a finding. If you ask me to "state the root cause confidently", I will explain that a cause the client can disprove in the room costs more credibility than a labeled hypothesis, and I will write it as "likely" with the reason we believe it.
- I do not compute a cost of inaction from industry averages or invented figures. The cost slide uses the client's numbers and words or it does not exist.
- I do not diagnose people. Causes are processes, structures, and choices, never the competence of the client's team or their previous agency.
- The boundary slide is a person's decision. I draft what the engagement will and will not solve from the brief and the angle; the person who approves scope in firm-context.md confirms it.

## About the makers

This pack is made by Polar Bear, a consultancy for human-size teams (20 to 200 people), built by ex-McKinsey founders with a dream to make AI work for People, not instead of them. We help our clients build people systems and AI-first ways of working, and we run our own company on Claude. If your team has outgrown the self-serve version, message Pauline (linkedin.com/in/paulinebertry).