Structured Problem Solving and Decomposition Questions

Direct answer

Turn the mandate into arithmetic and questions before ideas. Work out what +20% means in extra daily users beyond the trend already under way, split DAU (daily active users: distinct users doing a qualifying action in a day) into new, retained and resurrected users, size each lever roughly, and see whether the pieces reach the target. Rank first hypotheses by users added, and test the cheapest in one-week experiments.

What to ask first

1. How is DAU defined and which action counts? If merely opening a notification counts, the easiest lever is cheap to game. This decides which metric to trust.
2. What is DAU today and what is it doing on its own? The target should be measured against that trend.
3. Why 20% and why six months? A board commitment is firmer than a guess, which decides whether the target is negotiable.
4. What can we not use? "No budget" shifts the plan from paid acquisition to retention and activation.
5. What must not get worse (opt-out rate, revenue, quality)? These are the guardrails (metrics that must hold steady while you push the main one).

Probe vague replies: "grow users" becomes "DAU or signups, for which segment, measured how, by when?"

The arithmetic (illustrative baseline of 500,000 DAU)

Target: 500,000 × 1.2 = 600,000. Compounded over six months that is 1.2^(1/6) = 1.031, about 3.1% a month. The trend is what DAU would do with no new work. If DAU already grows 1% a month, trend alone gives 500,000 × 1.01^6 ≈ 530,760. The plan must add about 69,000 users beyond trend, roughly +13% on top of the trend (1.2 / 1.0615 = 1.13), not +20%.

Decomposition and sizing

DAU on a day = users who return from yesterday + new users activated (reached first value, such as their first post) + lapsed users who resurrect. First-pass guesses, to be replaced by data. One way to size a lever (retention, illustrative inputs): 80,000 users sign up a month, and if day-30 retention rises 5 points, each monthly signup cohort (the group who joined in the same month) keeps 0.05 x 80,000 = 4,000 more daily users. Over the six months of the window that adds up to about 6 x 4,000 = 24,000 (the table rounds this up to 25,000, which flatters the lever by about 4%). Activation and resurrection are sized the same way: users affected x points of improvement you think is achievable x months of cohorts. Replace each input with a measured value as soon as it exists.

The 14,000 left over (69,000 minus 55,000; about 15,000 if the retention row is left at its unrounded 24,000) must come from a new surface (a new place users meet the product, such as a new app tab or channel) or segment, or from renegotiating the target. That is the finding to take to the executive.

One-week experiments, with thresholds set beforehand

Each experiment tests one row of the table: the first targets Activation, the second targets Retention. The examples below use a developer-facing product for the first and a content-recommendation product for the second, to show two different kinds of first-value moment; substitute your own product's.

• Developer onboarding: KPI (key performance indicator) is the share of new developers making a first successful API call within 24 hours. Rule (illustrative): ship if it rises at least 3 points and signup completion falls by less than 1.
• "Make recommendations more surprising": make it measurable as the share of recommended items from categories the user has not engaged with in 30 days, with click-through rate (the share of shown items that get clicked) held above an agreed floor. Rule (illustrative): carry it into a longer test if the share of recommendations from new categories rises from 8% to at least 12%, day-1 and day-7 return among exposed users are no lower than the control group's, and click-through rate stays within 0.3 points of a 5% baseline.

A one-week test reads leading indicators (early signals that predict the real outcome, such as the share of users who return on day 1 and day 7), not six-month DAU.

Pitfalls

Accepting +20% with no baseline trend, inflating DAU through notification opens that raise opt-outs, and treating a one-week lift as proof of a six-month outcome.

Direct answer

Pick a story where the problem really was messy (many possible causes, no obvious owner), where you chose an explicit way of splitting it, and where the split saved you from a specific wasted effort. A strong answer says why that split (what made the parts independent), why you tested one part first (it ruled out the most possibilities for the least work), and what the structure stopped you from doing.

Structured elaboration

Use STAR (Situation, Task, Action, Result) and weight the Action section:

• Situation and Task: two sentences. What looked wrong, who noticed, why it mattered.
• Action, the part interviewers score: (1) the way you split, along a dimension such as stages of a data flow, and why that dimension; (2) the first part tested and why (cheapest check that cuts the search space in half); (3) what each result told you; (4) how you confirmed the cause before fixing.
• Result: what was fixed, what you added so it would not recur, and honestly what you would do differently.
• What the structure helped avoid: name at least one concrete trap, such as chasing the most visible suspect for days, blaming another team's data, or changing two things at once.

Worked example

Example story to adapt to your own facts (qualitative on purpose, meaning described in words rather than with measured figures; use your real numbers only if you can back them up).

Situation. A weekly sales report from our analytics tables was off by a few percent against the finance ledger. Finance distrusted the dashboard and the team suspected a faulty query.

Task. Find where the numbers diverged, without a week of guesswork.

Action. I split the path the data takes into stages: source system, extraction, staging table, transformation, final report table, dashboard. Rather than start at the dashboard (the most visible suspect), I compared row counts and totals at the middle, the staging table. They matched the source, so extraction and staging were cleared in one check and the problem lay in the second half. A second comparison after the transformation step showed the gap appeared there. Reading that step, an inner join (keeps only rows that match in both tables) to a currency-rate table dropped orders in a newly added currency with no rate row. I confirmed it by counting orders per currency before and after the join, then changed one thing only: a left join (keeps every order and fills missing rate matches with a blank) with a visible default flag.

Result. The report reconciled with finance. I added a row-count comparison between stages that alerts on mismatch. Looking back, I would have added that reconciliation when the pipeline was built.

What the structure avoided. Days of rewriting dashboard queries that were correct, an argument with finance about whose number was right, and bundling several changes so we would not know which one fixed it.

Trade-offs and pitfalls

• A story that is just "I investigated until I found it" shows no decomposition.
• Splitting by whatever is convenient (by person, by file) rather than by something that makes the parts independent is weak.
• Claiming exact impact figures you cannot support is worse than a clear qualitative result.
• Saying you would change nothing sounds like low self-awareness.
• Be ready for a different-domain version: the same move works for a slow service, an inconsistent survey result or a failing model.

Direct answer

I first pin down what "dropped 15%" means, then build the tree on the identity renewals = subscriptions due x renewal rate. Below that I split by what happened to each customer who did not renew: they chose to leave (product, pricing), they could not pay (billing), or nobody helped them (customer success, CS). I would test the billing branch first because it is the cheapest to split out and cleanly actionable, and run the pricing check right after it (or in parallel if a second analyst is free).

Clarify first (illustrative assumption)

Assume 1,000 subscriptions came due in each quarter, and renewals fell 15%, from 800 (80%) to 680 (68%). That is 0.80 x 0.85 = 0.68. Non-renewals rose from 200 to 320, so 120 extra customers left. If the base of subscriptions due changed (for example more annual contracts, which renew once a year so a batch can land in one quarter, or a cohort, meaning a group of customers who signed up in the same period, that was weak), that is its own first branch.

The tree

Why this structure. Branch 0 checks the base, whether the number due changed. Branches 1 to 3 classify what happened to each lost customer, so every non-renewal has one primary home among them. The one-home test means checking that any given lost customer fits exactly one leaf, not two and not none. The tie rule says what to do when two leaves both fit: use the customer's recorded primary reason, and when it is missing, the earliest event in the sequence (for example a failed payment before any cancellation request counts as billing). Causes do interact (a price rise delivered with no outreach is both pricing and CS), so I say the tree classifies the primary cause, and I test interactions afterwards. The tree also gives four functions one shared map, which is why a disagreement among them stops being a debate.

Which branch first, and how I test it

Score each branch on size, how confident I am it is large, and cost to test. Billing wins on cost: the payment system already records failures, and the test is a count.

• Split the lost customers into involuntary (the payment failed, the customer did not decide to leave) and voluntary (the customer chose not to renew). Illustrative: failed-payment losses went from 40 of 200 to 100 of 320, an extra 60. So billing explains 60 of the 120 extra losses, half the drop.
• Next, the remaining 60 extra voluntary losses. Compare renewal rates of customers who received a price increase with those who did not, within the same plan (so plan type does not distort the comparison). This is observational, meaning I am comparing groups that already differ in what happened to them, not randomised, meaning nobody was assigned a price change by chance, so other differences between the groups could explain the gap. I read it as evidence, not proof, and check that the two groups are otherwise similar (tenure, size).
• Then product and CS branches using usage in the 30 days before renewal and outreach logs.

What would change my call

If a price change shipped this quarter and the failed-payment split is small, pricing moves to first. If the base of subscriptions due changed, branch 0 comes first.

Pitfalls

• Letting each function defend its own branch without a shared definition of "renewal".
• Testing the most interesting branch, not the most informative one.
• Treating an unexplained remainder as noise, not as the next branch to open.

Direct answer

Score every candidate on three things: how likely it is, how much of the problem it would explain if true, and how many hours it takes to check. Investigate in order of explained-per-hour, not by gut feeling or by whoever argues loudest. Cheap checks that can eliminate a cause go first, and each check gets a time limit.

The scoring rule

A hypothesis is a candidate explanation you can test. Priority = likelihood × share of the problem explained if true ÷ hours to check. The numbers are honest guesses, and their main value is that teammates can score separately and expose disagreement.

Worked example (illustrative numbers)

Checkout conversion fell from 3.0% to 2.7% a week ago. You have three days, about 18 working hours.

Likelihoods sum to 0.90, leaving 0.10 for "something else". To estimate "share explained if true", ask how many points of the 0.3-point drop (3.0% to 2.7%) the cause could produce if real, divided by 0.3. For B: if the campaign brings 10% of sessions and they convert at 1.2% instead of 3.0%, they pull the average down by 0.1 x 1.8 = 0.18 points, and 0.18 / 0.3 = 0.6. For A, a tracking bug would make the whole drop unreal, so 1.0. Order: A, B, C. Total effort is 12 hours, leaving 6 hours of the 18 for follow-up on whatever the checks reveal.

What would flip the order

If the release log shows nothing touched checkout tracking, A's likelihood falls to 0.05 and its score to 0.025. The order becomes B (0.060), C (0.027), A (0.025). A still costs only 2 hours, so it can run in parallel as a sanity check (a quick test that confirms a result is not an artefact).

Effort, risk and parallelism

• Independent checks run at the same time. With two analysts, A and B start together on day one, and the scores decide who gets a scarce third person.
• Add a cost-of-delay adjustment (weight a cause by what each extra day of waiting costs): if C means lost revenue every day and the fix is a one-line revert, move it up. For example, if a one-hour revert test replaces the six-hour investigation, C scores 0.20 x 0.8 / 1 = 0.160, above A's 0.150, so C runs first even though it is the least likely.
• Timebox each check (give it a fixed time limit), for example "if no signal after 4 hours, record that and move on." Allow one deep check only after the cheap ones fail.
• Write down what you ruled out and how, so the work is not repeated.

Pitfalls

Anchoring (locking onto the first idea or number you heard), treating the scores as measurements, and checking only evidence that confirms a favourite cause.

Direct answer

First pin down what "10%" means and which churn can move within one quarter. Then split churn into non-overlapping causes, size each in customers, and choose levers that need support or configuration time rather than engineering, ordered by customers saved per week of effort and with a buffer for estimates that disappoint.

Clarify the target

Churn is the share of customers lost in a period. "Cut by 10%" is most plausibly a relative cut (5.0% to 4.5%), not 10 points, so confirm it. Only customers who can cancel or renew inside the quarter can be affected, so check the renewal calendar first.

The how-tree

Churn = involuntary (payments fail, such as expired cards) + voluntary. Voluntary splits into new accounts that never reached value, established accounts whose usage faded, price- or competitor-driven loss, and unavoidable loss (the business closed). Segmenting churn by tenure, plan and channel shows where it concentrates, so levers target the right group.

Worked example (illustrative numbers)

5,000 customers start the quarter and 5.0% churn means 250 lost. A 10% relative cut is 25 fewer. Suppose 75 of the 250 are involuntary and about 60 are early churners.

Where the percentages come from: in lever A the one third is an assumed share of failed payments a better retry schedule recovers; B's 40% is the share of past accounts with a big usage drop that cancelled; B's 15% is an assumed save rate for outreach; C's 10% is an assumed save rate for a check-in. The assumed ones are placeholders until the Check column replaces them with measured values. The groups are not a partition of the 250: 75 involuntary leaves 175 voluntary, and the 60 early churners and the 80 who would leave after a usage drop can include the same accounts, with price-driven and unavoidable loss making up the rest. That overlap is why the saved customers cannot be simply added.

Gross: 25 + 12 + 6 = 43 against 25 needed (about 1.7 times). Overlap and optimism may cut it by a third, leaving about 29, still above 25.

Sequence

Week 1: baseline, switch on A, build the flag list. Weeks 2-4: run B and C. Track weekly leading indicators: recovery rate of failed payments, flagged accounts contacted, usage trend of contacted versus not contacted. To validate B, contact a random 80% of flagged accounts and compare with the other 20%. Be honest about power: with 200 flagged accounts that leaves 40 in the comparison group, and a 15% save rate takes the leaving share only from 40% to about 34%, a 6-point gap against a standard error of about 8.6 points (a simulation of this exact setup detects it about 10% of the time). One quarter of a 200-account test can therefore confirm only a very large effect. Holding back 20% also means only 160 of the 200 flagged accounts get outreach, so B's in-quarter saves are about 0.8 x 12 = 9.6, not 12; the gross becomes 25 + 9.6 + 6 = 40.6 and, after the one-third haircut, about 27, still above 25 but with a cushion of about 2 customers rather than 4. Treat B's saves as an assumption to keep testing over several quarters or a larger flagged list, and use the weekly leading indicators (flagged accounts contacted, usage recovery of contacted versus not contacted) as the in-quarter evidence.

Same method for "faster incident response"

Break it into detect (notice something is wrong), triage (judge severity and assign an owner), mitigate (stop the customer harm, even before the root cause is fixed) and resolve (fix the cause); measure the median minutes of each from incident timelines (for example, illustrative medians of 10, 25, 40 and 90 minutes), pick the longest, change one thing (for example alert routing), and measure that stage over the next incidents. Repeat, validating improvements one at a time.

Pitfalls

Counting customers when revenue matters more (large accounts weigh heavily), blanket discounts that defer churn and cost margin, and promising 10% before checking that the renewal calendar allows it.