What Shipping a Feature Nobody Used Taught Me About Product Discovery

The feature made complete sense on paper. Multiple stakeholders had asked for it in different conversations over several months. I had written a thorough spec. Engineering estimated it at three sprints and we delivered it on time. The launch announcement went out, the documentation was written, and then almost nobody used it.

One month post-launch: three users had touched it. None of them were in the segment we had originally built it for.

This is not a rare experience. In my experience working across early-stage SaaS products, shipping features that get low or no adoption is common enough to have a pattern to it. The pattern is almost always the same: the signal that triggered the build was real, but the diagnosis of what that signal meant was wrong.

What Went Wrong: The Signal vs. The Diagnosis

The stakeholders who requested the feature were not lying about wanting it. They had a genuine problem. What I failed to do was go from the stated request back to the underlying problem and check whether the feature I was building actually addressed that problem.

This is the most common discovery failure in product work. The customer says "I need X." You build X. They do not use X because what they actually needed was Y, and they named X because X was the closest thing in their mental model to what would help.

The diagnostic question I should have asked in every conversation was: "What are you trying to accomplish right now that you cannot accomplish?" Not "would you use this feature?" Not "does this solve your problem?" The first question opens up the actual workflow. The second and third questions produce polite agreement.

The three people who did use the feature were using it differently than designed, for a purpose I had not anticipated. That told me something important: there was a real use case, but it was not the one I had built for.

The Expensive Part Was Not the Engineering

The six weeks of engineering time was recoverable. The real cost was the opportunity cost: six weeks of three engineers building something with low adoption instead of working on something that would have moved retention.

In a small team, opportunity cost is always the most expensive line item. Time spent on a feature nobody uses is time not spent on the thing that would have compounded. The calculus is not "how much did this cost to build?" It is "what else could this team have shipped in the same period and what would that have been worth?"

Getting this wrong once is a learning. Getting it wrong repeatedly is a prioritization process failure.

What I Changed in My Discovery Process

After that launch, I added two steps to my discovery process that I have used in every product role since.

The first is what I call a workflow walkthrough before any feature gets scoped. Before writing a single line of spec, I sit with at least three people who have the problem and watch them work through it in real time. Not describe how they work through it. Actually do it, with me watching and asking "what are you doing now?" at each step. The gap between what people describe and what they actually do is where the real feature requirements live.

The second is a failure pre-mortem on the proposed solution. Once I have a solution direction, I write a paragraph from the future: "It is six months from now and this feature has almost no adoption. Why?" I share that paragraph with the engineer who will build it and the designer who will design it and ask them to add to it. The exercise surfaces the weakest assumptions before any code is written.

Neither step eliminates the risk of building something that does not land. But they significantly reduce the probability of building something that solves the wrong version of a real problem.

The Feature That Never Should Have Been Built

The harder lesson from that experience was recognizing that the feature should probably never have been built in the current form. The problem it was trying to solve was real for a small segment. But that segment was not the core customer, and solving a real problem for the wrong customer is almost as expensive as solving the wrong problem.

The user research guide covers the five methods that would have surfaced this earlier, particularly the Five-Act Interview and behavioral analytics approaches. The prioritization frameworks cover how to evaluate whether a problem segment is worth building for before you commit. For the discovery process in more depth, Teresa Torres on continuous discovery is the most rigorous practitioner framework I have seen.