By Karan Gupta, San Francisco, CA
The idea was never the problem
Most failed products started as good ideas. That’s the part people forget when they talk about why something didn’t work. I’ve sat in enough rooms watching a launch fall flat to know the idea is rarely the reason. The reason is almost always something quieter: a wrong assumption about who wanted it, a timeline that skipped the boring validation step, or a team that fell in love with the build before anyone confirmed the need.
When I look back at projects that fizzled, the pattern is the same. Someone had a real insight. Then the team moved straight to execution because the insight felt too obviously right to test. That’s the trap. A good idea gives you confidence, and confidence is exactly what makes people skip the step where they’d find out they were wrong.
The gap between “interesting” and “wanted”
There’s a difference between something people find interesting and something people will actually change their behavior to use. I’ve watched products get genuine enthusiasm in early conversations, nods in meetings, positive reactions in demos, and still fail once they launched. Interest is cheap. It costs someone nothing to say “that’s cool.” Adoption costs time, habit change, and sometimes money. Those are different tests, and a lot of teams only run the first one.
If I’m evaluating an idea now, I ask a blunter question: what is someone giving up to use this? If the answer is “nothing,” that’s a good sign. If the answer is “their current workflow” or “money they’re already spending elsewhere,” I want to see evidence that the trade is worth it to them, not just to us.
Watching the wrong signal
One mistake I see constantly, and one I’ve made myself, is tracking the metrics that make a project feel alive instead of the ones that tell you if it’s working. Sign-ups, downloads, and press mentions all feel like progress. They’re easy to report and easy to celebrate. But none of them tell you whether the product solved a real problem for a real person who then came back.
The metric that actually matters is usually less flattering early on: repeat use, or someone paying for it a second time. Teams avoid that number because it’s often small or discouraging in the first months. But a small honest number beats a large hollow one. I’d rather see ten people use something twice than ten thousand people open it once.
Building in public failure points
Every product plan should have a few built-in moments where the team agrees, in advance, what would count as evidence to stop or change direction. Without that, momentum takes over. Nobody wants to be the person who says “maybe this isn’t working” three months into a project everyone’s invested in. So the project keeps going on inertia, not conviction.
I’ve found it helps to set those checkpoints before the emotional attachment sets in. Write down, at the start, what a bad three-month result actually looks like. Then when it happens, you’re not debating whether it’s bad. You already agreed it was.
What I actually do differently now
I spend more time on the smallest possible version of a test than I used to. Not a beta, not a soft launch, something closer to a conversation or a rough prototype that can be wrong cheaply. The instinct to build something impressive before showing anyone is understandable, but it’s usually backwards. The earlier something can fail, the less it costs to learn from.
I also try to separate my attachment to an idea from my attachment to being right about it. Those feel like the same thing when you’re inside a project, and they’re not. Letting go of a direction that isn’t working is easier when your ego was never really the thing at stake.
The real lesson
Failed products aren’t usually failures of imagination. They’re failures of listening, at the point when listening would have been inconvenient. The idea that doesn’t work still tells you something useful, if you’re willing to look at the actual evidence instead of the story you wanted the evidence to tell. That’s the whole skill, honestly. Not having better ideas. Being more honest about which ones are working.