Reference cards
Keep this page open during simulations. Everything here is a tool for one of the five questions — the header on each card tells you which letter of SOLVE: Surface · Observe · Learn · Vet · Earn.
S–O · The three Bs
| Level | Test | Village-well example |
|---|---|---|
| Build | Did we make/do the thing? | The well is built. |
| Behavior | Can I watch someone behave differently? | Villagers spend less time carrying water. |
| Bottom line | Is it a big number many factors feed? | Standard of living rises. |
Quick test in the wild: if a “goal” could be achieved while creating zero value (a shipped feature nobody uses), it's a build. If no single team could plausibly own it, it's a bottom line. Behaviors live in between: specific, observable, measurable. (Elsewhere you'll hear this ladder as outputs → outcomes → impact — same levels, different words.)
S · Opening checklist
- Client & context — who are they, what do they sell, to whom, how do they make money?
- Objective — what bottom-line metric, and what's the baseline today? (“Success compared to what?”)
- Scope & constraints — what's in, what's out, what's untouchable, what's the deadline?
- Terms — any word doing heavy lifting (“engagement,” “efficiency,” “premium”) gets defined now.
- Say it back — restate the problem in one sentence and get explicit agreement before proceeding.
O · The three behavior questions
2. What would they be doing differently if we succeeded?
3. What behaviors predict the result we care about?
And the linked form every target should take: If we create [this customer/user behavior], it will deliver [this business result].
O · Leading vs. lagging
A lagging indicator tells you how you did (revenue, NPS, churn) — real, but too late to steer by. A leading indicator is a behavior that predicts the lagging one (newsletter opens predicting return visits; early client–vendor meetings predicting deal success). Target behaviors that are leading indicators; report bottom lines that are lagging ones. If you can't name the leading indicator for your project, you don't yet know how it creates value.
L · Issue trees & MECE
- MECE test: no overlaps (each item counted once), no gaps (together they cover everything). Say your tree out loud; overlaps hide in silence.
- Profit tree starter: Profit = Revenue − Cost → Revenue = Price × Volume (× Mix across segments) → Cost = Fixed + Variable (per unit × units).
- Quantify the branches: how much of the change does each branch explain? If the bars don't sum to the observed change, keep digging.
- Choose your structure: economic question → tree. Behavioral question (“why don't people…?”) → journey map. Big engagements usually need one of each.
L · Journey map with boosters & blockers
- Lanes for each actor (customer, staff, system). Left to right: what they actually do, step by step — the real process, not the official one. Follow one real case end to end.
- Pass two, the behavior question: at each step, what behaviors predict success (boosters, green) and failure (blockers, red)?
- Harvest: “increase the rate of [booster]” and “decrease the rate of [blocker]” are your candidate target behaviors.
V · The hypothesis template
will create [this behavior change — observable and measurable].
We'll know we're right when [this evidence, observable by this date].
Then list what must be true for the claim to hold, and rank by shakiness. Your first test attacks the shakiest condition — not the easiest one. Vet before you bet.
V · The experiment ladder
Cheapest first. Climb only as high as the decision requires.
| Rung | What it looks like | Cost |
|---|---|---|
| Look | Query data you already have; find the correlation or its absence. | Hours |
| Ask | Interview or survey the people whose behavior must change. | Days |
| Fake it | Paper prototype, concierge test, landing page, pump-before-the-well. | Days–weeks |
| Pilot | Parallel run or one-site/one-category rollout with a baseline comparison. | Weeks |
| Prove it | Randomized test (A/B) on the real metric. | Weeks–months |
A note on the word “MVP”: it gets used two different ways — for a cheap experiment (the lower rungs of this ladder), and for a first sellable release with a deliberately chosen feature set, which is the standard meaning in product management. Both are legitimate; they are different things. This site says cheapest test for the first and first release for the second.
V · The evidence triad
| Kind | Question it answers | Examples |
|---|---|---|
| Analytical | Does the logic and math hold? | Model backtest, sensitivity analysis, savings model |
| Behavioral | Do people actually do what the claim requires? | Pilot usage, override rates, interviews, parallel runs |
| Outcome | Did the metric move? | A/B result, before/after on the leading indicator |
Which kinds you need follows from your deliverable: a pure recommendation maxes out at analytical + behavioral before the decision; a built artifact must eventually reach outcome evidence — until it does, it's a demo.
E · Conclusion-first synthesis
Because — two or three reasons, each backed by a number.
Worth — the value, in dollars and days, with its range.
Risks — the top one or two, each with a mitigation.
Next — what happens Monday, and who owns it.
The sixty-second spoken version keeps the same order and cuts everything that isn't load-bearing. Never narrate your process chronologically; nobody's decision depends on what you did second.
E · The adoption argument
Every recommendation asks somebody to change their behavior — which means your stakeholders are customers, and adoption is a behavior change you must design for, not hope for. The heavier the behavior change, the heavier the argument: name who changes what, what's in it for them, what makes the new way easier than the old way, and how overrides/exceptions are governed. Then close with the measurement plan: the two or three leading indicators that will show, within weeks, whether the must-be-trues are holding.
Any letter · Case math habits
- Set up before you compute: say the formula, get agreement, then do arithmetic.
- Round smart: 96 × 52 is “about 5,000” until precision changes the decision.
- Sanity check: compare the answer to something known. A $40B market for campus coffee should embarrass you before it embarrasses your interviewer.
- State assumptions out loud and flag which ones the answer is sensitive to.
- End with the so-what: a number is not an answer until it's attached to a decision.
The failure-mode table
| Step | The classic failure | The fix |
|---|---|---|
| S · Surface | Accepting the requested thing as the problem | “If this worked perfectly, what number changes — compared to what?” |
| O · Observe | Targeting a build or a bottom line and calling it the behavior | “What would I watch someone do differently?” |
| L · Learn | Reciting a canned framework; or analysis without end | Structure this problem; rank branches; go deep on few |
| V · Vet | Confirming instead of falsifying; testing by building everything | Attack the shakiest must-be-true with the cheapest test |
| E · Earn | Chronological narration; no adoption plan | Answer first; treat stakeholders as customers |