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

"Existing business-to-business (B2B) customers on the mid-market tier, with a 6-month sales cycle, are churning at a rate that jeopardizes the annual-contract renewal base; we want to identify the dominant driver and reduce churn within two quarters." From there: stakeholders are sales (for renewal and expansion context), customer success (for account-health signal), and finance (for the retention-versus-acquisition trade-off); likely root causes to test are onboarding time-to-value, a competitor feature gap, and support responsiveness; experiments and constraints follow from which of those the data actually points to.

Structured elaboration

Stakeholders: customer success owns the account-health and usage data and the closest relationship with churning accounts; sales owns the renewal-cycle timeline and competitive intelligence from lost deals; finance owns the retention-versus-acquisition cost trade-off, since a B2B (business-to-business) product with a 6-month sales cycle makes new-customer acquisition expensive relative to retaining an existing account.

Hypothesized root causes, in the order cheapest to check: (1) slow time-to-value, meaning accounts that take longer to reach a defined "activated" milestone churn more, checkable against existing account data without new instrumentation; (2) a specific competitor feature gap, checkable against sales' loss-reason notes from recent renewal conversations; (3) support responsiveness, checkable against existing ticket-resolution-time data correlated with churned versus retained accounts.

Experiments, one per surviving hypothesis after the cheap checks above narrow the field: if time-to-value is implicated, a guided-onboarding pilot for new accounts, measuring whether faster time-to-value correlates with lower churn in the next renewal cohort; if the feature gap is implicated, that becomes a roadmap input rather than an experiment, since building a feature isn't something you A/B test before committing resources; if support responsiveness is implicated, a pilot with a dedicated response-time service-level agreement (SLA) for accounts flagged at churn risk, measuring whether faster response correlates with retention.

Constraints: a 6-month sales cycle means any fix aimed at NEW accounts won't show up in the churn numbers for two quarters at the earliest, so this problem needs both a near-term mitigation for at-risk existing accounts and a longer-term structural fix.

Trade-off: acquiring a new mid-market account costs meaningfully more, in sales cycle length alone, than retaining an existing one, which is the argument for weighting investigation and mitigation toward the churn side even if a parallel acquisition push looks more immediately visible to leadership.

Worked example

If the loss-reason review (cheap check 2) shows 60% of lost-deal notes from the past two quarters cite a specific missing integration a competitor offers, that's a stronger, more specific signal than a vague "we're losing to competition," and it turns the roadmap conversation into a concrete build-or-don't decision rather than an open-ended investigation.

A structurally similar problem, framed cross-functionally rather than as a churn diagnosis, is leading discovery for international expansion: the same discipline applies, identify the likely user segments in the new market, name the local constraints (payment methods, localization, legal and regulatory requirements), specify what data would confirm product-market fit there, and propose a phased, single-region pilot with its own measurement plan before a full-market commitment.

Trade-offs and pitfalls

The main risk in a churn problem like this is treating it as a single root cause when B2B churn is frequently multi-causal: a real fix might require addressing time-to-value AND a competitive gap simultaneously, and stopping investigation after confirming the first plausible cause risks leaving a second, equally real cause unaddressed. The six-month sales cycle constraint is easy to overlook when a fix "feels" urgent; without accounting for it, leadership may expect churn numbers to move faster than the sales-cycle math allows.

Direct answer

An assumption is something you're treating as true without evidence; a hypothesis is a specific, testable claim you've deliberately set up to check against evidence. The distinction matters because an unexamined assumption quietly shapes a whole investigation, while a hypothesis is something you've committed to potentially being wrong about.

Structured elaboration

Improving internal search relevance, two assumptions might be: "users know what keywords to search for" (an unstated belief about user behavior, never checked) and "our current ranking algorithm treats all document types equally" (an unstated belief about the system, never verified against the actual implementation). Two hypotheses, in contrast: "search queries using exact document titles return relevant top results at a materially higher rate than queries using general keywords" (a specific, checkable claim) and "recently-updated documents are being under-ranked relative to older, more frequently-viewed ones, regardless of relevance" (a specific claim about a mechanism, checkable against the actual ranking output).

Converting each assumption into a hypothesis: for "users know what keywords to search for," rephrase as a testable claim: "at least 30% of zero-result or low-relevance searches use a phrasing that doesn't match any document title or common synonym in our index," which can be checked directly against search-log data. For "our ranking algorithm treats all document types equally," rephrase as: "when a wiki page and a formal document cover the same topic, the ranking algorithm returns them at similar positions rather than systematically favoring one type," checkable by sampling matched-topic pairs and comparing their ranked positions.

Worked example

Checking the first converted hypothesis against search logs: if 45% of low-relevance searches use phrasing absent from any indexed title or synonym list, that confirms the underlying assumption was masking a real, sizable pattern, worth acting on (expanding the synonym list, or improving fuzzy matching), rather than remaining an untested belief the team had been building around implicitly.

Trade-offs and pitfalls

The most common mistake is treating an assumption as though it were already a hypothesis, meaning already tested, simply because it feels obviously true; "users know what keywords to search for" can feel self-evident right up until search-log data shows otherwise. The conversion step from assumption to hypothesis is only useful if the resulting hypothesis is actually specific enough to be checked against real data; a hypothesis restated in equally vague terms as the original assumption ("search relevance could probably be better") hasn't actually made any progress.

Direct answer

A reusable problem brief forces the same five questions onto every proposed effort before it gets engineering time: what's the evidence, who's affected, how big is the impact, what do we believe is causing it, and how will we know we've fixed it. Filled in for "slow report generation for large datasets": evidence is a p95 report-generation time of 45 seconds against a 10-second target, affected users are accounts generating reports over 500,000 rows (roughly 8% of active accounts), and so on through the remaining fields.

Structured elaboration

The template's nine fields, and why each one is there: Evidence (the data that proves this is real, not anecdote); affected users (a specific segment, not "everyone"); impact estimate (how big a deal this is, to compete fairly for prioritization against other work); hypotheses (candidate causes, plural, not a single assumed one); proposed experiments (the cheapest way to test the top hypothesis before committing to a fix); success criteria (the metric and target that will confirm it's solved); owner (one accountable person, not a team); timeline (a fix-by date); risks (what could go wrong or what this might break).

Worked example, filled in:

• Evidence: p95 report-generation time is 45 seconds, against a 10-second internal target; this affects the "export large dataset" feature specifically.
• Affected users: accounts generating reports over 500,000 rows, roughly 8% of active accounts but disproportionately represented among the highest-tier customers.
• Impact estimate: three support escalations in the past month cite this directly, and it's a named blocker in two enterprise renewal conversations.
• Hypotheses: (1) the report-generation query itself is unindexed for this data volume, (2) generation is single-threaded and doesn't parallelize across data partitions, (3) the bottleneck is actually in rendering the output file, not the query.
• Proposed experiment: profile a sample of slow report requests to see where time is actually spent, query execution versus rendering, before committing engineering time to either fix.
• Success criteria: p95 report-generation time under 10 seconds for the 500,000+ row segment, measured over a rolling 7-day window post-fix.
• Owner: the data-platform lead for this feature area.
• Timeline: profiling complete in one week, fix scoped and estimated within two weeks of that.
• Risks: a fix to one part of the pipeline could shift the bottleneck elsewhere without profiling first, which is why profiling precedes any commitment to a specific fix.

A second filled instance of the same template, this time for an analytics team: evidence is "ad-hoc metric requests take a median of 4 days to fulfill," the hypotheses include an unindexed query pattern and a lack of self-serve dashboards, and the template's owner, timeline, and success-criteria fields work identically, only the domain (analytics turnaround time rather than report-generation latency) changes.

Trade-offs and pitfalls

A template like this adds friction to starting any effort, which is the point for anything nontrivial, but applying it uniformly to genuinely small, low-risk changes turns a lightweight fix into unnecessary process overhead; the template should scale down (a shorter version, or an explicit skip) for changes below some size or risk threshold, agreed in advance, rather than being enforced rigidly on everything. A second pitfall is filling in the hypotheses field with only one candidate cause, which defeats its purpose: the field exists specifically to force considering more than the first plausible explanation.

Direct answer

The original statement, "our homepage isn't converting enough, we need to make it better and align it with brand standards," is missing a baseline, a target, a specific user segment, a timeframe, and it smuggles in a solution ("align with brand standards") without establishing that brand misalignment is actually the cause. Rewritten: "Homepage-to-signup conversion for new visitors is currently 2.1%, below the 3.5% benchmark from comparable landing pages on this site; we want to close that gap within one quarter, measured as signup conversion rate for new (non-returning) visitors to the homepage."

Structured elaboration

What's missing from the original, specifically: No baseline ("isn't converting enough" compared to what?). No target ("make it better" by how much?). No named segment (all homepage visitors, or a specific subset?). No timeframe (by when?). An embedded, unverified solution ("align it with brand standards" assumes the cause is a branding mismatch, which hasn't been established by any evidence in the original statement).

The rewrite fixes each gap: it states a real baseline (2.1%) against a real comparison point (3.5% benchmark from comparable pages, which grounds "not converting enough" in an actual number instead of a feeling), a target and timeframe (close the gap within one quarter), a specific segment (new visitors, since returning visitors' conversion behavior is a different problem), and it removes the embedded solution entirely, leaving the cause open for investigation.

Worked example

Acceptance criteria that follow from the rewritten statement: (1) new-visitor signup conversion reaches at least 3.0% within the quarter, (2) the change does not reduce conversion for returning visitors by more than 0.5 points (a guardrail, since a homepage change optimized for new visitors could inadvertently hurt the experience for returning ones), (3) the fix ships with before-and-after data attributing the change specifically to the homepage modification, not a concurrent marketing campaign or seasonal effect. These are concrete pass-or-fail checks the original vague statement could never have produced.

Trade-offs and pitfalls

Rewriting a stakeholder's statement risks reading as a rebuke of their original framing, particularly when it came from someone senior; it helps to frame the rewrite as "here's how I'd operationalize what you're describing so we can measure whether we've fixed it," which credits the underlying concern while fixing what's missing. The pitfall in the rewrite itself is inventing a specific baseline number without actually pulling it from data; if the real baseline isn't known yet, the honest version of the rewrite states that measuring the baseline is the first concrete step, rather than presenting an invented number as though it were established fact.