The previous article shared the daily workflow of the product manager for the first time, and today I share the way of thinking of the product manager for the first time, the main answer: How do product managers think about problems? In other words, the product manager’s mindset.
To be honest, before I transformed into a product manager, I had a struggle with astronauts due to the limitations of my understanding of the product manager position – I only knew its name, didn’t know its roots, and couldn’t talk about the way of thinking and its value.
When I look back on my product career over the past ten years, I have some understanding of the way product managers think, so I “pulled them out” from my head, hoping to inspire you who are interested in the position of product manager.
What is a mindset?
The way of thinking is “how do you get used to thinking about problems”, just like some people are used to eating with chopsticks, and some people are used to using forks – although they can all eat enough, the process is different.
It is a scientific but mysterious soft ability, just like Zhang Wuji, when you learn the Nine Yang Divine Skill and the Star Absorption Technique, you feel that you are very powerful, and the actual most powerful martial art is Tai Chi – let you forget all the moves and cheats, just move with your heart, change with the situation, this is the high-level gameplay of the way of thinking.
To achieve these three challenges, product managers will only continue to appreciate
Good product managers are very scarce, and product managers who understand users, business, and data are still in demand when they go out of the Internet. On the contrary, if you only do simple communication, inefficient execution, and shallow thinking, I am afraid that you will not be able to go through the torrent of the next 3-5 years.
View details >
Product managers are synonymous with the way of thinking, how you are used to thinking about problems determines your upper limit.
Today, let’s take a look at it from two perspectives: a high-level global perspective and a beginner-level practical perspective, and the focus will fall on the latter (you know why, hahaha).
The first perspective is the higher-order global perspective. Give you an initial understanding of the global mindset required by product managers (as shown below), and that’s it—freezing three feet is not a day’s cold, and you can’t become a fat person in one bite – they all warn us to do things step by step.
The second perspective is the primary practical perspective.
The panorama of thinking may discourage you, but I am also ignorant in actual work, slowly tempered, and even now, there are still many ways of thinking (such as business thinking, essential thinking, framework thinking, etc.), which are not very proficient. The reason is also simple, that is, it is not used much in actual work – sharpshooters are fed by bullets.
Let’s focus on the five ways of thinking that junior product managers frequently use, so that you can be targeted on the road to transformation.
They are: user thinking, problem thinking, goal-oriented (priority thinking), data thinking, and growth thinking.
User thinking – the starting point of business is the benefit of users
When enterprises write “user first” into their values, this is not only a slogan, but also the underlying logic of product creation. As a bridge connecting business goals and user needs, product managers practice user thinking is not only the embodiment of corporate values, but also the core methodology for exploring the essence of demand.
In Yu Jun’s product methodology, two principles point directly to the core of user thinking:
- “Product managers are first and foremost users”: product managers are required to jump out of their professional identity, experience products from the perspective of real users, and perceive pain points and itches;
- “Look at problems from the user’s perspective”: Emphasize the abandonment of “egocentrism” and shift the decision-making benchmark from “I think” to “user needs”.
The essence of this thinking is to see the user as the starting point of the product definition rather than the end point – not to passively meet the needs, but to actively deconstruct the real motivations behind the requirements.
How to train user thinking? In the field of Internet products, the practical model proposed by Tencent is of great reference value:
- 10 user in-depth visits: Conduct in-depth conversations with 10 core users every month to explore hidden needs (such as discovering process redundancy issues through user complaints about “complex operations”).
- 100 user dynamic tracking: follow 100 users’ blogs, community speeches, etc., to capture scenario-based feedback (for example, users post screenshots of “clock-in failure” to expose the logical flaws in the positioning of the attendance system);
- 1000 experience data collection: Summarize 1000 experience feedback through questionnaires, logs, and other channels, and use data to trace user portraits (for example, 30% of negative reviews are concentrated in “export function is hard to find”).
When designing for B-end products, user thinking is also crucial. You can take:
- Rotation: Product managers participate in customer job operations (such as the actual work of resident tutors or attendance specialists) to understand the real stuck points in the business chain;
- Scenario-based research: Go deep into the customer’s office site and record the usage scenarios of different roles (decision-makers/executors/managers) (e.g., HR opens three systems at the same time during salary accounting).
From the C-end to the B-side, the user group and needs are changing, but the user’s thinking remains the same, and the core is always to become the “user’s translator”, stand from the user’s perspective, transform the appearance into the underlying demand, and make the product the best solution to the user’s problem.
Problem thinking – Falling in love with problems, not solutions
There is an instinct latent in human nature – when faced with problems, we often subconsciously choose to escape or find shortcuts. But the core mission of product managers is to break this instinct and learn to “dance with problems”.
The essence of this mindset is to see the “problem” as the starting point for creating value, rather than rushing to a seemingly perfect solution.
The essence of product work is to establish a dynamic balance between [problem-demand-solution]:
- Problem: The user’s unmet pain points or scenario contradictions (such as the attendance specialist’s difficulty in judging the real reason for the employee’s abnormal attendance);
- Requirements: The core claim behind the problem (e.g., “Confirm the authenticity of attendance” is essentially “reduce manual verification costs”)
- Solution: Specific functions or services designed for requirements (e.g., “Automatic Exception Alert + Electronic Signature Confirmation” function, turning passive verification into active collaboration)
At the same time, you need to distinguish between “needs” and “solutions”, which are the litmus test of problem thinking.
When users directly put forward “functional demands”, there are often hidden presumptions of “solutions” rather than real problems. For example:
- The user said: “Need to import attachments in batches”, but in fact it is expressing the problem of “inefficient data entry”;
- Users suggest that “I want to export abnormal attendance results”, which may be due to the need for “inefficient data query”.
At this time, the product manager needs to play the role of “problem detective”: not be fooled by the superficial solution, and dig into the essence by asking the question, “Why do we need to import in bulk?” “What is the purpose of exporting results?” , so as to transform the “solution demand” into a “problem definition”, and then design a lower-level solution based on the real problem.
Goal-oriented product management philosophy
Product managers are often jokingly referred to as “miscellaneous specialists with the title of ‘manager'” – although they hold the decision-making power of product direction, they do not have the jurisdiction of personnel in traditional management positions.
In the project environment with limited resources and multi-party games, goal orientation is like a compass, which can not only help you penetrate the question of “why do it”, but also condense fragmented needs, resources and disputes, and transaction priorities into a clear action path.
When product advancement encounters multi-party challenges, the clear goal is the only “consensus converter”:
- In the face of the boss’s resource question: “Why invest manpower in the scheduling function?” → responded quantitatively with goals: “Currently, 30% of customers are lost due to low scheduling efficiency, and it is expected to increase customer retention by 10% after optimization”;
- In response to the customer’s scheduling question: “Why haven’t my requirements been done yet?” → Prioritized by goal: “Demand A affects 80% of the attendance efficiency of core users, demand B belongs to the edge scenario, and the current goal focuses on improving the efficiency of core processes”;
- Resolve the pressure of competing products in sales: “Competing products have this function, why don’t we do it?” → Break the game with goal differentiation: “The current goal is to create the advantage of ‘lightweight attendance’, which is full of functions but high complexity, which conflicts with our goal of ‘3-minute rapid scheduling'”;
- Convince R&D cost concerns: “The cost of technology implementation is too high” → Evaluate from the target ROI: “Investing 20 people / month to implement this function is expected to solve the needs of 20 customers, resulting in a 5% increase in customer renewal rate, which is worth the investment”.
True goal-oriented is to inject “goals” into every decision-making process:
- During the requirements review: “whether it supports the core objectives” is used as the screening criterion, rather than “the level of the requirements proposer”;
- When competing for resources: use “target contribution” to persuade the boss: “Investing in Project A can directly achieve 30% of the annual revenue target, while Project B only contributes 5%”;
- When the solution is compromised: The “target bottom line” is used as the boundary: “The aesthetics of the interface can be compromised, but the accuracy of the scheduling algorithm must reach more than 95%, which is the target red line”.
From resource leverage at the time of project establishment to dispute reconciliation during implementation, the essence of goal-oriented is to use “result definition” to push back “process selection”, so that product managers can still lead the team through uncertainty and reach the final business and user value as a “target owner” without administrative power.
Data Thinking – From “Perspective-Driven” to “Fact-Driven”
Human beings are naturally accustomed to interpreting the world with “perspectives”, but in product decision-making, subjective judgment is often the root cause of deviation – the perspective of product managers may not be more accurate than users, and the technical obsession of R&D may also deviate from real needs. When “I think” replaces “data proof”, product iteration inevitably falls into the trap of “self-optimization”.
Data thinking is not simply “talking with numbers”, but establishing a set of decision-making logic based on objective facts:
- Opinion expression: abandon the assumption that “users will definitely like this function” and change it to “user survey shows that 65% of catering customers expect intelligent scheduling function”;
- Goal setting: Jump out of the vague direction of “improving customer retention” and clarify that “Q3 reduces the churn rate of catering customers from 40% to 34% through scheduling efficiency optimization”;
- Idea verification: Avoid the subjective judgment of “I think the process is fine”, and use “AB test shows that the task completion rate of option A is 22% higher than that of plan B” as the basis;
- Demand priority: Avoid “sales say this feature is important, do it first”, use “data shows that this function covers 80% of high-frequency usage scenarios, priority TOP1”;
- Effect evaluation: Avoid “I feel that the effect of this revision is not bad” and replace it with “The conversion rate of the core process increased by 18% after the revision, and the user satisfaction NPS +12 points” was instead.
When data collection is limited (such as the cold start period of a new product), data thinking requires a shift to “scenario-based realism”:
- Offline squatting method: Observe the catering store for 3 days, and record the real operation scenario of the waiter “frequently switching tables when scheduling with Excel, which takes an average of 2.1 hours”;
- User log analysis: Collected the operation records of 10 workers in the manufacturing factory, and found that “the overtime application process needs to jump to 3 systems, resulting in 33% of the applications being missed”;
- Storyboard restoration: Use graphics and text to record the communication between customer service and customers, and extract the core contradiction that “70% of complaints are concentrated in ‘attendance data cannot be connected to the financial system'”.
True data thinking requires a dialectical perspective and vigilance against the problems of “data-only” and “survivor bias”. Sometimes, data can be a hindrance to your decision-making, especially in the innovative product phase.
Growth mindset – a two-way evolution engine between products and individuals
“All things grow at a time” – this natural law also applies in the field of products. Whether it is the iterative evolution of a phenomenal product or the ability leap of a product manager from novice to expert, the growth mindset plays the role of a game-changer: it rejects the illusion of “overnight success” and takes “continuous evolution” as the underlying logic to find breakthroughs in dynamic changes.
The first is the product perspective. The birth of excellent products is never a flash of inspiration, but follows the scientific law of “growth iteration”:
1. Seed stage: Focus on core root growth
WeChat version 1.0 only retains the basic functions of “instant messaging”, just like a small tree taking root, first solving the core needs of “user communication”, rather than blindly piling up complex functions such as circles of friends and mini programs;
Douyin initially made a single breakthrough with “15-second music short videos”, and gradually expanded ecological branches such as live broadcast and e-commerce after the algorithm recommendation mechanism matured.
2. Growth Phase: Flexible iteration based on feedback
Data-driven evolution: An attendance product found that “30% of users gave up using the scheduling function”, and found that “shift rule configuration complexity” was the main reason through burying data, so the configuration step was simplified from 7 steps to 3 steps, and the usage rate increased by 45%;
Scenario-based extension: DingTalk started from “enterprise IM” and gradually grew the “intelligent personnel” module according to the coherent needs of users for “attendance + approval + salary” in the process of serving small and medium-sized enterprises.
3. Maturity period: ecological breaking circle growth
Starting from the single business of “group buying”, Meituan gradually expands its takeaway, hotel, tourism and other businesses through the extension of the “user-to-store consumption” scenario, forming a “local life service ecological tree”;
The core of a growth mindset is not to pursue a “perfect initial version”, but to establish a growth mechanism of “problem collection, solution verification, and rapid iteration”, just like a tree adjusts its branch and leaf density according to the climatic environment.
We can take two specific tools:
- Version evolution map: follow the end-to-end and comprehensive design; From beginning to end, the minimum closed-loop methodology, like the rings of a record tree, marks the core problems solved by each version with a timeline (such as “V1.0 solves attendance and clock-in, V2.0 solves scheduling efficiency, V3.0 solves salary docking”);
- User growth profile: Track the full-cycle behavior of typical users from “trial period” to “deep dependence”, and find that “when the enterprise grows from 50 to 200 people, the demand for attendance system shifts from ‘clock-in’ to ‘intelligent scheduling + permission management'”.
The second is the personal perspective. The transformation of product managers from “functional executors” to “strategic operators” also needs to break the perception of “fixed capability boundaries”:
1. Novice period: Accumulate growth potential energy in a single point breakthrough
Starting from “designing an attendance approval process”, the “abnormal approval pass rate” has been improved from 60% to 92% through 3 version iterations, and the design logic of “user operation path” has been understood.
Growth mindset requirements: do not despise “small functions”, but refine universal methods in each requirement implementation (such as “how to use flow charts to disassemble complex businesses”).
2. Advanced stage: expand the radius of ability in cross-field practice
Participate in the whole process from “demand research” to “online review”, and actively learn financial rules and system docking logic when responsible for the “salary calculation module”, forming a composite perspective of “business + technology + data”;
In order to understand manufacturing customers, a B-end product manager stayed in the factory for 3 weeks to learn the scheduling process from production line workers, and transformed the “workshop practical scenario” into an “error prevention mechanism” in product design, which is a typical “scenario growth” learning.
3. Expert period: Reconstruct the cognitive framework in the midst of industry changes
When AI technology emerged, it abandoned the “sticking to the traditional attendance model” and took the initiative to study the application possibilities of “face recognition + intelligent scheduling algorithm”, leading the team to transform from a “tool-based product” to an “AI-enabled platform”;
The ultimate embodiment of growth thinking: treat “change” as nourishment – whether it is technological iteration, industry policy or user habit changes, it can be transformed into new branches of personal ability trees.
Specifically, it is recommended that you have two gadgets:
- Capability gap radar map: Regularly evaluate the capability values of “user understanding, business understanding, data analysis, design ability” and other dimensions, such as finding weak “technical architecture cognition”, and formulating a growth plan of “studying 1 technical white paper per month”;
- Review the growth log: Treat each project landing as an irrigation of the “ability sapling”, record that “this iteration learned ‘how to persuade R&D investment with ROI'”, forming a reusable experience library and methodology.
Leave an interactive assignment
Today I mainly take you to take a quick look at the five foundations and commonly used ways of thinking of product manager positions: user thinking, problem thinking, goal orientation, data thinking, and growth thinking.
If you are interested in product managers and plan to transform, you can try to find one (or more) cases in your existing work or life, and train these ways of thinking in advance, so that you can be prepared during interviews or transformations.
Scenario 1: If you are a college student, you can organize a lecture in a university club
User Thinking: The audience is the students, what do they really want to hear? (For example, “job search skills” or “industry gossip”?) How to verify? ）
Problem thinking: Why was the attendance rate of lectures low last year? Is it a propaganda problem, a time conflict, or an unattractive theme?
Goal-oriented: What is the core goal of this lecture? (Members of the new club?) Increase impact? Or pure dry goods sharing? ）
Data Thinking: How to Measure Success? ——The number of attendees, the number of interactive questions, and the number of follow-up club registrations?
Growth mindset: If the lecture is not effective, should you give up directly, or optimize the publicity channel/content form after review?
Scenario 2: If you are a professional, you can review a failed project that you have personally experienced
User Mindset: Who is the target user of the project? Who are the customers? What core needs of them are not being met?
Problem thinking: What is the biggest problem facing users/customers right now? How are they solving it now?
Goal-oriented: What is the goal of this project? How to measure it? What is the reason for the failure?
Data thinking: Can data metrics be used to measure the achievement of goals? If not, why not? (Not considered?) What is not done? Unquantifiable? ）
Growth mindset: If you are the project leader and give you another chance, how should you adjust?
Scenario 3: If you are planning to lose weight, make a fitness plan for yourself
User thinking: Your “user” is yourself – do you really need to lose weight, or do you just want to relieve sedentary fatigue?
Problem thinking: What are the reasons for fitness failures in the past? (Short on time?) Aim too high? Lack of positive feedback? ）
Goal-oriented: Is the goal to “lose 5kg in 3 months” or “develop the habit of exercising 3 times a week”?
Data thinking: Record weight, body fat, exercise duration, which data can best reflect the effect?
Growth mindset: If you slack off in the middle, do you think “I don’t have perseverance”, or adjust your plan (such as changing the type of exercise)?
