Customer Championing!
We've heard how the best friendship ought to exist b/w support & product management teams. But saying "if product management is done right it'd totally eliminate support teams" is utopian. Here's why!
Lets’ start off with a famous quote!
“The key is to set realistic customer expectations and then not just meet them but exceed them in absolutely unexpected ways and keep on consistently at it”
- Sir Richard Branson
Revisit Customer Support & Success!
Consider this!
Imagine your 4-year old grandkid is getting into active gaming a lot and being a doting grandparent that you are, you bought a latest Nintendo & the excitement level in your house is touching the sky.
Scenario 1: Support
But, after you unbox the whole unit and try to set it up the joy-con doesn’t seem to respond.
Also, a common problem as seen on the internet!
What would you do?
Call support!! Duh!
Case1: Look for a support number to call either somewhere on the back of the packaging or go online and search for it. Talk to tech support about the problem and work with them to try out a few things and see if it solves the problem. Just supposing it still persists, the support would naturally do their best in helping solve it or assist you with getting a replacement.
Case 2: Try and go online yourself and look for videos that help you troubleshoot the problem. Follow the steps suggested in there & see if sorts out the problem. Again, if the problem seems to persist connect back to tech support & follow their lead.
That obviously is describing what a classic Customer Support desk’s workflow would entail in listening to customer queries & solving their problems.
But, in both these cases the assisting teams don’t come into the frame, as in their workflow doesn’t begin until they get approached which means they are waiting for the problem to occur & then start off their thinking over how to solve for those (of course not discounting the fact that they may have some sort of a framework, a stepwise approach to understanding the problem & classifying it). In other words, they are being reactive in their approach.
With the turn of the tide on the entrepreneurial / growth mindset and especially the culture that’s followed in startups adhering to PLG practices, this is a thing of the past.
Scenario 2: Success
So, just supposing you bought a Nintendo (or) someone you know happened to ordered it for you as a gift for the ongoing festive season and it arrived today that is on 08-Dec-2022.
And, just as for any proprietary products in the world today, there happens to be something called “Register your product online” which you obviously go online and finish.
Now, take a look at this for workflow.
This workflow is typical of any customer success team as they believe in connecting all internal teams by a clear download over the purpose of the product, its use cases befitting to given user persona, best practices - dos & don’ts et. al.
And, this could be a regular dashboard that CSRs, CSMs may be used to seeing and dealing with regularly…
But, could this be improved in any way?
Yes, of course.
When CSRs happen to receive calls over some trouble the user is facing over using the product, the problem could be understood by interpreting the conversation employing a STT (Speech to Text) algorithm, classified & aggregated with statistics obtained prior to the current call & routed to concerned teams with a visual dashboard depicting the exact criticality whilst also collecting information like Downtimes, TAT & updating them.
So, that could be something on these lines...
Also, another thing to ponder about though is, you are a product organization. So, if some user has faced a certain problem in the workflow and has reported it, solving it for him alone over a 1:1 could never be a viable solution.
Why?
Because there may be many others too who might have faced the same issue and might have not reported it yet or it is quite possible that they may face the problem going ahead and may look to report it. So, there is a burning need for you to think about the broader perspective which is from a product’s usage level and not the single-user solutioning level unless yours is a SaaS / PaaS product that’s delivered on the cloud.
And now that could be a great example of how customer success could function in conjunction with the other internal product teams to largely help customers identify with solutions to the problems & be there to assist them just in case they are needed.
On to Championing Now!
Having gone over the functions of Customer Support & Customer Success, it ought to be clear how the latter is a far better strategy suiting (rather befitting) any product-based organization that’s thinking of ways to build customer loyalty in an aim to be able to convert that to CLTV (Customer Life Time Value) at a later point in time.
But, talking of championing, to what degree is that different from the others?
Firstly, championing is about putting the customer at the center of everything and making their needs the base of every idea so discussed internally with the other teams with an acute focus on delivering the best of experiences and thinking about constantly improving it thereof.
How is customer championing different from customer success?
When one talks of customer success it is about putting the customer & his needs at the center of the workflow which is close to customer championing but it isn’t the same. Customer success largely deals with establishing protocols for internal teams to follow over serving the customers over identification, troubleshooting & resolving problems they are facing with the product.
Customer championing thinks much ahead of that in terms of closing out the loop, helping cover the last mile, help draw the full circle over ideating, envisioning, understanding, experimenting, validating, factoring & learning, building the solution so as to make it absolutely easy for customers to find solutions to problems that could arise in a few scenarios.
“PLG & Customer Championing”
Given the advent of a practice like product-led-growth where the product is put at the center of everything & so as to drive growth ahead as well, simply means that the product ought to be able to sell itself. If you get one step deeper and analyze this, it ought to be possible only if one has a larger, wider, deeper understanding of the customer and his needs and then uses that understanding to build some specs that would help all teams align.
Scenario 3: - Championing
Get back to the Nintendo example in the beginning of the article.
Use case:
Since the device is ordered in by an adult who is well in his 65s as a surprise for his grandkid and neither of them could really know or want to get their heads down into setting up the thing. They expect it to be just plug-and-play and would love to see someone demo it for them & run them through the whole gamut of possibilities over the product’s effective usage, just so that they are able to derive the best out of it.
When you were filling out the registration in the first step, let’s just suppose you had a checkbox there which was something on the lines of:
Yes, I’d love some assistance in setting up the product at my location
And, supposing you checked it & are immediately presented with a calendar dropdown to choose your convenient date & time against a given time of feasibility as set by the internal team, that’d be a welcome addition for someone absolutely new to the product isn’t it?
There’s a feel-good factor about this whole process & workflow, is there not?
It’s almost like someone out there who has been in the same situation is guiding you subconsciously, symbolically holding your hand taking you ahead - one baby step at a time.
That’s a proactive approach where you’re envisioning, thinking ahead of the user’s moves as he gets on to using your product & also contributing greatly to the overall UX, something that the user would certainly remember for a long time which could also be the base of his referrals.
Here is a list of mindset / behavioral changes to watch out for in your internal teams that could imply a successful implementation of “customer championing”:
1. Developers go from “CHANGES to IMPROVEMENTS”
The development teams change their mindset from solutioning, features, more additional features to being more centered around the overall purpose, the main reason why we have to do this, the motivations behind the users when they said they wanted a particular (x) feature.
Not only during the first product / feature release, this gets carried over even during the follow-up work stemming from the requests on-field right from a small bug to affecting a something that was a major change in the workflow.
2. Designers go from “Wow-FACTOR to SPECS”
Design teams may have tendency to stray away & go off on tangents in pinning on the UI & the WoW-Factor which is to say the way a given design / screen ought to look like. And, in doing so they get down to stretching the SPECS in a way that could compromise the requirements of the end users.
So, them going from the aura / look & feel / Wow-factor to start questioning their internal teams over the “Why” of some of the designs and whether or not they are required, aligned with the SPECS may take some time, but it could be made possible over a few silos.
3. Product Teams go from “FEATURES to ALIGNMENT WITH GOALS”
Product teams comprising of product managers across all levels of seniority seem to drift quickly from thinking of multiple features to whether or not a given feature they are thinking of taking ahead into the build cycle is needed, essential, aligned with the goals that have been set.
Also, since the product teams comparatively ought to carry more clarity on the goals, the prioritization of features the alignment is often presumed to be a natural extension but it sadly isn’t the case. Sometimes the requests they have are all so close and overlapping that “the alignment to goals” is one factor that could help them clear-up their confusion.
💡 PRO TIP for PM ASPIRANTS:
In case you are applying for any roles from Product owner and above consider strategically including the term “customer champion” in your profile.
Well! If not that exactly it could be a variant like “championing customer needs”.
Conclusion
Given the best practices followed in an organization that is into building products and has seen some growth cycles, it is only but natural that it is a result of tremendous research, insight that led to building what could be a product befitting the markets & the users.
But, the role CS teams play in dealing with customer problems on an ongoing basis right from the beginning of the growth cycle post the very first feature release right up until EOL cannot at all be discounted whatsoever.
Today the world is knee-deep into smartness / smart technology & it's just a matter of time before we'd be neck-deep.
Here's a thread🧵 exploring what it'd take for customer support / championing to scale smartness levels?
https://typefully.com/BgpInv/xfKMRcL
#productmanagement #smart #technology #insight