A problem statement is a short, clear description of a problem that needs solving. It names who's affected, what the problem is, and why it matters, usually in a sentence or two. A good one stays focused on the problem itself, not the solution, so the team agrees on what they're fixing before deciding how. It's the first step in any discovery or planning work.

Start with the user and the gap between where they are and where they want to be. Answer the five Ws: who has the problem, what it is, when and where it shows up, and why it matters. Keep it solution-free and specific. This template breaks it into columns, Users, Problems, Metrics, Stakeholders, Risks, so you don't miss a part.

Most problem statements cover the current state, the desired state, and the gap between them, plus why closing that gap matters. Fuller versions add who's affected, how you'll measure success, and what's in scope. This template lays those out as seven columns: Users, Problems, Solutions, Metrics, Stakeholders, Risks, and Limitations.

One worked example: a manager of a small team finds it hard to track OKRs and see how daily work rolls up to goals; the metric is a monthly score of how easy progress is to track, and the limitation is 'no code.' A UX example: new users abandon signup at the payment step because the form asks for too much too early. Both name the user, the problem, and a measure of success.

A problem statement describes the gap between the current and desired state, what's wrong and why it matters. An objective defines the specific, measurable outcome the team will deliver in response. The problem comes first and motivates the objective; the objective is the solution-side commitment. Write the problem statement before setting objectives, not the other way around.