I Spent Three Weeks Building Something Nobody Wanted

I was so sure about this one.

That's the part that stays with me. Not the wasted time, not the underwhelming launch metrics, not the awkward silence in the days after shipping when the usage numbers refused to move — but the certainty I'd felt going in. The complete, unexamined confidence that I understood what users needed and that what I was about to build was going to be the thing they'd been waiting for.

I had sketches. I had user flows mapped out across two whiteboards. I had a roadmap item with a name that sounded important. I'd already drafted the launch announcement in my head before I'd written a single line of code — imagined the replies, the engagement, the quiet satisfaction of shipping something people would actually love.

Three weeks later, I shipped it. Almost nobody used it.

How I Got There

The honest version of the story starts a few weeks before the build, in a handful of user conversations where a similar theme came up a couple of times. Users mentioned something in passing — a friction point, a minor inconvenience, something that wasn't quite working the way they'd hoped. It came up loosely, the way things do when people are talking about one thing and tangentially mention another.

A more careful version of me would have paused there. Would have asked follow-up questions. Would have tried to understand how often this was actually happening, how much it mattered relative to other things, what people were already doing to work around it.

Instead, I heard the signal and immediately started solving for it. I had enough information to feel like I understood the problem, and the gap between feeling like I understand and actually understanding is one I've now learned to treat with a lot more suspicion. At the time, I crossed it without noticing.

The sketches came first. Then the user flows. Then three weeks of building something that answered a question I hadn't actually asked carefully enough.

The Excitement Trap

There's something seductive about the early stage of a new feature — the part before the work gets hard, when it still exists purely as an idea and carries none of the weight of implementation. Ideas are genuinely fun. They feel like momentum. Sitting with a half-formed concept, sketching out how it might work, imagining the version of it that's elegant and clean and solves the problem perfectly — that's one of the better parts of building things.

Validation is slower and less comfortable. Talking to customers about a problem that isn't fully formed yet, asking questions when you don't know what you're looking for, sitting with ambiguity long enough to actually understand something — that process resists the feeling of progress. You're not shipping anything. You're not moving a ticket across a board. It can feel, especially when you're already busy and already behind, like the least productive use of your time.

So we skip it. Or we do a version of it that's really just confirmation — we ask questions shaped to produce the answers we've already decided on, and we call it research.

That's what I did. I found the signal I was looking for and stopped looking.

What I'd Actually Missed

The feature I built solved a real problem. That much was true. The users who'd mentioned it weren't making it up, and the friction they described was genuinely there.

What I hadn't understood — what I'd never actually asked about — was the severity of it. Whether it was something people encountered once a week or once a month. Whether it was blocking them from something important or just mildly annoying them when it came up. Whether they'd ever looked for a solution or had simply adapted around it without much thought.

When I went back and asked those questions after the fact, the answers were clarifying and deflating in equal measure. The problem existed, but it wasn't painful. It wasn't the kind of thing that made people stop what they were doing and search for a fix. It was background noise — present, occasionally noticed, not worth changing their behavior over.

People don't adopt features because they're clever or well-designed or technically impressive. They adopt features because they solve something they were already motivated to solve. A feature that addresses a problem someone has accepted and moved on from isn't really competing with anything — it's just asking people to change for no urgent reason. And people, reasonably, don't do that.

The Questions I Ask Now

I build differently since that feature. Not slower, exactly — more deliberately. Before committing to anything significant, I make myself answer three questions, and I don't let myself start building until I can answer them with actual evidence rather than intuition.

The first is how many people have this problem. Not how many people have mentioned it, not how many I've heard reference something adjacent to it — but how many are genuinely affected by it in a way that matters to their experience of the product.

The second is how often they experience it. A problem that surfaces once a quarter is a different problem than one that comes up three times a week, and the solutions to them have very different levels of urgency.

The third is what they're doing about it today. This one turned out to be the most useful. If users have already developed a workaround — a habit, a manual process, a way of getting around the friction without needing a feature — that tells you something important about how motivated they are for a solution to exist. Sometimes a workaround means there's real demand waiting for something better. Often it means the problem has been sufficiently tamed and the urgency is gone.

If I can't answer all three with confidence, I don't build. I go find the answers first.

What the Failure Was Actually Worth

The feature wasn't a complete waste. That's not just a reframe to make myself feel better about three weeks — it's genuinely true, in the specific sense that the failure taught me something that success, had it come, probably wouldn't have.

Winning on a bad process just teaches you to repeat the process. I might have shipped that feature, seen moderate adoption, and concluded that my instincts were good and my research habits were fine. I would have kept moving fast and kept skipping the uncomfortable work of properly understanding problems before solving them. The mistake would have stayed hidden.

Instead I got a clear, direct demonstration of exactly where the process had broken down and what it had cost. That's a more useful education than shipping something that works for reasons you don't fully understand.

Building faster isn't the goal. It never was. The goal is building the right thing — and the right thing almost always requires slowing down long enough to make sure you're actually solving a problem worth solving, for enough people, who are motivated enough to care.

That lesson cost me three weeks. I've used it every month since.