Free template
A problem statement is a single sentence that pins your product to a specific person, a specific frustration, and a specific definition of success. Teams that write one clearly before they plan anything ship the right thing faster. Teams that skip it build confidently in the wrong direction.
The common failure: writing a solution disguised as a problem. “We need to build a notification system” sounds like a problem statement. It isn't. The problem is “users miss critical updates because the current alert format is too easy to dismiss.” The first locks you into one solution. The second opens up three better ones.
Four fields. All required. This is the format Bandos uses to anchor every product session to a real customer problem.
“For [specific persona] who wants to [goal], we will solve [core friction / frustration] so they can [desired outcome].”
Worked example
“For new users who want to finish setup on day one, we will solve unclear next steps so they can reach their first ‘aha moment’ in under 10 minutes.”
The same four-field format applied to a B2B SaaS tool, a consumer app, and an agency client scenario. Notice that all three name a specific person in a specific situation — not a segment.
B2B SaaS
“For heads of product at 20–50 person startups who want to run a decision-making workshop with their team, we will solve the absence of a structured process so they can leave the session with a direction everyone has actually committed to.”
Consumer app
“For freelance designers who want to charge more, we will solve the inability to demonstrate ROI to clients so they can justify a 40% rate increase without losing the relationship.”
Agency / client discovery
“For client stakeholders joining a discovery workshop who want their input to matter, we will solve the fact that the most senior person always steers the outcome so they can vote honestly without deferring to whoever signs their budget.”
Most bad problem statements fail in the same five ways. Here's what each looks like and what to do instead.
"We need to build a notification system" is a solution. The problem is "users miss critical updates." Start with what the user experiences, not what you want to build. If your statement contains a feature name, a technology, or a verb like "build" or "add," rewrite it.
"Busy professionals" describes half the population and anchors nothing. Replace it with a person in a situation: "a solo founder in week 2 of their first product build." The more specific the persona, the more obvious the right solution becomes.
If your statement contains "and," you probably have two problems. Pick the one that, if solved, makes the other one less important. Two separate problem statements are better than one bloated one.
"We need to increase activation" is a company metric. The user's problem is "I can't figure out whether this product is worth my time." Write it from their side of the table, in language they would actually use.
"Users feel overwhelmed by the setup flow" names the pain but not the bar. The "so they can" field defines what success looks like, which is what you need to know before you can measure whether you've solved it.
Copy the template above directly, or take it into your next session.
The template is already in the block above — hit “Copy template” to get the formula, field explanations, and worked example in plain text. Paste it into Notion, Google Docs, or wherever your team works. No email required.
The persona and goal fields are the hardest to write well — they require knowing who your customer actually is, not who you assume they are. Start a free Bandos session and those two fields generate themselves from your product context. You arrive at the problem statement with the hard part already done.
Start free sessionRelated: How Bandos works · Product ideation tool · Anonymous voting tool