Every product team has a backlog shaped by conviction. You believe you know what matters next because you built the thing, you talk to users, you watch the dashboards. Most of the time that conviction is roughly correct—close enough to keep the flywheel turning.
But roughly correct has a cost. It lets blind spots calcify. The longer a team agrees that something is fine, the harder it becomes to see evidence that it isn't.
This is the story of one support ticket that broke through that calcification for us.
A mid-market customer—one we considered healthy by every metric we tracked—filed a ticket describing a workflow that took eleven steps to accomplish something they did dozens of times a day. They were polite about it. Almost apologetic. "I'm sure there's a faster way I'm missing," the message said.
There wasn't a faster way.
We had designed those steps deliberately. Each one existed for a reason that made sense in isolation: a confirmation here, a navigation there, a mandatory field that downstream processes depended on. The architecture was defensible. The experience was miserable.
The first instinct on the team was to reply with documentation. Show the customer the rationale, suggest a keyboard shortcut that would shave off a click or two. Close the ticket. Move on to the three features sitting at the top of the roadmap—features we had already committed to in quarterly planning.
That instinct was wrong.
We had heard versions of this complaint before. Not frequently—maybe once a quarter. Each time, someone on the team would note it, acknowledge it felt clunky, and then point to the list of reasons the workflow existed as designed. The reasons were real. They protected data integrity. They prevented a class of user error we had seen in early days. They kept an internal process reliable.
What we never did was measure the cumulative cost of those eleven steps. We never asked: how many times per day does a typical user repeat this workflow, and what does that friction add up to over a week, a month, a contract term?
When we finally asked, the answer was uncomfortable. For power users—the ones who drove adoption inside their organizations—this single workflow consumed a meaningful share of their daily product time. They had adapted to it. They weren't churning because of it. But they also weren't enthusiastic. They weren't expanding. They weren't referring.
The ticket didn't describe a bug. It described a tax.
Pulling engineers off the planned roadmap was not popular. The three features on deck had internal champions, customer requests behind them, and competitive rationale. They were the kind of work that looks good in a board update.
Reducing eleven steps to three does not look good in a board update. It sounds like maintenance. It sounds small.
We did it anyway, for one reason: the support ticket forced us to look at retention data through a different lens. We segmented customers by how heavily they used the workflow in question. The heavy users had measurably lower expansion rates and higher support volume—not about this workflow specifically, but across the board. The friction was coloring their entire perception of the product.
The fix took about six weeks. We collapsed the confirmation steps into a single action with an undo path instead of a gate. We removed two fields that downstream processes no longer needed (they had stopped needing them months earlier, but nobody had revisited the form). We restructured the navigation so the workflow could be completed without leaving the screen where it started.
Within one quarter of shipping the change, three things happened that the planned features would not have caused:
Expansion revenue from existing accounts increased. The customers who hit that workflow hardest started adding seats. They didn't cite the change directly—they said the product "felt faster." Perception shifted before anyone could articulate why.
Support ticket volume dropped. Not just tickets about that workflow. Overall volume. When the core daily action feels effortless, users have more patience for the rough edges elsewhere.
Referral activity picked up. Two new customers that quarter came from introductions made by the account that filed the original ticket. The person who wrote "I'm sure there's a faster way" became a vocal advocate once there actually was one.
The three features we delayed? We shipped two of them the following quarter. The third turned out to matter less than we thought. Nobody asked for it twice.
Support tickets are not interruptions to your strategy. They are the most honest signal your market will give you, delivered in the customer's own words, about the product they actually use—not the product you imagine they use.
The founders who build sticky products are not the ones with the best prioritization frameworks. They treat a single frustrated message with the same seriousness as a churned account. By the time a customer churns, the lesson is expensive. A support ticket is the same lesson offered at a discount.
Listen before it costs you more.
Be the first to comment.
0 comments
Loading comments...