This is a set of notes from an AI Product Manager Professional Certificate course under the AIPMM (Association of International Product Marketing and Management) system. It is designed for people who "want to get started or systematize their PM knowledge", but the audience for this set of notes is PMs who are already working in product — so I only extract the "naming frameworks / models / checklists worth an experienced PM keeping handy", skip all the beginner literacy sections (what a PM does), and reframe the content around "what directly applicable scaffolds this course provides".
Reorganized into six sections:① PM Roles and Responsibilities(including differences for AI PMs) → ② Product Lifecycle Methods → ③ Strategy and Innovation Frameworks → ④ Stakeholder Collaboration and Communication Styles → ⑤ Business and Commercialization → ⑥ Career Development. Each section provides "framework name + Why + when to use / counterexample".
Division of labor with existing wiki content: For empirical disagreements between PM and UX on "who owns this task", RACI implementation details, and PLG growth, see NNGroup Product and UX Collaboration (Empirical PM×UX Responsibility Disagreements · Root Causes of Overlapping Work · PM Role Models · RACI Division of Labor · Five Collaboration Recommendations · UXers Thinking Like Product Leaders · PLG · Glossary); for specific tactics for AI PM collaboration with engineering/design, see PM / Design / Eng Trio Collaboration in the AI Era (Cross-Author Thematic Synthesis). This article does not rewrite those topics, and only points to them where relevant — the positioning of this article is framework dictionary + methodology skeleton.
1. PM Roles and Responsibilities
1.1 Definition and Boundaries of Product Management (Conceive→Retire)
Framework: Product management = the discipline of being responsible for a product's full lifecycle, covering 7 actions — Conceive → Plan → Develop → Test → Launch → Deliver → Retire. It essentially answers three questions:what product to build, why build it, and how to keep it creating value.
Two orthogonal distinctions, useful to remember for interviews and organizational conversations:
- Internal vs External PM: Internal PMs build internal company tools (HRIS / CRM / ERP), with the goal of improving efficiency; external PMs build customer-facing products (physical / digital / SaaS), with the goal of driving revenue.
- Upstream vs Downstream: Upstream is strategy-focused (product strategy / roadmap / new product planning / product portfolio, "deciding what to build"); downstream is execution- and commercialization-focused (lifecycle management / launch operations / go-to-market / sales enablement, focused on Growth/Maturity/Decline, "taking the product to market and operating it").
Why / When to use: There is no standard answer for organizational structure (it is affected by company size / industry / culture / complexity), so when you join a new company, the first thing to do is locate which quadrant of internal/external × upstream/downstream you fall into — this determines whether your success metrics are "efficiency" or "revenue", "direction" or "operations".Counterexample: An upstream strategic PM role that evaluates you on downstream launch and operations metrics is a mismatch; you should clarify this before joining.
1.2 PM ≠ Project Manager (Product Manager ≠ Project Manager)
This is the dividing line the entire course emphasizes repeatedly, nailed down in one sentence:The PM decides "what to do / why (What / Why)", and the Project Manager (PgM) is responsible for "how to do it / when to deliver (How / When)". PM = business owner, PgM = delivery owner.
| Dimension | Product Manager (PM) | Project Manager (PgM) |
|---|---|---|
| Core responsibility | Manages the product | Manages the project |
| Time horizon | Long-term (several years) | Short-term (several weeks/months) |
| Start → End | Product concept → product retirement | After product definition → project completion |
| What is managed | Users / market / business | Schedule / budget / scope |
| Success criteria | Product success (revenue/share/retention/satisfaction) | Project success (on time/within budget/in scope/quality) |
Why: Many companies have "mixed roles", where one person wears both hats (the two-hat syndrome in section 1.6 below). But drawing the theoretical distinction avoids one trap —passing off delivery metrics (on-time launch) as product metrics (whether the product makes money). For a VR headset product, the PM focuses on "whether users can seamlessly connect to existing platforms", while the project manager breaks that into multiple projects for hardware / platform integration / testing; one PM often corresponds to multiple PgMs.Counterexample: The team treats "launching on time" as success, and ends up delivering a feature no one wants on schedule — the project succeeded, but the product failed.
1.3 PM Core Responsibility Checklist and Skill Inventory
The 3 most core responsibilities(from a skill checklist perspective):Vision(identifying market gaps: what users are missing / what the market is missing / why build it),Collaboration(driving across Engineering/UX/Marketing/Sales/Delivery/Leadership, without building the product yourself),Customer Advocate(speaking for users — when engineering asks "how to build it", the PM asks "what do users actually want").
The PM's position = the company's central hub, sitting at the intersection of Technology × Business × Marketing, acting as the "glue" connecting these teams, usually reporting to the CPO or CMO. The full set of responsibilities expands to: strategy / user understanding / market and competitive analysis / product planning / roadmap / prioritization / cross-team collaboration / Ownership (the PM is the first person contacted when the product has problems) / Advocacy (product spokesperson) / lifecycle management / creating user personas.
When to use this checklist: When doing a personal capability inventory or writing a JD for the team, check which of the three pillars "Vision / Collaboration / Advocate" is weakest.Counterexample: Treating the PM role as a "requirements administrator" (only writing PRDs, scheduling requirements, following up with development) — the course repeatedly characterizes this as a degradation; a real PM is a "cross-functional business integrator".
1.4 Business Acumen — Think Like an Owner
Framework: business acumen = understanding how a business makes money, and making decisions that benefit the company in complex business contexts. Three core business capabilities + three supporting capabilities:
- Data analysis capability: reading data / BI tools / competitive analysis / trend forecasting — understanding user behavior to identify problems and opportunities (why are users churning? which feature is unused? why is growth stuck?).
- Financial Literacy: Must understand 6 basic metrics —Cash Flow / Profit / ROI (Return on Investment) / IRR (Internal Rate of Return) / NPV (Net Present Value) / Payback (payback period). The goal is not to do finance work, but to judge "whether this product is worth building".
- Market capability: who the target users are / what users actually want / how to position the product / how to deliver more value than competitors.
- Supporting capabilities:Strategic capability(product roadmap must align with company strategy: growth? profit? internationalization? AI transformation?),Adaptability(budget cuts / priority shifts / supply chain / policies and regulations — ability to dynamically adjust the roadmap),Leadership(ability to drive progress without direct management authority),Communication influence(communicating strategy upward to secure resources, communicating goals and cadence downward).
Why: This is the hardest distinction between "an excellent PM ≠ a requirements administrator" —understanding finance lets you speak the language the company understands when competing for resources (using NPV/Payback to argue that a feature is worth investing in).When to use: When presenting a project proposal to leadership to secure budget, translate user value into ROI/payback period.
1.5 Differences Between AI PMs and Traditional PMs (the Core of This Course)
Core proposition: AI products are not linear software following a "design → develop → launch → maintain" flow, but are continuous learning systems — data, model performance, user trust, and the features themselves are equally important, and "finish after one launch" does not apply. AI PM = Traditional PM + AI literacy + data strategy + AI ethics governance.
How AI Rewrites Every Step of the Product Lifecycle(This comparison table is the most worth memorizing part of the entire course):
| Stage | Traditional products | Additional work for AI products |
|---|---|---|
| Conceive | Define user needs / scenarios | Also define data requirements / model objectives / what AI can solve |
| Plan | Fixed roadmap | Iterative roadmap(model performance changes, so leave room for learning and adjustment) |
| Develop | Write code per requirements | Also train / tune / continuously improve the model |
| Qualify | Alpha/Beta test features | Also verify that the model is stable / fair / reliable across different datasets |
| Launch | One formal release | Progressive Rollout, adjusting the model while launching |
| Deliver (operations) | Focus on feature performance | Additionally monitor Model Drift, and continuously retrain |
| Retire | End support | Also handle model decommissioning / data processing / system retirement compliance |
Four new challenges for AI PMs: ① Data quality (dirty/insufficient/biased data → unreliable models, requiring early data governance) ② Bias and ethics (introducing Responsible AI framework) ③ Talent gap (traditional PMs do not understand AI / AI engineers do not understand products, so hybrid talent is needed) ④ User trust (black boxes are hard to trust, so we need to push explainability + transparency).
Counterintuitive points from real cases: Financial anti-fraud AI — fraud strategies change, so the model cannot be trained once and used forever, a fixed retraining mechanism must be established (e.g., retraining every 3 months) + real-time monitoring.
Why / When to use: This is the most important thing for experienced PMs transitioning to AI PMs to internalize —your product will never be "finished", and five new workstreams appear out of nowhere in your job: "data strategy / model performance / risk governance / trust mechanisms / continuous learning".Counterexample: Managing AI products with the mindset of building SaaS features, setting a fixed roadmap and shifting to maintenance after launch — model drift will quietly degrade performance, and by the time users complain, it is already too late.
1.6 Soft Skills and Two-Hat Syndrome
Soft skills checklist: Leadership (whether the team is willing to follow your direction and turn disagreements into value) / Research / Analytical thinking (breaking big problems into solvable small problems) / Communication / Creativity / Team collaboration.
Two-Hat Syndrome: Many PMs wear two hats at the same time — Hat 1 Product planning (vision/strategy/roadmap, strategy) + Hat 2 Project management (timeline/resources/execution, execution). Both hats are heavy, and wearing them at the same time easily leads to strategy being swallowed by execution. Solution: Bring in professional project managers for support and keep roles clear.
When to use: When you find yourself following up on development progress all day and having no time at all to think about product direction, you are being swallowed by Hat 2 — this is a signal to request a PgM allocation, not a sign that you are not working hard enough.
II. Product Lifecycle Methods
2.1 Do not confuse the two lifecycles (Product Lifecycle vs Product Management Lifecycle)
This is the foundation of this module and extremely easy to confuse:
- Product Lifecycle = The product itself from birth to retirement,4 stages: Introduction → Growth → Maturity → Decline. It describes "the state of the product in the market".
- Product Management Lifecycle = The methods/processes by which the product team advances the product,7 stages(see 2.3 below). It describes "how PMs do their work".
4 stages of the Product Lifecycle + PM priorities:
| Stage | Characteristics | PM priorities |
|---|---|---|
| Introduction stage | Just launched, Early Adopters, product is often imperfect (bugs/experience issues) | Formulate a complete go-to-market strategy + quickly collect feedback for improvement;Highest risk, may fail directly |
| Growth stage | Accepted by the market, rapid expansion | Scale up promotion to expand users; be cautious (already live, wrong adjustments will directly hurt user experience) |
| Maturity stage | Growth slows, user base stabilizes, lasts the longest | Continuously optimize to extend the lifecycle; more refined marketing (from "making you aware" to complex strategies) |
| Decline stage | Demand drops / replaced by new technology (CD → streaming) | Identify decline signals early, decide whether to optimize / exit / build the next generation, do not wait until the market disappears to act |
Why: Judging "which stage the product is in now" directly determines what actions you should take — aggressively pushing new features in the maturity stage may be a waste, and trying to "keep growing the current product" in the decline stage is going against the trend.Counterexample: Operating all stages as if they are long-term, investing large amounts of resources in new features during the decline stage instead of planning for the next generation.
2.2 Three delivery methods for value creation (Waterfall / Iterative / Incremental Iterative)
Framework: The essence of value creation = output value > input cost, and user value × business value both must hold true at the same time (users love it but it does not make money = failure; it makes money but users do not need it = also failure). When it comes to "turning ideas into products", there are three delivery rhythms:
| Method | How it works | When users get value | Difficulty of making changes | Suitable for |
|---|---|---|---|---|
| Serial / Waterfall | Define everything at once, execute in sequence | At the very end | Very hard | Stable requirements, no room for trial and error: automobiles/medical/aviation/hardware |
| Iterative | Build one round, revise one round | Not necessarily (may only be internal versions) | Possible | Need to learn while building, goals yet to be clarified |
| Iterative+Incremental / Incremental Iterative | Build and launch at the same time | Very early | Very easy | Internet products (WeChat started with messaging and gradually added images/voice/Moments/Pay) |
Key difference between pure iterative and incremental iterative(most easily confused): Pure iterative may involve repeated revisions of internal versions that users never see; incremental iterative delivers real user value to external users in every round.
Why / When to use: Choosing the wrong delivery method = choosing the wrong risk structure. Using "launch first and see feedback" to build cars will cost lives; using waterfall for internet products will mean you only discover the direction is wrong months later, at enormous cost.The PM's role also changes across different methods: In waterfall the PM is a "planner" (thinks everything through upfront), in iterative the PM is an "experiment lead" (continuously learns to decide the next round), and in incremental iterative the core capability is "splitting value" (cutting large requirements into small modules that can be delivered independently).
2.3 The 7 stages of the Product Management Lifecycle + key deliverables
Framework: Conceive → Plan → Develop → Qualify → Launch → Deliver → Retire. Goals + key outputs for each stage (this is the checklist of "what I should deliver at each stage"):
| Stage | Goal (one sentence) | Key deliverables |
|---|---|---|
| Conceive | First prove this thing is worth doing | Market research / Competitor analysis / SWOT / Identify needs / Multiple options + prioritization / Product concept / Prototype Demo → Product opportunity assessment + product concept |
| Plan | Turn the "idea" into a "project" | Team formation / Project plan / Business Case / Implementation plan / Roadmap / Marketing strategy / Beta plan → Complete execution plan |
| Develop | Turn the PPT into a real thing | Development / Design refinement / QA / Usability testing / Pricing / Sales strategy / Customer service plan / Training materials → Launch-ready product + commercial supporting materials |
| Qualify | The last chance to avoid a flop | Beta testing / Collect feedback / Fix issues → Launch decision (launch / delay / cancel) |
| Launch | Really push the product out | Launch preparation / Risk assessment / Contingency plan / Marketing materials go live → Official release |
| Deliver | Launch is not the end, it is the beginning (lasts the longest) | Hand over to business teams for operation / Monitor feedback / Adjust the product / Revise positioning / Iterate → Growth and optimization |
| Retire | Take it offline gracefully | Stop support / Terminate contracts / Inventory handling / User migration / Compliance → End of lifecycle |
Why: These stage names are the "official terminology" of the AIPMM/ProdBOK system, used in certification exams and formal product reviews — remembering them lets you "speak the same language" as people who follow this system. Note that the Conceive stage uses SWOT (Strengths/Weaknesses/Opportunities/Threats) and PEST (Political/Economic/Social/Technological) for strategic analysis to judge timing.Counterexample: Skipping Qualify (Beta validation) and going straight to Launch is equivalent to pushing all previous assumptions to the market at once with all their risks.
2.4 Project Management Lifecycle: Predictive vs Adaptive
Framework: There are only two approaches to advancing a project, depending on whether you face a "certain problem" or a "changing problem":
- Predictive: Draw the full map before setting out (clarify requirements/budget/timeline → execute strictly). Suitable for stable requirements and high change costs: hardware / factories / supply chain / infrastructure.5 stages: Initiating (project approval, prove it is worth spending money) → Planning (detailed planning) → Executing → Monitoring → Closing.
- Adaptive: Adjust as you go, suitable for high-change scenarios (corresponds to agile/iterative).
When to use: This is the projection of the waterfall/iterative approaches in section 2.2 at the "project" level — when choosing between predictive and adaptive, first ask "is it expensive to change this, are the requirements stable?"
III. Strategy and Innovation Frameworks
This section is a set of named analysis models — their value is not "remembering the names", but that when you need to make market judgments / defend project initiation, you have ready-made scaffolds to force yourself to think comprehensively.
3.1 Two classification systems for innovation
A. Four types of innovation in the Oslo Manual (Oslo Manual, 1992) — innovation targets are not limited to products:
| Type | What it is | Example |
|---|---|---|
| Product innovation | New/enhanced features or better experience | Continuous improvements to the iPhone series |
| Process innovation | Improving production/delivery methods | Factories introducing automated robots |
| Marketing innovation | New methods in design/packaging/promotion/pricing | Social media marketing |
| Organizational innovation | Improving business practices/internal operations/ways of working | Cross-functional teams breaking down departmental boundaries |
Supporting five-step innovation process: Staging (preparation: define innovation team/roles) → Alignment (align with senior leadership on priority scope) → Exploring (exploration: identify areas for improvement) → Creating (creation: turn ideas into plans/business models) → Mapping (roadmap: schedule steps/timeline).
B. Three tiers of innovation by magnitude of change:
| Tier | Magnitude of change | Example | Supporting methods |
|---|---|---|---|
| Incremental | Small-step optimization | Each generation of iPhone updates | DMAIC (Define/Measure/Analyze/Improve/Control) |
| Radical | Large-scale reshaping | Landline phones → smartphones | Encourage breaking conventions, allow failure and post-mortems |
| Disruptive | Replacing old rules | Tesla electric vehicles replacing gasoline cars | New technology/new business models, limited early profits, high risk |
Why / When to use: Not every problem requires disruption — continuous optimization is more effective when market rules are stable, and products only need to be redefined when rules are changing.Counterexample: Forcibly pushing a disruptive solution in a mature, stable market just to "look innovative" burns money and easily fails; conversely, if market rules have already been rewritten by competitors and you are still doing incremental optimization, you will be replaced.
3.2 Analytical and abstract thinking (dual wheels)
Framework:Analytical ability Answers "what does the data show" (breaks complex problems into smaller ones, identifies patterns/trends/causality, makes data-driven decisions, challenges assumptions);Abstract thinking Answers "what do these phenomena mean behind the surface" (holistic perspective, broader impact, innovative solutions). The former makes decisions reliable, the latter makes solutions strategic.
Counterexample (original course example): The food delivery team assumed that users valued restaurant ratings most, but data showed users were more likely to order from restaurants with "rich dish selection" — the value of analytical ability is to challenge such seemingly reasonable assumptions. When checkout churn is high, abstract thinking does not just add a prompt, but redesigns the checkout process to reduce steps.
3.3 Porter's Five Forces — how attractive a market is
Framework(Michael Porter): Used to judge the attractiveness of a market and where competitive pressure comes from. The five forces:Threat of new entrants / Threat of substitutes / Bargaining power of buyers / Bargaining power of suppliers / Intensity of existing rivalry. Simple rule: the lower the barriers to entry, the more substitutes, the stronger buyers or suppliers are, and the more cutthroat peer competition is → the harder it is to make money.
Three response strategies: Overall Cost Leadership / Differentiation / Focus (concentrate on a niche segment).
When to use: Run through the five forces before entering a new market / new category to judge "whether it is worth entering, where the main pressure comes from, and how the product should be positioned". The competitive structure of opening a burger shop (low barriers) and building jet aircraft (extremely high barriers) is completely different.
3.4 Kotler's Five Product Levels — how products create value
Framework(Philip Kotler): The 5 levels a product goes through from "satisfying needs" to "building long-term competitiveness":
- Core Benefit: What the user truly wants (buying a mobile phone = staying connected / accessing information) → determines "whether there is value"
- Basic Product: The delivered product + core functions (calls / SMS / internet access) → determines "whether it is usable"
- Expected Product: The quality users expect by default (storage / battery life / performance / support) → determines "whether it is good enough"
- Augmented Product: Differentiated value that exceeds expectations (free delivery / extended warranty / extra features) → determines "why users choose you"
- Potential Product: Future scalability (AI assistant / personalization) → determines "whether it can still attract users in the future"
Supporting three stages of "how users judge value":Need (become aware of the need) → Want (focus on the desired experience) → Demand (willing to pay).
Key counterintuitive point: No matter how rich the higher-level features are, if the core benefit and basic functions are not met, users will still not buy.When to use: When doing product positioning / competitor benchmarking, fill in level by level — especially use the 4th level (Augmented Product) to find differentiation levers.
3.5 Market Segmentation + Primary/Secondary Research
Market Segmentation = splitting a large market into smaller groups, with dimensions:Needs / Behavior / Interests / Demographics. The essence is not "classifying users", but "providing more precise value for different users" (elderly people need large fonts and easy operation, young people need photography, gaming and social features).
Two types of research:
| Primary Research | Secondary Research | |
|---|---|---|
| What it is | Go ask users yourself (interviews / questionnaires / focus groups / usability testing) | Review work done by others (industry reports / databases / government statistics / academic research) |
| Advantages | Precise / fresh / understands the "why" | Fast / cheap / quickly understand the market |
| Disadvantages | Expensive / time-consuming / prone to bias | May be outdated / quality uncontrollable / may not answer your specific questions |
When to use: The essence of Research is "reducing uncertainty in product decisions", not "collecting data". First use secondary research to quickly build a big picture of the market, then use primary research to dig deep into specific hypotheses. The PM is essentially "the bridge between the market and the company", and the core responsibility is Voice of Customer.
3.6 SWOT + Five Steps of Product Strategy
Make SWOT actionable(don't just make a PPT): Step1 Strengths→Opportunities (what opportunities can my strengths bring, turn opportunities into reality); Step2 Weaknesses→Threats (what risks will my weaknesses cause, make action plans to reduce risks). In reality, multiple strengths often jointly create opportunities, and multiple weaknesses jointly lead to risks.
Three elements of product strategy: Product market (target user preferences / motivations) + Unique Selling Proposition (USP, differentiated selling point) + company business objectives (growth / profit / market share).Five-step formulation: ① Market research (based on objective data, not subjective judgment) → ② Create a complete strategic plan (including SMART product definition / business case / competitors / cost-benefit / milestones / risk mitigation) → ③ Develop the product (prototype + continuously listen to stakeholders) → ④ Launch and deliver → ⑤ Track sales / complaints / feedback (consider delisting when the product no longer creates value).
Why: Product strategy is not a one-time plan, but continuous calibration throughout the lifecycle — "making a plan" is only the beginning; the real difficulty is constantly adjusting the direction after launch based on market feedback.
IV. Stakeholder Collaboration and Communication Styles
This is the part of PM work that is the largest in volume and the hardest to quantify. Core insight:The essence of a PM is not managing the product, but managing "people" — the success or failure of a product often does not depend on the idea itself, but on whether the PM can coordinate all key stakeholders well. For the empirical PM×UX disagreements on "who does this work" in collaboration and the complete usage of RACI, see NNGroup Product and UX Collaboration (Empirical PM×UX Responsibility Disagreements · Root Causes of Overlapping Work · PM Role Model · RACI Division of Labor · Five Collaboration Suggestions · UXers Thinking Like Product Leaders · PLG · Glossary); for specific collaboration between AI PM × Engineering / Design, see PM / Design / Eng Trio Collaboration in the AI Era (Cross-Author Thematic Synthesis); this section provides the naming framework unique to this course.
4.1 Stakeholder Management + RACI
Communicate in layers by influence(not treat everyone the same): A single decision from the CEO can terminate a project (high influence) → provide a one-page weekly briefing; engineering / testing / customer service execution layers have high impact → provide fine-grained execution information. First identify who the key roles are, then set different communication strategies according to importance. Balance internal (management / engineering / finance / marketing / sales / operations / testing / customer service) vs external (suppliers / channels / end users) simultaneously.
RACI Responsibility Model:R esponsible (the person who executes)/ A ccountable (the person ultimately responsible, only one per task)/ C onsulted (the person consulted)/ I nformed (the person notified). Core value = preventing "everyone thinks someone else will do it" or "everyone gets pulled into unnecessary meetings".
When to use: When a complex project starts / after a retrospective meeting finds that "so-and-so was missed / tasks were delayed", draw RACI to make responsibility boundaries transparent. For the complete R/A/C/I quantity rules and details such as skills/relationships/interests to consider besides position when assigning, see NNGroup Product and UX Collaboration (Empirical PM×UX Responsibility Disagreements · Root Causes of Overlapping Work · PM Role Model · RACI Division of Labor · Five Collaboration Suggestions · UXers Thinking Like Product Leaders · PLG · Glossary) Section 5.
4.2 Five Dysfunctions of a Team Pyramid (Lencioni)
Framework: When a team fails to deliver results, it is usually not because they are not smart/hardworking enough, but because they fall into 5 progressive traps. Solve them level by level from the bottom up; skipping levels is ineffective:
Results 结果 ↑ Accountability 问责 ↑ Commitment 承诺 ↑ Conflict 健康冲突 ↑ Trust 信任
Chain: Absence of trust → Fear of engaging in real discussion → Lack of real commitment → Avoidance of accountability → Inattention to results.
| Dysfunction | Manifestation | PM's Role |
|---|---|---|
| ① Absence of Trust | Afraid to admit mistakes / ask for help / expose weaknesses (fear of losing face) | Create psychological safety(no punishment for raising problems) |
| ② Fear of Conflict | Fake harmony: no objection, no debate, mediocre output | Foster healthy conflict(clash of views ≠ quarreling) |
| ③ Lack of Commitment | Say OK in meetings but resist after meetings (commitment ≠ agreement) | After full discussion unify action(even with reservations) |
| ④ Avoidance of Accountability | Someone misses deadlines and no one points it out; low standards become the norm | Establish peer accountability peer accountability(peers point out issues to each other) |
| ⑤ Inattention to Results | Everyone chases personal KPIs/exposure, no one cares whether users pay for the product | Continuously pull back to shared business outcome |
Why / When to use: When the team is clearly busy but fails to deliver results, use this pyramid to diagnose from the bottom up — usually the root cause is at the "trust" level, not the superficial "insufficient execution".Counterexample: Seeing poor team execution and adding KPIs to pressure accountability (④), but with underlying trust (①) missing, it will only make people more afraid to expose real risks.
4.3 SMART Goals + Dual-Layer Checklist
SMART: Specific / Measurable / Achievable / Relevant / Time-bound. "Improve user experience" is a slogan; "Optimize onboarding within 6 weeks to raise registration completion rate from 42% to 55%" is a goal.
Key upgrade: A good goal = dual-layer check of executable (SMART) + valuable (Business Value) — even if a goal is very SMART, it must pass the second layer of "is it worth doing": Does it improve decision-making ability / customer satisfaction / engagement / retention and adoption rate / reduce communication friction / optimize space / product quality / delivery speed / production efficiency?Only when both layers are YES is it a qualified goal.
Modern supplement (noted by the course itself): SMART is an entry-level tool; real internet products pay more attention to outcome rather than output("Launch 20 features" is output, "Reduce onboarding drop-off by 25%" is outcome), and layer on OKR / KPI / North Star Metric / outcome-driven roadmap.Counterexample: The goal is written as "Launch 20 features this quarter" — it meets all SMART criteria, but this is output, and does not answer "for what business result".
4.4 Six Elements of Elevator Pitch — Product Positioning Framework
Framework: Compress product positioning into an expression that people can understand in 30 seconds; it is essentially a positioning tool, not a speaking skill. Fixed six-element template:
For[Target users],Who[their problem],Our product is[product category],That[value provided],Unlike[competitors],Our product[core differentiation].
It forces you to answer 6 often skipped questions: For whom / Why they need it / What we are / What users get / Why choose you / Biggest selling point. A shorter modern version is a one-line positioning: "User + Problem + Value + Differentiation" (e.g. "Airbnb for business travelers").
When to use: When reporting to the boss whether it is worth doing, quickly building awareness with investors, aligning the team, writing website/landing page copy. First have a clear product vision (answering "what problem does this product ultimately want to solve", not a feature list), then compress it with an elevator pitch.
4.5 Influencing without Authority — Six Sources of Influence
Core reality: PMs "have responsibility, but no authority" — they are responsible for product outcomes, but cannot directly manage engineering/design/marketing. Therefore they must rely on influence to make people "willing to do it" rather than "being ordered to do it".
Six sources of influence(from *Influencer*, split along the two axes of Motivation × Ability):
| Personal | Social | Structural | |
|---|---|---|---|
| Motivation | ① Buy in yourself first (do you truly believe in this) | ③ Leverage allies (tech lead / senior designer / business sponsor, social proof) | ⑤ (Environment / incentive design) |
| Ability | ② Expertise is influence (credibility / expert positioning) | ④ Coalition operation (mobilize / build relationships / win over dissenters) | ⑥ (System / process / tool support) |
Why / When to use: When a PM cannot push things forward, don't first think "why don't I have authority", but go through the six sources — many times what is missing is "① not being firm enough (others can sense it)" or "③ not finding the right allies".Counterexample: Pushing hard alone without finding a supporting tech lead as social proof, resulting in key people not nodding and everyone else waiting and seeing.
4.6 5-Step Problem-Solving Method + Decision Matrix
5-Step Problem-Solving Method: ① Define the problem (write a problem statement + align with stakeholders; if the problem is defined wrong, all subsequent work is wasted) → ② Find root causes (brainstorm / brainwriting, look from People/Process/Policy/Tools/Systems) → ③ Rank root causes (Nominal Group Technique, structured to let everyone express fairly, avoiding "the loudest voice wins") → ④ Focus on priorities (Pareto 80-20 Pareto principle, 80% of results come from 20% of key causes) → ⑤ Verify and iterate (if solved, record lessons; if not solved, go back upstream to re-analyze).
Decision Matrix: Put multiple options into a unified scoring system to reduce subjectivity; common dimensions include impact, effort, cost, risk, and strategic fit Impact / Effort / Risk. When stakeholders disagree on scores, use a "multiple options × multiple reviewers × multiple dimensions" scoring system (High=3/Med=2/Low=1), take the average or apply pre-agreed weights, and select the highest-scoring option — this essentially prevents outcomes where "whoever speaks loudest wins".
When to use: When cross-team arguments over "what to build first" cannot be settled, bring out the decision matrix to shift the debate from "who is right" to "scores". Note that it systematizes subjective scoring rather than eliminating subjectivity — its value lies in transparency and reviewability.
4.7 Four Communication Styles × Tuckman Ladder × Situational Leadership (the most systematic section of this lesson)
A. Four Communication Styles (Emergenetics) — For the same content, if your expression does not match the other party, comprehension and buy-in will decrease:
| Style | What they care about | How to communicate | Gains trust / Loses trust |
|---|---|---|---|
| Analytical | Logic / facts / data / value | Provide data / evidence / logical chains; do not only talk about feelings | Win: Precise data that saves time / Lose: Exaggerated value, incorrect data |
| Structural | what/when/where/how, processes / responsibilities / timelines | Provide milestones / RACI / checklists / rollback plans | Win: Clear guidance that stabilizes direction / Lose: Frequently changing guidance, micromanagement |
| Conceptual | Big picture / possibilities / innovation | Leave room for divergent thinking; use vision / future scenarios / roadmap sketches | Win: Leave space for brainstorming / Lose: Allow no exploration, only demand convergence |
| Social | Relationships / stories / human impact | Talk face-to-face + share real stories, emphasize collaboration and who is involved | Win: Emphasize teamwork and friendly interaction / Lose: Sarcasm, negative nonverbal cues |
B. Tuckman Ladder (1965) — Four stages of team development: Forming (newly formed, unfamiliar, low productivity) → Storming (conflicts emerge, productivity drops) → Norming (conflicts decrease, trust increases) → Performing (self-driven, high efficiency).
C. Situational Leadership (adjust leadership style according to team stage) — Combine A and B:
| Stage | Leadership style | What to do |
|---|---|---|
| R1 Forming | Tell / Direct | Use a one-page "North Star + milestones + RACI" to clarify direction / division of labor / decision-making mechanisms |
| R2 Storming | Sell / Facilitate | Break disputes into "shared metrics / must-do vs. can-do / decision deadlines", and ask each party to make minimum concessions |
| R3 Norming | Participate / Support | Reduce commands; spend 15 minutes each week on an "obstacle list" to unblock dependencies; do not micromanage |
| R4 Performing | Delegate / Monitor | Delegate to self-driven teams, only review "monitoring metrics + rollback strategies", and align at key milestones |
Why / When to use: This set is a complete operating system for PMs to "adjust communication based on people and stage" — newly launched program groups should be Told, three-way standoffs in review meetings should be Facilitated, and smoothly running teams should be Delegated to.Counterexample: Prematurely delegating (R4) to a team still confused in the Forming stage (R1) will cause the team to spin in place due to lack of shared understanding; micromanaging with line-by-line instructions (R1) to a highly self-driven team in the Performing stage (R4) will be seen as micromanagement and hurt morale.
4.8 Six Methods to Build Trust
Framework(Trust = daring to openly express failures / weaknesses / concerns, not "being on good terms"): ① Active listening (ask "Which part are you most worried about?" and paraphrase to confirm) ② Emotional intelligence (acknowledge ideas first before guiding feasibility; do not pour cold water directly) ③ Effective communication (pay attention to nonverbal cues: do not look down to reply to messages while listening) ④ Cultural awareness (some people value "face in public settings"; talk privately first before presenting in meetings) ⑤ Build rapport (let the other party feel understood in their preferred communication style) ⑥ Resolve conflict (pull the conversation back from "who is right or wrong" to "shared goals", and give both parties a graceful way out).
When to use: These six methods are the "relationship foundation" of the 4.7 communication styles — style matching solves "being willing to listen", while the six trust methods solve "being willing to tell the truth". Especially in cross-border / cross-department collaboration, cultural awareness (④) is often a hidden minefield.
V. Business and Commercialization
5.1 Business Development
PMs do not only "build products" but also drive "business growth": researching sales leads / persuading customers / studying user behavior and market opportunities. The tool is SWOT(see 3.6). Core qualitative point: A PM is both a "product role" and a "business growth role".
5.2 Product Portfolio Management (Portfolio Approach)
Framework: One PM is responsible for an entire group of related products (rather than a single one), unifying strategy from a higher perspective / optimizing resources / avoiding redundant development / improving overall returns. Two dimensions:Product line width(how many types of products: Coke / Sprite / tea) × Product line depth(how many variants per item: Coke has original / zero sugar / cherry / caffeine-free).
Portfolio PM vs. Regular PM(This is the watershed for senior roles):
| Regular PM | Portfolio PM |
|---|---|
| Manages one product / focuses on features / handles execution | Portfolio PM |
| Focuses on user needs / builds roadmap | Focuses on ROI / builds portfolio strategy / manages business risk |
Why companies do this: ① Unify strategy (avoid brand confusion / positioning conflicts, e.g., a company-wide low-sugar strategy) ② Limited resources (put money and people where they are most worthwhile) ③ Risk control (avoid over-reliance on a single product, diversification). Common job titles: Senior PM / Portfolio PM / Product Line Manager / Director of Product.
One-liner: A single-product PM is "building the product well", while a Portfolio PM is "deciding which products the company should build well, and why".When to use: When you are promoted from managing one SKU to managing a product line, your focus must shift overall from "feature details" to "investment priorities + business risk".
5.3 Public-Facing Communication: PR Plan + Marketing Materials Checklist
PR Plan: Manage communication with the public / stakeholders (objectives / strategies / tactics), select media channels (broadcast / publishing / internet), and continuously reinforce core themes.
Pre-Launch Marketing Materials Checklist(checklist for launch readiness): Messaging (convey value) & Positioning (define vision / market position) / product name and trademarks / marketing materials (logo / website / brochures / online ads) / point-of-sale POS materials / advertisements / press releases and media relations / FAQ / white papers (for rational, in-depth customers) / case studies and customer testimonials (to increase credibility) / trade shows / social media.
Communicate to the Four Styles(different expressions for the same product): For Analytical types, provide key facts + success criteria + controlled experiments; for Structural types, provide clear what/when/where/how steps; for Conceptual types, provide a pitch + room for imagination + differentiation; for Social types, provide stories + emotional hooks + "let contributions be seen".
When to use: During the product Launch phase (see 2.3), use this materials checklist to verify item by item whether "all required launch assets are ready", and use four-style communication to cover different customers.
VI. Career Development
6.1 PM Industry Status and Opportunities
PM skills are applicable to almost all industries (software / utilities / infrastructure / customer service / manufacturing / consumer goods), because any company with a "product" must continuously answer "what do users want / are we still competitive / what to optimize next / when to upgrade or retire". Demand continues to grow,with many sources of career switchers: engineers (strong technical understanding) / project managers (familiar with development processes) / supply chain professionals (understand markets and supply systems) — no formal specialized degree is required. Promotion path: PM → Senior PM → PM Lead/Manager → Director.
When to use: When defining your career positioning, first identify which type of PM you will fall into: "growth-oriented / strategy-oriented / delivery-oriented / business-oriented" — PM responsibilities vary greatly across companies.
6.2 Resume: fit-not-identity
Core mindset: A resume is not "showing who you are", it is "showing whether you fit this role" — read the JD first before writing,one resume cannot be mass-mailed(Technical PM / Growth PM / Strategic PM / Platform PM are very different; tailor it to the role). Write fewer empty phrases (Good communication / Team player are basically useless), write more about "specific things you have done" (not "I can collaborate", but "coordinated a 12-person team of design + R&D + operations to take the project from 0 to launch").
Most valuable PM skills: Collaboration / driving execution (full chain from idea → execution → launch) / project management (processes / milestones / risks / priorities).Any experience can be mapped to PM skills: Engineer → ownership + technical collaboration; teacher → curriculum design + user understanding; factory work → process optimization + quality management.
Counterexample: Writing a resume as a chronological self-introduction and mass-mailing it to all PM positions — recruiters only care about "whether you fit this specific role", and irrelevant experience will drown out truly valuable information. Delete fluff; resume space is expensive.
6.3 Certifications and the Rise of AI PM
AIPMM Certified Product Manager (the certification corresponding to this course) is a career plus, not a requirement; ability and project experience remain core. In terms of trends: AI PM is not a niche role and will become mainstream, responsible for AI compliance + human-AI collaboration experience (whether users dare to use it / trust it / find it easy to use) + cross-industry expansion (Healthcare / Energy / Transportation / Government). People suitable for switching to AI PM: traditional PMs / UX designers / technical PMs / entrepreneurs (who understand user experience + product logic + can grasp the boundaries of AI capabilities).
Sourced from will-design-notes / AI Product Manager Professional Certificate (AIPMM system, 87 articles, 8 modules). This article is a comprehensive synthesis (ingest_quality: synthesized), based on close reading of the 8 module outlines + all high-density framework subsections (approximately 35 articles). For empirical responsibility differences between PM and UX in collaboration and communication, complete RACI rules, and PLG growth, see NNGroup Product and UX Collaboration (Empirical PM×UX Responsibility Differences · Root Causes of Overlapping Work · PM Role Models · RACI Division of Labor · Five Collaboration Recommendations · UXers Thinking Like Product Leaders · PLG · Glossary); for practical playbooks for AI PM collaboration with design/engineering, see PM / Design / Eng Trio Collaboration in the AI Era (Cross-Author Thematic Synthesis) — this article is positioned as an "AI PM methodology skeleton + framework dictionary", cross-referenced with the above two without rewriting their content. Scanned content such as module glossaries is retained in the original source files.
Sources and Related Materials
- NNGroup Product and UX Collaboration (Empirical PM×UX Responsibility Differences · Root Causes of Overlapping Work · PM Role Models · RACI Division of Labor · Five Collaboration Recommendations · UXers Thinking Like Product Leaders · PLG · Glossary)
- PM / Design / Eng Trio Collaboration in the AI Era (Cross-Author Thematic Synthesis)