Problem Statements: When Framing Stops Too Early

Problem statements are supposed to be the insightful move.

When a conversation gets fuzzy, someone says, “Hang on — what problem are we solving?” Heads nod. A marker appears. A tidy sentence goes on the whiteboard: “Users struggle to manage projects.”

It feels like you just did the hard part. You didn’t. You did the halfway part.

Statements like this name a negative state from our side of the glass — they’re struggling, they’re confused, it’s hard — and then stop. They don’t say what the person is actually trying to make happen, what changed in their world to make it urgent, or what “better” would look like in their terms.

So the sentence sits there looking serious while the room fills it with whatever solutions everyone already knows how to ship: dashboards, Kanban, timelines, “AI insights,” digests, redesigned navigation.

Six months later, you’ve “solved” project management and still don’t own any of the moments where project work actually lives or dies.

That’s framing that stopped one step before an actual Job.

Problem statements are supply‑side. Listen to the usual pattern: “Users struggle to…” “Customers have difficulty…” “People don’t understand…” “It’s hard to…”

All of that is written from the product outward. It describes an absence — no ease, no clarity, no success. It almost never captures:

• what’s happening in their world when this shows up
• what progress they’re trying to make
• what counts as “good enough” in that situation
• what they’re afraid of if it goes wrong

In other words, it gives you pain without progress. A complaint without a direction. When you don’t name progress, you don’t get a design target.

A Jobs lens flips the question. Instead of “what problem do they have with our thing?”, it asks: “when does this show up in their life, what are they trying to change, and what would better feel like?”

“Users struggle to manage projects” becomes: When my team’s work is scattered across messages, docs, and meetings, I want one place to see who’s doing what and what’s at risk, so nothing slips and I don’t get surprised.

Same domain. Completely different level of usefulness.

Now there’s a scene: scattered work, real deadlines, social exposure if something slips. There’s a direction of progress: from scattered and blind to one place, clear ownership, visible risk. There are emotional stakes: don’t get surprised, don’t look incompetent.

You can design against that. You can’t design against “struggle” in the abstract.

Know the difference between a category label and a job

“Manage projects” sounds specific. It isn’t. It’s a bucket. Inside that bucket are jobs that look identical on a roadmap and behave nothing alike in reality. In the same product, you’ll see people trying to:

• plan the next six weeks so the team stops thrashing
• stay ahead of what’s blocked so they aren’t blindsided before a review
• recover a slipping launch without blowing up trust
• reassure leadership that things are under control
• stop being the human router for every status question

All of those are “project management problems.” None of them are the same job.

A problem statement flattens them into one prompt. A job statement pulls them apart into actual segments. The moment you do that, “good experience” stops being a single thing.

Planning and alignment want a different kind of surface than fast re‑entry and triage. “Stop routing everything through me” wants something different again. The jobs you choose define what quality even means.

This is how you can ship “good” features into what looks like a “good” UX and still miss: you executed on the category, not on a specific job in a specific moment.

Same problem, two jobs, opposite decisions

Go back to this problem statement: “Users struggle to manage projects.” It almost begs for a generic answer: “we need a better, more powerful dashboard.”

Now look at the two jobs that hide inside it.

Job A: Execution visibility: When work is in flight and I’m on the hook for the outcome, I want to instantly see what’s blocked, what changed, and who needs a decision, so I can keep momentum without running more meetings.

For this job, more panels and charts are a distraction. What matters is a spine: what changed since last time, what’s stuck, what needs attention, and where a decision is waiting. The right answer may look more like an inbox, a triage lane, or a “what changed” strip than a traditional dashboard. It could even look “too simple” on a roadmap and still be exactly right.

Job B: Planning and alignment: When we’re about to start a new initiative, I want to agree on scope, owners, and sequence in a way that survives reality, so we don’t thrash for the next six weeks.

For this job, a triage view is not enough. You need ways to converge on a plan and keep it trustworthy: clear ownership, visible dependencies, recorded decisions, some way to adapt without everyone feeling like the plan is constantly being yanked out from under them.

Both jobs live under “project management.” They do not want the same product. The first wants fast re‑entry and risk visibility. The second wants alignment that can flex without breaking trust.

If all you have is “users struggle to manage projects,” you’ll aim both at “better dashboard” and end up with something that’s fine for nobody.

When you move from problems to jobs

You can feel it in the meeting. With a problem statement, the idea machine runs wild.

“Users struggle to manage projects” supports anything: more templates, an AI assistant, new navigation, more integrations, status emails, reports. Every suggestion is equally “on brief,” because the brief is unfocused.

With a job statement like “when work is scattered and deadlines are real, I want one place to see ownership, status, and risk so nothing slips,” you suddenly have constraints. Now every idea has to move “scattered” toward “one place,” and “surprises” toward “I see risk early.” The question in the room becomes, “What would have to exist for ‘nothing slips’ to feel true?” Decorative ideas die fast when they can’t answer that.

Tradeoffs change too. Problem framing gives you arguments like “Kanban vs timeline,” “more customization vs less,” “simplify vs add power.” Those are taste debates. Job framing gives you choices you can actually decide: “If we optimize for fast re‑entry and risk visibility, are we willing to accept less flexible planning views?” “If we optimize for alignment that survives reality, do we accept a heavier setup at the start?” Now you’re deciding which progress to privilege, not which pattern you like.

And “for whom” stops being “our users” on a persona slide. Jobs force you to acknowledge that context changes everything. The same “project management” surface means different things to a team lead who checks it once a day, a new manager inheriting a mess, a cross‑functional initiative with political stakes, or a three‑person team just trying to keep track without overhead.

Job framing surfaces those differences before you flatten them into an average.