Structured Problem Solving and Decomposition Questions

Direct answer

Do not let each function's theory become its own branch. First agree one revenue figure and split it into parts that add up exactly, find which part carries the plateau, then give each branch one accountable owner with a named partner from the other teams. Cheap checks run first, and deep analysis goes only to the branch that earns it.

1. Agree one number before arguing theories

Fix the definition: recurring revenue (ARR, annual recurring revenue), net of refunds, same calendar period, produced from Finance's ledger. "Plateau" then means something specific: yearly growth fell from some rate to roughly zero.

2. The tree: an exact revenue bridge (MECE)

MECE (mutually exclusive, collectively exhaustive) means the branches do not overlap and together cover the whole. A revenue bridge is MECE by construction: growth = new customers + expansion - contraction - churn (each of the last two as a positive amount lost), where expansion is existing customers buying more, contraction is existing customers downgrading, and churn is customers leaving.

Illustrative bridge (M USD of ARR; last year opened at 100 and closed at 110, so this year opened at 110). Losses are shown as negative numbers, so each net row is just the column sum: 18 + 10 - 3 - 15 = +10 last year, 12 + 8 - 3 - 17 = 0 this year. Growth was therefore 10% last year and 0% this year.

Here 6 of the 10 M USD of lost growth sit in new customers, so that branch is checked first. Churn worsening by 2 M USD stays on the list. Read the table as dollars, not rate points, because the two years open from different bases (100 and 110). In growth-rate points on each year's opening ARR the same bridge reads: new customers fall from 18.0% to 10.9% (-7.1 points), expansion from 10.0% to 7.3% (-2.7), contraction improves from -3.0% to -2.7% (+0.3) and churn moves from -15.0% to -15.5% (-0.5), which sum to the 10-point fall in growth. New customers carry about 7 of those 10 points, so the ranking does not change, but their share is closer to 70% than 60%. The real numbers will differ, but the reading method is the same.

3. Hypotheses, first checks and owners

The bridge gives three revenue branches (contraction and churn grouped as "losses") plus two cross-checks.

The cross-check works like this. If every product and region flattened in the same months (for example, four products each going from about 10% growth to about 0% in the same quarter), suspect something company-wide (macro conditions, pricing, a shared process). If one product or region diverged (three products still at 10% and one at -30%), suspect a product or local-market cause. When a change rolled out in phases (a price change or a feature released region by region), compare regions that had it with those that did not over the same weeks to separate the change from the market. Illustrative: region A got the new price in March and grew 2% over March to May, while region B, still on the old price until June, grew 6% over the same weeks. The 4-point gap points at the price change rather than the market, which hit both.

4. Sequence

Days 1-2: reconcile and publish the bridge. Days 3-5: run the first check on the biggest branch and the cross-check in parallel. After that, go deep only on the branch that explains most of the gap, with a stated rule (for example, "if one branch holds more than half the gap, it gets the analysts").

When instrumentation (the usage tracking built into the product) is thin or only partial (for example, events missing for some products), lean on sources that do not depend on it: payment-processor totals, closed-won counts in the CRM, order counts in the database, support-ticket volumes. Two independent sources agreeing is the standard of evidence.

5. Shared ownership

An owner is accountable for the branch's number and its next decision, not for doing all the work. Every branch names a data partner. The integrator (the analyst or PM who ties the branches together) owns the bridge and the weekly readout (a short weekly summary of findings and decisions). Competing theories become sub-branches with separate checks: "Sales blames marketing" splits into lead volume (marketing's number) and win rate (sales' number), so one table settles it.

What a good plan contains

The agreed revenue definition, the bridge, branches with single owners, checks with time limits, a decision rule for going deep, and a readout date.

Pitfalls

Starting with the loudest function's theory, assigning ownership to a committee, and doing deep analysis before the bridge exists.

Direct answer

Pick one story where the task was genuinely vague, you chose a small first deliverable on purpose, and the plan changed because of what you learned. STAR means situation, task, action, result. The story below is an illustrative skeleton; swap in your own facts and numbers.

Structured elaboration: how to choose the first deliverable

I pick the piece that (1) is the smallest thing that is useful end to end, (2) can be tested within about two weeks, (3) uses data or access I already have, (4) carries low risk if wrong, and (5) teaches me the most about the parts I do not yet understand. Everything else gets sequenced after it.

Worked example (STAR)

• Situation: Leadership said, "Use AI to cut our support workload." No spec, no owner, no baseline.
• Task: I owned turning that into a plan within three weeks.
• Action:
  1. Wrote a one-sentence outcome with the sponsor: fewer agent minutes per ticket on routine questions, without a drop in customer satisfaction.
  2. Hand-labelled a random sample of 200 tickets by intent (the reason the customer wrote). 54 of 200 (27%) fell into just three intents with near-scripted answers (password reset, invoice copy, plan change).
  3. Cut the work into pieces: baseline measurement, draft replies for those three intents shown to agents, then a customer-facing chatbot later. Chose draft replies as the first deliverable. Why: 27% of tickets had near-scripted answers, so drafts could be right often; a support agent (a human on the support team, not an AI agent) reviews every draft, so a wrong draft costs little; and the chatbot would have to handle all 200 tickets, including the 73% with no script, while talking to customers directly. Drafts also produce labelled feedback for later steps.
  4. Shipped to four agents in week two.
• What changed: Agents ignored the drafts. The cause was that drafts lacked the customer's account context (plan, last invoice), so agents had to look it up anyway. I added an account lookup to the draft before widening the rollout, and parked the chatbot until acceptance was healthy (we had agreed at least 50% of drafts sent after changing less than about a fifth of the text). I also learned early that the intent categories needed one more split (billing questions with and without a dispute).
• Result: The weekly rate of drafts accepted with little editing, which I had set up before launch, was 22% in week 3 (44 of 200 drafts) and 61% in week 6 (122 of 200) once context was added (illustrative figures; use your own). The sponsor approved a second phase based on that measured number, not on a demo. Be honest about what that number is: acceptance rate is a leading indicator (a proxy that should move before the real outcome), not the outcome the sponsor asked for. Agent minutes per ticket and customer satisfaction were not yet measured, so the second phase was approved on the condition that the first milestone of phase two is that baseline, with a stated bar for the next review. A good result line names the metric, the before and after values, and what decision followed.
• What I would do differently: Measure agent minutes per ticket before building anything, and sit with two agents on day one instead of week two.

The same shape in other settings

• Ambiguous security task, little documentation: first deliverable was an inventory of services holding customer data (a usable v1 in days), which then told us where to look deeper.
• Cross-team operational problem: first deliverable was a shared timeline of handoffs between teams, since nobody owned the whole picture, followed by one agreed fix per handoff.

Pitfalls

• Starting with the most interesting piece, not the most informative.
• A story with no plan change. Interviewers are probing whether you adapt.
• Inventing precise results. If you lack a number, say what you measured and how it moved.

Direct answer

A sprint is a fixed work period, often two weeks. A horizontal slice is a piece of work along one technical layer (the database, then the service, then the screen). A vertical slice is a thin piece that cuts through every layer and delivers something a user can actually use. It matters because only vertical slices produce feedback and real risk information early. I default to vertical slicing and avoid it in a few specific cases: a shared foundation that must exist first, specialist teams that need an agreed interface to work in parallel, and work with no user-visible increment.

Search feature, two ways

Terms: the search index is the lookup structure that makes searching fast, the API is the service the screen calls to run a search, typo tolerance matches "shose" to "shoes", and an increment is a piece of working product a user can use.

Why it matters

• Early feedback: after slice 1 real people can type queries, and the team learns what they search for before building filters nobody uses.
• Risk shows early: speed with real catalog size, or the index missing half the products, appears in week one, not after three layers are "done".
• Optionality (keeping your choices open): if priorities change after slice 2, the team stopped with a working feature, not three unfinished layers.
• Honest progress: "layers done" says little about whether a user can do anything.

The test for a good slice

Can a real user do something useful with this slice alone? Can it be demoed? Does it touch every layer, even thinly?

When I would not default to vertical

• A risky shared foundation several features will depend on, such as migrating the search engine or a data model hard to change later. I would still make the first step a thin "walking skeleton" (one query end to end) to prove the layers connect.
• Specialist teams working in parallel, where agreeing the interface first (a time-boxed horizontal step) lets them proceed independently. The interface is the agreed contract between the teams, for example: the screen sends the query text and a page number, and the service returns a list of product id, title and price. That is a two-day agreement session, not a two-sprint build.
• Work with no user-visible increment, such as security hardening or compliance changes. A horizontal first step here looks like a one-sprint (two-week) task such as "enforce encrypted connections on the search service", finished and verified on its own, with a visible done-test (for example a scan that reports no unencrypted endpoints).

Second example: a reporting dashboard

Two independently valuable vertical slices: (1) a "weekly sales by region" chart for regional managers, covering the data pull, calculation, chart, access control and export, using data that already exists; (2) a "late deliveries" table for operations, with its own query, definition of "late", alert threshold and permissions. Either can ship alone and be judged by its users, which a plan of "build all queries, then all charts" cannot offer.

Pitfalls

• A "vertical" slice that is really one layer, such as a screen with fake data and no backend.
• Slices so thin they carry no user value (a search box that returns nothing).
• Skipping the foundation for ever, then paying for it in rework.

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

Break search into the layers a query passes through, agree the contract between the layers first so teams can work in parallel, then ship the thinnest slice that goes all the way from the search box to a tappable result. A thin vertical slice (one narrow path through every layer) beats finishing one layer completely, because only a shipped slice produces the real queries that tell you what to build next.

Structured elaboration

Subcomponents of "add search to a mobile app"

Dependencies. The UI needs the API contract (request and response shape), not the finished API, so UI and backend can start together against a stub (a stand-in that returns fixed sample results so the screen can be built before the real service exists). The API needs the index; the index needs access to the content. Ranking improvements need query logs, which need instrumentation, which needs the UI to be live. That last chain is why the first slice should ship early.

Which slice first. Choose the slice that touches every layer and teaches the most: search one content type by title with prefix matching (what has been typed so far is matched against the start of titles, so "sho" finds "shoes"), return the first 20 results, tap to open the item, log every query. Defer filters, typo tolerance, autocomplete, voice input and personalization. Each is a bounded add-on once real queries exist.

Worked example

Slice 1 for a shopping app: "type a product name, see up to 20 matching products, tap one." Contract agreed on day one: request is a query string plus a page cursor (a marker saying where the next page of results begins); response is a list of item id, title and thumbnail. Done-criteria: the UI renders results from the stub; the real API answers within the latency target the team set; every query is logged. As one checkable sentence: typing "shoe" returns up to 20 matching products from the real API within the agreed response time, tapping one opens its detail page, and a log row with the query text and result count exists.

The same method on other initiatives, in short

• Save for later: the interfaces are client to saved-items API (save, unsave, list) and API to analytics (event schema). Agreeing those two contracts lets mobile, web and backend build in parallel.
• Four-market wallet launch: decompose by workstream (compliance, partnerships, UX, backend, fraud) and launch one market first as the thin slice. Compliance and partner approvals are external and slow, so start them first even though the engineering path looks shorter.
• Audit logging: components are what to record, capture hook, tamper-resistant storage, retention, and a viewer. Validate each by performing an action and checking one record with who, what and when appears, then trying to alter it and confirming that fails.
• ML feature pipeline (ingestion, features, training, inference, monitoring), each with one done-criterion and one risk to mitigate. Terms: a feature is an input signal given to the model; offline means on stored historical data and online means on live traffic; training teaches the model from past examples and inference is the model predicting on new cases; a label is the known right answer used to teach and score the model; a schema is the agreed list of columns and types in the data; proxy metrics are quick stand-in measures used while real labels have not arrived yet.

Trade-offs and pitfalls

• Splitting by team ("backend search, mobile search") hides dependencies; split by what each piece delivers.
• Finishing the index and ranking before any UI exists means no user learning for weeks.
• A slice must be usable, not a demo: includes an empty state and error handling.
• Do not turn each component into a long acceptance-criteria document; one checkable done-criterion is enough at this stage.