What a Problem Statement Must Contain

A problem statement is not a mission statement. It is a claim about the world that can turn out to be false. If yours cannot be false, it is not a problem statement, and the work that follows it will not be research. It will be decoration.

All 12,631 records in our library have a problem statement field. A populated field is not a good statement, and that gap is the subject of this post.

The weak version describes a missing product. The strong version describes a person losing something.

Part 1: who is stuck

A role, not a market. "Operations lead at a 20 person logistics company" is a role. "SMBs" is a category. You cannot email a category, and a category does not call you on Friday because the report is wrong.

The test is simple. Could you find five of these people this week without paying for an audience? If not, the statement is too broad to test.

Part 2: doing what, exactly

This is the part most statements skip, and it is the part that makes the rest useful. Not "managing invoices". "Chasing six overdue invoices by email every Monday, then rebuilding the same spreadsheet because two clients paid on Friday."

Specificity is not style. It is what lets you count the cost, and it is what tells you whether software can help at all. A vague workflow hides the fact that the real problem is a client who will not pay, which no dashboard fixes.

Part 3: at what cost

The cost must be in a unit the buyer already tracks. Hours per week. Error rate. Days of cash flow. One person's salary. A fine.

If the cost is annoyance, the buyer complains and does not pay. People pay to remove costs that appear on a report, not costs that exist only as a mood.

This is the part that separates a request from a purchase, and it is the reason how to kill a SaaS idea in an afternoon puts the money question last. By then the cost is written down, so the answer means something.

Part 4: what they do instead

Every problem has a current solution. Name it, and name why it survives.

The workaround is your real competitor, and it wins on three dull advantages: it already exists, it is already paid for, and nobody has to learn it. A spreadsheet that is wrong but trusted keeps winning until the error cost crosses a line the buyer can see. That line is usually a customer complaint, an audit, or a late payment.

If you cannot name the workaround, you have not looked. In the records we read it is a common gap. We have not counted how often the field is empty, so treat that as an observation, not a rate.

The four parts together

Here is a statement that passes.

"The billing coordinator at a small clinic spends four hours every Friday matching insurance payments to visits in a spreadsheet, because the practice management system exports a format the bank feed cannot read. Errors surface as patient calls two weeks later. Today the workaround is a part-time bookkeeper at roughly one day a week."

Every part is checkable. You can find the role. You can watch the workflow. You can count the hours. You can price the workaround. And you can be wrong, which is the point.

Here is the same idea written badly.

"A modern, AI-powered platform that streamlines insurance reconciliation for healthcare providers."

That sentence cannot be wrong, because it does not claim anything. It also cannot be tested, priced, or sold.

A rewrite test you can run in two minutes

Take your current statement and delete the product name. If the sentence still makes sense, it is probably a problem statement. If it collapses, it was a product description.

Then delete the adjectives. "Seamless", "powerful", "modern", and "intuitive" are claims about your future work, not observations about the buyer. What remains is either a person with a cost or a mood.

Finally, ask a stranger to read it and tell you what the person does on a Tuesday. If they cannot answer, the statement is still too abstract to test.

Keep the version that survives. It becomes the first line of every customer conversation, and it is the sentence you will read in month four when the build is behind schedule and the evidence is the only thing keeping you honest.

Write it before the product name

The order matters. If you name the product first, the statement bends toward the name. Every part becomes a justification, and the workaround section quietly disappears because the product is supposed to replace it.

Write the four parts with no product in the room. Then decide whether software is the right answer. Sometimes it is a checklist, a template, or a service, and those are cheaper to sell and faster to prove.

The full method, including the failure criterion, is in how to validate a SaaS idea before you build it. If you want to see how weak counts mislead this work, read why request counts in idea libraries are usually wrong. The topic page is build or do not build.

Sources

• SaaS Idea Finder idea library, 12,631 records, each with a problem statement field, collected May 2025 to November 2026.
• The two example statements are written for this post. They are illustrations, not records from the library.
• No external framework is cited. The four-part structure is our own.