Most of our best decisions started in a spreadsheet or a whiteboard session. This one started in a support queue on a Tuesday afternoon.
A customer filed a bug report. The summary line was blunt: "Unexpected behavior when running two environments under one account." The description was three sentences long. It did not contain the word "please."
We almost closed it as a configuration error.
The customer had set up two separate environments — staging and production — under a single account. They expected clean separation: independent data, independent access controls, independent everything. What they got was bleed. Configuration from one environment leaked into the other in ways that were hard to predict and harder to debug.
Our initial response was the classic support reflex: user error, not a bug. The system wasn't designed for that workflow. The documentation didn't promise it. Technically, nothing was broken.
But the ticket sat open. The customer pushed back. A second customer reported something similar. Then a third.
Our first instinct was to write a knowledge-base article explaining the correct setup. Basically: don't do that.
One engineer disagreed. She pulled three months of support data and found a pattern. Seventeen tickets — different customers, different sizes, different industries — all describing some version of the same problem. They all wanted strict isolation between environments inside a single account. They were all working around its absence in creative and fragile ways.
The room split into two camps.
Camp one: this is a niche need. Build a workaround guide, move on, ship the features on the roadmap.
Camp two: seventeen tickets is seventeen customers who told us what they need without us having to ask. The roadmap is a guess. The tickets are data.
The turning point was a question someone asked during a Friday standup: "If we had built this from day one, would anyone complain?"
The answer was obvious. No. Environment isolation is a reasonable expectation. We hadn't built it — not as a design choice, but as a gap we hadn't noticed because no single ticket had been loud enough.
Once we reframed the bug as unmet demand, the conversation changed. We stopped debating whether to fix it and started debating scope. Full multi-tenancy inside a single account? Lightweight environment tags? Something in between?
We picked the smallest version that would solve the actual problem those seventeen customers described. Not the most elegant version. Not the most extensible. The one that matched reality.
The fix — now a feature — went out six weeks later. We told nobody. No blog post, no changelog fanfare. We emailed the seventeen customers who had filed related tickets and asked them to try it.
Fourteen adopted it within a week. Several expanded their usage in ways we hadn't predicted. One customer consolidated three separate accounts into one, cutting their own operational overhead. Another started onboarding internal teams they had previously kept on a different platform.
Within a quarter, environment isolation became one of the most-used capabilities in the product. Not because we marketed it — because it solved a problem people already had.
New customers started mentioning it during onboarding. "We picked you because we can run staging and production under one roof without worrying about cross-contamination." We hadn't put that on the website. They heard it from the customers who had filed the bug reports.
Roadmaps are hypotheses. Support tickets are evidence. Both matter, but they're not equal. A roadmap tells you what you think customers will want. A support ticket tells you what a customer needs right now, in their own words, with enough frustration to write it down.
The dangerous habit is treating support as a cost center — a queue to be drained, not a signal to be read. When you optimize for closing tickets fast, you optimize for silence. Silence feels like success. It isn't.
We now review support tickets as a product input, not just an operations metric. Every two weeks, someone on the product team reads the raw tickets — not summaries, not tags, the actual words customers wrote. The patterns don't always jump out. Sometimes they take months to surface. But when they do, they carry more weight than any brainstorm.
The fastest product-market signal often hides where you're least inclined to look: the complaints. Not the compliments, not the feature requests with upvote counts, not the analyst reports. The bugs. The frustrations. The three-sentence tickets filed on a Tuesday afternoon by someone who didn't even say please.
Pay attention to what people struggle with. That's where the next feature lives.
Be the first to comment.
0 comments
Loading comments...