People don't want to buy a quarter-inch drill bit. They want a quarter-inch hole.
Theodore Levitt (Harvard Business School)
There is a line every product person knows. “People don't want a 6mm drill bit, they want a 6mm hole”. I’ve heard it in more than one meeting. Probably because it does point at something real: the literal request is rarely the actual want.
But it’s not supposed to suggest that we just go one level deeper and stop. Because nobody wants a 6mm hole either! A hole in your wall is a horrible thing to want. What the person wants is a shelf on the wall. The hole is a means, same as the drill bit. The quote just stopped one step earlier than the literal request and gave itself a medal.
Keep going. Why a shelf? Somewhere for books. Why there? To find them, or to show off how well read you are, or because the room feels wrong without them. Each of those is a different product, and the further down you go, the more the solution space opens up. Stop at "hole" and you compete on drills. Stop at "shelf" and you're Ikea. Keep going and you might end up somewhere nobody has built yet. The good stuff is layers down in those questions.
What happened. The agents are extraordinary at making holes. And we are getting extraordinary at making sure they make exactly the hole asked for, not a 5mm one, not a 7mm one. The harnesses, the evals, the loops, the scaffolding, the whole apparatus of agentic engineering is pointed at precision and pace. “Make the hole I wanted, reliably, every time”. It is genuinely impressive work, and I’ve spent a lot of my own time on it.
And I think we are so pleased with the precision that we have not noticed the axis that needs improving now has shifted.
Because look at what the precision did. It made building cheap. It made building consistent. It nearly solved building. And when you solve a thing, the constraint moves somewhere else. The bottleneck in shipping good product used to be how long it took to build. So it was important to know which hole to build; getting it wrong cost you weeks, at best. It was important to make the time to work out what the right thing to build was (and cull the wrong things before they took up your precious engineering time). Doing the business of sitting with a user and working out what they are actually trying to change about their day. And honestly, as the PM who did most of that, finding the time to do it was never a problem.
But, we poured our cleverness into building precisely at unheard-of pace with agents. And here's the bit that bothers me: we have kept aiming the best of agentic engineering at the step that is now cheap, and left a step that matters running on a human with a notebook and three weeks of interviews.
Why we stop doing it. Here's the trap. The agent empties the backlog faster than humans can fill it. So the scarce thing is no longer build capacity; it's ideas. You are constantly running out of things to feed the insatiable hunger of the feature factory. And the discipline that used to produce your best features, figuring out “why?”, has a property that is now fatal: it reduces the number of ideas. It merges five requests into one real need. It kills things. It says no.
So the faster the backlog drains, the more the careful thinking feels like the obstacle. The thing slowing down the refill. And the worst part is that it's not wrong. When the constraint is throughput, the “why?” genuinely is the bottleneck. You are being asked to drop the one discipline you cannot afford to drop, and the maths is telling you to drop it.
Why spend three weeks walking the why stack on a feature you could ship and A/B test by Friday? Especially with that insatiable factory to feed. I get it. I feel the pull.
What it costs. Not just feature clutter, and there is feature clutter; you feel it, I feel it, and your users are the ones who have to absorb the clutter on your product. The real cost is the one you can't see. You build 10 buttons, each solving 10% of the problem, and you never build the one feature that solves the whole thing. The reimagining only ever lived four questions down in the “why?”. The fast path doesn't go there. So you don't trade quality for speed, exactly. You trade the unlock for volume, quietly, and you never know what you didn't find.
The “why?” was the thing that found the unlock. It was the only thing that ever did.
I’m not arguing for always doing deep research. Sometimes the answer really is just “add the button”. The user has done their own why-walk, their behaviour will change exactly as much as a button changes it, and there is nothing four questions down because there is nothing down there. Build the button. The digging wasn't wasted, it just confirmed what you already had. The failure is not building buttons. It’s building them by default, because asking got too slow.
Confession. I have done this. I tuned my harnesses like everyone else. I got better at building than I had ever dreamed and felt good about it. And it is only now, late, that I have started turning the same attention to the other end, to the question of which hole. I am writing this slightly behind my own argument, which is the most honest thing I can tell you about how strong the pull is.
So. I get it! There is a seductive distraction of watching the agents nail the build of 10 features for you. But I guarantee one feature that solves a want for your user is better than 10 features that give them what they asked for without asking and went no deeper than that.
So here is what I’m arguing for: If the bottleneck has moved to the why-walk, then that is where the machinery should be pointed. The same agentic evolution we used to make building cheap and consistent - the loops and the harnesses and the relentless iteration - we should be aiming at ideation. At the questioning. At the discovery of “why?” At driving down the why stack instead of churning out the holes.
The agents are very good at making 6mm holes. We have got very good at making sure they make exactly 6mm. Let's make them as good at asking what the hole is for.
ps
Thinking about this post I got curious enough to try something. I built a skill that walks you down the why stack. You tell it the feature idea, it asks what's the value, how does it fit your workflow, what does it unlock, why do you want that to change, etc before it gives you anything. It is a first attempt at pointing the machinery at the next bottleneck...
You can find the "why-hole" skill on my GitHub, let me know if you find it useful.