The Missing Question

The meeting where a company loses a year is usually a good meeting.

I have had this meeting described to me more times than I can count, always afterwards, always by someone trying to work out where the year went. The details move around. The shape barely does.

Everyone is smart. The data is real. Someone has done the work, built the deck, run the numbers. There is a decision on the table and it is a reasonable one. A bigger version of the product. A rebuild that finally pays down the mess. A push into the enterprise segment that keeps showing up in the pipeline.

The version I keep coming back to was a team deciding to build the enterprise edition of their product. Five customers had asked for it. Two of those were key accounts, and everyone in the room knew what those two were worth. The engineering lead had scoped it. The founder was convinced. The room worked through the objections one at a time, and every objection had an answer. The decision was made in under an hour. People left lighter than they came in, the way you do when a hard thing finally has a direction.

Nobody in that room was wrong.

The bill did not arrive for months. When it came, the shape of it was plain. The enterprise build had eaten the roadmap. Both key accounts went quiet, months apart, without ever saying why.

It did not cost that company a year. It nearly cost them the company. Not through a bad decision. Through a good decision, made well, answering every question that got asked.

Go back through it, question by question, and they were all about execution. Could we build it. How long. What would it cost. What might break. All good questions. All answered.

The question nobody asked was whether the thing should exist at all. Whether the business that wanted it was still the business they were.

Here is the uncomfortable part. An unasked question is close to invisible, and that is what makes it dangerous. Sometimes one person in the room feels the shape of it and cannot get it into words, which is its own signal and worth trusting. Most of the time there is nothing to feel. The room seems complete. Everyone probed, everyone pushed, everyone got answers, and the answers held up.

Competence is not much protection here, and it can widen the gap. A confident room stops probing sooner, because the people in it are used to being right, and they usually are. The stronger the team and the cleaner the meeting, the less likely anyone is to notice that a whole category of question never came up. Skill closes the meeting faster. It does not widen the set of questions.

I have stopped being surprised by which companies this happens to. It is usually the good ones.

Over enough of these, the missing question starts to have a shape. It is rarely "did we build this right." Teams are practised at that one. They ask it by reflex, they have reviews for it, they have roles with the word in the title.

The question that gets dropped is the one before it. Should this exist. And the quieter, harder version: is this still what we think it is. The feature we are protecting. The customer we believe we are building for. Are those still true, or did we just stop checking.

Those are questions about value, not execution. And in most startups, value has no owner. Big companies build a function for this. Strategy teams, portfolio reviews, someone whose job is to ask whether a thing still earns its place, and where that person exists and has standing, this whole failure gets smaller. A startup has nobody doing that, and nobody notices the absence, because the role was never there to go missing. Execution has owners almost everywhere: a lead, a name against the ticket. Value gets assumed at the start and rarely revisited, because revisiting it feels like reopening something already decided.

So here is something you can use on Monday. Not a method, just a handful of questions to force into the room before an expensive call. Ask them out loud, before the decision, not in the postmortem.

None of these are clever. That is the point. They are the questions a confident room skips because the answers feel obvious. Say them anyway. The one that produces an awkward pause is the one that earned the meeting.

Notice what they share. Not one of them asks whether you can build the thing. They all ask whether you should, and whether the answer you settled on a year ago is still the answer.

That is the pattern underneath it. Execution questions have owners, so they keep getting asked. The ones about value mostly do not, so they quietly fall off the table. And an organisation that stops asking a certain kind of question rarely hears the silence. It just gets a little heavier every quarter, until everyone mistakes the weight for maturity. That heaviness has a name. Bloat is the pile of assumptions no one remembers choosing, and it starts the moment a question stops being asked.

That is the idea behind Core and Bloat™: not better answers, but a recurring way to surface the questions no one owns.

Companies rarely fail because they answered a question badly. They fail because they stopped asking one, and got so good at answering the rest that nobody noticed in time.

There is one more thing I have learned about that missing question, and it is why it stays hidden even from teams who know to look for it. It rarely arrives dressed as a question about value. It shows up in a costume, usually a technical one, and everyone treats it as an engineering problem right up until the year is gone.

That costume is where I will start next time.

Cases in this series are composites. The patterns are real, the companies are not.

The full method, four boxes and all, sits at dirkbauer.com/core-and-bloat.html.