Lessons from Melissa Perri

Lessons from Melissa Perri

Melissa Perri is a product management educator, consultant, and author of Escaping the Build Trap. She coined the "build trap" to describe how companies fail when they mistake shipping a high volume of features for creating actual value. This profile covers her advice on product strategy, the daily work of a product manager, and how to structure organizations around outcomes.

Part 1: The Build Trap

1. On the core definition: "The build trap is when organizations become stuck measuring their success by outputs rather than outcomes." — Source: [Escaping the Build Trap]
2. On misaligned focus: "It’s when they focus more on shipping and developing features rather than on the actual value those things produce." — Source: [Manas Saloi]
3. On proxy metrics: When companies do not understand user problems, they create a proxy that is easy to measure, like the sheer quantity of features delivered. — Source: [Will Larson]
4. On agile theater: Traditional Agile implementations often ignore effective product management by assuming someone else has already validated the ideas, optimizing only the production of software. — Source: [Unremarkable Tester]
5. On the illusion of progress: "The biggest thing I've learned in product management is to always focus on the problem. If you anchor yourself with the why, you will be more likely to build the right thing." — Source: [Goodreads Quotes]
6. On bad ideas: "Kill the bad ideas before they take up too much time and energy from the teams and before you get hooked on them." — Source: [Escaping the Build Trap]
7. On shifting perspective: "Instead, fall in love with the problem you are solving." — Source: [Goodreads Quotes]
8. On defining work: "For too long, product teams have defined their work as shipping the next release… The vast majority of our conversations take place in the solution space." — Source: [SuperSummary]
9. On the feature factory: A feature factory environment assumes success inherently comes from launching features rather than solving problems. — Source: [SuperSummary]
10. On the JIRA trap: "The point of Product Management is not to put things in JIRA in a specific format... The point of Product Management is to create valuable products that customers love." — Source: [Medium]

Part 2: Defining Value and Outcomes

1. On the value exchange: Product management is a two-way value exchange: solving customer problems in order to achieve business objectives. — Source: [Melissa Perri]
2. On useless software: "If you're not doing both of those things, your product is just a fancy piece of code for show." — Source: [Melissa Perri]
3. On understanding customers: "When companies do not understand their customers' or users' problems well, they cannot possibly define value for them." — Source: [Will Larson]
4. On solving big problems: "Solving big problems for customers creates big value for businesses." — Source: [Product Thinking Podcast]
5. On superhuman users: "You want to turn your user into a superhuman—how do you make them awesome? That's the value you provide." — Source: [Gainsight]
6. On output constraints: Outputs are necessary to produce outcomes, but outputs alone do not guarantee that value has been created. — Source: [Manas Saloi]
7. On measuring success: The primary metric of success must shift from the number of features shipped to the business and customer impact achieved. — Source: [Will Larson]
8. On missing data: "If you don't have the data then you can't make secure decisions and alter course." — Source: [ProductPlan]
9. On blame: Stop blaming the user when they do not use a feature; take accountability for failing to validate the hypothesis before building. — Source: [Melissa Perri]
10. On the ultimate goal: Value is realized only when a user successfully achieves their goal using your product. — Source: [Escaping the Build Trap]

Part 3: Product Strategy

1. On what strategy is: "Strategy is a deployable decision-making framework, enabling action to achieve desired outcomes, constrained by current capabilities, coherently aligned to the existing context." — Source: [Escaping the Build Trap]
2. On what strategy is not: "A good strategy is not a plan; it’s a framework that helps you make decisions." — Source: [Goodreads Quotes]
3. On strategy connection: Product strategy connects the company's vision and economic outcomes back to individual product initiatives and solution options. — Source: [Manas Saloi]
4. On the illusion of strategy: "Most product managers think they're doing strategy, but they're not." — Source: [Aakash Gupta]
5. On the company vision: Strategy starts with a high-level, long-term 5-to-10 year direction that anchors the entire organization. — Source: [Melissa Perri]
6. On strategic intents: Organizations must translate vision into strategic intents—specific business goals used to achieve that vision. — Source: [Product Thinking]
7. On product initiatives: Strategic intents are realized through product initiatives, which are the actionable steps and experiments that teams tackle. — Source: [Dragonboat]
8. On capabilities: True strategy must be constrained by the company's current and realistic capabilities, not wishful thinking. — Source: [Goodreads Quotes]
9. On alignment: Strategy must be coherently aligned to the existing context of the market and the organization. — Source: [Escaping the Build Trap]
10. On decision deployment: A strategy is only successful if it can be deployed down the hierarchy so teams can make independent decisions aligned with the top. — Source: [Tim Woods]

Part 4: Product Discovery and Problem Solving

1. On generative research: "Problem-based user research is generative research, meaning that its purpose is to find the problem you want to solve." — Source: [Escaping the Build Trap]
2. On the Product Kata: Teams should use an iterative framework—asking what the goal is, where they are now, what the biggest obstacle is, and what they expect to happen. — Source: [Medium]
3. On reducing unknowns: "Product management is the domain of recognizing and investigating the known unknowns and of reducing the universe around unknown unknowns." — Source: [Unremarkable Tester]
4. On continuous discovery: Discovery should not be isolated to a research department; it must involve the product trio of Product Manager, UX Designer, and Tech Lead. — Source: [The Fountain Institute]
5. On the solution space: Teams spend too much time arguing over solutions before they have fully mapped and agreed upon the exact problem. — Source: [UX Podcast]
6. On validating ideas: Do not commit to full-scale development until you have optimized a solution through experimentation and learning. — Source: [Medium]
7. On market opportunity: Product teams must actively size the market opportunity during discovery to ensure the problem is worth solving. — Source: [ProductPlan]
8. On asking the right questions: Discovery is fundamentally about altering your course based on newly uncovered evidence rather than confirming what you already believe. — Source: [Escaping the Build Trap]
9. On getting hooked: It is dangerous to get attached to an idea before gathering evidence; kill it early if the problem does not exist. — Source: [Goodreads Quotes]
10. On exploring the problem: Teams must explicitly separate the act of exploring the problem from the act of exploring the solution. — Source: [Medium]

Part 5: The Product Management Role

1. On PM responsibilities: A product manager's role is to be a decision-maker who owns outcomes, not just a facilitator who coordinates tasks. — Source: [Aakash Gupta]
2. On the danger of note-taking: PMs who act primarily as meeting schedulers and note-takers fail to drive the actual product strategy. — Source: [Aakash Gupta]
3. On learning: "The best product managers are the best learners." — Source: [Shaping Software]
4. On front-of-funnel work: Effective product management requires dedicated time at the front of the funnel to generate and validate ideas. — Source: [Unremarkable Tester]
5. On filling backlogs: Success for a PM is not measured by making sure developers have full backlogs of tickets. — Source: [Medium]
6. On framework obsession: Over-indexing on specific goal-writing frameworks can distract PMs from simply creating a valuable product. — Source: [Medium]
7. On owning the outcome: If a shipped feature fails to produce the intended business outcome, the product manager must take responsibility for the gap. — Source: [Escaping the Build Trap]
8. On the art of PM: Product management is an art that requires balancing deep customer empathy with harsh economic realities. — Source: [Melissa Perri]
9. On managing risk: A core part of the PM job is systematically retiring risk before expensive engineering work begins. — Source: [Unremarkable Tester]

Part 6: Leadership and the CPO Transition

1. On the CPO's core value: "The chief product officer is the cornerstone of the product team in companies, helping to tie together the business outcomes to the roadmap." — Source: [Manas Saloi]
2. On boardroom impact: The CPO must be able to confidently represent the product's financial and strategic impact directly to the board. — Source: [Bookey]
3. On time allocation: Chief Product Officers should spend more than 75% of their time on strategic initiatives, leaving tactical execution behind. — Source: [Amplitude]
4. On role confusion: New CPOs frequently struggle because they fail to delegate tactical work or lack clarity on executive expectations. — Source: [Melissa Perri]
5. On bridging the gap: The CPO acts as the critical bridge between the high-level business goals and the daily work of the product organization. — Source: [Amplitude]
6. On executive presence: CPOs must earn the trust of the broader executive team by communicating in terms of business value, not technical milestones. — Source: [Medium]
7. On transitioning from VP: Moving from a VP of Product to a CPO requires shifting from managing product managers to managing the entire product capability of the business. — Source: [Produx Labs]
8. On aligning the C-suite: A successful CPO ensures the CEO, CTO, and CRO share the same definition of product success. — Source: [Dragonboat]
9. On team structure: Leaders must design an organizational structure that directly supports the strategic intents of the company. — Source: [Tim Woods]

Part 7: Organizational Alignment and Agile

1. On Agile limitations: "Agile does indeed promote a better way of collaboration and a faster method of building software, but it largely ignores how to do effective product management." — Source: [Unremarkable Tester]
2. On half measures: Many organizations invest in Agile transformations but fail because they don't change their structure to align with products. — Source: [Scrum.org]
3. On value streams: "Every organization should strive to optimize this flow [of value] in order to get value out of the door faster to customers." — Source: [Unremarkable Tester]
4. On organizing around value: To speed up value delivery, it makes sense to organize your internal teams around the value stream rather than functional silos. — Source: [Unremarkable Tester]
5. On a strong vision: "A strong company vision keeps everyone aligned and helps teams focus their efforts on a common goal, rather than drifting." — Source: [Product Thinking]
6. On failing alignment: If you ask different people in a company about the most important goal and get different answers, the company is not aligned. — Source: [Manas Saloi]
7. On tying work back: Everyone in the organization should be able to articulate how their specific daily work ties back to the top-level company goal. — Source: [Manas Saloi]
8. On building capability: Implementing Agile ceremonies is not enough; companies must deliberately develop a dedicated product management capability. — Source: [Scrum.org]

Part 8: Product Operations and Scaling

1. On the definition of Product Ops: "Product operations is where product management becomes a scalable resource and function for companies instead of a made-to-order one-off." — Source: [ProductPlan]
2. On strategic enablement: "Product Operations is there to enable strategic decision-making." — Source: [Reddit AMAs]
3. On the curling analogy: "Product Management is the guy lining up the angle of the shot, and Product Operations is the guy furiously brushing the path so that the rock can effortlessly glide across the ice." — Source: [ProdPad]
4. On removing obstacles: Product ops is the art of removing obstacles from evidence-based decision making for product managers. — Source: [Melissa Perri]
5. On PM bandwidth: The primary reason PMs do not talk to customers is a lack of time; product ops removes the friction of recruiting and scheduling. — Source: [Reddit AMAs]
6. On business data: A core pillar of product ops is building infrastructure that easily surfaces business data and insights to the product team. — Source: [Befreed]
7. On continuous insight: Product ops embeds continuous user insight loops so that teams are perpetually fueled by market reality. — Source: [Befreed]
8. On codifying practice: Scaling requires codifying repeatable workflows and practices to reduce organizational chaos and increase speed. — Source: [Sobrief]
9. On infrastructure: Ultimately, product operations provides the connective infrastructure that allows a product organization to grow without losing its strategic alignment. — Source: [Reforge]