Describe the difference between a capability bet and a feature commitment.

Two roadmap lines can look almost identical and mean completely different things: one is a promise about what the product does today, the other is a bet on what the model will be able to do later. Verdreth builds an AI code-review assistant for engineering teams. Priyanka Sood is Head of Product, and the question in front of her is why her team keeps confusing the two.

How to answer this, stage by stage

Nobody is scoring whether you can define two terms. They're scoring whether you can tell, on sight, which promise a given roadmap line actually is.

Let's learn

Here is what a code-review tool looks like when a promise about tomorrow's model quietly gets treated like a fact about today's.

Before Verdreth, Dana Okafor, a six-year backend engineer, reviewed every pull request from her two junior engineers by hand. About forty minutes a PR, six PRs a week, roughly four hours she spent walking through her reasoning line by line in the comments. With Verdreth, a bot flags likely issues in seconds and, for common ones, offers a one-click "auto-apply fix." Dana's review time dropped to about forty-five minutes a week for the same six PRs.

Same roadmap slide, two different contracts. Only one of them is safe to put a date on.

Here's the turn: the extra mistakes that occasionally slip through auto-apply are not the real problem. The real problem is what auto-apply removed on the way to being fast: the pause where Dana used to explain, in words, why a fix worked. That pause was never on anyone's roadmap. It just used to exist, because two separate clicks used to be two separate moments.

At its worst, this looks like a product that got faster and a team that quietly got weaker in a way no dashboard would show for months.

What I would leave alone: the flagging step itself. Dana still wants a fast first pass on obvious issues, and reviewing every trivial style flag by hand would be exactly the kind of caution that helps nobody.

The lesson: a capability bet you never wrote a threshold for isn't a bet. It's a hope wearing a roadmap's clothes, and it will sit on the roadmap forever looking done.

Now here is the same thing as a story

The short version above is what you'd say scoping this live in an interview. Read this one for how one question from a new hire undid eight months of assuming.

Dana Okafor has spent six years writing backend services, the last three of them mentoring whoever joins her small team. She can read a diff and tell, in about ten seconds, whether the person who wrote it understood the tradeoff they were making or got lucky.

For Verdreth's first eight months on her team, the tool was a quiet, useful pre-filter. It flagged the obvious stuff, an unclosed transaction, a missing null check, and Dana still wrote out the reasoning herself in the PR comments, same as always. Review time barely moved. Nobody complained, because nothing had really changed yet.

Same fix, two very different amounts of understanding left behind afterward.

Then Verdreth shipped auto-apply, pitched internally and externally as a capability that would keep getting more precise with every release, the same open-ended promise the flagging feature had always carried. One click now flagged and fixed a whole class of common issues at once. Review time for those PRs dropped from ten minutes each to about ninety seconds. Dana, like everyone on her team, started clicking through them fast. There was, after all, always a next PR waiting.

Nobody at Verdreth decided, on any single day, to stop teaching junior engineers. The auto-apply button applied to everyone's PRs equally. But the two things that used to happen in sequence, flag then explain, had been merged into one thing: flag-and-fix, no explanation required. The pause where reasoning used to live simply had nowhere left to go.

Three steps look the same as before. The fourth one used to be a person explaining something out loud.

It took a new hire, five weeks in, asking Dana in a stand-up why a particular fix had been applied the way it had, for anyone to notice. Dana didn't know either. She'd stopped reading them in detail months earlier, same as everyone else. That was the moment the merged button stopped being a convenience and started being a capability bet nobody had ever actually verified.

Each step made sense alone. Together, they quietly removed the one thing a junior engineer actually needed to see.

What I'd tell myself, watching that new hire's question land in the room: the auto-apply button was never wrong to exist. It was wrong to be sold, internally, as a capability that was already delivering more than it had ever been asked to prove.

PICK, the pick that survives being pushed on

The recap, one line per letter: position is naming the two contracts before naming any date, impact is the engineering debt on one side and the sales promise on the other, cost asymmetry is the mislabeled bet being the expensive one because it's invisible, and kill criteria is a stated threshold and recheck date that lets you actually call time on a bet that isn't paying off.

And if you want to be sure it really works, try it somewhere elseSame four letters, a veterinary clinic's scheduling assistant instead of a code-review tool. Different flip family entirely, the same undated bet.

Oakendell Veterinary Partners runs an AI assistant that suggests appointment slots for incoming calls. Mapped onto PICK: position is the clinic treating "suggest a routine checkup slot" as a feature commitment and "suggest a slot for an ambiguous, possibly-urgent case" as a capability bet still waiting on a threshold. Impact lands on Hollis Bramwell, the clinic manager, who absorbs a wasted ten-minute hold if a routine suggestion is off, versus a family whose sick animal waits two extra days because an urgent case got slotted like a routine one. Cost asymmetry favors the same shape as Verdreth's: a slow routine suggestion is cheap and visible, a wrongly-confident urgent suggestion is hidden until the family calls back worried. Kill criteria is a stated miss-rate on ambiguous cases; above five in a hundred, urgent-sounding calls route to a human first, no exceptions. The flip here is abandonment, not delegation: once Hollis's front-desk staff got burned twice by confident-sounding suggestions on ambiguous calls, they quietly stopped opening the suggested-slot panel at all, for every call, including the easy ones the tool actually handled fine.

The same four parts turn "it'll get smarter" into something you can actually check, in a clinic or a code-review tool alike.

The quadrant makes the same point the code-review story did: it's not about the tool's overall accuracy, it's about which quadrant a given call falls into.

Swap the trigger and it still runs.
Speed: an interviewer caps you at sixty seconds. Say "never let a bet on tomorrow's model borrow a shipped feature's confidence," and stop.
Cost: no time to build a recheck process this quarter. Say so honestly, and put a manual calendar reminder on every open capability bet rather than let it drift with no owner at all.
The model gets better, for real: if Verdreth's explanation quality genuinely clears the threshold next quarter, that's the bet paying off as designed, and the honest move is converting it into a real feature commitment, not treating "it might still improve more" as a reason to keep dodging the question.

Where people run it wrong.
They ship a capability bet with no threshold, so "almost there" can mean anything for as long as anyone likes.
They treat a slipped date as the only real cost, and miss the cheaper, quieter one sitting behind a feature that shipped on time and never improved.
They let one team's optimism about the model set the whole roadmap's confidence, instead of naming the bar out loud where everyone can see it.

How to use it live. The moment a roadmap line sounds like both a promise and a hope in the same sentence, ask which one it actually is. If nobody can name the threshold, it's a hope, and it needs to say so.

Flashcards (tap any card to flip it)

Check yourself Score: 0 / 0