Are We Building Too Many Features Nobody Asked For?

This hits right where it hurts for most indie hackers. We’ve all been guilty of building a feature because it was "cool to code" rather than "needed by the market."To answer your question, my framework for what to build next shifted completely after wasting 3 weeks on an advanced analytics dashboard that exactly zero users clicked on.Here is how I filter everything now:The "Pay Before Built" Rule: If a customer requests a massive feature, I ask: "If I build this by next Tuesday, would you be willing to upgrade to the $X tier today to support it?" If they hesitate, it’s a nice-to-have, not a pain point.Support Messages > User Interviews: I’ve found that user interviews can sometimes mislead you because people want to be nice and will say "Oh yeah, that feature sounds cool!" Support messages, however, are raw data. If multiple users are complaining about a friction point or asking how to do something, that is your next feature.The 3-User Rule: Unless 3 entirely unrelated paying users explicitly ask for the same thing, it goes into the icebox. No exceptions.The biggest mistake I made: I used to look too much at competitor research. I thought, "Well, competitors have this integrations page, so I need it too." Turns out, half of the features your competitors have are also dead weight that they built out of intuition and are too scared to remove. Copying competitors means copying their mistakes.Focus on LaunchNest's core value proposition and ignore the noise. If the product is slightly buggy but people are still using it because it solves a painful problem, you're on the right track.

I try to separate evidence from enthusiasm: keep a short list of requested problems, then rank each feature by how often the problem appears, how painful it is, and whether it supports the core workflow. Before building, I test the smallest version manually with a few users. If nobody changes behavior or asks for it again, that is usually the signal to stop.