Problem Definition and Framing Questions

Direct answer

State it as: "Among users who signed up by email in the past 14 days, onboarding completion fell from 80% to 60% after the new onboarding flow shipped; we want completion back above 80% within [N] weeks, measured as sessions that reach the 'setup complete' event." That single sentence names the target user, the current state, the desired state, a timeframe, and the metric that will tell you when the problem is solved.

Structured elaboration

A well-formed problem statement carries five load-bearing parts, and a statement missing any one of them invites the wrong kind of solution:

1. Target user - not "users" in general, but the specific segment the data is about (email sign-ups in the last 14 days, not all users). Naming the wrong segment sends the team investigating a population that was never affected.
2. Current state - the measured baseline, with enough specificity to be re-derived by someone else (80% completion, this cohort, this date range).
3. Desired state - what "fixed" looks like, ideally the prior baseline unless there is a reason to target something else.
4. Timeframe - both the window the drop was observed over and the window you're giving yourself to fix it. Without a fix-by timeframe, "reduce this" never gets prioritized against other work.
5. Metric - the exact signal you'll watch, defined precisely enough that two people computing it independently get the same number.

Two things a problem statement should NOT do: it should not name a cause ("completion fell because the new flow is confusing") and it should not name a solution ("we need to simplify onboarding"). Both foreclose investigation before it starts. The statement's job is to make the gap undeniable and measurable, not to explain it.

Worked example

Given the scenario: baseline is 80%, current is 60%, a 20 percentage-point drop, among the email-signup cohort, in the 14 days since the new flow shipped. The statement: "Onboarding completion among email-signup users has fallen from 80% to 60% in the 14 days since the new onboarding flow launched; we want to recover to at least 80% within 3 weeks, measured as the share of that cohort reaching the account-setup-complete event within 24 hours of signup." Note what's absent: no claim about WHY it dropped (a new step added friction, a bug, a segment mix shift) and no proposed fix. Those come after this statement, once investigation starts.

The same five components (target user, current state, desired state, timeframe, metric) transfer directly whether the trigger is a product metric, a data-science churn model, or a machine-learning (ML) launch: an ML repeat-purchase-drop variant of this exact scenario needs the identical five parts, just with an ML-specific metric (a model's tracked outcome) standing in for the product metric.

Trade-offs and pitfalls

The most common failure is writing a statement that is really a solution in disguise ("we need to add a progress bar to onboarding"), which locks the team onto one hypothesis before anyone has checked whether it's the right one. The second most common failure is omitting the timeframe: a problem statement without a "by when" for the desired state reads as aspirational rather than actionable, and competes poorly against work that does have a deadline. A statement that is too broad ("improve onboarding") fails the same test as no statement at all: it can't be disproven, so nobody can ever confirm it's solved.

Direct answer

A high-quality problem statement names the specific target user, states the current measured condition, states the desired condition, gives a timeframe, and specifies the metric that will confirm the gap is closed. Leaving any one of these out is what turns "we should fix onboarding" into an unactionable slogan instead of a scoped, testable problem.

Structured elaboration

Walking through why each part earns its place:

• Target user: without a named segment, "users are dropping off" could mean everyone or one small cohort, and those two situations call for completely different investigations.
• Current vs desired state: this is the gap the rest of the process exists to close. Stated as two numbers (or two qualitative states with a clear boundary between them), it gives the team a shared definition of "done" before anyone proposes how to get there.
• Timeframe: both the window the current state was observed over, and the window given to close the gap. A statement with no fix-by date competes poorly for prioritization against work that has one.
• Metric: precise enough that two people computing it independently land on the same number. A metric like "engagement" without a computation rule invites disagreement later about whether the fix worked.

A statement that includes all four but is still too broad ("increase engagement, ever, by some amount") fails a different test: it can't be disproven, so nobody can ever say with confidence that it's been solved.

Worked example

For the scenario given: "Among users who received the design update, monthly active users (MAU, the count of distinct users active at least once in a 30-day window) dropped 12% in the 30 days after the update shipped. We want MAU for this cohort back to its pre-update baseline within 6 weeks, measured as the 30-day rolling MAU count for users on the updated design." That single sentence is specific enough that a different analyst, handed only the sentence, could pull the same number from the event logs.

The same components apply to a one-paragraph ML problem statement written for a product requirements document (PRD): target user, current versus desired state, and constraints carry over unchanged, with one addition, an ML problem statement should also name the evaluation metric and baseline the model will be judged against, since "success" for a model is otherwise undefined.

Trade-offs and pitfalls

The most common failure mode is a statement that smuggles in a cause or a solution ("MAU dropped because the new layout hides the main action, so we should revert it"), which shuts down investigation before it starts by presenting an unverified theory as settled fact. The second is treating this as a one-time exercise: the components matter because they are testable, not because they're a checklist to fill in once and never revisit if new evidence emerges during discovery.