The main subject of this batch of notes is “how PMs and UX can work together to build good products without fighting.”Product Manager (PM) owns business value, prioritization, and whether to build something;User Experience (UX) team owns research, design, and whether users can use the product smoothly. In an ideal world the two sides are golden partners; in reality they often step on each other’s toes fighting over “who is supposed to do this work.” An NNGroup survey of 372 people found in practice: UX on average feels their work is being meddled with by others every so often (frequency 2.6/4, close to “sometimes”), and PMs feel the same (2.4).
For a PM, the value of these materials is turning the vague feeling of “why do designers and I always rub each other the wrong way” into a quantifiable map of disagreements + actionable responsibility-allocation tools. The full text has nine sections: ① Empirical disagreements(who thinks which work belongs to whom, with double-digit percentage gaps between the two sides) → ② Frequency/root causes/harms of overlapping work(why work gets grabbed) → ③ Essential difference between collaboration and overlap(when two people do the same task, what is good and what is bad) → ④ PM role archetype model(designer perspective: what kind of person a PM is, and how to collaborate with them) → ⑤ RACI responsibility matrix(a tool to nail down “who owns what” once and for all) → ⑥ Five collaboration recommendations(how to manage the relationship) → ⑦ UXers should think like product leaders(how the UX side can proactively break the deadlock) → ⑧ PLG and UX(the new role of UX under growth models) → ⑨ Glossary(shared language for PM×UX).
1. Empirical disagreements: For the same piece of work, who do PM and UX think owns it? (372-person survey)
NNGroup surveyed 372 people (279 UX practitioners + 93 PMs; 60% had 3–10 years of work experience; 54% were based in the US / 27% in Europe). Core finding:The two sides’ perceptions of “who owns this work” can differ by dozens of percentage points — this is not an attitude problem, it is structural role ambiguity. All key data are listed below (numbers represent “the proportion of people in that group who hold this view”).
Research-type tasks (discovery / interviews / testing) — the biggest disagreement is on “discovery”:
| Task | PM believes it is a UX responsibility | PM believes it is a PM responsibility | UX believes it is a UX responsibility | UX believes it is a PM responsibility |
|---|---|---|---|---|
| Discovery (identifying problems and opportunities) | 19% | 44% | 73% | 7% |
| User Interviews | 45% | 23% | 88% | 2% |
| User Testing | 46% | 17% | 88% | 1% |
How to read this: 88% of the UX group believes “user testing is our job,” but only 46% of PMs agree — meaning nearly half of PMs think user testing does not have to belong to UX. “Discovery” is the most dangerous: 73% of UX treat it as their core work, but only 19% of PMs see it that way, and 44% of PMs think discovery belongs to PM.
Counterexample warning for PMs: You may think “I can just talk to users myself during discovery,” but UX almost universally considers this their professional territory. If you skip them and do discovery directly, you are both grabbing their work and throwing away professional quality.
Design-type tasks — the two sides differ wildly on “who owns design ideation”:
| Task | PM believes it is a UX responsibility | UX believes it is a UX responsibility |
|---|---|---|
| Ideation (proposing design ideas) | 33% | 76% |
| Defining Task Flows | 34% | 70% |
| Wireframing | 42% | 74% |
| Prioritizing User Needs | 38% | 78% |
Even for work that looks most like exclusive UX territory, such as “drawing wireframes (interface sketches),” nearly 60% of PMs do not believe it necessarily belongs to UX.Mental model: Once PMs casually take over wireframing and ideation, UX is reduced to “draftspersons who build to spec” (see Section 7 on UXers’ core pain points).
Information Architecture IA (Information Architecture, how content is organized, how menus are categorized): 50% of PMs think this should belong to the development team, while 75% of UX think it is a core UX responsibility. — This is a classic “no one owns it / everyone owns it” zone.
Managing design work (who sets research direction / who decides which features to design):
| Task | PM believes it is a PM responsibility | UX believes it is a UX responsibility | UX believes it is a PO responsibility |
|---|---|---|---|
| Deciding the areas the UX team researches | 47% | 59% | 15% |
| Determining which features the UX team designs | 56% | 39% | 34% |
| Incorporating user research into the roadmap | 55% | 38% | 22% |
PO = Product Owner (the person in agile Scrum who manages the backlog, often overlapping with the PM or being the same person). Note that UX splits responsibility for “which features to design” across the PO (34%), reflecting that UX itself also has no internal consensus on “who calls the shots on what to build.”
Project management-type tasks — PMs assert stronger ownership here, but “voice of the customer” is severely misaligned:
- Product vision and prioritization: Over 63% of PMs believe vision and prioritization belong to PM; UX views are split between PM and PO.
- Progress tracking:60% of UX think this is PM’s job, actually higher than PMs’ own self-assessment (45%) — i.e., UX is more willing than PMs to push progress management onto PMs.
- Maintaining the product backlog: 56% of PMs think it belongs to PM;Ensuring the project meets business needs: 73% of PMs think it belongs to PM.
- Product Evangelizing: 72% of PMs think it belongs to PM; UX is more inclined to assign it to PO (41%).
- Competitive research: PMs tend to assign it to PM; UX splits it across PM/PO/marketing.
Transmitting the “Voice of the Customer” to the product team — the most dangerous misalignment:
| Who should be responsible for transmitting the voice of the customer | PM’s view | UX’s view |
|---|---|---|
| PM themselves | 25% | — |
| Customer Experience team (CX) | 29% | — |
| Product Owner (PO) | 16% | — |
| UX team | 9% | 54% |
Counterexample (key NNGroup warning): 54% of UX believe “bringing users’ real voices to the product team/leadership” is their inherent duty, but only 9% of PMs agree. The result is non-designers often report design to senior leadership on behalf of designers— the design rationale gets misrepresented when relayed, and UX also wastes the chance to demonstrate its value and build trust within the organization.Reminder for PMs: Letting designers present design to stakeholders themselves is both respect for their expertise and a way for you to get undistorted first-hand information.
Content decisions: 61% of PMs + 79% of UX both believe content should belong to UX or a dedicated content team. NNGroup comment: Many people think “anyone can write copy,” but only professional content teams can guarantee content quality for digital media.
Explaining design / securing buy-in: 45%–53% of PMs think “explaining design and securing stakeholder buy-in” is PM’s job; only 23%–29% of UX think it belongs to UX. — Another area where UX gets spoken for.
Role power ranking: The two sides largely agree on the power ranking of each role,the only statistically significant difference is — UX’s power rating for the Product Owner (PO) is higher than PMs’ rating for PO (UX thinks PO has more say than PMs imagine).
Three major harms of role ambiguity + remedies:
| Harm | Explanation |
|---|---|
| Lack of proficiency | Frequently switching tasks → no one builds deep expertise |
| Lack of professionalism | Non-professionals forcing UX work → quality collapse |
| Low efficiency | Work lands in the hands of people who are not good at it → slow and poor output |
Remedies (for PMs to copy directly):①Align early in the project — before work starts, PM and UX should first clarify responsibilities for research/design/task flows face to face; ②Ongoing communication — reconfirm who does what at each stage; ③Clarify role boundaries — avoid the chaos of “everyone is responsible.”
2. Overlapping work: how frequent, who overlaps with whom, why, and how harmful it is
Section 1 covered “perceptual disagreements”; this section covers the actual consequences after those disagreements play out —work overlap. From the same group of 372 people, they were asked “how frequently does others meddle in/duplicate your work” (1=never, 2=rarely, 3=sometimes, 4=often):
| Group | Average frequency (1–4) | Meaning |
|---|---|---|
| UX | 2.6 | Close to “sometimes,” and statistically significantly higher than PMs (p<0.05) |
| PM | 2.4 | Between “rarely” and “sometimes” |
Conclusion: UX gets meddled with more frequently and more broadly — because UX’s role is the most ambiguous (everyone feels they can do a bit of design/research), so it is easiest for others to “help out” on their behalf.
Who overlaps with whom (perceived overlap intensity 1–4 by group):
| Who UX feels they overlap with | Intensity | Who PM feels they overlap with | Intensity |
|---|---|---|---|
| Product Owner (PO) | 2.75 | Other PMs | 2.71 |
| Development | 2.53 | Product Owner (PO) | 2.44 |
| Customer Experience (CX) | 2.5 | UX | 2.37 |
| Content | 2.3 | Marketing | 2.25 |
Negative impacts of overlap (lower score = worse, 2=neutral):
| Impact dimension | UX score | PM score | Interpretation |
|---|---|---|---|
| Product/service quality | 1.60 | 1.97 | UX perceives significantly heavier quality harm (p<0.05) |
| Job satisfaction | ≈1.5 | ≈1.5 | Both sides score below neutral — overlap makes people unhappy |
| External perception of the team | ≈1.76 | ≈1.76 | Overlap makes others think less of your team (p<0.05) |
Typical complaints: PM — “Duplicate work lowers morale and makes me doubt my own value”; UX — “Unclear roles make design governance (who uniformly checks design consistency) difficult, leading to inconsistent experiences”; UX — “The most frustrating thing is that others think ‘you don’t need a professional background to do this job.’”
Root causes of duplicate work (selection rate for each cause):
| Cause | UX selected | PM selected | Significance |
|---|---|---|---|
| Lack of leadership | 54% | 42% | Approaching significance (p=0.07) |
| Trying to do the right thing | 46% | 66% | Significant (p<0.05) |
| They believe they are skilled | 46% | 34% | Not significant |
| Unclear about your own responsibilities | 28% | 26% | Not significant |
| Unclear about the other party's responsibilities | 19% | 26% | Not significant |
| Personality / The team is too busy to help / They enjoy the work | ≤21% | ≤17% | Not significant |
| Don't trust others to do it correctly | 0% | 0% | — |
The most counterintuitive finding: Overlap is not caused by mutual distrust (0% of respondents selected this option); on the contrary —it mostly stems from good intentions(66% of PMs believe "everyone wants to do a good job"). In other words, people who take over others' work are often enthusiastic, responsible, and believe they are capable; the problem lies in leadership failing to clearly define responsibilities(54% of UX practitioners blame "lack of leadership").Takeaway for PMs: Don't interpret UX complaints about "you stepping in" as "they think you're unskilled / don't trust you". The root cause is that no one above has set clear boundaries — this is a management issue, not a character issue.
Three improvement tactics: ① Clarify the scope of responsibility for each role on every project (→ use the RACI framework in Section 5); ② Use cross-functional teams to help members understand each other's work (strengthen role awareness); ③ Leadership should proactively identify overlaps and organize open discussions to clearly define responsibilities.
III. Collaboration vs Overlap: A One-Word Difference, a World Apart
This is the conceptual foundation of the entire set of materials, and PMs must internalize it: when "two people are involved in the same task", it can be either good or bad, and the difference comes down to two points.
| Dimension | Collaboration (Good) | Overlap (Bad) |
|---|---|---|
| Responsibility | Clear — who leads and who supports is defined in advance | Vague — no one can say clearly who owns it |
| Communication | Smooth — aligned before starting, synced during the process | Absent — stepping in without prior communication |
| Outcome | Improves overall quality | Confusion + inefficiency + duplicated effort |
A UX interviewee said in their own words:"Every piece of work should improve overall quality, not create duplicated effort. Collaboration must be built on clear division of responsibilities." — This statement is essentially the overarching principle for all solutions in this set of materials:It is not about keeping PMs and UX further apart (that creates silos), but about clarifying boundaries before working together.
IV. PM Role Archetypes: What Product Managers Look Like in Designers' Eyes
This NNGroup article is written for designers on "how to understand and work with your PM" — but conversely, it also acts as a mirror for PMs themselves. Foundational premise: PMs (also called Product Owners in Agile) are responsible for driving product strategy and creating value for both the business and users;ideally PMs should understand the value of user research, but reality is often different. Designers need to proactively demonstrate their value, build trust, and use their expertise to influence product decisions.
Below are five dimensions, each listing "Typical PM traits" + "How designers should collaborate":
| Dimension | Typical PM Traits | Designer Collaboration Tactics |
|---|---|---|
| Goal · Rapid experimentation | Validate hypotheses and evaluate opportunities using rapid experiments | Push for experiments "based on high-quality research" to avoid wasted resources from blind testing; conduct prototype testing for pain points in the discovery phase and invite PMs to observe |
| Goal · Value-based prioritization | Maximize the business value of product decisions | Introduce prioritization frameworks that combine business metrics (e.g., revenue) and user metrics (e.g., task success rate) for ranking |
| Goal · Team alignment | Ensure everyone's work is aligned with shared goals | Tie day-to-day design activities to high-level goals, regularly check priorities with the PM to avoid drifting off course |
| Goal · Risk management | Identify business / usability / technical risks | Use research methods to assess usability and functional risks, and sync them to the PM by severity |
| Strength · Strategic thinking | Integrate information from engineering, design, and marketing to set direction | Ask the PM to explain "the logical chain between design requirements and goals" to avoid conflicts caused by opacity |
| Strength · Communication skills | Communicate frequently to maintain alignment and continuously deliver value | Proactively reach out to the PM for information instead of waiting, to avoid wasting effort working in the wrong direction |
| Strength · Decisive decision-making | Grasp key points from massive amounts of information and prioritize quickly | Ask the PM about the basis for their decisions in a "patient + curious" tone, then use research evidence to help them reach consensus |
| Challenge · Time management | Too much data, no time to work through long, complex research reports | Simplify research findings into key insight summaries so PMs can understand them in a few minutes |
| Challenge · Balancing details | Need to trade off between user needs and technical priorities | Invite PMs to participate in user research firsthand to help them remember user details |
| Challenge · Data exploration efficiency | Easily led astray by "interesting but out-of-context" data | Help PMs dig into the reasons behind user behavior and deliver insights meaningful to the business |
| Challenge · Urge to step into design | May directly jump in and lead design work | Deeply understand business and user goals, proactively explain the rationale behind design decisions (to remove their reason to step in) |
| Activity · Managing the backlog | Regularly review and update the to-do list | Ensure user stories clearly state user needs and expected outcomes |
| Activity · Researching business data | Analyze data to identify problems / opportunities | Figure out which key metrics the PM cares about, and use research to add context to those metrics |
| Activity · Researching competitors | Track competitors' strategies and technology | Supplement competitive analysis from a "feature usability" perspective |
| Activity · Documenting progress | Track team outcomes and secure support for the team | Help update progress documentation to ensure design work is not overlooked |
| Skill · Technical knowledge | Understands some technical concepts, but relies on engineers | Bring engineers and the PM together to discuss technical constraints, improving design feasibility |
| Skill · Business knowledge | Drive financial sustainability and growth | Learn the business metrics PMs use, and find connections between "UX success metrics ↔ business metrics" |
| Skill · Design knowledge | Limited design knowledge, may have some experience | Use clear deliverables backed by research to earn PM trust in design professionalism |
Self-reflection for PMs: See how designers are on guard against your urge to "step into design"? That is not an offense — it is an industry consensus. What you should do most is thoroughly explain "why we are building this feature" (business/user goals), and then leave how to design it to UX, so you save yourself effort and get more professional results.
V. The RACI Responsibility Assignment Matrix: A Tool to Nail Down "Who Owns This Work" Once and For All
Previous sections diagnosed the root cause as "unclear responsibilities", and RACI is the most direct prescription.RACI (Responsibility Assignment Matrix) = A table with tasks listed vertically and roles listed horizontally; each intersecting cell is filled with one letter to clarify each person's role in each task:
| Letter | Meaning | Quantity rule | Example |
|---|---|---|---|
| R = Responsible | The person who actually does the work | Multiple people allowed | User researchers are responsible for running usability tests |
| A = Accountable | The person who takes ultimate responsibility for completion timeline and quality | Each task can have only one A | The UX lead both oversees research and participates hands-on |
| C = Consulted | People who need to provide professional input (two-way communication) | Multiple people allowed | Subject-matter experts across domains |
| I = Informed | People who need to be kept updated on progress but do not work on the task directly (one-way notification) | Multiple people allowed | Stakeholders, legal, marketing |
Flexibility of RACI——Both roles and tasks can be customized per team:
- Roles: UX side (UX designers, user researchers, information architects) + key partners (PM, PO, engineers, Scrum Master)
- Tasks arranged by phase: Strategy phase (define vision/goals/strategy/roadmap) → Discovery phase (user interviews/competitive analysis) → Design phase (prototypes/usability testing) → Delivery phase (release plan/QA/product demo). The "X" in the diagram indicates that the role does not participate at all.
Why + when to use it: Without a RACI chart, these problems easily arise: necessary roles are left out, people are brought in too late, affected parties are forgotten to be notified, and misunderstandings arise over "who is responsible". The best times to adopt it are:① After a retrospective, when the team mentions "so-and-so was left out / tasks were delayed";② When a new project kicks off, hold an initial division-of-labor discussion during a Scrum sprint or product increment phase. It is recommended that the UX team take the lead in proposing it, promote it as an experimental tool, and have it jointly developed by all members(not filled out by one person alone and handed off to everyone else).
When assigning tasks, in addition to job descriptions, also consider:
- skill sets: A PM who knows interview techniques can be Responsible (R) for user interviews, while the UX lead is responsible for creating interview questions (C/A) — do not rigidly assign work based solely on titles.
- Relationship with the team: Even if UX cannot directly conduct a particular interview this time, they should at least be Informed (I)to ensure outcomes flow back to the UX team in a timely manner.
- Availability and interest: Assign work reasonably based on each person's schedule and willingness.
Collaboration discipline: Roles marked as R or A for the same task must collaborate closely and clarify "who specifically does what"; do not turn it into one-way handoffs, but instead build a design culture of continuous collaboration(regularly check in on each other's progress).
VI. Five Recommendations to Improve PM×UX Collaboration (Relationship Management Level)
The previous section covered "division-of-labor tools"; this section covers "relationship management" — five ways of working together provided by NNGroup:
| # | Recommendation | Key actions | Counterexample (do not do this) |
|---|---|---|---|
| 1 | Share past experiences and current intentions | Openly discuss each other's skills, interests, past experiences, and areas for improvement to build trust and eliminate information asymmetry | Hiding information and hoarding intelligence for personal gain → unhealthy internal team politics |
| 2 | Collaborate on discovery research | PM defines business goals and OKRs (explaining the purpose of the research), UX leads high-quality user research, and PM + engineering jointly participate in discussion and analysis | PM or UX conducts discovery alone, or even skips discovery entirely → the entire team's understanding of user problems and opportunities is weakened |
| 3 | Mutually respect design capabilities and decision rights | UX leads the concretization of solutions (wireframes/prototypes), PM provides constructive input through whiteboard co-creation; UX understands that PM needs to make prioritization decisions based on feasibility | PM steps in to lead design; UX does not understand PM's prioritization responsibilities → role conflict |
| 4 | Accept feedback, do not be defensive | Be open to feedback from stakeholders/colleagues/users; when PM and UX disagree on a solution set aside subjective opinions and let user testing decide | Taking a defensive stance toward feedback → wasting time going in the wrong direction |
| 5 | Jointly understand and focus on metrics | Everyone on the team knows which metrics are being collected/tracked (PM leads consensus-building); UX combines qualitative insights with quantitative data; when PM reports good news to leadership, make sure the whole team receives recognition | Only the PM knows the metrics; PM takes all the credit and leaves the team out |
Overarching thread: Item 4, "use user testing to resolve disagreements", is the strongest dispute-resolution tool for PM×UX — when you and a designer are deadlocked over "should we design it this way", don't compete over who is louder;set aside both parties' assumptions and let real users vote. This is fast and convinces everyone.
VII. UXers Should Think Like Product Leaders (A Breakthrough Approach for the UX Side)
Previous sections were mostly from the PM perspective; this article is a self-breakthrough guide for UX(authored by Fuego UX) — but PMs who read it can better understand what designers are anxious about, and how a "designer who wants to advance" will approach you.
The triple dilemma facing UX today:
| Dilemma | Specific manifestations |
|---|---|
| Loss of decision-making power | Product and engineering hold the main decision-making power, and UX teams are small; although more and more UX roles now report to product, engineers still dominate most tech companies; designers often can only draw screens as requested and cannot influence product direction |
| Misaligned priorities + language barrier | Product wants to ship new features quickly, and designers cannot understand long-term goals → enthusiasm is dampened;PMs talk about business metrics such as user growth and retention rate; if designers cannot express value in the same language, their ideas will be ignored |
| Resource tightening + role ambiguity | After layoffs, UX headcount is reduced and work is split among other teams → collaboration increases but professional standards decline |
Four steps to break through (UX takes proactive action):
- Master the business (not just superficially)——First figure out what product leaders are doing (developing new features/maintaining customer relationships/monitoring competitors), observe how they collaborate, how they adjust priorities, and what formats they use to communicate (demos/spreadsheets/plans). See the big picture, not just your own patch; understand all of the company's products and services.
- Draw a "relationship map" to map out power and resource flows——NNGroup provides a practical template (excerpted in the table below), listing everyone you interact with: name/position/collaboration content/key support points/department. Use two symbols to clearly mark dependency relationships:
- ⊝ (minus sign) = You depend on the other party: Information/resources/collaboration you need to get from them
- ⊕ (plus sign) = The other party can provide you support: Help they can offer that you may not proactively ask for
| Name | Position | Collaboration content | Key support points | Department |
|---|---|---|---|---|
| Aditi L. | Product Manager | Product Backlog | ⊝ Useful feature designs, user behavior · ⊕ Prioritize addressing product UX debt | Product |
| Naomi I. | Director, Product Design | Overall UX lead | ⊕ Reporting line, sets strategic direction | UX |
| George Q. | UX Researcher | User research support | ⊝ Timely provision of research support · ⊕ User recruitment, research templates, personas | UX |
| Jess G. | Architect | Backend architecture and feasibility | ⊝ Feasibility recommendations · ⊕ Performance issue recommendations | Development |
What this diagram is for: it helps designers clearly see "what leverage they hold, and whose hands they are stuck in," shifting them from passive wireframe drawers to people who proactively manage relationships.Takeaways for PMs: A designer who draws this kind of relationship map is treating you as a "key collaborator" to build a relationship with, not someone coming to take your job — they are worth bringing closer.
- Strategic collaboration and communication— use business understanding to help PMs/engineering validate ideas and solve technical problems; good product leaders are all skilled at handling interpersonal relationships. Three key actions:Build good working relationships / Showcase work outcomes / Know when to compromise. When reporting to executives, be concise, pile on fewer technical details, and tailor your message to your audience.
- Adjust your approach by company type(to make UX a "product necessity" rather than an optional decoration):
| Company type | What UX should emphasize |
|---|---|
| Data-driven | How design improves key metrics (retention rate, conversion rate) |
| Engineer-led | How design improves efficiency and drives revenue; speak with data while understanding technical constraints |
| Product-led | How UX helps the product compete in the market; design aligns with product strategy, and research supports product direction |
Additional capabilities: Cultivate "workplace political intelligence + cross-functional skills" — understand the company atmosphere, distinguish which UX issues are important and which are trivial, don't box yourself into the job description (work across teams is becoming more and more similar, anyone can participate in research and planning), and do more practical quick research(getting fast user feedback > doing overly deep research).
VIII. Product-Led Growth (PLG) and the Role of UX
PLG (Product-Led Growth) = An acquisition/conversion/retention strategy that lets users try the product for free first, experience its value themselves, and then pay. It stands in contrast to the traditional SLG (Sales-Led Growth)— the latter requires users to watch a demo, sign a contract, and pay before they can use the product.
Three monetization models for PLG:
| Model | How it works |
|---|---|
| Freemium | Some features are permanently free; pay to unlock premium features |
| Free Trial | Full functionality is free for a limited time; pay to continue use after expiration |
| Hybrid | Combination of the first two |
Why choose PLG / What are the costs:
| Advantages | Disadvantages |
|---|---|
| Quickly delivers value to users (shortens the time from "first contact" to "perceived value") | High upfront costs: you need to build and maintain the product well even for non-paying users |
| Cost savings: no need to insert sales representatives into the customer journey | Requires more paying users: paying users must support the large number of non-converted trial users |
| Risk diversification: not dependent on contract revenue from a small number of large customers |
Six key PLG metrics (PMs must monitor):
| Metric | Definition | Direction |
|---|---|---|
| Time to Value | How long it takes from first contact to perceiving value | The smaller the better |
| Conversion Rate | Proportion of free users who become paying users | The larger the better |
| Retention Rate | Proportion of users who return within a given period | The larger the better (low retention cost, high return) |
| Churn Rate | Proportion of users who do not return within a given period | The smaller the better |
| Usage-Churn | Proportion of users at risk of churning due to reduced usage | The smaller the better |
| Customer Acquisition Cost (CAC) | Cost to acquire one new customer | The smaller the better |
Why UX is the lifeline in PLG: Under PLG, the user's first experience directly determines success or failure— if the first experience is poor, users will switch to a competitor in seconds (there is no salesperson in the middle to step in and retain them). Therefore, UX's job is to "optimize the first experience + clear usage barriers" to reduce risk for PLG.
7 tactics for UX to support PLG:
- Keep a close eye on PLG metrics— tie every design/content change to specific PLG metrics, and clearly articulate the value contribution.
- Reduce friction in the acquisition stage— make the first experience easy to use and high-value; reduce unnecessary steps,avoid login walls(unless verification is truly necessary).
- Minimize Time to Value— study user mental models so that product value is perceived quickly.
- Focus on converted users— according to the Pareto principle (80/20 rule), prioritize serving the 20% of users who contribute the most revenue, and dig deep into the behavior and feedback of high-value customers.
- Improve retention— compare behavioral differences between "converted vs. non-converted" users to identify pain points; use both quantitative and qualitative methods.
- Prevent churn— predict churn risk based on usage behavior and intervene proactively; push new features to low-activity users to drive engagement.
- Cross-business communication— align with product/marketing/sales so that UX goals serve the overall business strategy; define macro and micro conversion metrics, and track key milestones in the user journey.
Bridging for PMs: Almost every one of these 7 tactics requires deep collaboration between UX and you (metric alignment, login wall tradeoffs, conversion funnel optimization) — which brings us back to Section 6, "Jointly focus on metrics." Under the PLG model, UX is no longer about "making things look pretty," but is directly responsible for conversion/retention numbers; this is the best entry point for you to empower designers and also hold them accountable for results.
IX. Product and UX Glossary (Common Language for PM×UX)
Core terms compiled by NNGroup, grouped by topic — this is the dictionary for PMs and UX to "speak the same language."
Revenue models:
- Advertisement-Based revenue model: Profit by selling ad space in the product, billed by impressions/clicks.
- Freemium: Some features are free; pay to unlock premium features.
- Subscription revenue: Pay monthly/annually for usage rights.
Business and strategy:
- Blue-Ocean strategy: Create an entirely new market through significant differentiation, avoiding head-on competition.
- Red Ocean: A highly competitive market with homogeneous products, where players compete for customers through low cost or differentiation.
- Business-Model Canvas: A tool describing the nine building blocks of a business model (value proposition/customer segments/channels/revenue streams, etc.).
Product development and management:
- Minimum Viable Product (MVP): An initial version that demonstrates core value with minimal resources, used to gather feedback quickly.
- Product Vision: An idealized statement of the product's future impact and user value.
- Product Lifecycle: Four stages: Introduction → Growth → Maturity → Decline.
- Product Roadmap: A high-level plan showing future work priorities and goals, including cross-functional content for UX/development/marketing.
Users and market:
- Customer Feedback Loop: Continuously collect and analyze user feedback (surveys/feedback forms/social media) to iterate on the product.
- Customer Lifetime Value (CLV): The projected total revenue a customer will generate for the business over their entire lifecycle.
- Target Market: The expected customer group defined by demographics/behavior/needs.
- Total Addressable Market (TAM): Potential total market revenue = number of potential customers × average revenue per customer.
Operations and technology:
- Bottleneck: When requests/workload exceed system processing capacity, causing performance degradation.
- Feature Creep: Adding more and more features actually reduces usability and utility.
- Feature Flag: A technology that allows features to be toggled on or off without redeploying code, facilitating experiments/quick fixes.
- UX Debt: The cost of sacrificing long-term experience for short-term solutions, which erodes satisfaction and brand loyalty (analogous to technical debt).
Measurement and decision-making:
- OKR (Objectives and Key Results): A framework for setting quantifiable goals; objectives are qualitative, key results are quantitative.
- Time to Value: The time it takes for a user to obtain core value (a core PLG metric).
- Customer Acquisition Cost (CAC): The average cost to acquire one new customer (marketing + sales, etc.).
- Value Proposition: The unique core value a product provides, which is key to attracting and retaining users.
Sourced from NNGroup Topics / Product and UX Study Guide - Product and Designer (8 articles). This is the batch in the NNGroup series specifically focused on "PM × UX collaboration," and it complements the foundational concepts in NNGroup UX Fundamentals (UX/Usability/UI Definition Distinctions · Human-Centered Design (HCD) · Design Thinking 5+1 Phases · Product Triad DVF · No Research, No UX · Research Methods Three-Dimensional Framework/20 Methods/9 Quantitative Methods/User Interviews · 6-Step Solution Tradeoff · 10 Heuristics Index · UX Career 5 Stages/Transition/Portfolio/Resume), UX team management in NNGroup UX Team Organization and Operations (DesignOps 5 Structures · Centralized/Embedded/Matrix Reporting · MUXI · RACI · Role Responsibilities · Onboarding 30/60/90 · UX Research Plan PET(S) · Design-Strong Teams · Team Decision Quality: Confirmation Bias/Groupthink/Written Thinking · UX 6-Level Maturity and Biggest Challenges · Refine/Remodel/Rebuild); on the research methods side, it can be connected to personas in NNGroup Personas (Essence/Three Types/Scope Hierarchies/Creation/Comparison with JTBD-Prototypes-Segmentation/Application/Maintenance/5 Big Failures) and usability testing in NNGroup Usability Testing and the Ten Usability Heuristics (Full Table of 10 Heuristics · Complex Application Use · User Pleasure Hierarchy · Testing Methods 5-User Rule/Recruitment/Remote/Task Scenarios/Step-by-Step Tasks/Attitude vs. Behavior/4-Step Analysis/Small Sample Error/Competitive Evaluation). Images/original documents are kept in sources.
Sources and related materials
- NNGroup UX Fundamentals (UX/Usability/UI Definition Distinctions · Human-Centered Design (HCD) · Design Thinking 5+1 Phases · Product Triad DVF · No Research, No UX · Research Methods Three-Dimensional Framework/20 Methods/9 Quantitative Methods/User Interviews · 6-Step Solution Tradeoff · 10 Heuristics Index · UX Career 5 Stages/Transition/Portfolio/Resume)
- NNGroup UX Team Organization and Operations (DesignOps 5 Structures · Centralized/Embedded/Matrix Reporting · MUXI · RACI · Role Responsibilities · Onboarding 30/60/90 · UX Research Plan PET(S) · Design-Strong Teams · Team Decision Quality: Confirmation Bias/Groupthink/Written Thinking · UX 6-Level Maturity and Biggest Challenges · Refine/Remodel/Rebuild)