In today’s rapidly changing business environment, technology and business are becoming more and more closely combined, and product thinking is the bridge between the two. This article delves into how to grow from a technologist to a product manager with business insight through the author’s personal transformation story.
Preface: The Revelation of a Small Miscellaneous Society
On weekends, when I went shopping with my daughter, she would always pull me into a small shop called “Utility Club”. At first, I didn’t quite understand her obsession – it sold just the usual stationery and decorations: pens, notebooks, stickers, etc. But an hour later, watching my daughter excitedly choose various small items, I began to realize the hidden product wisdom behind this.
These seemingly ordinary stationery, through careful design and themed packaging, make recording daily life colorful and full of ritual. In the words of my daughter: “These things allow me to create my own life.” ”
I began to observe the customer base of the grocery store. As my daughter and her classmates observed: the main users are girls from the third grade of elementary school to junior high school, and a significant percentage of boys will buy horoscope-themed products, and even high school and college girls will be attracted to cute earrings and hair accessories. A small store can allow customers to shop for more than an hour.
This is a successful 2C product case. From stationery to cultural creativity, Chenguang has a clear positioning. Before the miscellaneous society landed, they had been polishing the theme of the living hall for three years.
This small observation made me think: the creation of a product may have stemmed from the discovery of a gap in the market, perhaps from insights into user pain points, or simply to validate a business hypothesis. But to create a viable product, there are far more complex factors to consider than we think.
My Story: The Path from Code to Product Transformation
First frustration: great code ≠ successful product
I once led a very good R&D team. At that time, I was convinced that as long as we build a high-quality product strictly according to the requirements documentation, success will come naturally.
However, reality gave me a blow. Our carefully crafted products have not been recognized by the market and customers. This was followed by large and small restructurings, team morale dropped, and I fell into deep confusion.
How can product managers do a good job in B-end digitalization?
All walks of life have taken advantage of the ride-hail of digital transformation and achieved the rapid development of the industry. Since B-end products are products that provide services for enterprises, how should enterprises ride the digital ride?
View details >
During that time, I often asked myself: Why do such a technologically good product fail? Where did we go wrong?
This setback made me realize that I needed to think from a higher dimension. I am eager to be involved in the process of product definition, not just the executor.
Opportunity: That interview at Microsoft
By chance, Microsoft is hiring a product manager with a background in open source software. I still remember that interview scene: the interviewer discussed with me on the blackboard how to help MSN users type their responses faster and better.
“Do you think we can provide some common response templates?” He asked.
“Sure,” I replied, “but more importantly, can we intelligently recommend possible responses based on the context of the conversation?” ”
That discussion made me feel the charm of product thinking for the first time – not simply adding features, but deeply understanding the real needs of users.
A painful and precious week: the awakening of the hypothetical framework
After joining Microsoft, I attended a week-long system training on “Customer-Driven Product Validation.” This week’s experience is still fresh in my memory.
On the first day, I confidently targeted my target user group: developers who were using an IDE. I assume they are bothered by issues such as slow startup of some IDEs, and therefore will be potential customers of our editor.
I was proactive in communicating with these developers on the phone, ready to validate my hypothesis. However, after a round of communication, I was confused.
“Slow start?” A senior developer smiled on the phone, “It’s a bit annoying indeed, but it’s a one-time problem when booting up in the morning.” In contrast, I am more concerned with the accuracy of code completion and the stability of debugging functions. ”
Another developer said, “To be honest, I’m used to the tools now. Unless the new editor can significantly improve the core functionality, it will be too expensive to learn. ”
I went from being confident to frustrated, and from that frustration I learned how to rebuild my cognition based on new information. That week, I went through a complete cycle from pain to pleasure, and also learned the assumption-proof-iterative product thinking framework.
Successful transformation: the birth of PaaS services for developers
After mastering the hypothetical framework, I began to systematically interview a large number of users, gradually identifying the customer base and real opportunity points. After several rounds of user interviews and product prototype testing, we finally built a PaaS service for developers.
This success gave me a deep understanding of the truth: the core competency of product managers is not to predict the future, but to quickly validate hypotheses and iterate based on feedback.
New challenges: the complexity of traditional industries
Due to some changes, I desperately hope that I can contribute to the field of life and health. So I left Microsoft to join the traditional industry. If the product management of the Internet industry is like driving on a highway, then the traditional industry is like driving on a complex mountain road – with a more diverse user base, more complex needs, and stricter regulatory requirements.
Sometimes, colleagues in the business department come to me with their initial vision for the business, such as: “We need a system to improve user productivity.” Faced with this kind of starting point, I often ask further: “What kind of users are they?” In what specific scenarios? What kind of changes do they expect to make to improve efficiency? Such conversations have not been uncommon in the past few years, and this is the typical challenge and exploration process faced by traditional industries when deeply understanding and defining user needs. Over the years, my business department and I have gradually established an effective collaboration model, learning how to explore real user needs and pain points with business partners in a complex environment.
mission
I conceived of recording my product manager diary/essay, with successful experiences, failed practices, and many helpless measures. There are many books on product design on the market, and there is no shortage of candidates in job interviews who talk about gathering customer needs and prioritizing methodologies. However, in real work, I often encounter situations where experienced product managers are overwhelmed in practice. There is a gap between theory and practice. I hope that the records I have compiled can be a bridge to this chasm.
The original idea was not just for the product manager, but for everyone who worked closely with the product manager: the business unit, the development and testing team, the marketing department, and the sales team. Only when everyone has product thinking can we truly build a viable product and continue to win the market and customers.
Our hero
In the following chapters, four fictional characters will accompany us as we explore the world of product management:
- Fumiko: MBA graduate, rich market experience, keen insight into business models, but sometimes too focused on competitors and neglecting user needs.
- Dawu: More than ten years of Internet product manager, experienced but sometimes sticking to traditional thinking, cautious about emerging user research methods.
- Xiaoshuang: 5 years of project experience, solid theoretical foundation, but easy to be anxious in the face of complex practical situations and eager to find standard answers.
- Full-time worker: Product manager who has transformed from an engineer with a deep technical background, but is still learning in terms of user communication and business understanding.
Their stories and confusions may be what you and I have experienced or are experiencing.
Next, let’s take a look at how to define a product and verify that it is worth building.
Chapter 1: User Groups Overview – Who Are You Fighting For?
1.1 Discover your users: Start with the confusion of “eighteen to sixty”
Xiaoshuang organized a user testing session for a new product. In the conference room, the product demo shows a beautiful interface and smooth operation on the big screen.
“Is the font too small?” The leader suddenly asked, “Can the elderly use it easily?” ”
“Does the typography take into account visually impaired users?” Another colleague added.
The leader turned to look at Xiaoshuang: “Who is our target user group?” ”
“Eighteen to sixty year olds. Xiaoshuang replied confidently.
The leader then asked: “Do the users in their fifties to sixties use the product themselves, or do their children operate it on their behalf?” ”
Silent.
The air in the conference room seemed to freeze. This seemingly simple question exposes a fundamental product management challenge: Do we really know our users? A seemingly broad definition of “user group” may actually hide a lack of awareness of the core users of the product.
In product design and development,User GroupRefers to those individuals who will use our products or services directly. They are the ultimate experiencers of product value and are at the heart of the product life cycle. Knowing who your users are is the first step to product success.
1.2 Analysis of the diversity and needs of user groups
Users are not a single, homogeneous concept. Even the same product may be used by users with different backgrounds and needs. In-depth analysis of the diversity of user groups is key to accurately defining product features.
1.2.1 Age and physiological characteristics: invisible need disorders
The challenges posed by user physiological characteristics to product design cannot be ignored. Users of different ages may have significant differences in cognitive ability, operating habits, audio-visual ability, and physical function.
Fumiko shared her story after Xiaoshuang’s user testing session. She was once in charge of a short video app for the public. The team initially found that the users were mainly young people, with a stylish and cool interface design and smooth and fast operation. But as the number of users grew, they found that a considerable number of middle-aged and elderly users were also trying to use it.
These middle-aged and older users gave feedback in the test:
- “The font is too small, and sometimes the title is not clear.”
- “The button icon is too abstract, I don’t know what it does.”
- “The sliding speed is too fast to react.”
This shows that even for the same product, users of different ages have different requirements for the details of product design. Younger people may pursue trends and efficiency, while older users focus more on clarity, legibility, and operational error tolerance. Changing the entire layout directly was too costly, and they ended up making the product more accessible to new demographics by introducing accessibility features such as voice input and control zoom mode.
1.2.2 User roles and responsibilities: same product, different worlds
In a complex B2B product, even within the same company, users with different roles will have completely different needs and usage scenarios for the product. Let’s take a look at the following case of the claims department of a large insurance company.
Zhang San and Li Si are senior auditors in the claims department, and they are tasked with a critical task: reviewing the medical reimbursement documents of the company’s customers. These reimbursement documents are large and complex, covering a wide range of medical items and expense types, and the review process requires not only a high level of meticulousness but also a must ensure that they are completed within the specified timeframe. Every day, Zhang San and Li Si’s desks were piled up with pending reimbursement documents. They need to verify the authenticity of invoices one by one, calculate the amount of compensation, and ensure that all data complies with the company’s policies and regulations. This process is not only cumbersome and time-consuming, but also prone to human error. Especially during the peak reimbursement period at the end of the year, the workload has surged, and overtime has become the norm. Still, they struggled to reduce customer response times to less than a week. Customer urging calls came one after another, putting immense pressure on the entire department.
Wang Wu, the head of the department, knows that this traditional work model is difficult to meet the company’s development needs. He realized that to solve this problem, process optimization and technological innovation must be started. He faced two options: one was to continue to hire more manpower, but this would lead to a sharp rise in costs and a significant increase in management difficulty; The second is to introduce digital solutions and use automation technology to undertake some of the tedious and repetitive audit and calculation work, thereby improving efficiency and accuracy. However, this solution needs to be supported by the company’s IT department, as the introduction of the new system will involve many key issues such as system deployment, operation and maintenance, and data security.
The core users of this example include:
- Claims auditors (users): For example, Zhang San and Li Si, who are the main operators of the system. They need to: Efficiently and accurately review handwritten reimbursement forms and verify invoice validity; Automatically calculate the compensation ratio to reduce manual errors; The system can clearly display processes and data to improve work efficiency; It is best to have an early warning mechanism to remind them to deal with urgent or abnormal reimbursement forms.
- Department Head (Purchaser): For example, Wang Wu, who is a key figure in deciding whether to introduce or upgrade the system. He cares about: the cost-effectiveness and ROI of the system; whether it can improve the overall efficiency of the team and reduce the error rate; Can you provide team performance data and approval process bottleneck analysis?
- Colleagues in the IT department (influencers/users): They are responsible for the deployment, maintenance, and security of the system. Their needs revolve around: ease of deployment and maintenance of the system; standardization and stability of data interfaces; monitoring and alarm mechanism of system failure; Data security and compliance guarantees. Each character has a different focus.
If you want to design a successful product, you must fully consider the needs of different roles. We had not fully considered the IT department’s needs for system deployment in the early stages, resulting in slow progress after product launch, and almost missed a valuable market opportunity.
1.3 Users, buyers, and customers: three different concepts
In product management, we often confuse three concepts, which directly affect our understanding of product value and the formulation of business strategies:
- User: The individual who ultimately uses the product and is the real experiencer of the product’s value. They care about whether the product is easy to use, whether it is functional, and whether the experience is enjoyable.
- Buyer: The individual or entity that actually decides and completes the purchase, holding the budget and decision-making power. They care about product price/performance, ROI, compliance, deployment costs, and more.
- Customer: This is a broader concept that includes users and buyers, and is the core object of our business model. It could be an individual, a family, or a business.
Judging from the case of insurance claims in the previous chapter, this insurance company is a customer. Wang Wu not only considers ROI from the company’s perspective but also ensures that the new system can seamlessly integrate with the company’s existing business processes.
Let’s take another example from life: I went to the toy store as a mother to buy toys for my children. In this scenario:
- My child is a user
- I am a Buyer
- Our family (or my family) constitutes the Customer
Why is this distinction important? Because different characters focus on completely different value points:
- Children care about being fun, fun, and cool.
- I care about cost-effectiveness, safety, and education.
If the product manager focuses on only one of these roles, the product is likely to fail. The success of a product often needs to meet both the experience needs of users and the business needs of buyers.
1.4 Stage division and characteristics of customer groups: product adoption life cycle
The success of your product is not just about the number of users, but also about who accepts and uses your product when, and in what way. Everett M. Rogers describes five types of product adopters in Diffusion of Innovations, which are critical to understanding customer segments at different stages:
Innovators (2.5%)
- Characteristics: Willing to take risks, keen to try new things, curious about the technology itself, and don’t mind the initial defects of the product. They are pioneers in the industry.
- Product strategy: Provide MVPs that are not fully perfect but attractive enough, focusing on technological innovation and uniqueness. Get early feedback through them.
Early Adopters (13.5%)
- Characteristics: are opinion leaders, open to new things but more cautious, willing to pay a premium for innovation. They focus on the competitive advantages and solutions that products bring.
- Product strategy: Optimize on the basis of MVP, provide a more stable product version, and focus on solving practical problems.
Early Majority, 34%
- Characteristics: Cautious but open, need to see success stories and market validation before accepting new products. They focus on practicality, reliability, and ease of use. It is the key to product scale.
- Product strategy: Provide stable, mature, and easy-to-use products, focusing on user experience and functional improvement.
Late Majority, 34%
- Characteristics: Skeptical and will only change driven by peer pressure or changes in the external environment (such as the inability of the old scheme to meet the demand). They focus on cost-effectiveness and risk control and need a complete support system.
- Product strategy: The product needs to be highly stable and mature, providing comprehensive solutions and customer support.
Laggards, 16%
- Characteristics: Adherence to traditional methods and the lowest acceptance of change. Change only when necessary, such as the complete elimination of the old scheme.
- Product strategy: Provide ultimate stability and reliability to ensure the lowest migration cost.
Generally speaking, it may take a long time for us to observe the characteristics of adopters at different stages for a product. However, in the last three months, DeepSeek’s adoption and deployment has been an exception. We saw that more than 700 hospitals across the country had deployed DeepSeek, a number that was quite staggering in a short period of time. However, in terms of proportion, there are more than 30,000 hospitals across the country, and the deployment rate of DeepSeek is about 2-3%, which means that the current adopters are basically in the stage of innovators and some early adopters.
Innovators and early adopters are highly sensitive to new technologies and are willing to take risks and try new solutions. With its powerful features and innovative technology, DeepSeek has quickly captured the attention of these pioneering groups. For example, some hospitals with deep accumulation in the field of artificial intelligence quickly integrated DeepSeek into their systems, optimizing algorithms to improve medical efficiency and exploring diagnostics, scientific research and other scenarios. These early success stories have laid a good foundation for AI empowerment, but further efforts are still needed to achieve wider market penetration, including the advancement of corresponding laws and regulations.
1.5 Product strategy at different stages: who is designed for and what value is provided
Understanding the different types of adopters can help us develop a more precise product strategy and think about what value proposition, problem solving, and specific value the product should provide to customers at different stages.
For 2C products:
- If the innovator and early adopter are older users (e.g., a smart health watch for the elderly), then the product design should prioritize basic usability such as large fonts, simple operation, voice interaction, etc. Products need to address their health concerns and fears of operating smart devices, bringing a convenient health management experience and a sense of security.
- If the innovator and early adopter are young (e.g., a trendy social app), more innovative features, cool designs, and personalized experiences can be introduced. Products need to address their needs for self-expression, social interaction, and trend-chasing, bringing a unique lifestyle and sense of community belonging.
For 2B products:
- If the early adopters are large enterprises (e.g., large enterprise-level SaaS), security and compliance are top priorities, and the product needs to be highly customizable and integrated; The product needs to solve the pain points of their existing system inefficiency and data silos, bringing business value in reducing costs and improving efficiency.
- If the early stage is mostly small businesses (e.g., financial management tools for startups), cost and ease of use are more important, and products need to be lightweight and ready to use right out of the box; The product needs to solve their pain points of irregular financial management and high labor costs, and bring efficient, convenient and economical solutions.
1.6 Chapter Summary: Precise positioning to win the minds of users
The user group is the foundation of the product, and the customer group is the source of business success. This chapter highlights the following core concepts:
- User group definition: Clarify who is the direct user of the product.
- User diversity: Recognize the differences in age, physiology, roles, responsibilities, etc. of users, and design differentiation accordingly.
- User, Buyer, and Customer Separation: Understand the concerns of different personas to balance user experience and business value.
- Characteristics of customers at different stages of product life cycle: Formulate corresponding product strategies according to the characteristics of customers at different stages. Ensure that at different stages of the product lifecycle, products provide unique value that matches customer needs.
After clarifying the customer groups and their phased characteristics, we can’t help but think about what kind of market environment these users live in? What unmet questions do they face? What solutions do existing markets offer, but what are the shortcomings? In the next step, we will delve into how to truly “enter” the world of users and customers and explore their real needs through systematic research methods.
