A few months ago, I almost built my own notetaking app. I had Claude Code open and three markdown files drafted: architecture.md, claude.md, design.md. I’d named the thing. I’d spec’d block-based outlining, natural-language dates, bidirectional links. Then I ran out of tokens, and the spell broke.
What I’d been about to build was a version of tools I already use. Logseq does most of it. iA Writer is beautiful. My app would have been an 80% clone of things that already exist, plus 20% of features I wanted on a Tuesday afternoon and would have forgotten by Friday.
I’m not alone. Everyone seems to be building their own markdown editor, or their own to-do list, or their own calendar app. The tools make it possible. As a hobby — software for one — that’s fine, and I’ve argued for it. But the instinct doesn’t port to building a business.
The fallacy has a name
Joshua Porter called it the Next Feature Fallacy: the belief that the next feature will finally make people want the whole product. I came across it via James Gilyead, who cites him.
“Some estimates suggest that around 80% of product features are rarely if ever used and have negligible impact on growth.”
It took me years of shipping to learn this. Every feature I’ve been part of, at the moment of release, I thought it might unlock the next 10x. Mostly it didn’t. I watched the curve flatten. I told myself the next thing would be different. It usually wasn’t, not on its own.
This predates LLMs. What LLMs did was make the fallacy cheaper, and a cheap mistake is a mistake you make faster.
Why it compounds now
Shreyas Doshi names the same thing at the decision level: product work is “100s of micro-decisions that quietly attach you to what you build, and constrain future choices.” Both halves matter.
The constraints are how the feature costs you later. The attachment is what you get in return, because every rejected option, every small revision is how you actually learn the shape of the problem.
Here’s the trap. In the AI era, you can skip most of that. Let the model make the micro-decisions, and you still ship the code, but you haven’t earned the judgment that should have come with it. You end up with the carrying cost and not much of the learning. It fails quietly: nobody on the team has the reps to catch the mistake before it ships, or the taste to know which version is actually better.
The question changed
That morning, before I recorded the voice memo that became this post, I synced one highlight in Readwise:
“AI is an incredible force multiplier for implementation, but it’s a dangerous substitute for design. It has no sense of history, taste, or how a human will actually feel using your API. If you rely on it for the soul of your software, you’ll just end up hitting a wall faster than you ever have before.” — Lalit Maganti
The question product people need to answer is no longer does it work? That used to be the hard part. The hard part now is should it exist?
The counter-discipline
This isn’t a case for not shipping. The opposite of the Next Feature Fallacy isn’t paralysis. It’s a question, applied before the building starts.
I’ve stopped asking “what’s our value proposition?” It’s too easy to bullshit yourself with that one. Three questions I ask instead, borrowed from Bob Moesta and sharpened by a few years of getting it wrong:
- What’s the struggling moment? When does the customer hit the wall that makes them look for a new solution at all? Ladder “so what?” until you hit the emotional root — “I can’t do X” → “I miss the deadline” → “I don’t get promoted.” If it bottoms out mild, it’s not a must-have.
- Would they not not buy it? Not “would they use it.” Authentic demand means that in the situation, with the alternatives they already have, they cannot not reach for your solution. Nice-to-have and should-have are the graveyard.
- Does solving it make our product more itself, or less? A real struggling moment you solve against your vision makes the product sharper. A real one you solve around your vision turns you into a services shop. Both halves have to be true — the pull has to be real, and the shape has to hold.
I know this sounds counter to the “ship and learn” zeitgeist. It isn’t. You still ship. You just make each feature earn its place.
Saarinen again: “Products rarely fail because they lack features. They fail because they lack the right features, or because the features they have are poorly conceived. Every feature should earn its place.”