Support teams almost always know more about their customers than anyone they work with.

They’re talking to them constantly, whether through email, chat, or phone. They know their customers’ job roles, what problems the product solves for them, and what they wish it would do (but doesn’t). Those experiences — all of those anecdotes and stories they pick up along the way — create an unmatched foundation of qualitative knowledge.

One of the biggest challenges for any support team is making sure their knowledge makes its way to:

  • Product: so the roadmap includes the customer’s voice and needs
  • Engineering: so the right bugs and features get prioritized
  • Marketing: so the company’s brand represents its customers

When you’re working closely with customers every day, the information you acquire is valuable to everyone. To make sure you can have company-wide alignment around the customer, you need the right processes around support, backed up by the right tools, to make it happen.

At FullStory, we’re on a mission to make empathy bionic. To us, that means our product, success, support, and marketing teams are constantly working in harmony on the most business-strategic and customer-focused projects at any given time. We’ve taken great pains to develop and build systems that allow us to do just that, which is why we were so excited to hear InVision’s story in pursuit of a common goal.

Known across the industry for their systematic and customer-first approach is InVision, a design, prototyping, and collaboration platform. With a 98.1% ticket satisfaction rating over the last two years, it’s clear they know a thing or two about how to structure an efficient and effective support workflow.

We talked to InVision’s Vice President of User Enablement, Brandon Wolf—whose expertise notably includes building and improving customer experience and support processes—to learn more about how InVision gets alignment across their organization to make sure the customer is heard in all aspects of product management.

Balancing product, engineering, and support.

For Brandon and InVision, everything begins with customer advocacy. You need to have people on your team who have an innate sense of the customer and the ability to articulate and argue for their stance.

Product management and engineering meet with support on a structured cadence to hear about the problems customers are facing. At these meetings, Support Team Leads give a full-throated account of the customer’s voice regardless if it happens to overlap with their own position or not.

“The customer may not always be right, but they must always be heard.”

Product managers need to balance the customer’s voice with the realities of the product roadmap and the requirements of the organization, and for this reason, support can be their greatest ally. There’s an “internal calculus” of feature requests, bug reports, and potential improvements that can’t be forced:

“The product manager’s job is, from my perspective, unenviable,” Brandon shared. “In many cases, you’re dealing with non-overlapping and competing goals. So I try to properly set expectations and remind teams that there are any number of different axes upon which you can measure urgency, severity and priority.” And more importantly, success!

Too often, product managers have trouble understanding the customer experience because there simply isn’t a system in place that lets them contextualize and prioritize the different things their support team is hearing. When the customer’s voice sounds like a cacophony, it winds up getting largely ignored, but organizing these voices takes a curated — yet constantly evolving — cross-departmental workflow.

Letting everyone live where they need to.

Everyone in an organization doesn’t have the time or inclination to use every tool. The trick is creating an ecosystem where all teams’ toolkits live in harmony — and all have access to the same data.

At InVision, they use Zendesk and a combination of internal tools to accomplish this. “If you’re a product manager at InVision, you or anybody at the company can go through and look at every single ticket back to the dawn of time,” he says, “You can see what people were talking about in your little swath of the product back in 2011, 2012, 2013, 2014, etc.”

When it comes to transitioning issues from support to product, there’s a rigorous process of escalation, curation and tool-switching that goes into making this data availability work.

At InVision, when a user identifies a bug, a Zendesk ticket is escalated to a support engineer, who tries to replicate the issue. If they’re successful at replicating it, a parent ticket is created. That parent ticket then becomes associated with an issue in the bug-tracking software JIRA — which is the domain of the engineering team. All future customer reports from Zendesk get bolted on as children tickets.

This is the kind of process that makes the “full-throated customer advocacy” inside InVision work at scale. If an engineering or product manager goes to look at a bug in JIRA, they can immediately see its relative impact. If one bug has 50 reports and one has 2, it’s clear which one is the bigger priority.

“It’s unreasonable to think that engineers will live in Zendesk the same way it’s unreasonable for engineering to think that my support people will be in JIRA,” Brandon says, “So we make all the information transparent across both systems. That ensures both that everyone can live where they need to and the customer is satisfied.”

Single source of truth.

Herein lies the difficulty of picking a toolset that will make the relationship between product, support, and engineering work:

Everyone has a tool or tools that they’re most comfortable working in, but building a customer-centric culture means everyone must have access to the same types of information about customers.

Your support team is acutely aware that a bug is causing severe user frustration because they’re hearing about it 24/7. But if that information isn’t getting to the product team, and then to the engineering team, then it’s not going to get fixed — because its importance simply won’t be conveyed properly.

Product managers are tasked with weighing the pros and cons of different feature requests against the product roadmap and the engineering team’s capabilities, but without accurate analytics and a qualitative perspective, their internal calculus is going to be off.

You can’t let the customer run the product, but you do need a structure in place that enables the customer’s voice to come in loud and clear. You know your own capabilities and those of your engineers. You know which bugs are quick fixes and which are more involved projects. But if you don’t know your customer inside and out, then you’re not going to be able to prioritize your efforts in a way that leaves them satisfied and coming back for more.