The hardest part of improving a product that millions of people use isn't the engineering. It's deciding what to fix first.
Most teams get this wrong in the same way. They hold a prioritization meeting. Everyone brings opinions. The loudest voice, the highest-paid person in the room, or the stakeholder with the most recent customer complaint wins. The team builds what got the most votes — which has no reliable relationship to what would actually move the number that matters.
I took over product leadership for a major banking mobile app that had been stagnant on customer satisfaction for over a year. The platform had millions of users, a large cross-functional team, and no shortage of ideas about what to build next. What it lacked was a prioritization process that anyone trusted.
The Problem
When I joined, the incoming feedback signal was rich but ungoverned. App store reviews, customer support tickets, NPS verbatims, internal stakeholder requests, competitor feature comparisons, product manager intuitions — all of it was arriving, and none of it was being synthesized into a prioritization framework that engineering, design, and business could align around.
The result was a roadmap built on negotiation rather than data. High-priority items that a senior leader had mentioned once appeared on the backlog. Low-effort requests from vocal internal stakeholders crowded out high-impact customer problems. Compliance items — non-negotiable, time-bound — weren't reflected in the capacity plan at all, which meant they kept creating surprise scope crunches that pushed real product work.
Meanwhile, NPS sat flat. Not declining — flat. Which in a competitive mobile banking environment is a slow decline in relative standing, even if the absolute number holds.
The Approach
I didn't start with the backlog. I started with the measurement system.
First: I built a unified feedback taxonomy — a consistent vocabulary for categorizing incoming customer feedback across every signal source. App store reviews, support tickets, NPS verbatims, and session recordings all got categorized against the same 40-category taxonomy that mapped to our core product surfaces: account management, payments, navigation, notifications, security, and six others.
Once the taxonomy was in place, the signal became quantitative. Instead of "customers seem frustrated with payments," I could say "payments feedback is the second-highest volume category this month, up 18% from last month, with complaint density highest around transfer confirmation flows."
Second: I built a scoring model that weighted each backlog item against three variables — customer impact (derived from feedback frequency and sentiment severity), engineering effort (estimated by the team, not by me), and strategic alignment (does this advance an OKR we've committed to?). Items got a score. The backlog sorted by score. Prioritization meetings became reviews of the scoring methodology, not debates about opinions.
Third: I brought compliance into the capacity model explicitly, not as a surprise. Every sprint had a compliance reserve — a fixed percentage of engineering capacity that was pre-committed to regulatory and legal requirements. This made compliance visible and plannable rather than disruptive.
The roadmap that came out of this process looked different from anything the team had built before. Some long-advocated features dropped significantly because the data didn't support the intuition behind them. Some problems that had been treated as minor fixed themselves as high-priority items when the feedback volume became quantifiable.
The Results
- 10-point NPS improvement within six months of adopting the new framework
- Feedback-driven prioritization model adopted as the team's permanent operating standard
- Compliance items planned into capacity rather than discovered mid-sprint
- Cross-functional alignment — engineering, design, business — measurably improved: prioritization debates dropped from hours to minutes once the data model was in place
The Real Lesson
The 10-point NPS lift didn't come from a breakthrough feature. It came from fixing the right things instead of the loudest things.
The measurement system was the product work. Everything that shipped in those six months was downstream of the decision to build a disciplined, reproducible way to know what customers actually needed — not what stakeholders assumed they needed, not what competitors had shipped, not what looked good in a roadmap presentation.
This is underinvested in at most product organizations. The measurement infrastructure is treated as an analytics concern, not a PM concern. It gets resourced after the product, not before it.
The teams I've seen consistently improve customer metrics are the ones where the PM owns the measurement system the way they own the roadmap. Because without it, the roadmap is just organized guessing.
