Fatskills
Practice. Master. Repeat.
Study Guide: Principles of Product Management: What is Product Management (PM vs Product Owner vs Project Manager, Three Pillars: Business, Tech, UX)
Source: https://www.fatskills.com/product-management/chapter/product-management-what-is-product-management-pm-vs-product-owner-vs-project-manager-three-pillars-business-tech-ux

Principles of Product Management: What is Product Management (PM vs Product Owner vs Project Manager, Three Pillars: Business, Tech, UX)

By Fatskills Exam Guides Team — the exam nerds behind 28,500+ quizzes and 2.1M practice questions across 500+ global exams.

⏱️ ~9 min read

What is Product Management (PM vs Product Owner vs Project Manager, Three Pillars: Business, Tech, UX)


What This Is

Product Management (PM) is the discipline of building the right product for the right users at the right time—balancing business goals, technical feasibility, and user needs. It’s not about coding, designing, or managing timelines (though you’ll collaborate with those teams). Instead, PMs define the "what" and "why" (vision, strategy, roadmap) while empowering engineers, designers, and marketers to execute the "how." A real-world example: When Stripe launched its Radar fraud detection tool, the PM had to align sales (business), engineers (tech), and merchants (UX) to create a product that reduced fraud without increasing false positives—proving PM’s role as the "CEO of the product" (without the authority).


Key Terms & Frameworks

  • Product Manager (PM) vs Product Owner (PO) vs Project Manager (PjM):
  • PM: Owns the product vision, strategy, and outcomes (e.g., "Should we build a fraud tool?"). Focuses on user problems, market fit, and business impact.
  • PO (Scrum/Agile role): A tactical subset of PM—focuses on backlog refinement, user stories, and sprint execution (e.g., "What goes into the next sprint?"). Often reports to a PM in larger orgs.
  • PjM: Owns timelines, budgets, and cross-functional coordination (e.g., "When will the fraud tool launch?"). Measures success in on-time delivery, not product impact.
  • Trap: PO-PM. A PO without a PM is like a chef without a menu—you’ll ship features, but they may not solve real problems.

  • The Three Pillars of PM:

  • Business: Revenue, growth, market share, unit economics (e.g., "Will this feature increase LTV?").
  • Tech: Feasibility, scalability, technical debt, system design (e.g., "Can we build this without breaking our API?").
  • UX: User needs, pain points, usability, delight (e.g., "Does this reduce friction in checkout?").
  • Example: Amazon’s 1-Click Checkout balanced all three: Business (higher conversion), Tech (patented system), UX (reduced steps).

  • Product Lifecycle (PLC): Discovery-Definition-Delivery-Growth-Sunset

  • Example: Slack’s huddles went from Discovery ("Do users want audio chats?") to Definition ("MVP scope") to Delivery (launch) to Growth (iterations).

  • Jobs to Be Done (JTBD): Framework to uncover why users "hire" a product (not just what they say they want).

  • Formula: "When [situation], I want to [motivation], so I can [outcome]."
  • Example: "When I’m in a noisy café, I want to quickly mute my mic, so I can take a call without background noise." (Led to Slack’s "Push to Mute" feature.)

  • North Star Metric (NSM): The single metric that best captures the core value your product delivers.

  • Examples:
    • Airbnb: Nights booked (not revenue—focuses on user value).
    • Facebook: Daily Active Users (DAU) who connect with 10+ friends in 30 days.
  • Trap: NSM-vanity metric (e.g., "app downloads"-NSM for a social app).

  • ICE Score (Impact, Confidence, Ease): Prioritization framework: Impact × Confidence × Ease (1–10 scale).

  • Variables:
    • Impact: How much this moves the NSM?
    • Confidence: How sure are you? (Data, user research, stakeholder alignment.)
    • Ease: Effort (engineering, design, legal).
  • Example: A fintech PM might score:

    • "Add biometric login" = 8 × 9 × 7 = 504
    • "Build a crypto wallet" = 10 × 5 × 3 = 150
  • Double Diamond (Design Thinking): Discover-Define-Develop-Deliver

  • Steps:

    1. Discover: Diverge (user interviews, data analysis).
    2. Define: Converge (synthesize insights, pick a problem).
    3. Develop: Diverge (brainstorm solutions).
    4. Deliver: Converge (prototype, test, ship).
  • Leading vs Lagging Indicators:

  • Leading: Predict future success (e.g., "Time to first value" in onboarding).
  • Lagging: Measure past success (e.g., "Retention at 30 days").
  • Example: For a fitness app, leading = "Workouts completed in first week"; lagging = "Churn rate at 6 months."

  • User Story vs Use Case:

  • User Story: Who (user) + What (action) + Why (outcome). Format: "As a [user], I want [action] so that [outcome]."
    • Example: "As a busy parent, I want to save recipes to a list so I can cook them later."
  • Use Case: Detailed flow of interactions between user and system (e.g., "User clicks ‘Save Recipe’-System adds to ‘My Recipes’ list-User receives confirmation toast").
  • Trap: User stories-requirements. They’re placeholders for conversations.

  • MVP vs MMP (Minimum Marketable Product):

  • MVP: Smallest experiment to validate a hypothesis (e.g., a landing page to test demand for a feature).
  • MMP: Smallest viable product that delivers value to users (e.g., a basic version of the feature with core functionality).
  • Example: Dropbox’s MVP was a video demo (not a working product) to test demand. Their MMP was the first beta with file sync.

  • The 4 D’s of Product Work: Discover-Define-Develop-Deploy

  • Example: For a food delivery app’s group ordering feature:
    1. Discover: User interviews reveal pain points in splitting bills.
    2. Define: Problem = "Users abandon carts when splitting payments is hard."
    3. Develop: Prototype a "split bill" UI.
    4. Deploy: A/B test with 10% of users.

Step-by-Step / Process Flow

How to Apply the Three Pillars in a Real Product Scenario Example: Launching a "Subscription Upsell" feature for a SaaS tool.

  1. Align on Business Goals
  2. Action: Meet with finance/marketing to define success (e.g., "Increase ARPU by 15% in 6 months").
  3. Tool: OKRs (Objective: "Improve monetization"; Key Result: "15% ARPU growth").
  4. Output: A clear business case (e.g., "Upselling to Pro plan = $X in new revenue").

  5. Understand User Needs (UX Pillar)

  6. Action: Conduct 5–10 user interviews with power users and churned users.
  7. Question: "What’s missing in the current plan that would make you upgrade?"
  8. Tool: JTBD ("When I hit usage limits, I want to upgrade seamlessly so I don’t lose access to features").
  9. Output: A list of pain points (e.g., "Users don’t know what they’ll get in Pro plan").

  10. Assess Technical Feasibility (Tech Pillar)

  11. Action: Sync with engineering to estimate effort (e.g., "Building a pricing page = 2 sprints; integrating Stripe = 1 sprint").
  12. Tool: ICE Score to compare options (e.g., "In-app upsell banner" vs "Email campaign").
  13. Output: A prioritized backlog (e.g., "Build in-app modal first—highest ICE score").

  14. Prototype & Test (UX + Tech)

  15. Action: Create a low-fidelity prototype (Figma) and test with 5 users.
  16. Tool: Usability testing (e.g., "Can users find the ‘Upgrade’ button in <3 clicks?").
  17. Output: Iterated design (e.g., "Move button to top-right; add tooltips").

  18. Launch & Measure (Business Pillar)

  19. Action: Soft-launch to 10% of users; track leading indicators (e.g., "Click-through rate on upsell banner").
  20. Tool: A/B test (e.g., "Does a discount increase conversions?").
  21. Output: Data to scale or pivot (e.g., "Discounts increase conversions by 20%—roll out to all users").

  22. Iterate (All Three Pillars)

  23. Action: Review lagging indicators (e.g., "ARPU at 30 days").
  24. Tool: Retrospective with team: "What worked? What didn’t? What’s next?"
  25. Output: Next sprint’s priorities (e.g., "Add annual billing option").

Common Mistakes

  1. Mistake: Confusing Product Owner with Product Manager.
  2. Correction: A PO is a tactical role (backlog, sprints); a PM is strategic (vision, roadmap). In startups, one person may do both, but in scale-ups, they’re separate. Why? Without a PM, you’ll ship features that don’t align with business goals.

  3. Mistake: Ignoring the Tech Pillar until late in the process.

  4. Correction: Involve engineers early (e.g., during discovery). Why? A "simple" feature might require 6 months of refactoring—better to know upfront.

  5. Mistake: Prioritizing features based on stakeholder opinions (e.g., "The CEO wants this").

  6. Correction: Use data + user research (e.g., ICE scores, JTBD). Why? Stakeholders are often wrong about what users want (see: New Coke).

  7. Mistake: Treating UX as "making it pretty" (vs. solving user problems).

  8. Correction: Focus on usability and outcomes (e.g., "Does this reduce time to first value?"). Why? A beautiful app that’s hard to use will fail (see: Google+).

  9. Mistake: Measuring success with vanity metrics (e.g., "app downloads").

  10. Correction: Tie metrics to business impact (e.g., "Retention at 30 days"). Why? Downloads-engaged users.

PM Interview / Practical Insights

  1. Tricky Distinction: "How do you balance business, tech, and UX?"
  2. What they’re probing: Can you prioritize trade-offs without alienating teams?
  3. How to answer:

    • Business: "I start with the company’s North Star Metric (e.g., revenue, retention)."
    • Tech: "I partner with engineers early to assess feasibility and trade-offs (e.g., 'This feature will take 3 sprints—is it worth it?')."
    • UX: "I validate assumptions with users (e.g., 'Do they even want this?')."
    • Example: "For a subscription upsell, I’d prioritize UX (clear value prop) over tech (fancy animations) because users won’t upgrade if they don’t understand the benefit."
  4. Trap: "What’s your process for prioritization?"

  5. What they’re probing: Do you have a repeatable framework, or do you wing it?
  6. How to answer:

    • "I use ICE or RICE to score ideas objectively."
    • "I validate with user research (e.g., surveys, interviews)."
    • "I align with stakeholders (e.g., sales, marketing) to ensure buy-in."
    • Trap: Don’t say, "I prioritize based on gut feeling."
  7. Tricky Question: "How do you handle a conflict between engineering and design?"

  8. What they’re probing: Can you mediate trade-offs without taking sides?
  9. How to answer:

    • "I reframe the debate around user impact (e.g., 'Will this design slow down the page load time?')."
    • "I prototype and test (e.g., 'Let’s A/B test both options')."
    • "I escalate to data (e.g., 'What does our analytics say about this user flow?')."
  10. Practical Insight: "How do you define an MVP?"

  11. What they’re probing: Do you understand lean experimentation?
  12. How to answer:
    • "An MVP is the smallest experiment to validate a hypothesis (e.g., a landing page to test demand)."
    • "It’s not a half-baked product—it’s a focused test (e.g., Dropbox’s demo video)."
    • Trap: Don’t say, "MVP = first version of the product."

Quick Check Questions

  1. Scenario: Your team wants to add a dark mode to your app. It’s popular with power users but will take 2 sprints to build. How do you decide?
  2. Answer: "I’d use the ICE framework to score it against other priorities. If dark mode has high Impact (e.g., improves retention) and high Confidence (e.g., user research shows demand), but low Ease (2 sprints), I’d weigh it against other initiatives. If it’s not a top priority, I’d deprioritize it or find a quicker way to test demand (e.g., a toggle in settings)."
  3. Why? Dark mode is a "nice to have"—you need to validate its impact on the NSM.

  4. Scenario: Your CEO wants to add a feature that your data shows will increase engagement but hurt NPS. How do you respond?

  5. Answer: "I’d present the trade-offs clearly: 'This feature may boost short-term engagement, but our NPS data suggests it will frustrate users long-term. Let’s test it with a small cohort to validate the impact on both metrics before scaling.'"
  6. Why? Never ignore data—even if the CEO is pushing for it.

  7. Scenario: Your engineering team says a feature will take 6 months to build, but your sales team says customers need it in 3 months. What do you do?

  8. Answer: "I’d break the feature into smaller milestones (e.g., MMP) and deliver the highest-value pieces first. I’d also explore workarounds (e.g., manual processes, third-party tools) to unblock sales while we build the full solution."
  9. Why? You can’t always build everything—focus on minimum viable value.

Last-Minute Cram Sheet

  1. PM vs PO vs PjM: PM = strategy, PO = backlog, PjM = timelines.
  2. Three Pillars: Business (revenue), Tech (feasibility), UX (user needs).
  3. JTBD Formula: "When [situation], I want to [motivation], so I can [outcome]."
  4. ICE Score: Impact × Confidence × Ease (1–10 scale).
  5. MVP-MMP: MVP = experiment; MMP = smallest viable product.
  6. North Star Metric: The one metric that captures your product’s core value (e.g., Airbnb = nights booked).
  7. Leading vs Lagging: Leading = predictive (e.g., onboarding completion); Lagging = historical (e.g., retention).
  8. User Story Format: "As a [user], I want [action] so that [outcome]."
  9. Double Diamond: Discover-Define-Develop-Deliver.
  10. Trap: PO-PM. A PO without a PM is like a chef without a menu.