We had been running experiments on a product customers weren't using. The data looked like an engagement problem. It was an abandonment problem. Those require completely different responses.
Inheriting a metric means inheriting a definition of the problem. This is a case about what happens when that definition is wrong.
I inherited a hardware product line with a clear mandate: reduce lapse on our voice assistant feature. The metric was well-established, rigorously tracked, and deeply embedded in the team's roadmap. My job, as framed, was to build a software roadmap to fix it. I almost did exactly that.
Before committing to a roadmap, I did something that felt basic but turned out to be the whole game: I asked what the metric was actually measuring.
The lapse metric tracked whether customers stopped using the voice assistant. What it didn't track was whether they stopped using the device entirely. Those are different problems with different solutions. One is a software and engagement problem. The other is a hardware problem — and no amount of software investment can fix a hardware problem.
I separated the two signals. The pattern that emerged was unambiguous: customers weren't disengaging from the voice assistant. They were abandoning the device altogether. The root cause, confirmed through customer research and engineering retrospectives, was physical — a hardware design constraint that made the product uncomfortable to use.
I escalated with a recommendation that ran counter to the team's existing position: fix the hardware problem first. A voice assistant has no value on a device a customer won't use. The pushback was real. I framed it as a sequencing argument — earn the right to build the experience by first building a product people will keep. The hardware redesign went forward. Customer feedback validated the diagnosis.
The discipline I now apply before any roadmap commitment: separate the metric from the outcome it's supposed to represent. Find where they diverge. That gap is almost always where the real problem lives. The framework behind this →