Inspired cover image
My Rating: 5/5

Inspired by Marty Cagan

High-Level Summary

A battle-tested guide to product management from a living Silicon Valley legend. Highly recommend if you want to deeply understand the ins-and-outs of customer-driven product discovery.


10 Biggest Problems with Waterfall

  1. The source of ideas. Stakeholder's aren't the best source of ideas.
  2. Business cases imply you can know the right solution and how much it'll cost. (Often wrong on both counts.)
  3. Product roadmaps don't work for two reasons: 1) Half of the ideas we try simply won't work out and 2) The promising ideas typically require several iterations to deliver the right business value.
  4. Waterfall defaults the role of the product manager to gather and document requirements for engineers.
  5. Design is implemented far too late in the game, resulting in "lipstick on a pig."
  6. Engineering gets introduced to the problem way too late. "If you're just getting engineers to code, you're only getting about half their value."
  7. Agile principles aren't applied until far too late — only affecting delivery.
  8. The entire process is project-centric rather than solving for business outcomes.
  9. Customer validation is pushed until the end (way too late!)
  10. Missed opportunity cost of what the team should have been building instead.

3 Principles of Empowered Product Teams

  1. Risks are tackled up front, rather than at the end.
  2. Products are defined and designed collaboratively, rather than sequentially.
  3. It's all about solving problems, not implementing features.

Product discovery answers 4 critical questions:

  1. Will the user buy this (or choose to use it?)
  2. Can the user figure out how to use this?
  3. Can our engineers build this?
  4. Can our stakeholders support this?

What is a Prototype?

A prototype is not something that's ready for prime time. Not something your team would try to sell and stand behind. Instead it's optimized for fast, cheap learning. Strong teams test 10-20 experiments per week using prototypes.

Prototype vs. MVP

The MVP should be a prototype, not a product. A product means your customers can run their business on what you release, sell & support. Building a fully baked product to learn is a huge waste — even if it's simple. The Product Manager is ultimately accountable for a product's success because their primary responsibility is to evaluate opportunities and determine what the product team builds for customers.

When a product succeeds, it's because everyone on the team did what they needed to do. But when a product fails, it's the product manager's fault.

Successful PMs must be the best versions of smart, creative and persistent.

  • Smart = Stay curious. Learn quickly. Apply new technologies.
  • Creative = Solve business problems by thinking outside the normal product box.
  • Persistent = Use evidence to push past resistance, build cross-functional bridges, & communicate consistently

Core Principles to Structure Successful Product Teams

  1. Alignment with investment strategy
    • Intentionally spread out your investments over time & risk.
  2. Minimize dependencies
    • Reduce whenever possible to increase speed & feeling of autonomy.
  3. Ownership and autonomy
    • Harder than it sounds, but aim for a team of empowered - yet accountable - missionaries, not mercenaries.
  4. Maximize Leverage
    • When the price is right, don't be afraid to create shared services like a Platform squad.
  5. Product vision and strategy
    • Product Vision = where the organization is trying to go.
    • Product Strategy = Describes major milestones to get there.
  6. Team size
    • Minimum size for a product team: two engineers + a product manager.
    • Max ratio: 10-12 engineers / 1 product manager + designer
  7. Alignment with architecture
    • Architectures drive technologies, which drive skillsets.
    • Warning signs: Teams shouldn't constantly feel like they're fighting architecture, disproportionately dependent on each other, or always moving too slowly.
  8. Alignment with the customer
    • Example: In a two-sided marketplace, splitting into separate buyer and seller teams can enable product teams to go deep with their specific customers.
  9. Alignment with business
    • Consider the above factors first, then feel free to prioritize the role of business lines built around a shared, foundational product.
  10. Structure is a moving target
    • Review your team structure roughly every year to account for your organization's natural evolution.

The Problem with Product Roadmaps: Two Inconvenient Truths

  1. At least half of product ideas won't pan out because they're invalidated by one of the 4 risks (Value, Usability, Feasibility, Business).
  2. Time to money isn't perfectly measurable. Successful products usually take several iterations to successfully deliver the intended business value even if your products pass the 4 Risks Test.

Remember: We need to solve a problem, not just build a feature.

The Alternative to Roadmaps

Despite their systematic flaws, many organizations use product roadmaps for two reasons.

  1. Management wants to ensure teams are working on the highest impact items for the business.
  2. Key players in the business need commitments to concrete dates so they can plan effectively.

Luckily, two lifesaving resources can replace the product roadmap at a tech company and provide more reliable value by enabling high-integrity commitments:

  1. Product Vision and Strategy
  2. Business Objectives

Get a New Book Summary in Your Inbox Every Monday

Every week I'll send you bite-size learnings from battle-tested books to help you level-up your life and career.

No spam. Unsubscribe anytime.