Describe the flywheel for a product where more usage genuinely improves quality.

Interviewer's question: "Describe the flywheel for a product where more usage genuinely improves quality." Cobblestead Property Group runs Fixwell to triage tenant maintenance requests. Tomasz Okonkwo has dispatched repairs there for five years.

How to answer this, stage by stage

Nobody is grading whether you can define "flywheel." They're grading whether you can name the exact signal that keeps it spinning, and the exact way it stalls.

Let's learn

The tool is a shared tablet bolted to the dispatch desk at Cobblestead Property Group, the same one three different dispatchers pass around across a week.

Cobblestead manages forty rental buildings. Fixwell is the feature behind that tablet: a tenant texts what's wrong and a photo, and Fixwell reads it and suggests which kind of vendor to call, plumber, electrician, appliance repair, or pest control.

Before Fixwell, Tomasz read every message by hand, checked the photo, and picked the vendor himself, about four minutes a ticket. On a typical Monday, thirty eight messages had piled up over the weekend, and he wasn't done until well past lunch.

Now Fixwell suggests a vendor instantly, with a note on how sure it is, and Tomasz accepts it or overrides it.

Here's the turn: the falling override number is not, by itself, the win. What matters is whether the corrections still happening are real ones, made by someone who actually looked, not someone who's learned to tap "accept" out of habit.

Same ticket, same dispatcher. What changed is how many of them ever need real judgment at all.

Four small parts. The fourth one is the only reason this is a flywheel and not just a shortcut.

At its worst: the override rate keeps falling, everyone reads it as success, and nobody notices that dispatchers have quietly stopped actually checking the photo before tapping accept. The model keeps "improving" on corrections that were never true corrections, and quality drifts the wrong way in silence.

What I would leave alone: the refund and invoice math, the actual dollar amount owed for a repair, doesn't need touching. This design is only about who confirms the category, not how the bill gets calculated.

The lesson: a flywheel isn't proven by usage going up. It's proven by the correction signal staying honest while usage goes up, and those are two different things that happen to move together for a while.

Now here is the same thing as a story

The short version above is what you'd say defending this design to Cobblestead's operations lead. Read this one for how the quiet failure almost happened.

Tomasz Okonkwo has dispatched repairs at Cobblestead for five years. Ask him which building has a temperamental boiler and he'll tell you before you finish the question.

For its first two months, Fixwell mostly agreed with him, and when it didn't, Tomasz caught it fast: a glance at the photo, a tap to override, done in ten seconds.

Then someone on the product team noticed dispatchers were moving faster than expected and added a quiet convenience: if nobody tapped anything within ten seconds, Fixwell's suggestion auto-accepted, so the queue kept moving during a rush.

Nothing about that felt wrong at the time. Tomasz was already fast. The timeout just caught the cases where he'd glance and agree anyway.

The near miss came on a Thursday. A tenant's message said the kitchen smelled like gas, with a blurry photo of the stove. Fixwell read "stove" and suggested appliance repair. Tomasz was mid-call with another tenant when the ten-second timeout hit, and the suggestion auto-accepted before he'd even read it.

Same ticket, two different desks. Only one of them ever produces a real correction.

The tenant called back forty seconds later, scared, and Tomasz caught it on the second ring, before the appliance repair vendor was even dispatched. He rerouted it to the gas utility's emergency line himself.

Here's the decision I'd take back: the ten-second auto-accept default. It made sense when it shipped, dispatchers really were fast, and the queue really did move better. Nobody meant to hide anything. But it meant the loop was quietly counting silence as agreement, and silence is not a correction.

Replayed with the default removed: the same blurry gas-smell photo comes in during the same busy Thursday. Fixwell still suggests appliance repair. But nothing auto-accepts, so it sits flagged until Tomasz explicitly taps something, and when he does look, thirty seconds later, he overrides it himself, correctly, and that override, a real one, becomes the labeled example that teaches the model to weigh "smell" words above "stove" next time.

The old design let the clock make the call. The new one makes sure a person's actual attention is the only thing that ever counts as a correction.

I approved that auto-accept timeout because it felt like a small kindness to a busy dispatcher, ten seconds nobody would miss. It took a scared phone call and a fast second guess to see that those ten seconds were exactly where the flywheel's real fuel was quietly leaking out.

SPARK, in one screenNot a UI exercise. SPARK is what tells you why a flywheel needs a genuine correction, not just a fast one.

Each of these is a real feature Cobblestead could build eventually. None of them is this design's job today.

Only the bottom-right corner is where trusting the suggestion is actually safe. The top-left is exactly where a person has to look.

The loop wasn't the whole idea from day one. It's the piece that turned a suggestion tool into an actual flywheel.

The recap, one line per letter: situation is a dispatcher reading every ticket by hand, payoff is trusting the routine case while pausing on a real flag, anchor is the correction-to-retrain loop, risk is a convenience default quietly faking a correction, and keep out is holding back on full automation until the loop is proven solid.

And if you want to be sure it really works, try it somewhere elseSame five letters, a smallholder farming app instead of a maintenance desk. A completely different domain, the same correction-fuels-the-loop shape.

SproutLens is a photo-based crop disease app used by smallholder farmers. Priya Adjei is an agricultural extension worker who visits farms and checks the app's diagnoses against what she actually finds on the leaf.

Mapped onto SPARK: situation is a farmer today, waiting days for an extension worker's visit to find out if a spotted leaf means blight or just sun damage; payoff is farmers trusting SproutLens's common, clear-photo diagnoses while still flagging the blurry or unusual ones for Priya's next visit. The anchor is structurally the same loop, aimed at a different correction: every time Priya's on-farm diagnosis confirms or overturns the app's guess, that becomes one labeled example, folded into the next regional retrain, so the model sharpens fastest on exactly the diseases it currently misreads. Risk is the same shape too: if farmers start trusting every diagnosis without sending Priya the unusual cases, the flywheel starves, not from a bad default this time, but from nobody bothering to flag anything anymore. Keep out is no automatic pesticide-purchase recommendations yet, no farm-to-farm disease alerts without a human check, no fully unattended diagnosis in the field.

Swap the trigger and it still runs.
Speed: an interviewer caps you at sixty seconds. Say "the loop runs on corrections, not clicks, protect the correction and the flywheel takes care of itself," and stop.
Cost: if a weekly retrain is too expensive to run at first, batch it monthly, and say so honestly, a real loop that turns slowly still beats a fast loop that isn't real.
The model gets better, for real: if Fixwell's routing gets so accurate that overrides become rare, that's not a reason to stop watching, it's exactly when a fake "no override needed" default becomes the easiest mistake to make.

Where people run it wrong.
They count total usage as proof the flywheel is working, without checking whether the corrections behind that usage are still honest ones.
They add a convenience default, an auto-accept, a skip button, without asking what it quietly teaches the model to treat as agreement.
They let retraining slip to "whenever there's time," which turns a loop into a one-time training run with extra steps.

How to use it live. When someone asks you to describe a flywheel, ask yourself one question first: what specific human action produces the label, and what happens to the loop the day people stop doing that action carefully. Build the anchor around protecting that one action.

Flashcards (tap any card to flip it)

Check yourself Score: 0 / 0