The Missing Customer-Centric Link
Threading the customer through the product team
Time and time again the advice is given to make your product team more customer-centric. Get the customer into product decisions: Build customer advisory board, go on ride alongs, listen in on customer support calls, do this, do that…
Last week this topic surfaced again for me when I read a great post titled “Is your marketing team working with the customer support team?” by Abhishek Anand. His advice is as follows:
“No team in your firm should stay isolated from customer support. Answer support calls if you need to, but be involved in customer support if you want to improve your product, marketing, operations. Literally anything” — Abhishek A.
All of this advice is great if you are set on keeping your product team as classically organized with a product manager, a marketing team, a development team, etc relegating the customer support team to a minimum wage tactical crisis management call center role… a supporting role.
If you are willing to change — One can and should do better!
Working with customer support is mandatory but…
Just about every healthy product team that I’ve had the pleasure of working with is full of individuals who want a closer connection to the customer. Many of them do get contact with the customer either directly or through support and bring back a wealth of information that helps evolve the product in ways that would be impossible without those touch points.
But here is the rub — In practice I’ve found that this “working with” process is insufficient, impractical to scale, and often times harmful.
Insufficient
Consider the following thought experiment.
Let’s say you have an engineer who can participate in 10 customer support cases in a given month without impacting their normal responsibilities. Note that this experiment applies to any member of the product team be they product marketers, product managers, sales leadership, or even the product owner — I am former engineer who wanted customer contact.
Now contrast that with the customer support team who might field 1,000 cases that same month.
In this case, the engineer’s sample size of 1% is so small that everything could look great or terrible — statistical distribution — the engineer has no way of knowing.
Impractical to scale to sufficiency
You might be tempted to think that you can add more engineers to the mix to get a larger sample size. Unfortunately this approach isn’t practical and doesn’t actually yield a larger sample size.
To get a complete picture of the full set of samples, each engineer would need to bring every member of their team up to speed on the context and details of each support case — the cost is #_cases * #_team_members. As soon as the number of cases reaches the maximum a single person can process, you’ve consumed the entire group. This sharing of the full context is a less efficient but analogous version of having every team member sit in on each case.
Reducing the cost of sharing requires that each engineer provide a summary and conclusion from their learnings to the group. Every omitted detail is unconsciously chosen based on the individual’s biases, understanding, and ability to effectively summarize.
This summarization results in a very lossy transmission of information, often to the point where different sample sets are difficult to correlate making it challenging to globally prioritize efforts — the goal.
On the flip side, there is also a significant cost for the customer support team as every engineer would need to be brought up to speed on the context of each customer and case draining the support team of vital resources for every engineer they agree to host.
Now consider what happens to the company’s overall efficiency as teams other than engineering start asking to join the support calls. YEOUCH!
Harmful
Worse, each engineer who participates in this program naturally becomes anchored to their impressions as they are theirs and therefore the most relevant to defend as otherwise their efforts will feel wasted.
Consider:
- One engineer could have gotten 10 simple user errors that require no changes to the product or documentation. Impression: everything is great!
- Another engineer could have gotten all 10 cases focused on a specific type of issue that caused significant customer pain. Impression: stop the press! Fix the product!
At the same time there was a different issue that would’ve provided the most global benefit that neither was exposed to.
Example of the last point — at LineRate Systems we regularly met with our customers’ leadership and participated in deployment activities. Yet, none of us were able to argue in favor of prioritizing a simple feature that yielded dramatic operational benefits over the backlog of capability features because in spite of our efforts we were never exposed to the pain that missing feature was causing.
This situation is analogous to the parable of the blind men and an elephant.
Customer Support is the team with visibility
The question really needs to be, why are other teams inserting themselves into the support process to engage with customers in the first place? The customer support team already has most of the necessary information.
Why aren’t we injecting the customer support team into other functions?
Customer Success is the way forward
In my opinion, the root issue is the underlying dysfunction where companies treat their “customer support” function as a tactical “pain/crisis management center” and isolate them from the revenue generating product team.
Instead what we’ve done at Balanced Blends is create a strategic Customer Success* team with a relationship-oriented mission to ensure that the customer experience is the best it can be. They are broadly chartered to be the primary advocate for all customer needs be they product issues or customer/market requirements. It is their job to proactively ensure all teams understand the elephant.
* Note — Customer Success is an evolving term and we’ve chosen the organization below for our team — other organizations are likely suitable for the skills of different product teams.
Making Customer Success Successful
Required that we completely the roles and responsibilities of our product team. Specifically we identified 4 key areas that a successful customer success team needs to own (accountable and resourced).
Support beyond crisis management
First and foremost, the customer success team must be supportive of customers when they are needed the most. This touch point with customers in crisis is where the company has the option to really shine and engage with the customers allowing them to learn not only what isn’t working but what is working as well.
The change we made is that the customer success team needs to be accountable, and capable, for proactively bringing the relevant and necessary information into all product team discussions. To live up to this level of accountability, the team cannot — I repeat cannot — be a minimum wage call center whose task it is to run through scripted interactions with the sole mission of putting out the fire as quickly as possible.
At both Balanced Blends and LineRate, we found that our “support” engagements disproportionately increased the value of our brand by connecting with our customers and making them feel heard and safe.
Get to know your customers, including what makes them both happy and sad!
Social Interactions
Next, why are social interactions typically handled by a completely separate team (digital marketing)? A team that requires, at a minimum, similar product training to the support team. A lot of effort just so they can effectively engage with customers on facebook, twitter, whathaveyou.
You’ve already got a team that is already fully trained in both the product and customer engagement. I mean, what better proof of engagement success can you have than a team that is specifically trained in handling desperate and/or angry customers and turning the situation into a success?
Even better, from a mindset perspective this dual social and support interaction mix will blend both positive and negative interactions resulting in a healthier team.
Pre-Sales
How many times have you heard this story — A sales team closes a great deal only to find out that the solution consumes more than its profit in support?
The irony in the question above is that there is often an equivalent solution that would’ve resulted in a better experience for everyone but that specific pre-sales team didn’t have broad enough product knowledge to propose the best solution.
What if the customer success team — who is intimately aware of the product’s capabilities — was an integral part of the pre-sales team playing a supporting role to help match specific customer requirements to the best overall solution? Imagine how much better one could make the overall customer experience, the bottom line, and overall brand impression.
Market Research
How often are product owners told to “get out of the office” and meet with customers? How often are product owners admonished to sell value and solve unsolved customer problems?
Answer — All too often.
Reality — Getting out of the office rarely yields a value increasing “ah ha!” moment because, just like the previously discussed engineers, the best product owners or product managers can do is sample a small subset of their market (the elephant problem)— typically from executive level conversations that are divorced from the operational realities.**
Wouldn’t it be great if there was a team that was already collecting positive and negative market data simply by doing their jobs day-in and day-out? A team that is already engaged with customers through support and social channels? A team that was already riding along with the sales teams?
Why not task this team with formally tracking the market?
** I believe this reality applies to all companies including startups and is why it is best if entrepreneurs already have broad domain expertise or enter an established market with known limitations.
Putting it together
At Balanced blends we’ve created this team and made them direct peers with the Customer Engagement (Marketing, Sales, Business Development), Product Development, Operations, and Finance teams directly reporting to the product owner.
By making this team a full peer in the product team, we have minimized the need for individuals from other teams to have to participate directly with customers while efficiently providing richer customer feedback.
What other organizational structures have you tried to get a similar outcome?
