#027 - PM Lessons by Meituan Co-Founder - Pt 21: Needs - The Microscopic Needs
9 mins read - demand thinking, user research, can you even product?
Hi! It’s been a while. I’ve been focused on building my product so I had less time for writing. My apologies for the lack of update. Despite that, people continue to find this newsletter valuable and a lot of new friends just discovered it. Welcome! Shout out to Lillian’s amazing newsletter Chinese Characteristics. I’ve also realized that a better mode for learning is probably in an equilibrium state of input and output. So yes, I should be writing more. Thank you for being on this journey with me!
The Microscopic Needs
What we have covered in the previous lectures are the Big Needs that create a new industry category. Recognizing Small Needs is equally difficult because it’s very hard for us to see what those needs really are.
Generally speaking, almost no user will directly tell you what his/her needs really are. What they’re saying is usually demands or requirements, and rarely do they speak to their needs. We’re not talking about the economic need here (i.e. quantity demand at a certain price), but the underlying reason that triggered the idea in their mind to want something / seek a solution. For example, the company’s sales team may say that they need a CRM (customer relationship management). But CRM is quite a complicated product, you can’t be making a Salesforce for them right?
(Note: We may be a little too punctilious about the wording of needs, demands, requirements, wants, etc. here and this might still sound confusing to you. How I understood this point here better is actually through the language of Supply and Demand. Demand Thinking - Episode 1: Feature requests aren’t demand. Watch from 0:00 to 9:47.
When your users say they need a CRM, or permission controls in a project management software, these kinds of feature requests may sound like needs or demand from the users, but they’re actually supply-side ideas - they already have the solutions in mind. It’s no different from the ideas that a product team or higher management think will work. Or in design language, form vs. function.)
On User Research
In our daily lives, a girl in a relationship probably won’t say directly what her needs are. She may just be mad sometimes. If you can figure out why, that’s when a happy life starts. At least, that’s the case for me, haha.
At work, clients probably can’t tell you what their real needs are either. Like what Henry Ford said, “If I had asked people what they wanted, they would have said faster horses.”
Well, you say, I’m a product manager, I’ll conduct user research to find out for sure. But user research can be tricky. In user research, there’s a thing called the Hawthorne Effect.
During Frederick W. Taylor’s Scientific Management (or Taylorism) era, they conducted numerous studies to find out how to improve the efficiency of assembly line workers. One such study varies the light intensity at the manufacturing plant to see if it affects workers’ productivity. And they found at both higher or lower levels of light, workers’ productivity had increased.
It wasn’t because the current light intensity was the worst for productivity, but as workers knew they were being observed, they worked a little harder for that period of time. These kinds of confounds and artifacts are common in social science experiments.
Human psychology is a highly intricate system. What you can observe is the final outcome. You have no idea how many twists and turns it had gone through inside someone’s mind before being manifested in the physical world. You can’t tell whether it’s the truth or a lie. Sometimes, the person you’re asking doesn't know either.
Suppose you’re sitting face-to-face with another person. If you stay silent, the other party might just start talking. Many people would be willing to say anything to break the awkward silence.
If your product experience is not great, conducting user research may not help you much, because rarely can users truthfully feedback on their product experiences. For one, if others can use the product but I can’t, it makes me look stupid. So in the feedback, I probably won’t give too many details in how I operated, avoiding things that reflect badly on me.
When we encounter setbacks in life or work, telling the story may make us feel super vulnerable. We’d be too embarrassed to recount the story truthfully and what we let out is just a mood.
There’s an app for that?
Sometimes, a company facing some internal problems may ask the product managers to make a product to fix everything. However, if the underlying problem is really a management problem and not a tools problem, then you won’t be able to make a good product. Because you don’t understand the real need for the product.
Of course, it’s not very realistic to expect your boss to be a great leader. The law of gravity in management is the Peter principle: people in a hierarchy tend to rise to “a level of respective incompetence” - they are promoted until they reach a level at which they are no longer competent.
Can you even product?
Meituan initially had 3 versions of CRM and it was due for an update. I was in charge of product and marketing, so this was under my purview. However, I was having too much fun with marketing and PR, so I had no time for product. As such, I delegated the task of developing a new CRM to willing subordinates.
Once they were done, the product was not usable at all. Even after another round of modification, it’s still not up to expectation. In the end, even Wang Xing (CEO of Meituan) questioned me, “Dude, can you even product?!”
“Can you make a good product?” is a question that a product manager will face throughout his career. Even if you’ve reached the god-level like Allen Zhang (product leader for WeChat), every day, a billion people want to teach him how to make a good product.
(Note: Here is a popular rant on WeChat’s UI - “In 10 years, Allen Zhang made WeChat an ugly monster”. It’s in Chinese but I think through the browser translation you’d get the picture. Below, I translated one picture for illustration.)
In the entire Chinese internet industry, there are no more than 20 people who have earned the industry recognition that they can make good products. So I had no other option but to work on the CRM myself. Luckily, at that time (late 2011), we were able to convince “Ah Gan” from Alibaba to join Meituan.
(Note: Gan Jiawei, employee No.67, ex-VP of sales at Alibaba, ex-COO of Meituan-Dianping, now a partner at Hillhouse Capital. Regarded as one of the best in B2B sales in the Chinese tech industry.)
I told Ah Gan that the previous two versions have failed and it’s critical for us to have a great CRM software. We only have a dozen product managers at our disposal, so I made a list of requirements to let Ah Gan choose 3 from. After we were done, the CRM product we have was the best in the group buy industry.
(Note: Some context for the importance of the CRM. Ah Gan has a formula for sales: Revenue = Customer Unit Price * Prospects Density * Area * Efficient of Customer Visits * Close Rate. At Alibaba, their customers were the suppliers of goods, and they were located in industrial parks and the like, so they’re highly dispersed. Their customer unit price was ¥50K/year, which was considered high, but the prospects density was low and it’s hard to close. As such, the sales reps need to cover a lot of ground, sometimes even across provinces to find customers. Towards the end, each sales rep served about 50 customers, and with a unit price of ¥20K/year - the product became cheaper as is the case for tech, the avg. annual sales per rep was a respectable ¥1M/year.
For Meituan, it’s a different case. During the “Thousand Groupons War”, Meituan’s customer unit price was almost zero, because merchants pay for performance, not upfront. However, their prospects density was super high - restaurants and service providers are clustered in urban areas, so they were relatively easier to visit and easier to convert. For a B2B business, the salespeople are its production capital and you have control over two variables - scale and efficiency.
When Ah Gan joined Meituan in Nov 2011, the sales team was about 1,000 and they had about 20-30K merchants on the platform, and on average, each rep served 27 merchants. That’s much lower than Alibaba, which has a higher customer unit price. Based on the expected customer unit price and prospects density, if Meituan’s CRM can support, each sales rep should easily serve over 200 merchants.
As for how big Meituan needed to be, if they’re talking about serving local services providers all over the country, which was estimated to be over 6 million in the country at that time, with a 200-to-1 merchant to rep ratio, their headcount would be 20-30K people.
At IPO, Meituan had 28,458 employees in sales, marketing, and business development and 4.4 million active merchants.)
You can only guess
This is the “rough and ready” that we talked about before. Why we couldn’t make a good CRM is because people from product, sales, business intelligence, HQ, and the local teams all want different functionalities. They also have different ideas on how to manage the sales team. Even if different people like Ah Gan and Wang Xing have made the same requirement, they may have used the same words to convey different expectations. And the end product didn’t meet either one’s expectation.
A lot of the time, you can only guess what people’s needs are. Therefore, the accuracy of your guesses is very important. One way of guessing is to offer options for the product features and based on people’s selection of the options to deduce the underlying need.
Like when girlfriends are mad, the boyfriends keep asking what they want to do, where they want to go, etc. One possibility is that through the elimination of wrong options, you arrive at what she really wants. The other possibility is after exhausting all the options, you find that her needs can’t be satisfied. Thus, we have to continuously offer options until we find what users really want.
For the longest time, Meituan has always wanted to make an internal tool to score merchants. At first glance, it should be simple enough to build and many departments do feel the need for such a tool. However, when the first version was out, no one was satisfied.
So I asked Ah Gan, do we what to separate merchants with high and low customer satisfaction rates? He said nope. Then I asked, is it to separate merchants with high sales and low sales? No again.
Finally, we figured out that the quality control team doesn’t want to separate merchants by sales or customer satisfaction, they want to isolate the merchants who have taken advance payments but can’t pay Meituan back. They are the most likely to leave the platform and hurt the company. For the same “merchant scoring” need, what the sales team wants and what the quality control team wants are totally different.
How to listen to customers
It’s like this not just internally within the company, where different teams want different things, external customers are the same. It’s common to hear from your customers that your product lacks a certain feature. But when you actually made that feature, they may not necessarily use it. They only said so because you asked. They just may not be your target customer.
Customers may potentially have real answers, but it’s difficult to dig them out from them. If the product is hard to use, they may not directly say it, as it may make them look stupid or it may embarrass you.
In the early days of building a product, it’s probably futile to ask people who don’t use the product why they don’t use it. The more effective method is to ask the people who use the product. These people must have a certain degree of approval for your product, but they might just be facing some problems with it.
(Note: In the Segmenting section, we’ve mentioned Superhuman’s engine to find PMF. They first segmented out the users who aren’t of the target profiles, then they focused on the users who would be very disappointed or somewhat disappointed if they could no longer use the product. Same wisdom on whose feedback you should listen to.)
When we talk about needs, there are some misunderstandings that need to be clarified. Many people would be quick to propose solutions. (Note: supply-thinking.) But solutions aren’t the need itself. Like in the CRM example, there can be countless requirements for the CRM. But at that time, the ones that really mattered to Meituan were only a few.
Find the article insightful? Please subscribe to receive more learnings from Chinese Internet companies and I’d appreciate it if you can leave a comment or help spread the word!