Three years into running IT operations at a regional telecom, I noticed a pattern that changed how I thought about product feedback. Every quarter, the product team presented interview findings that painted a mostly positive picture: customers liked the new self-service portal, valued the expanded coverage area, rated satisfaction at 7.8 out of 10. And every quarter, the support queue told a completely different story. Billing confusion tickets had tripled since the portal launch. “Can’t find” searches in the help center spiked every Tuesday after the weekly marketing email. Customers who rated satisfaction at 8 were filing tickets about the same three workflows.
The interviews captured what customers said they thought. The support tickets captured what they actually struggled with.
The Structural Limitation of Self-Reported Data
Product discovery interviews are essential. Teresa Torres’ continuous discovery framework, built around weekly customer touchpoints, has become the baseline practice for serious product teams. But interviews have a structural limitation that no amount of skilled facilitation fully overcomes: they rely on self-reported behavior.
Customers answer interview questions through a filter of what they think the interviewer wants to hear, what they can remember accurately, and what they believe is worth mentioning. A customer who spent 14 minutes trying to find the “export” button last Thursday will not bring it up in a discovery interview the following week. It was a small frustration. It resolved itself. It felt too minor to mention. But multiply that friction by 2,000 active users, and you have a usability problem that is silently driving churn.
Support tickets don’t have this filter. When someone submits a ticket, they are describing a problem they could not solve on their own, at the moment they are experiencing it. The emotional and practical context is live, not reconstructed from memory.
Atlassian’s 2026 State of Product report found that nearly half of product teams don’t have enough time for data analysis, leaving many teams “flying blind” on customer experience. Meanwhile, most of those same teams are sitting on thousands of classified, timestamped, severity-tagged customer interactions in their support tool. The data already exists. It is simply not being used for discovery.
Three Categories of Insight Tickets Surface
Support tickets reliably surface three types of insight that interviews consistently miss.
Friction at actual scale. An interview might reveal that 3 of 12 participants found a workflow confusing. A support ticket analysis for the same feature might show 340 tickets in 90 days, with 78% filed within the first 48 hours of a user encountering the feature. The interview tells you “some people are confused.” The tickets tell you exactly when, where, and how often.
The language of real frustration. Interview participants choose polite, considered language. Ticket submitters use the words that come to mind when they are stuck. Those raw descriptions are gold for copywriting, for error message design, and for understanding how customers actually conceptualize your product versus how your team conceptualized it.
Problems customers solved themselves (badly). Some tickets are not about things that are broken. They describe workarounds. “I exported the CSV and re-imported it to update the dates” is a ticket that technically resolves as “no bug found.” But it signals that the date editing workflow is so poor that users built their own process around it. These workaround tickets almost never surface in interviews because the customer already “solved” the problem.
A 45-Minute Weekly Practice
Running a support ticket discovery review does not require a new tool or a dedicated analyst. It requires a standing 45-minute block once a week and a tagging system that your support team is probably already maintaining.
Set up a saved filter. In Zendesk, Intercom, Freshdesk, or whatever your team uses, create a view showing tickets from the past seven days filtered to your product area. Exclude password resets and billing-only issues unless those connect to your current discovery focus.
Read 20 to 30 actual tickets. Not summaries. Not tag counts. The real tickets, including the customer’s words, the back and forth with support, and the resolution. You are looking for patterns, but you are also building intuition about how customers experience the product. This is the same muscle that interview practice builds, just from a different data source.
Tag for discovery themes. If your support team already tags by issue type (bug, feature request, how-to question), add a layer: tag tickets that map to your current product discovery objectives. If you are investigating onboarding friction this quarter, tag every ticket that relates to a user’s first 14 days. Over a few weeks, you will have a corpus of real onboarding problems that no interview protocol would have surfaced.
Bring three tickets to your next product trio meeting. Teresa Torres’ product trio model (PM, designer, engineer) works best when the team shares a common evidence base. Printing or screenshotting three specific tickets and reading them together takes five minutes. The discussion that follows is often sharper than an interview debrief because the evidence is concrete and unfiltered.
Turning Ticket Patterns into Roadmap Inputs
The Zendesk CX Trends 2025 report found that 63% of consumers will switch to a competitor after a single bad experience, a number that grew 9% year over year. That statistic is abstract until you read 30 tickets from customers who churned after encountering the same broken workflow.
Ticket pattern analysis becomes a roadmap input when you move from “how many tickets did we get?” to “what is this pattern costing us?” The calculation is straightforward: take the top three ticket categories by volume, estimate the support cost per ticket (HDI benchmarks place the industry average at roughly $15 to $25 per B2B SaaS ticket), multiply by monthly volume, and present that number alongside the feature request.
“Fixing the date picker saves $4,200 per month in support costs and reduces a friction point that generated 47 churn-risk tickets last quarter” is a different conversation than “users say the date picker is confusing.”
Tools like Productboard and Cycle can automate the connection between support tickets and roadmap items. But the practice does not require specialized tooling. A spreadsheet with columns for ticket theme, count, cost estimate, and connected roadmap item works for teams under 50 people.
When to Pair Tickets with Interviews
Support tickets are not a replacement for customer discovery interviews. They are a complement. Tickets tell you where the problem is. Interviews tell you why the problem exists and what the customer’s underlying goal was when they hit the wall.
The strongest continuous discovery practice uses tickets as the scouting layer: identifying which problems are most frequent and most painful. Then interviews go deeper on those specific problems, with the PM already knowing the landscape before the first question is asked. This is a more efficient version of discovery because you are not fishing for problems in open-ended interviews. You are validating and deepening your understanding of problems the data already surfaced.
Across 20+ years in IT operations, the teams I worked with that shipped the fewest post-launch surprises were the ones where the PM read the support queue every week. Not occasionally. Not when something broke. Every single week. The practice built a type of product intuition that no dashboard or interview transcript could replicate: a felt sense of what customers were actually experiencing, in their own words, at the moment of frustration.
Your support queue is already running a continuous discovery program. The only question is whether your product team is paying attention.