Problem Statement

Writing a problem statement is not a formality. It is the foundation that everything else depends on. Your problem statement becomes the reference for developers building the solution, designers shaping the experience, and QA testing the outcome. If you fail to articulate the problem clearly, the whole product risks being off-target.

The trap many PMs fall into is writing vague or generic problem descriptions that do not guide decision-making. Instead, your problem statement must be specific, user-centered, and actionable — so it can be a north star for your team.

The actual job of the PM in problem articulation

Your actual job as a PM is to translate messy observations — customer feedback, data signals, anecdotal complaints — into a clear problem that the team can rally around.

This is what I tell PMs repeatedly: the problem statement is the single most important document you will write. It sets expectations, drives prioritization, and shapes design and engineering decisions.

No one else in the team is expected to do this. Engineers will focus on the solution once the problem is clear. Designers will ideate once they understand the user pain. QA will test against the problem criteria. The PM owns the problem, owns the narrative, owns the clarity.

How to craft a problem statement that works

Start by capturing everyday annoyances, unmet needs, or inefficiencies you observe in your target users or market. Use a diary or spreadsheet — whatever you can maintain consistently.

Then apply the 5 Whys technique: keep asking "why" to peel back the layers until you reach the root cause. For example, if users complain "the app is slow," ask why. Maybe it's because the network calls are not optimized. Ask why again — maybe the data payload is too large. Keep going until you find the fundamental issue.

Once you have the root cause, write a single sentence that clearly describes the problem from the user's perspective. Make it specific and focused on the value or pain point.

For example:

• Weak: "Users want a faster app."
• Strong: "Users in tier-2 cities drop off after 3 seconds of load time due to slow network speeds and large image sizes."

The latter tells you exactly what to solve and for whom.

Why articulation matters so much

When I train PMs, I emphasize that the problem document is almost like a bible. It will be referred to repeatedly:

• When engineers face ambiguity in implementation.
• When designers decide what to prioritize in the interface.
• When QA tests scenarios and edge cases.
• When stakeholders ask why you built a certain feature.

If your problem statement is unclear or generic, confusion and assumptions creep in. The team will guess what you meant, leading to rework and frustration.

Here is where articulation becomes a competitive advantage for you as a PM. Write a problem statement that is:

• Readable: Use simple language, avoid jargon.
• Accessible: Share it widely, make it easy to find.
• Easy to consume: Use bullet points or short paragraphs if needed.
• Evidence-backed: Reference data or user quotes that support the problem.

This kind of alignment saves weeks of back-and-forth later.

Case study: How a clear problem statement accelerated delivery at a fintech startup

At a Series B fintech startup in Bangalore, the PM noticed many users dropping off during onboarding. Instead of jumping to solutions, she spent a week interviewing customers and analyzing analytics. She discovered the root problem was that users in smaller towns lacked KYC documents accepted by the app.

She wrote a problem statement that read:

"Users in tier-3 towns cannot complete onboarding because local government IDs are not supported by the KYC process, causing 40% drop-off."

This clarity enabled the engineering team to build support for alternative documents quickly. The design team created flows explaining acceptable IDs. Within a month, onboarding completion improved by 25%.

This is what happens when the problem is written clearly — the solution is focused and effective.

The problem statement is not the solution

A common mistake is to confuse the problem with the solution. For example, writing "Build a faster checkout flow" is a solution, not a problem.

The problem might be "Users abandon checkout because the payment form takes too long to load on slow networks."

The difference is crucial. Your problem statement guides what to build; the solution is how you build it.

If you cannot clearly state the problem, you are not ready to design or implement.

How to handle ambiguous or evolving problems

Sometimes the problem is unclear or changes as you learn more. That is normal.

Your problem statement should be a living document. Start specific but be ready to iterate as you gather more data.

Communicate changes to the team explicitly.

Use the problem statement to prioritize discovery work: "We are not sure if the problem is X or Y; let's validate with 10 user interviews this week."

The PM's problem statement checklist

Before you finalize your problem statement, ask yourself:

• Is it user-focused? Does it describe the user's pain or need?
• Is it specific? Does it identify who, what, and why?
• Is it actionable? Can the team design or build a solution from this?
• Is it evidence-backed? Do you have data or user quotes supporting it?
• Is it clear and readable? Would a new team member understand it?

If you answer yes to all, you have a solid problem statement.

Test yourself: Problem statement critique

From the field: Why I obsess over problem statements

Where to go next

• If you want to learn how to validate your problem with users: User Research Methods
• If you want to translate problems into solutions: Solution Fit and Prototyping
• If you want to master prioritization based on problem impact: Prioritization Frameworks
• If you want to practice writing PRDs: Writing Effective PRDs

PL alumni now work at Flipkart, Razorpay, Swiggy, PhonePe, Amazon, and dozens of other companies.