Problem Statement

Planning documents have traditionally started from the solution. "Let people comment on documents," then screens and behavior underneath. Documents written that way are easy to read and quick to start on, which is why the habit lasted as long as it did.

What they leave out is the aim. Pagedeck decided to build document comments this way. Two weeks in, Mia asked again what the feature was for, and the answers split three ways. Theo said it was about pulling conversations out of chat and into the document. Noa said it was about helping new joiners see what needed fixing. Sofia said an enterprise customer had asked for it. All three had read the same document. With no aim written down, each of them had filled the gap with the problem they already knew about.

Build with the aim split like that and the feature still ships. Four months later, though, when nobody uses it, nobody can say why. Whether it worked depends on what it was for, and that never made it onto the page. The paragraph exists so that what gets solved is written down before what gets built.

It is one paragraph, but there are five slots to fill, and any slot left empty gets filled in by the reader's own guess.

1. Whose problem. Narrower than "users." If there is a persona, a specific group of users drawn as one concrete individual, use that name; otherwise describe the condition. "Someone on a team of five or more who mostly reads documents rather than writing them" can be found and checked with later.
2. What they cannot do, and when. Not the absence of a feature, but the moment they get stuck. "Reading a colleague's document, they spot something to fix and have no way to leave it there, so they retype the passage into chat."
3. How they cope today. People usually already have a workaround, and the workaround tells you the size of the problem. Copying a document link and a paragraph into chat means annoying but survivable. Giving up and moving on means something larger.
4. What it costs to leave alone. Attach a number: 40 support messages a month on this topic, or two-week return rate for teams of five or more stuck at 34 percent. Without a number there is no basis for choosing between this problem and the others competing for the same quarter.
5. Why now. A problem that also existed six months ago needs a reason for surfacing today — an enterprise renewal next quarter, or a competitor shipping the same thing.

The rule for this paragraph is that no solution goes in it. Write "build comments" and the paragraph becomes a conclusion, which closes off every other way of solving it. Solutions belong to the next step, the hypothesis, where a proposed fix is written so that it can be shown right or wrong. If the five slots will not fit into one paragraph, the problem has not been narrowed enough yet.

One person writes it, usually the product manager who owns the area. Writing it alone does not mean sourcing it alone. The raw material is notes from user research, where you watch and question people actually using the product, the collected complaints and requests known as the voice of the customer, and the numbers coming out of the product itself. Written without that material, slots three and four come out empty and the paragraph becomes the writer's guess.

Four groups read it, and each one reads a different slot.

1. Engineering. Theo goes to slot two. Knowing where a person gets stuck tells him whether this is a screen change or a structural one.
2. Design. Noa reads slots one and three. Knowing who this is for and what they currently do instead gives her a habit to design a replacement for.
3. Approval. Grace reads only slots four and five. Unless the cost and the timing beat the other candidates, nobody gets assigned to it.
4. Customer-facing roles. Sofia and Ravi read slot one. If the group described there does not match the customers they talk to, they say so on the spot.

It gets written right after a problem is chosen and before the product requirements document (PRD). Reverse that order and the problem gets picked backwards, to fit a solution already settled on. It gets reread twice: whenever a new request arrives mid-build, to see whether it matches, and four months after release, to check whether the problem actually shrank.

"Let's rewrite the problem statement. Right now the doc has what we're building and no why."

A request to drop the solution and agree on the aim first.

"This request isn't in the problem statement. We either change the paragraph or push it to later."

Treating a new request as a decision about aim rather than something to quietly append.

"Just send me the problem statement. I'll give you an estimate off that."

Knowing what is being solved is enough to judge the size of the work.

At Pagedeck, Mia writes the paragraph and reads it out loud in the meeting. It takes about 30 seconds, and within those 30 seconds you can see which person in the room is shaking their head. When Sofia says the customers she meets are not that group, the meeting does not move on to solutions that day; it goes back to narrowing the audience.

The paragraph keeps working after release. Four months on, Mia opens it again and checks the number in slot four. A return rate that moved from 34 percent to 41 says the aim was right; one that did not move means looking at the problem again before building more.

The most common mistake is writing a solution in the shape of a problem and calling it done. "There is no comment feature" points at something missing, so it reads like a problem, but it is a decision about what to build. Written that way, nothing is left to check. An in-document task marker or a suggested-edit flow might remove the same friction for far less, and none of those candidates reach the discussion, because the first line already answered the question.

The other one is treating it as a form you fill in once. Filling it in before work starts and pinning it to the top of the document looks like the job is done. But the value of the paragraph comes from being used as a test while the work happens. Skip checking new requests against it and features keep piling up in the order the requests arrived, aim or no aim.