The motorbike repair shop and product management
What digital products can learn from the motorbike mechanics in terms of customer experience
Last month, I went to a motorbike repair shop to have my motorbike overhauled (after 5 months of inactivity). I came fairly early and didn’t have to wait for anyone. My bike got scrutinized and some parts were taken off. I, despite having driven intensely/insanely for the past 5 years, am not at all knowledgeable about bikes i.e. problems, gears…
That means I was totally in the dark about what the mechanic was doing, and how much trouble my motorbike was really in. But since I’m one of the first customers, I’m chilled.
Until.
I started seeing people coming by to have their tires fixed, or pumped up. Sometimes, many people came at the same time, pulling the mechanic away from my bike.
That’s not good.
I suddenly realized this is exactly what happens to a Product person on a daily basis.
Product management and distractions
As a product manager, I receive a lot of “urgent” requests from our customers on a daily basis. The technical effort to solve such problems individually is relatively small, at least compared to highly strategic but time-consuming projects. As a result, I often fall into the trap of trying to solve them immediately as they come up.
“It’s gonna take only a day” — I said
I wish life could be that simple. Context switching kills. Asking (very politely :D) our engineers to switch from the current task (which I, ironically, pushed them on a daily basis to meet the deadlines), to solve something else more urgent, requires them to read up on the problems, discuss the solutions with me, only to come back to the main project blank-minded of what was going on.
Now, we can’t simply and blindly “follow the company’s vision” by solely focusing on our plan and ignoring those urgent requests. This is the same as the mechanics: they can’t tell the passers-by to wait for my bike to be fixed first, while I indeed came first and I will pay them so much more!
“It’s just a simple flat tire that needs pumping, that’s all” — any sane customer (even me)
What good of a bike shop if it takes 30 minutes to fix a flat tire?
For customers, they have one problem and so it’s everything they see.
The brilliant solution of the mechanics
There was one thing that the mechanic did that really struck me.
He constantly updated me on the current progress.
Wait, let me remind you of two things: 1) I don’t know a dime about motorbikes, and 2) I understood half the things he told me.
But it works. Why?
Because I have a sense of progress. Human hates inactivity. It’s a fact that has forced companies like Uber to show the real-time location of the car to keep their users entertained with the little animated car on their screen. It’s the same fact that has forced shipping companies/e-commerce platforms to show the progress of an order. It’s also the same fact that propels the “animated typing bubble” of Meta Messenger and Instagram. It’s everywhere if you take a look around you. It’s people’s tendency to be idleness averse.
What people need, as Don Norman calls it professionally in his book The Design of Everyday Thing, is Feedback.
The Uber car on the screen is equivalent to the mechanic giving me updates. Hardly do I know (and hell I care) the brand of the car or the streets it must go through, and so little did I understand what the mechanic said. The other half of the mechanics’ saying that I understand turns out to be how much work has been done (“hey we’re draining the old engine coolant and it’s nearly done “). And that’s exactly the type of feedback I want to know. I don’t really care what is being done, I care how much time is left until I can get on the road.
Another thing that also played a huge role in rescuing my short-lived patience is the position.
In a Vietnamese traditional motorbike repair shop, you have nowhere to sit except right in front of your bike, watching everything the mechanics do to your beloved bikes. This is because those shops are usually small and made out of the current accommodation the mechanics and their families reside in.
In more modern, franchised shops, you have a dedicated room, separated from the main fixing room by a wall of transparent glass.
Either way, you are encouraged to see what people do to your bike.
Intentional or not, it’s a great move to improve customers’ satisfaction. Operational transparency has proven to be effective in improving citizens’ trust in local government, patients’ engagement with their treatment, diners’ satisfaction with the food, and so much more.
This reminds me of the pleasure I had when going to Japanese restaurants/food stalls. The interior of Japanese restaurants is usually designed so that the customers can sit around the kitchen and can observe the end-to-end cooking process. At some high-end restaurants, a chef is designated just for you (or your group), and they will “perform” the art of making your meal right in front of you (Have a look at “Omakase” on Youtube for a more immersive experience :D)
Zooming in to digital products, we’re observing the rise of “public roadmapping tools” where users are encouraged to view and vote for the features they like, and see the progress of those features. Some popular names include Canny, Uservoice, and ProductBoard.
Of course, doing so is a double-edged sword as you can easily exert a ton of pressure on yourself and your colleagues to meet your promises. But doing it well and you’ll win yourself an army of loyal customers. A bright example of this is Obsidian: The app was developed and maintained by two people only, but in the past 2 years it has been shipping a ton of feature requests, bug fixes, and publicly promised functions. Their shipping momentum helps a 2-man-army compete head-to-head with Roam Research, which raised $9M in its seed round in 2020.
This traces back to the sense of progress. We at least have the control of “should I go somewhere while my bike is being fixed” or “let’s stay here for a little while because things are about to wrap up”.
Again, little a role does understanding play here. What the customers want in cases they have to wait is not to be explained of the cause of errors (input), but to be informed of the progress (output).
Learning from this experience
People want to feel important, and giving them feedback like this makes them feel like they are in control of the entire situation.
I wouldn’t dare to imagine I would apply this lesson to my job that soon.
Just this month, I had a catch-up call with one of our company’s highest-paid customers. As much as they believe in our product’s philosophy and future roadmap, they are downright frustrated. They told me they would either triple their contract with us next year or find another vendor if we fail to provide them with a certain feature set. For them, we lacked some of the so-called “basic features” that many of our competitors possess, and that crippled them to completely abandon other vendors to marry us.
Now, let’s put the sensical part of their request aside, since… it’s always a sensical request for our customers, right?
I want to focus on how we handled the situation, which similarly resembles the motorbike mechanic’s technique.
The most important thing was to take care of the idleness aversion. After carefully noting down their requests, we set up a Notion page to list all of their requests, their critical level, and the current status: “Researching”, “Discussing”, “In development”, “Released”. Then, we invited our key product managers to that page to follow up with more probing questions. The exchange of inputs was spirited as our (frustrated) customer was eager to share all the pain points while the PMs were thirsty for new insights.
We even went so far as to set up a Slack Connect channel with them to make sure they feel heard at any time and can escalate any critical issues to us without downplaying their urgency like when sent via emails. Please note here that emails and support tickets have always been our main support channels, and we rarely set up direct-message channels for our clients. But this time, such a tactic was much needed.
I feel like setting up an instant messaging channel like this is not that different from sitting the customers right next to where the mechanics were working. At the same time, the Notion page provides the customers a peek into what was actually going on inside the organization.
Just yesterday I had a call with the same frustrated customers. Although I have to repeat, we haven’t delivered a single feature they requested, they were surprisingly calmer than last time, and even were asking me to discuss future contracts.
What a save!
Idleness aversion: the challenge
One thing I learned from the tech world: what works for my competitors might not work for me.
Ron Johnson, Apple’s Senior Vice President of Retail Operations, at that time revolutionized the customer experience at Apple Store and earned himself more than $400 million after twelve years at Apple. He was considered Job’s A-player. However, he was fired only 17 months after working as the CEO of J.C.Penny, a department store company.
Similarly, Marissa Mayer, who was once a top-ranked VP at Google for 13 years, failed miserably as the CEO at Yahoo after 4 years working there.
It would be naive to simply bring the motorbike shop model over to digital products without carefully considering the key difference between the two, which is the scale.
The motorbike repair shop’s pool of customers is limited to the residents in the local area, as repair shops are ubiquitous in Vietnam. If a customer sees that the shop is already full, they will find an alternative shop, which discourages the need to expand those shops.
However, a border-less digital product can have customers from all over the world. Those customers cannot physically see if the support team is already drowned under incident tickets, so there’s no reason for them to delay sending their (as usual) urgent tickets. Plus, the support team is the only “motorbike repair shop” they can go to, as they belong to the sole provider of the product in the world.
When a product is still small, everyone from the CEO will take care of the first few (brave) customers, from personal onboarding calls to answering support tickets (though I personally believe everyone should read support emails regardless). As the customer base expands, companies start to hire a dedicated customer success team and try to automate the customer-company interaction process as much as possible (unless you are Superhuman whose strategic objectives largely depend on 1-on-1 onboarding calls). Even so, we would never hire enough people to help everyone in need, especially when timezone, foreign languages, and edge cases are involved.
In other words, we need to handle idleness aversion coming from all corners of the world. We have a mass idleness aversion problem.
That’s where the communities shine.
Communities as the key to mass idleness aversion
When customers encounter a problem with the product, they will stop at no means for a fix. As long as they can find the solution, it doesn’t matter where it comes from. Communities, knowledge bases, and documentations are all the same when viewed under the lens of a problem solver.
The communities are, thereby, a part of the entire product experience. They are equally responsible for handling the idleness aversion of the customers as the product itself.
In some cases, they are even more effective.
First, online communities are comprised of people from different parts of the world, which addresses the timezone challenge of the in-house support team. When the support team is sleeping, their community fans half a day away from them are still awake and are ready to answer any questions of neighboring timezones. This model can amplify its own potential when based on instant-messaging platforms like Slack. Take dbt community for example: it grew from 1k to an incredible 10k members in just a few years and is currently one of the most engaged online communities for analytics engineers on earth — and a powerful lead magnet for dbt themselves. Here, analytics engineers do not just get their “motorbikes fixed”, but can also hang out and chat with people with similar problems, or pick the brains of “motorbike seniors”.
Second, the product creators can leverage the brains of the communities to fill in the gap of development. More specifically, the communities can produce what later can become a part of the product, which the product creators did not have the resource to validate the need for or to execute. A bright example of this is the Figma community. Figma allows its users to create plugins and share them on the community for free. So instead of waiting for Figma to release a feature, users can develop a solution themselves, then plug in Figma to use. That way, the users can solve edge cases that even the Figma team is unable to imagine, or hesitant to support. This is a brilliant move of Figma to keep focusing on their core customers, while pleasing the less ideal ones.
Third, the value of communities compounds over time. The more discussions take place, the more use cases are uncovered and the more likely a new customer can find their answer in the existing community’s questions. As the community accumulates more knowledge (thereby more organic traffic), it also gains more SEO juice, which helps it gain even more traffic. In other words, the longer an active community exists, the less time it takes a user to answer, the better idleness aversion is handled.
When the company grows to a point that the original community is no less than a massive pool of audiences hungry for answers, it gives rise to new communities. Product experts branch off from the original community to start their own, with their own rules and ways of conveying knowledge. For example, although Microsoft has built a large Excel community of well nearly 54k members, Kat Norton, a Tiktok influencer, still makes up to six figures a day sharing Excel tips on Tiktok (can you believe that?!). She has her own community of over a million followers on the platform, with each video “infused with as much creativity and fun as possible”.
Although new platforms might take different formats from the traditional forum-based, thread-by-thread one, they are still communities full of fans of the same product. And they are only born as an aftermath of the maturity of current communities.
Back to product managers
I believe building and managing communities are the roles of no one but product managers, or even CEOs. Who is better to keep the heat on with a customer than the person that understands the product inside out?
I have a strong feeling that communities should be built and maintained since the very early days of a startup. I have witnessed multiple stories of startups using communities as the leverage point to gain insights for iterations and traction. One such story was the journey of Knoetic and his founder — Quan — who bet on the community of CPOs and succeeded to resurrect his on-the-brink-of-destruction startup. I have not found any evidence of startups that only start building their communities at later stages, so I’d die to hear from you if you know one.
The community will inevitably grow with the startup, and it, again, is the responsibility of the product managers to figure out how best to intertwine the experience between the community and the product itself. This is what I’m still learning and observing at my current company. Hope I will be able to share something about this point soon.
Originally published at https://tuanmon.com on January 11, 2022.
