When businesses start out, support and sales teams (like any other team) are closely knit. The teams are small and most folks know the ins and outs of the product being sold. Everyone stays on top of new product updates by playing with the latest features, reading documentation or just being quizzed in the hallway by another team member.
When these team members work together, they create knowledge that’s shared within their tribe. They know what works really well in the product and what doesn’t, what pitch to use when on a sales call and what’s the best solution to provide when a certain problem is reported by customers. Even if someone doesn’t know the direct answer, they’d most certainly know an expert in the tribe who can help them out.
This is tribal knowledge. In most companies, tribal knowledge is not written down. It’s created every day. People acquire tribal knowledge by working together, talking about problems, sharing insights and know-how when solving those problems together.
Once someone has acquired tribal knowledge about a certain situation, they don’t have to think much. They just have to do what tribal knowledge has already ingrained in them to do. When tribal knowledge is active, muscle memory kicks in to recommend appropriate next steps to troubleshoot an issue when responding to a chat from a customer, or the right feature for a certain usecase when on a sales call.
Tribal knowledge is great when you’re a small team because it leads to a better customer experience (your customers get fast and accurate answers).
But as your teams grow in size by the hundreds, and as your product teams launch something new every week, it becomes hard for a sales or support person to keep up with all the latest updates. New product updates get missed or forgotten in the long trail of what’s going on in an ever growing, ever-changing organization.
Tribal product knowledge becomes stagnant and outdated.
Because VC-funded businesses grow so fast, refreshing tribal knowledge takes a backseat amidst all other pressing problems that team leads need to deal with (motivating teams, setting up operations and hiring processes, etc.). As a result, teams end up with a growing bag of biases around what worked and what didn’t work in your product, based on tribal knowledge from months or years ago.
If efforts aren’t made to explicitly keep a tribe’s knowledge up to date when an organization grows large, it leads to subpar experiences for your customers. Your customers get answers based on what was known months or years ago, not based on what’s possible today.
Quite recently, we had to fight against tribal knowledge and help everyone discover the details of what my team was building: the help widget.
For close to a decade, businesses using Freshdesk were able set up a portal (a mini website, like support.yourbusiness.com) and show helpful articles to their users before they reach out for support. Our teams knew this part of the product pretty well: there was tribal knowledge around how the portal should be setup, what features were available, and how it can be customised with hacks and CSS to solve specific use cases.
With the help widget, something we had just launched back then, a business (Freshdesk customer) can embed these articles right inside their website, brand it, and do a lot more, without having to redirect their users to a dedicated portal. The help widget didn’t replace the portal entirely, but it worked in a lot of cases. Because the help widget was new: there was no tribal knowledge around it within our teams yet.
When we glanced at email and chat conversations that our teams were having with our customers after we launched the help widget, we noticed that there were a lot of situations when our folks could have recommended the feature, but they weren’t doing it because everyone was so immersed in what they already knew. Their muscle memory dictated them to recommend the portal even when the help widget was obviously the right pick (a customer would have come asking for a way to embed help articles directly on their site, and someone would have recommended the portal).
Even new hires were doing the same thing because they had acquired this outdated tribal knowledge (i.e., recommending the portal to be embedded as an iframe when the customers want to have help articles on their site). We had to figure out a way to retrain this organizational muscle memory so that our teams recommend the help widget in the right situations.
To raise awareness about the help widget, we tried our best to distribute product updates in our internal Hangouts and Workplace groups, and even emailed sales and support teams at every chance we could get about what’s new and nice about the help widget. That just didn’t work. They were just getting lost amidst a sea of updates about the product, about the org, and pretty much everything that was going on as the business grew bigger.
By now, Freshworks had grown to 3,000 employees and we hadn’t figured out a way to systemically train and coach our customer-facing teams about new product features. This isn’t a flaw – it’s just everyone had different, immediate problems to solve while the business and org grew so fast.
To solve the problem, we started making efforts to seed fresh tribal knowledge around the help widget. We went ahead and scheduled a one-time quiz, followed by an in-person demo for every shift in the support and sales teams. The quiz was mandatory but it could be taken anonymously. We didn’t ask arbitrary trivia questions about the help widget in the quiz. Most of our questions mimicked the kind of things a customer would ask our teams over chat and email. This really helped retrain the muscle memory I was talking about, so our teams don’t default to old answers when customers come asking.
Based on a suggestion from our support managers, some of these sessions were run by leads in the support team. The product team that built the help widget trained these leads about what’s possible with the widget, who went on to train their own team members. This made them experts in the tribe, when previously there was no one to rely on for questions about the help widget.
We also made several systemic interventions besides these one-time efforts – including setting up alerts for conversations that our teams were having with customers that could potentially have been about the help widget. If the right solution wasn’t recommended, we left a friendly note with links to help the team member suggest a more up-to-date answer for the customer.
Now that considerable tribal knowledge was created, we started explicitly pointing to documentation when customer-facing teams reached out to us for help around advanced functionality. This way, they didn’t have to rely on us to solve time-consuming questions. They could play with the features when they have some time, by test-driving things themselves. We were also placing in their minds the idea that they can just go ahead and look at the documentation instead of scrambling for help when no one is available.
With all these efforts (both one-time and systemic interventions), we stirred updates to tribal knowledge that remained stagnant in this area of the product. Over a few months, we saw a significant uptick in the quality of answers our customers were receiving, when they sent questions about the help widget.
If there’s one thing you should take away from this post, it’s this: if you’re building a product or a feature, and it’s not being recommended enough by sales and support teams in your large org, start looking for systemic interventions that can lead to internal knowledge being built up around it.
Just don’t remain dissatisfied looking at what doesn’t seem to work. The conventional methods that used to work back when you were a smaller business or a startup almost certainly won’t help anymore.
With the support and sales teams fully equipped with new tribal knowledge, we were then free to go ahead and market the help widget to our own customers, even better. I’ll save a blog post about it for another day 🙂
Shankar is thinking 