Units & exercises
Six units. The first five each train one question (one letter of SOLVE) — a short drill you can run in class, then a simulation in the Wisconsin Case Lab, where you interview the people involved — clients, executives, frontline staff — played by AI. Unit 6 runs the entire arc twice: once as a classic diagnosis engagement, once as a data-and-code build.
Legend: Drill in-class, pairs or solo · Sim Wisconsin Case Lab, simulated clients & colleagues · Code uses data and AI coding agents (see the companion vibecoding course) · time estimated duration.
Surface — the ask behind the ask
Train yourself to never accept a brief at face value: clarify, find the bottom line, restate, and get sign-off.
Drill20 min Six bad briefs
You get six one-sentence asks the way they actually arrive: “we need a TikTok strategy,” “build a dashboard for leadership,” “our onboarding is broken, fix it,” and three more. For each, write (a) the three clarifying questions you'd ask first and (b) your best guess at the bottom-line metric hiding underneath. Debrief by comparing question quality: a good clarifying question changes what you'd do next; a bad one just delays.
Drill15 min Opening rounds
Pairs, three rounds, rotating. One partner plays a client with a one-line ask (cards provided); the other has four minutes to run a real opening: clarify, establish the bottom-line metric and its baseline, and say the problem back until the client agrees. Partners score one thing only: did you end with a problem statement I'd sign?
Sim45–60 min The App Nobody Needed
A founder-CEO — confident, visionary, twice successful — opens with: “I want us to build a new app. Something world-class. Can your team scope it?” Somewhere behind that ask is a real business fear and a real bottom-line metric. Your job is to interview your way to it. The CEO will happily let you spend the whole session talking about features; the underlying problem only surfaces for teams that ask about the business, not the app.
Deliverable: a one-sentence problem statement with bottom-line metric and baseline that the CEO explicitly agrees to — plus the list of questions that got you there.
Observe — what people do is the unit of value
Master the framework's signature move: translating bottom lines into measurable human behaviors, and telling builds, behaviors, and bottom lines apart on sight.
Drill15 min Build, behavior, or bottom line?
Twenty statements, sixty seconds each in pairs: “the well is built” … “villagers spend less time carrying water” … “40% of reimbursements now arrive through the new form” … “NPS rose six points” … “the model achieved 94% accuracy.” Sort each into build, behavior, or bottom line — and for every build, propose the behavior it's presumably in service of. The accuracy statement starts the best argument of the day.
Drill25 min The behavior questions, applied
Take five feature requests (from Unit 1's briefs and new ones) and run each through the three behavior questions: What are people doing today? What would they be doing differently if we succeeded? What behaviors predict the result we care about? Then produce, for each request, one linked pair — “if we create [this customer behavior], it will deliver [this business result]” — with a measure for each, tagged leading or lagging.
Sim45–60 min The Campus Partner
A director from a campus organization (dining, recreation, or the food pantry — your section will be assigned one) has funding for “a mobile app to boost engagement” and wants your help spending it well. Interview the director and a frontline staff member to find out what people in the system actually do today, then locate the behaviors worth changing. The best teams leave the app question open until the target behaviors are nailed down — and some sections will conclude the app isn't the answer at all.
Deliverable: two candidate target-behavior statements (who, what they'd do differently, measure, baseline → target), each with its linked business result and one leading indicator you could start watching next week.
Learn — trees and journeys
Decompose problems MECE before solving them, choose the right structure for the question, and use structure to find what you don't know.
Drill25 min Profit-tree sprint
A company's operating profit fell from 9% to 4% of sales in two years on flat revenue. You get a small fact pack. Build the tree — price, volume, mix, cost — and quantify how many points of margin each branch explains. House rule: if your bars don't sum to roughly the five-point fall, the diagnosis isn't done. Then the twist: which single branch would you investigate first, and what specifically would you ask for?
Drill30 min Boosters & blockers
In teams, journey-map a service everyone in the room has used — course registration, the campus clinic, getting coffee between classes. Sticky notes, left to right, two lanes: what the customer does, what staff/systems do. Then the behavior pass: mark green every behavior that predicts a good end (boosters), red every behavior that predicts failure (blockers). Each team leaves with the two behaviors they'd most want to encourage or eliminate — which are, you'll notice, target-behavior statements.
Sim60 min The Reluctant Expert
A diagnosis case where the operations manager holds nearly every fact you need — and volunteers none of them. Vague questions get vague answers; specific questions born from a structure get gold. Teams that build the tree first and interview from it finish in half the time of teams that “just start asking around.” That's the lesson.
Deliverable: your driver map with branches quantified where the facts allow, plus your fact-vs-assumption ledger: what you now know, what you're still assuming, and what you'd go get next.
Vet — cheap experiments, honest evidence
Write falsifiable hypotheses, design the cheapest test of the shakiest assumption, and start letting data argue with you. Vet before you bet.
Drill20 min We believe / we'll know
Take the target behaviors your team produced in Unit 2 and write each as a full hypothesis: We believe [change] will create [behavior change]. We'll know we're right when [evidence]. Then swap with another team and attack: is the evidence actually observable? Within what timeframe? Would it convince a skeptic, or only the authors?
Drill25 min The experiment ladder
One hypothesis, five proposed tests — ranging from “query data we already have” to “run a six-month pilot.” Rank them by cost and by strength of evidence, then design the cheapest test that could genuinely kill the hypothesis. Anchor case: before drilling a village well, you can rent a pump and some hoses for a week. What's the pump-and-hoses version of your test?
Drill20 min Case math sprints
Interview-style quantitative reps: market sizing, breakeven, percentage change under time pressure — clean setup, smart rounding, sanity check, answer stated with its “so what.” These reps run in every remaining unit; speed and composure compound.
SimCode75–90 min The T-Shirt Test
An online t-shirt retailer believes social sharing drives repeat visits — that's the marketing lead's pet theory, and there's budget riding on it. You get a small customer dataset and an AI coding agent. Interview the marketing lead to pin the hypothesis down precisely, then let the data speak: is the claimed relationship there? How strong? What would you still need to rule out before spending the budget? First coding-integrated exercise — the analysis is a few prompts, and the thinking is the deliverable.
Deliverable: the written hypothesis, your analysis (chart + one paragraph), and a verdict: supported, refuted, or “correlation found, causation untested — here's the cheap experiment that would settle it.”
Earn — the argument and the adoption
Deliver conclusion-first recommendations that survive hostile questions — and that the people involved will actually adopt.
Drill20 min The sixty-second answer
Fact pack in hand, you have sixty seconds: recommendation first, two or three reasons, the number that matters, one risk with its mitigation, next step. No wind-up, no chronology, no “so first we looked at…”. Recorded, replayed, repeated. Painful, then permanent.
Drill25 min The hostile question gauntlet
Teams exchange draft recommendations and ask each other the questions the most-affected person would ask: Why won't customers walk? Who does this work land on? What happens in month two when compliance slips? A recommendation that dies here would have died worse in the boardroom — better to find out for the price of a class period.
Sim60 min The Skeptic
Present a recommendation (provided, or carried forward from Unit 3's diagnosis) to a VP whose team it would most disrupt — and who has heard consultants before. The VP probes exactly where your adoption argument is thinnest. Round two: revise and re-present. The grade tracks the delta between rounds as much as the polish of either.
Deliverable: a one-page conclusion-first memo — recommendation, reasons, quantified value, risks, adoption plan, and the measurement plan naming the leading indicators that will show within weeks whether it's working.
Two complete engagements
Run all five questions end to end, twice — once in the classic consulting format, once as a modern build with data and code. Same framework, different center of gravity.
Sim2–3 sessions Engagement A · The Turnaround
A family-owned manufacturer's operating profit has slid badly while revenue stayed flat, and the CEO wants a diagnosis and a plan before a board meeting. Different people hold different pieces — a CFO with the segment numbers, a sales VP with strong opinions, an operations manager who knows where the chaos lives — and their stories don't fully agree. This is the archetypal consulting engagement and the most common case-interview format you'll meet in recruiting: diagnosis-first, evidence assembled under time pressure, and a conclusion-first board recommendation at the end. Outcome evidence isn't available before the decision — by design — so your recommendation must build its own measurement plan.
Deliverable: a board-style recommendation: quantified diagnosis, options considered with must-be-trues, the plan with owners, risks, and monitoring.
SimCode3–4 sessions Engagement B · Flashion (capstone)
Flashion, an online flash-sale fashion retailer, thinks its event pricing “feels like guesswork” — some events sell out in hours, others leave racks of unsold inventory. The VP of Merchandising is your entry point; a data analyst holds roughly two years of event data, and shares it with teams that ask what exists. Your job runs the whole framework: open the real problem, find the behavior (careful — the target is not “an accurate model”), structure how pricing works today, then build and test an actual pricing tool with AI coding agents, and win adoption from the merchandiser whose judgment your tool would challenge.
Two warnings, offered with love. The dataset contains at least one trap that has fooled professional data scientists — teams that interview carefully and explore the data before modeling tend to find it; teams that jump straight to fitting a model tend to become the debrief example. And the merchandiser does not have to use your tool. A model without its adoption argument is a demo, not a deliverable.
Deliverable: a working pricing tool plus the full argument: quantified expected value, honest limitations, override governance, a monitoring plan, and a proposed real-world experiment to reach outcome evidence.
The debrief that ties it together
After Unit 6, we compare the two engagements directly. The Turnaround is diagnosis-first: the problem hides inside a symptom and Question 3 (Learn) is the star. Flashion is build-first: the ask arrives pre-shaped and the danger is skipping Questions 1–2 (Surface and Observe) to start making things. The evidence mix differs too — the board case maxes out at analytical evidence plus stakeholder pressure-testing, while the build must reach behavioral and outcome evidence or it has shipped a demo. And the adoption burden runs a full gradient: a board that asked for the answer, versus a merchandiser being asked to let a model overrule her judgment. Same five questions, different centers of gravity — and being able to say where the center of gravity is for any new project you meet is the mark that the framework has become yours.