Minimum Viable Thinking

The KPI That Lies Politely

Wed, 12 Aug 2026 16:02:37 GMT

The screen marks your order ready long before it is.

You are at a fast food joint. You order at the counter. A screen lights up with your number, and a few minutes later it shows as ready. Then it vanishes from the screen, implying that the order has been delivered.

Except you’re still standing there waiting. The food arrives ten, sometimes fifteen minutes after the screen said you got it.

I’ve seen this happen many times across fast-food outlets. Same brand names you’d recognise, same gap between what the screen says and the reality.

The number rolls up to someone who never stood at the counter.

That screen isn’t decoration. It originated to improve the user experience and now it’s a KPI. It measures how fast the outlet serves you, and that number rolls up to someone who runs many outlets and maybe has never stood at this one.

So the staff do the smart thing when they’re running behind. They mark the order ready and delivered before it is. The dashboard records a quick, on-time delivery. The head office sees a fast kitchen. But unfortunately, the customer sees a wait with no signal.

Somewhere far from that counter, decisions get made on the basis of that number. Staffing levels. Bonus payouts. Which outlet is a top performer and which needs a talking-to. All of it based on a handover that didn’t happen when the system said it did.

A KPI you enter about yourself is not a measurement.

There is a name for numbers that look good and mean little: vanity metrics, like follower counts and page views that present a rosy picture without telling you anything concrete. The usual advice is to swap them for actionable ones, measure outcomes not outputs, pick a better KPI.

And that advice isn’t wrong. It just isn’t the problem here.

What’s happening at the counter is a KPI being gamed. A gamed KPI is a real, useful metric distorted by the person who enters it. The order-ready time is a good metric. The problem is who enters it: the person reporting the number is the same person being graded by it, and no amount of metric-picking can fix that.

We built a tracker that measured nothing.

It’s easy to sneer at an overworked teenager at a fast food counter and miss yourself. So here’s our own version.

We once built a tracker for our field team. The idea was simple, maybe too simple. An executive would reach the visit location, open the app, start the visit, fill the details in real time, then stop it when they left. Start, stop, and we’d know how long each visit took and what happened in the visit.

That was the SOP: the standard operating procedure, how it was meant to be done.

And here’s what actually happened. People did their three or four visits for the day, then sat down in the evening and marked all of them in one go. Start, stop, start, stop, sitting at home, a cup of chai in hand, hours after the fact.

The data came in clean. Every visit had a list of tasks done and a duration, but none of it was true.

We have a shorthand for this gap now: SOP versus GOP. SOP is how the work is supposed to be done. GOP, or ground operating procedure, is how it’s done on the ground. The KPI is always written against the SOP. It gets gamed against the GOP. The distance between the two is where the gaming happens.

The phrase came out half-jokingly, in a review meeting where we were discussing how people behaved while freezing the requirements for a new feature. What we saw on the ground didn’t match what the process assumed. It didn’t match what we, sitting in the room, assumed either.

The staff aren’t cheating — the system asked the wrong question.

You could call this dishonesty. You could also argue it isn’t.

The counter staff aren’t villains. The field team wasn’t lazy. Both were handed a system that asked “are you fast?” — or “are you efficient?” — and then made the person being judged the one who answers. Given that, marking the order done early, or batching the visits at night, isn’t cheating. It’s the sane response to a badly built question.

Eliyahu Goldratt put it flatly: tell me how you measure me, and I will tell you how I will behave. Measure me in an illogical way, then don’t complain about illogical behaviour.

Donald Campbell named this mechanism decades ago — the more a number is used to make decisions, the more it corrupts the thing it was meant to measure.

And then distance finishes the job. Nobody upstream stands at the counter or rides along on the visits. They see the dashboard, and it looks fine. Everyone relaxes.

One self-reported number is never enough.

So how do you stop a KPI being gamed? Not by finding the one true metric — that’s the same trap in a nicer suit.

The failure is trusting a single, self-reported number watched from far away. The fix is plural, and deliberate.

Use more than one, and make them different in kind. Pair the number people enter with one they can’t touch. If a visit is self-started, check it against a system event: a location ping, a call log, a signature. A second number that can’t be gamed the same way is what turns it into a measurement.

Measure what the button is supposed to prove. The button press is easy to capture. What it stands for — a fed customer, a visit that happened — is the point. Before you trust a number, ask what it would look like if someone were gaming it, then go and measure that instead. Treat a spotless number as a prompt to look closer, not to celebrate.

Close the distance. No dashboard beats standing where the work happens. A manager who sees the queue catches what the service-time report never will. Where you can, separate the person who enters the number from the person it grades: a mystery audit, a second pair of eyes, anyone who isn’t scored by the same figure they’re reporting.

This isn’t only instinct. In Harvard Business Review, Michael Harris and Bill Tayler call it surrogation: when a metric stands in for the goal, people chase the number and forget the goal. Wells Fargo set a cross-selling target; staff opened around 3.5 million accounts no one asked for. Studying it, the authors conclude what we did: no single yardstick should carry the whole judgement.

None of this is expensive. It’s a willingness to distrust your own dashboard on the first reading. The same restraint that keeps a product simple keeps a metric honest.

The delivery companies already fixed this.

You’ve been the second check yourself, without noticing.

A courier marks your parcel “attempted delivery, customer unavailable.” Once, that was the end of it: the agent entered the number, and the number was believed.

Now your phone vibrates a moment later: did the agent actually attempt delivery, or reach you? You confirm it, or you say it never happened. The platform has stopped treating the agent’s word as the only record and started checking it against the one person the agent can’t overrule: you. Too many mismatches against the same person and lo and behold, you caught a bad apple.

That’s the whole idea, running at a national scale.

And here’s what we did on our own tracker: geolocation tagging, selfie capture at the location, OTP inputs and other data points on the visit. Together they made it difficult to game the system.

The self-report still exists. It just doesn’t get to be the truth on its own.

Find the number nobody checks.

A green dashboard buys you a feeling of control. It tells you the kitchen is fast, the visits are logged, the work is getting done. All is well.

Sometimes that’s true. And sometimes it isn’t, because you asked people to report on their own work from far away — and far away is exactly where you can’t catch it.

The counter was never the point. Your product is. Look at your own dashboards and workflows, find the number someone enters about their own work and nobody checks, and make sure you’re not making the same mistake.

And if you do find one being gamed, the question to ask is this: why does the employee feel the need to game it? That’s the harder question to answer, but the right one to ask.

Minimum Viable Thinking is for product people searching for clarity in a culture of clutter. If this one landed, subscribe, and forward it to anyone who owns a dashboard.

Hire for Passion, Not Fit

Sat, 11 Jul 2026 15:54:19 GMT

Most hiring processes today would have rejected one of the best writers in gaming in under ten seconds.

Wrong industry. No prior credits, no neat career arc.

Close tab. Move on.

But that same person, Jennifer Svedberg-Yen, went on to write the 800-page script for Clair Obscur: Expedition 33, one of 2025’s highest-rated games. She came from private equity: mergers and acquisitions in New York, then a pension fund in Hong Kong. Her way into the project was a Reddit post asking for people to record voice auditions for free.

On paper, she was exactly the kind of CV most companies are built to ignore.

The studio behind Expedition 33 didn’t ignore her. They built an entire team of people like her.

A Game of the Year, Built by “The Wrong People”

Sandfall Interactive is a tiny French studio. Its director, Guillaume Broche, left Ubisoft, posted on Reddit, browsed SoundCloud, and dug through art forums. He ran more than 200 interviews looking for one thing: talent and hunger, not years of experience.

The composer, Lorien Testard, was a guitar teacher who uploaded a new track to SoundCloud every week. He became the composer of a 154-song, eight-hour soundtrack that has since passed a million and a half streams. The art director was an illustrator Broche found on ArtStation. The lead writer was Jennifer.

Around 90% of the team were juniors. For most of them, this was their first game. The whole studio was roughly thirty people, only three of whom came from Ubisoft.

The result: a breakout hit, a Game of the Year contender, a million copies sold in three days.

There’s a hiring philosophy hiding in that:

Find people already doing the work out of love, then give them a stage.

I Know This Pattern, Because I’m One of Them

It’s tempting to file this under nice indie game story, doesn’t apply to me.

But I’ve lived the other side of it.

I quit a corporate job and joined a startup as its first employee. I was hired to design and write content for a 16-week program to manage Type-2 Diabetes. That was the whole brief. I had no formal background in healthcare or product management, but I had a huge interest in technology and a lot of curiosity.

That curiosity kept pulling me past my job description. Why was the app built this way? What would actually help someone twelve weeks into changing their life? I started picking up more of the product, then more, until I was designing the app and owning the entire product experience. Eventually, I was made a co-founder.

Nobody hired me for that. They hired me for my background in training and content creation. What I brought that wasn’t on the CV was the part that mattered.

I’ve since done the same for others. We once had a senior designer working with us on a consulting basis. He was genuinely good, but he couldn’t give us enough time, and our velocity was suffering for it. So we went looking, and we found someone fresh out of college, hunting for his first job.

What struck me in the room wasn’t his portfolio. It was how much he cared about good design, the way he talked about the user experience like it was a personal responsibility. We hired him. He became instrumental in building IRIS, the in-house software we run our rehab and recovery hospitals on.

None of us would have stood out in a traditional filter. Short CVs, no big brands. The shared signal was never the résumé; it was how much each of us cared about the output.

Most standard processes are designed to avoid regret, not to discover outliers.

We over-index on brand names, years spent in a narrow box, familiar tool stacks, and portfolios that look like everyone else’s. We under-index on evidence of self-driven learning, work done in the evenings and across domains, and plain curiosity about the problem.

The data backs this up. McKinsey’s research found that hiring for skills is more than twice as effective at predicting performance as hiring for work experience. The proxy we trust most is one of the weakest signals we have.

The hidden cost is simple. You get reliability, but you quietly give up possibility.

There’s a fashionable fix for this: stop hiring for “culture fit,” start hiring for “culture add.” It’s a real improvement. But it mostly widens the net on background. The signal I’ve come to trust is harder to fake and harder to filter for: evidence of obsession, of pride in one’s work.

Someone already doing the work, unprompted, before they ever knew you existed.

Real passion isn’t loud. It’s energy that keeps showing up over time.

But Fire Burns

There’s another part to the story that most “hire for passion” posts miss.

A team of mostly juniors shipping something that looks like a hundred-million-dollar production did not do it on a comfortable nine-to-five. Passion at that intensity has a cost, and pretending otherwise is how good stories quietly become cautionary ones.

The research is uncomfortable. Across eight studies of more than 2,400 people, researchers found that people consider it more legitimate to ask passionate employees to work unpaid, give up their weekends, and take on tasks well outside their role. And they don’t recommend paying them any more for it. Passion is the one trait an organisation can lean on hard while calling it a compliment.

And it burns the person carrying it. The same intensity that makes someone great is what wears them down.

So hiring for fire without any structure is a good instinct that quietly turns into a liability.

Build a Fireplace, Not a Bonfire

The answer isn’t to stop making these bets, but to contain them. A fire in a fireplace warms the house; the same fire on the living-room floor burns it down.

A few things that have helped me:

Source where passion lives, not just where CVs live. Niche communities, forums, GitHub, blogs. Look where people are already doing the work you need, the way we found our designer, the way Broche found his team.

Ask for proof, not adjectives. Everyone says they’re passionate; the word is useless in an interview. “Show me something you built or wrote that nobody asked you to.” “What’s a detail in your work almost no one notices, but you’re proud of?”

Make deliberate bets, without betting the house. You don’t need to copy Sandfall and put 90% juniors on critical systems; in sectors like healthcare that would be reckless. Carve out real slots for these hires, pair each one with a strong senior anchor, and design your process so they don’t get filtered out before you meet them.

Build the fireplace. Guardrails, not just a stage: clear goals, regular reviews, mentorship, and the harder ones: fair pay for the scope they grow into, and a genuine stop on the hours. When someone made me a co-founder, that was the fireplace working: passion met structure and reward, not just more work.

The Question I Keep Coming Back To

If a Jennifer (or a young designer with a rough portfolio and an obvious obsession) applied to your team tomorrow, would your process recognise them, or reject them in ten seconds?

I’m not arguing you should hire for passion instead of fit. I’m arguing that passion, plus the values that actually matter to your team, is the fit worth hiring for, far more than the brand on a CV.

Don’t just light the fire. Build a fireplace.

Minimum Viable Thinking is a newsletter for product people searching for clarity in a culture of clutter. If that’s you, subscribe — one essay at a time.

The Lost Art of Dry Running

Wed, 03 Dec 2025 02:30:31 GMT

I’ve noticed something lately — people don’t really dry run things anymore.

Not ideas. Not flows. Not integrations. Not even the obvious edge cases.

Somewhere along the way, thinking became optional.

And the cost of this silent decay shows up everywhere: avoidable delays, circular discussions, “surprise” blockers that shouldn’t have been surprises at all.

The small miss that nearly became a big mess

We were recently working on a third-party integration with our system. Midway through, one of my colleagues reached out and said they were stuck. A key functionality we had planned couldn’t be implemented. If true, the options were ugly: ship compromised functionality, or lose a few more weeks to rework on a project already running late.

When they walked me through it, I did what I often do — went old school. Picked up a pen and paper and started doing a dry run of the entire process with them.

Step by step. As the user. As the system. Down to the API calls.

Halfway through, we hit it.

We’d baked in an invisible assumption: we were treating the system as if it already knew whether to insert a new record or overwrite an existing one. Nothing in the flow actually told it what to do. On paper, during the dry run, that gap was obvious.

That’s all it took to find the small oversight that was about to derail days of work across two teams. In Jira and Figma, it was completely hidden. No tool caught it. No documentation flagged it. No meeting surfaced it. Yet, a simple dry run would have.

And that’s what stayed with me, not the mistake itself, but that no one had walked the flow end to end before committing serious effort to it.

We weren’t blocked by a technical limitation. We weren’t blocked by complexity. We were blocked by a thinking limitation.

Learning to think before we built

Back when I learnt to program, before we even got near a computer, we learnt how to think things through, or as I’m framing it, dry run them. We wrote algorithms in plain English, drew flowcharts, and walked through pseudo-code line by line, tracking variable changes on paper.

We weren’t debugging yet. We were understanding.

Before a single line was typed, the logic had already been tested — slowly, deliberately — in our heads and on the page. We were making sure it was error-free. There was a rhythm to it, a kind of clarity in seeing logic unfold before us.

We didn’t just know what the program did. We knew how. We understood it.

During these dry runs, most of what we caught fell into three buckets: missing steps, wrong assumptions, and conflicting states that only became obvious when we walked the flow end to end.

Those early exercises taught me something that has stayed with me: never trust what you haven’t walked through yourself.

Over the years, it’s helped me in ways far beyond code, in designing products, improving processes, and debugging complex integrations. A 10-minute dry run often reveals what a polished design or well-written PRD can’t — a missing step, a confusing moment, or an assumption that doesn’t hold up in the real world.

This simple process has saved me more time, rework, and embarrassment than any tool ever has.

At that time, dry running wasn’t a step; it was an apprenticeship in learning to think like the system.

Why is it disappearing?

It didn’t die naturally. We choked it out.

It faded for a simple reason: thinking deeply stopped being recognised.

We replaced thinking with doing. We rewarded activity over clarity, quantity over quality. Tools made outputs look finished, even when the thinking behind them was thin, and the details were still missing. Speed replaced comprehension. Fancy FigJam templates replaced rough sketches and sticky notes. Now the artefacts look polished, but the logic underneath stays fuzzy.

Most teams are measured on movement, not understanding. Stand-ups obsess over what shipped, not what was prevented. Dashboards celebrate velocity, tickets closed, and features delivered. No one gets celebrated in an all-hands for the bug that never reached production or the integration issue that never made it to UAT.

Most issues and bugs I’ve encountered aren’t engineering failures. They’re thinking failures. The kind we would have caught if someone had done a simple dry run.

Many teams believe they’re building fast when they’re actually just building blindly.

My take — we didn’t lose the skill. We abandoned it.

How do we bring dry running back?

Dry running isn’t so much a technique as a shift in how you examine work before committing to it.

The goal isn’t to slow the work, it’s to surface the truth early.

1. Visualize.

Outline the flow, mark the key steps, track the variables, trace the moments where something changes. It’s faster and clearer than any diagram when your goal is understanding rather than presentation. Use a pen and paper if you need to.

2. Run it twice.

Once as the user, once as the system. The shift in perspective exposes assumptions you didn’t realize you were making. Most issues hide exactly in that space.

3. Make it a small team ritual.

Give it a name — a “table-top dry run” or “paper walkthrough” — and run it before you start a build or integration. Thirty minutes around a table with a designer, engineer, and QA walking the flow end to end, out loud, almost always surfaces at least one “Wait, what happens if…?” moment. Capture those, adjust the flow, then build.

Dry running won’t make the work slower. It simply makes the thinking clearer before the real cost of mistakes begins.

A discipline worth keeping

This isn’t nostalgia for nostalgia’s sake. Dry running is practical, cheap, and fast. And very effective.

It isn’t outdated. It’s just underpracticed.

At its core, dry running is a product mindset, the discipline to pause before you act, to imagine before you build. Tools can model the steps, but only you can test the assumptions.

The bugs you never ship, and the blockers that never appear, are its real output.

Dry running forces truth early, and early truth is one of the highest-leverage habits in product.

Restraint is a Product Muscle

Tue, 11 Nov 2025 11:11:03 GMT

Start with the real questions.

Most families ask one thing — “How’s the recovery going?” That single question reshaped how we built our app at HCAH.

We started with the questions. The ones families always ask.

“How’s the recovery going?”

”What’s my next session?”

”What are my dues as on date?”

We realized early that families didn’t want more features. They wanted clarity. And yet, for the longest time, we couldn’t give it to them.

There was no single source of truth in our systems!

We had already defined clinical recovery milestones — a breakthrough in itself — but they were tracked offline.

Billing visibility came only at discharge or was available on demand.

Service requests? Usually routed through WhatsApp or calls with uneven closures.

It created stress — not just for the family, but also for our clinical teams.

That was our starting point.

Not “Let’s build an app.”

But: “Let’s solve the emotional need behind these questions.”

Find a Need That Helps Both the User and the Business

As product folks, we often find ourselves pulled in opposite directions:

Users want simplicity — something that just works.
Businesses want monetization or improved efficiency.

But the best products — the ones that endure — sit at the intersection of the two. However, sacrificing the former for the latter is a trap that we see many fall into.

In our case, clarity around recovery progress did exactly that:

Families felt more confident and in control.
Clinical teams had fewer update requests to handle.
Operations got visibility into what was working and what wasn’t.

And the business? Faster recovery tracking helped us live our core promise — Fastest Recovery.

This wasn’t about a “feature.” It was about anchoring our entire product strategy around a shared pain point that mattered to every stakeholder in the ecosystem.

We Learned From Our Failures In The Past

In one of our apps that we made for our Homecare business, we made a classic mistake.

In addition to the information that was relevant to the users, we added what we wanted as a business — showcase our breadth of services, chatbots (because why not), customisation, lead generation, in-app sales — in short, everything but the kitchen sink.

At the core, it seemed logical — we had a captive user, and the business wanted to push value-added services. But the impact was clear:

Organic downloads were few and far in between because the core value was unclear.
For those who downloaded, app engagement was low.
Even internal teams hesitated to push the app. They also felt it lacked value.

We learned the hard way: just because a feature is possible, doesn’t mean it belongs.

Today, the HCAH Recovery App includes only what users need — nothing more.

Whatever features we add, it’ll be because they add clear value to the user — not just because we want them there.

Restraint Is a Product Muscle

We all know this line:

“Less is more.”

In practice? We forget it the moment we start building. Every stakeholder has a feature request. Every roadmap has a monetization idea. Every app screen feels like an opportunity.

But in healthcare, the moment matters more than the module. Families are navigating stress, uncertainty, and fragile hope. The last thing they need is a cluttered app or a decision tree.

So we made three tough decisions:

No selling. Not unless it’s user-first.
No overload. Every screen has a clear job.
No distractions. Recovery, billing, payments, tickets — that’s it.

And the payoff?

What the Data Told Us (and Didn’t)

When we launched the current version, we sent two simple WhatsApp nudges — one when billing started, and one when the first milestone was achieved.

That was it. Just enough to show families how the app could help them navigate recovery.

And, we waited for signs of impact. Using Mixpanel, we tracked:

How often do families check milestones
How many use real-time billing and payment

We saw:

Downloads happened, no other push needed
Approximately 1/3rd of our residents checked their bills every day and raised billing concerns immediately.
Doctor queries about recovery progress dropped — families could now see milestones being achieved in real time.

And importantly, we saw positive anecdotal feedback from both families and clinicians.

We’re not saying it’s perfect. Our vision for what this app will be to recovery is grand. There’s a long road ahead.

But we’re proud of what it’s become: Not a tool to push, but a platform families want to use — because it brings peace of mind.

5 Takeaways for Product Builders

If you’re building for real-world problems — in sensitive domains like healthcare — here’s what we learned along the way.

- Solve for the emotional need, not the functional one.
”How’s the recovery going?” → Progress, billing, and support clarity.

- Don’t build to sell. Build to serve.
Let usage and trust be your first north star — monetization will follow.

- Default to subtraction, not addition.
If a feature doesn’t actively make the experience better, leave it out.

- Use data first, but don’t ignore the narrative.
Mixpanel gave us numbers, but true feedback came from real users in real situations.

- Keep asking at every step: who is this for?
Your roadmap should reflect the needs of the user at the moment they use your product — not what fits your OKRs.

Closing Note

At HCAH, we say our tech exists to enable Fastest Recovery.

But recovery isn’t only about protocols and outcomes.

It’s about confidence.

And sometimes, the best thing a product can do is step back — and give people clarity, when they need it the most.