Every funded project you’ve ever seen had one thing in common before anyone touched a slide deck: someone wrote four sentences that made the ask impossible to say no to. Not clever sentences. Not inspiring ones. Just specific, here’s where the gap is, here’s what it’s costing, here’s what done looks like. That’s a problem statement, and most people writing them skip straight to the solution, which is exactly why half the funding requests you’ve reviewed this quarter came back with “can you clarify what problem this actually solves?”
Below: the four-line template, then twelve real-shaped examples, weak version, rewritten version, why it works, across PM, finance, analytics and engineering. Steal whatever fits your draft.
What Makes a Strong Problem Statement (The 4-Line Template)
A problem statement is four lines, in this order, and the order matters more than people give it credit for:
● Context — where and when this is happening. One sentence, no adjectives doing the heavy lifting.
● Problem — the actual gap between current and desired state. Single sentence. No solution words allowed — “we need a dashboard” is not a problem, it’s a conclusion you jumped to.
● Impact — what the gap is costing, quantified, even roughly. “Significant” isn’t a number. “~₹40L/quarter in discount leakage” is.
● Success — what “solved” looks like, measurable, with a date attached. Not “improve” — a number.
Filled in, for something painfully ordinary:
Context: Since the Q2 pricing change, the sales team has been manually approving every discount over 10%.
Problem: Approvals take an average of 3 days, and deals are stalling in that window.
Impact: ~₹40L/quarter in discounts lost to deals that die waiting, based on last quarter’s pipeline data.
Success: Approval turnaround under 4 hours for 90% of requests by end of Q3.
Four lines. No adjectives carrying the argument, nothing you’d be embarrassed to read out loud in a review.
Here’s why this exact shape gets funded when a paragraph of context doesn’t: a reviewer can say yes to something specific. “We need better approvals” invites a follow-up meeting. “₹40L/quarter, fixable by Q3, here’s the number that proves it” invites a signature.
Resources like Asana’s problem statement guide and Indeed’s career-advice writeup land on roughly this same shape, and that’s not a house style thing, it’s just what tends to survive an actual budget conversation.
12 Problem Statement Examples: Bad vs Good Rewrites
Funded projects share one trait: someone framed the gap, the impact, and the success measure before asking for money or for AI output. That’s literally the Stage 1 exercise baked into Scaler’s PGP in Business & AI turned here into a template you can use today, no enrollment required.
One gut check before you write yours: does the problem line describe one gap, or is it quietly three problems stitched together? If it’s the second one, you’ve broken MECE before you even got to the impact line, split it now, not after someone asks which problem you’re actually solving.
Twelve real-shaped examples below, three per role, all in the same format so you can pattern-match to your own draft.
Product Management
Weak: “Users are dropping off during onboarding.”
Context: Since the redesigned signup flow shipped in March, weekly activation has been tracked in the same funnel dashboard.
Problem: 38% of new signups abandon between account creation and first project setup, up from 22% pre-redesign.
Impact: ~1,200 lost activations/month at current signup volume, roughly ₹18L in first-quarter conversions.
Success: Drop-off between signup and first setup back under 25% within 6 weeks.
Why it works: Names the exact step, the delta, and a number instead of “onboarding feels clunky.”
Weak: “We need a new dashboard for the exec team.”
Context: The exec team currently pulls weekly numbers manually from four separate tools before Monday standup.
Problem: Compiling the weekly update takes ~3 hours across two people, and numbers are sometimes stale by meeting time.
Impact: ~24 person-hours/month spent on manual compilation, plus at least one decision delayed last quarter waiting on numbers.
Success: Weekly exec numbers available same-day, compiled in under 20 minutes, by next sprint.
Why it works: “We need a dashboard” is the solution; the rewrite finds the actual cost of not having one.
Weak: “Feature requests are piling up and we don’t know what to prioritize.”
Context: The product backlog has grown to 140+ open requests across three customer segments.
Problem: There’s no consistent method for ranking requests, so prioritization depends on who asked most recently or loudest.
Impact: At least two roadmap reversals last quarter traced back to requests that shouldn’t have been prioritized.
Success: A scoring rubric applied to 100% of new requests, reviewed monthly, starting next sprint.
Why it works: Replaces a vague feeling (“piling up”) with a specific process failure and a fixable target.
Finance & Strategy
Weak: “Churn is too high.”
Context: Monthly logo churn has been tracked consistently since last year’s CRM migration.
Problem: Churn has climbed from 2.1% to 3.4% monthly over the last two quarters, concentrated in accounts under ₹5L ARR.
Impact: ~₹85L in ARR at risk over the next two quarters if the trend holds.
Success: Monthly churn back under 2.5% for the sub-₹5L segment within two quarters.
Why it works: Names the segment doing the damage instead of treating churn as one undifferentiated number.
Weak: “Budget approvals take forever.”
Context: Department budget requests above ₹2L route through a three-person sign-off chain.
Problem: Average approval time is 11 business days, against a target of 3.
Impact: Two vendor contracts were lost to competitors last quarter due to approval delays, worth an estimated ₹30L combined.
Success: Median approval time under 4 business days by next fiscal quarter.
Why it works: Turns “forever” into a measured delta and ties it to money actually lost.
Weak: “Our pricing feels off compared to competitors.”
Context: The last competitive pricing review was conducted 14 months ago.
Problem: Three of five tracked competitors have adjusted pricing since, and win-rate on price-sensitive deals has dropped 9 points.
Impact: ~₹22L/quarter in deals lost specifically to price objections, per last quarter’s lost-deal notes.
Success: Updated pricing model live and win-rate on price-sensitive deals back to baseline within one quarter.
Why it works: “Feels off” becomes a dated fact plus a measurable business consequence.
Analytics
Weak: “The data is messy and hard to trust.”
Context: The customer table is fed by three upstream systems merged nightly.
Problem: About 12% of customer records have conflicting values across systems, mostly in signup date and plan tier.
Impact: At least one board-level report was corrected mid-quarter after a stakeholder caught a discrepancy.
Success: Conflict rate under 2% and a documented source-of-truth rule for each field within 6 weeks.
Why it works: “Messy” becomes a measured percentage with a named root cause.
Weak: “Stakeholders keep asking for different versions of the same report.”
Context: The revenue report currently exists in 4 slightly different spreadsheet versions across teams.
Problem: There’s no single owned definition of “revenue”, recognized, booked and pipeline-weighted are all used interchangeably.
Impact: ~6 hours/week spent reconciling numbers before leadership meetings, per last month’s time tracking.
Success: One agreed revenue definition, documented and adopted by all teams, within 3 weeks.
Why it works: Locates the actual disagreement (definitions, not tools) instead of blaming stakeholders for asking.
Weak: “Our models keep drifting and nobody notices in time.”
Context: The churn-prediction model has run in production for 9 months without a formal monitoring step.
Problem: Precision has dropped from 78% to 61% over the last quarter, caught only when a manual audit was run.
Impact: Roughly 400 at-risk accounts/month likely mis-flagged or missed during the drift window.
Success: Automated drift alerts live, with precision monitored weekly, within one sprint.
Why it works: “Nobody notices” becomes a specific monitoring gap with a measurable consequence.
Engineering & Ops
Weak: “The pipeline is slow.”
Context: The nightly ETL pipeline has run on the same infrastructure since last year’s migration.
Problem: Average runtime has grown from 40 minutes to 3.5 hours, occasionally missing the 6 AM reporting SLA.
Impact: Reporting SLA missed 9 times in the last 30 days, delaying downstream dashboards each time.
Success: Runtime back under 1 hour, SLA met consistently, within 4 weeks.
Why it works: “Slow” gets a before/after number and a named consequence, not a vibe.
Weak: “We have too many production incidents.”
Context: Incident tracking has been consistent since the on-call rotation started in January.
Problem: Sev-1 incidents have risen from 2/month to 7/month, mostly traced to one deployment pipeline.
Impact: ~14 engineering hours/month spent on incident response, pulled from planned roadmap work.
Success: Sev-1 incidents back under 3/month, with root cause documented for each, within two months.
Why it works: Names the source (one pipeline) and the actual cost, hours pulled off the roadmap.
Weak: “Support tickets are overwhelming the team.”
Context: Ticket volume has been tracked in the helpdesk tool since the last product launch.
Problem: Volume is up 65% month-over-month, with 40% of tickets tied to one known bug that hasn’t been prioritized.
Impact: Average response time has slipped from 4 hours to 19 hours, breaching the support SLA.
Success: Response time back under 6 hours and the known bug fixed within 3 weeks.
Why it works: Separates the symptom (ticket flood) from the actual driver (one unfixed bug), which is also the fix.
The Most Common Problem-Framing Mistakes
Four mistakes show up constantly, and they’re worth naming because most bad problem statements are one of these, not some unique blend of all four.
Solution in disguise. “We need X” isn’t a problem statement, it’s a conclusion. Strip the solution back out and ask what gap made X seem necessary, that gap is your actual problem line.
No baseline. If you can’t say what the impact is compared to before, you can’t quantify the impact line, and “the impact is bad” doesn’t get funded. Go find last quarter’s number before you write this section.
Unmeasurable success. “Improve the experience” isn’t success criteria, it’s a mood. No number, no date means you haven’t decided what done looks like, you’ll know it when you see it, which reviewers correctly read as “never.”
Scope sprawl. Three problems crammed into one statement, usually because they felt related and bundling seemed efficient. Split them. A statement trying to fund everything usually funds nothing, because nobody can evaluate three asks wearing one sentence.
One more, worth its own line because it’s sneaky: sometimes what you’ve framed is a symptom, not the actual problem, churn “is high,” but the real gap sits upstream in onboarding or pricing. That’s a root-cause question, not a framing one, and it’s worth running an RCA before you lock the problem line in.
Frame Before You Prompt: Problem Statements as AI Inputs
Here’s the part most problem-statement guides skip entirely: the same four lines that get a project funded also happen to be the best prompt you’ll ever write.
Try this. Ask an AI tool “why is churn high and what should we do,” and you’ll get back something confident, generic and mostly useless, five bullet points that could apply to any SaaS company on earth, because you gave it no scope, no constraints, and no definition of done.
Now feed it the filled template instead: the context (sub-₹5L accounts, since the CRM migration), the problem (churn climbed from 2.1% to 3.4%, concentrated in one segment), the impact (₹85L at risk), the success bar (back under 2.5% in two quarters). Same model. Wildly different output, because now it has a segment to reason about, a number to anchor against, and a target to work backwards from, instead of guessing at what you actually want.
This isn’t a coincidence. A problem statement and a prompt are doing the same job: turning a vague feeling into something a system, human reviewer or language model, can act on without pinging you back with five clarifying questions.
Rewriting weak statements into sharp ones is, not coincidentally, a week-one exercise in AI-first programs, the PGP calls it debugging bad prompts into high-quality instructions, and it’s built on exactly this template. The instinct runs both directions: better framing makes better prompts, and the discipline of prompting well tends to sharpen how you frame problems for humans too.
If the scoring rubric example from earlier felt familiar, that’s because it’s really a mini issue tree hiding inside one problem statement, worth knowing once you’re ready to break a bigger problem into ownable pieces.
From Framing to Solving: The Full Structured-Thinking Loop
A problem statement isn’t really step one of a project, it’s step one of every structured-thinking tool that comes after it. Once the gap, impact and success line are locked, the natural next moves are: break the problem into ownable pieces, run the analysis, and if the surface-level problem turns out to be a symptom, drop back into root cause to find what’s actually driving it. Framing, decomposition, analysis, root cause, that’s the whole loop, and this article is just step one, written out properly.
The template above is free, and it’ll make your next proposal or prompt noticeably sharper on its own. What’s harder to pick up from an article is the reflex, framing every messy, half-formed problem this way automatically, under deadline pressure, without reaching for the solution first. That’s the part structured-thinking training is actually built to drill, across enough real problems that it stops being a template you consult and starts being how you think by default.
FAQs
What are the 4 parts of a good problem statement?
Context, the problem itself, quantified impact, and success criteria.
What is an example of a bad problem statement?
“We need a new dashboard”, it’s a solution in disguise, with no problem, impact, or success measure attached.
How do problem statements improve AI prompts?
They give the model scope, constraints and a success definition, turning generic output into something actually usable.
How long should a problem statement be?
2-4 sentences. If it needs more than that, the problem probably isn’t defined yet.
