Review

I was wrongly skeptical of this book before reading it. In hindsight, I should have read it sooner. I thought the book would attempt to cover product management end-to-end without depth. Instead, I found the book focused on where theory hits practice and things don't work as you expect. Clearly, the author's been in the trenches and experienced that cognitive dissonance between theory and practice. And for that, this book deserves a place on your product management shelf.

You Might Also Like:

The Lean Product Playbook

The Lean Product Playbook offers the clearest description of a process to achieve product-market fit. The book's primary premise is that there is a logical sequence to follow, which includes:

andrewclark.co.uk

Book Summary: Continuous Discovery Habits by Teresa Torres

In Continuous Discovery Habits, Teresa Torres introduces a framework for building the right product by maintaining ongoing, weekly touchpoints with customers. She advocates for continuous discovery—a process of conducting small research activities to uncover valuable insights. Rather than viewing discovery as a one-time event, Torres emphasizes the importance of consistently framing problems in a customer-centric way and exploring the opportunity space. Using the Opportunity Solution Tree, teams can prioritize what to do next and focus on high-impact opportunities. Ideal for product managers seeking to balance discovery and delivery, and build products that create value for both the business and its customers.

andrewclark.co.uk

Book Review and Summary: Escaping the Build Trap by Melissa Perri

In Escaping the Build Trap, Melissa Perri explains how companies can stop building features nobody wants and start focusing on creating products that deliver real value. By shifting from a build-driven to a product-led mindset, teams can prioritize customer needs, measure impact, and develop a clear strategy. The book outlines how product managers play a critical role in guiding organizations through this transition, emphasizing outcomes over outputs. Learn how to restructure teams, align strategies, and leverage research to escape the build trap and ensure that every feature delivers meaningful results. Perfect for product leaders aiming to build with intent.

andrewclark.co.uk

Key Takeaways

The 20% that gave me 80% of the value.

Product management involves stewarding a value exchange between a business and its customers without direct authority. Product managers are responsible for outcomes but rely entirely on influencing others. They bridge gaps across business goals, user needs, and technical execution by proactively filling whatever role is required rather than passively awaiting instruction.

Common pitfalls of ineffective product managers, such as the "Jargon Jockey" or the "Hero Product Manager," often stem from insecurity due to the intangible nature of their contributions. Effective product managers accept indirect recognition, understanding their value is realised through their team's success.

Curiosity is essential for product managers because it facilitates trust, builds context-awareness, and expands internal networks. Product managers should proactively learn about colleagues' work before assistance is needed, genuinely showing interest to continuously expand trust within the organisation.

Product managers benefit from adopting a growth mindset, constructively handling inevitable failures. Distinguishing personal worth from product outcomes allows transparency, humility, and openness, turning setbacks into learning opportunities.

Over-communication is safer than under-communication. Product managers must explicitly ask obvious questions to uncover hidden assumptions. Passive language (such as "looks fine") signals disengagement; direct, clear communication and proactive resolution of disagreements through techniques like "disagree and commit" lead to stronger alignment.

Product managers manage senior stakeholders effectively through clear information rather than persuasion or manipulation. Instead of fostering division ("us versus them"), they transparently explain leadership decisions, even if they personally disagree. Important decisions should be socialised privately beforehand to prevent surprises and ensure alignment. Maintaining user value at the centre of stakeholder discussions helps manage internal politics effectively.

Effective conversations with users require product managers to deliberately abandon their role as experts, adopting curiosity and humility instead. Product managers should ask users about specific past examples rather than general behaviours, letting implicit behaviours reveal deeper insights. Users should never be relied upon to prescribe solutions directly; uncovering underlying, unarticulated needs is the product manager's responsibility.

Best practices from admired companies rarely translate directly into new contexts due to differing organisational realities. Product managers must pragmatically adapt these methods incrementally and experimentally, avoiding outright copying.

Agile methodologies are often misunderstood as rigid frameworks rather than flexible approaches rooted in collaboration, frequent delivery, reflection, and continuous improvement. Ironically, strict adherence to Agile rituals often undermines its value. Effective teams pragmatically adapt Agile values to their unique contexts rather than rigidly following prescribed rules.

Documentation such as roadmaps and specifications should support team alignment instead of serving as proof of productivity or completeness. The most useful documents intentionally remain incomplete, provoking collaborative discussions. Excessively detailed documentation detaches teams from user realities and delays critical feedback; effective documentation should be brief initially, then refined collaboratively.

Product managers should avoid semantic confusion around vision, strategy, and objectives. These concepts exist simply to articulate clearly what to achieve and how. Outcomes and outputs are interconnected rather than opposites. Setting measurable goals through frameworks such as SMART, CLEAR, or OKRs gives teams freedom in execution. Effective strategy is simple, clearly defines what not to pursue, and tightly connects to daily decisions and actions.

Being data-driven requires first clearly defining the decision to be made, then selecting relevant information, not vice versa. Metrics should explicitly link to business and user outcomes while avoiding vanity metrics. Experiments should provide direct user value instead of internal victories. Accountability means deliberately aligning team actions with measurable outcomes that are continually monitored and prioritised, rather than simply hitting numerical targets.

Prioritisation explicitly involves accepting incomplete information and trade-offs. Effective prioritisation methods include starting small to gather rapid feedback, clearly segmenting and prioritising user groups, transparently documenting assumptions, and systematically managing stakeholder emergencies through structured questions to evaluate genuine urgency.

Remote work requires intentionally built trust, clear expectations, and explicit communication agreements. High-stakes discussions benefit from structured approaches ("synchronous sandwich"), which involve pre-reads, focused synchronous meetings, and prompt follow-ups. Informal interactions must be deliberately encouraged rather than left to chance.

Product leadership means shifting from individual execution toward empowering others. Effective leaders relinquish personal heroics, clearly externalise their knowledge, and consistently coach teams rather than intervening directly. Leadership effectiveness stems from enabling team autonomy, maintaining transparency, and modelling behaviours aligned with organisational goals.

Effective product management persists through both positive and negative times by proactively addressing disagreements, continuously challenging team assumptions, and avoiding complacency. Product managers should resist becoming martyrs by accepting their limits, delegating effectively, and fostering psychological safety to promote innovation instead of defensiveness.

Ultimately, ambiguity defines the central challenge and reward of product management. Formal authority is absent. Influence depends entirely on continuously earned trust, transparency, humility, and the willingness to do whatever the team and product require for success.

Deep Summary

Longer form notes, typically condensed, reworded and de-duplicated.

Chapter 1: The Practice of Product Management

Product management involves stewarding a value exchange between a business and its customers. Rather than directly building products, product managers facilitate collaboration among diverse stakeholders, bridging the gaps between business goals, customer needs, and technical execution.

Three consistent themes unite all product management work:

• You have lots of responsibility but little authority. You're accountable for outcomes but rely entirely on others' cooperation, without direct authority.
• If it needs to get done, it's part of your job. Your role isn't limited to any job description; you step in wherever necessary to ensure team and product success.
• You are in the middle. You mediate conflicts, translate perspectives, and connect strategy with day-to-day decisions, constantly navigating ambiguity.

Product management is not:

• Being the boss or a ‘mini-CEO.’ Success depends on building trust, not wielding authority.
• Directly building or coding the product yourself. Micromanaging technical or design decisions undermines team effectiveness.
• Waiting to be instructed. Proactively identifying and addressing issues affecting the team's ability to deliver is essential.

Common types of bad product managers include:

• The Jargon Jockey: Uses excessive, unclear terminology to appear knowledgeable.
• The Steve Jobs Acolyte: Values vision and innovation above practical customer insights.
• The Hero Product Manager: Insists their ideas alone can save the company, ignoring input and collaboration.
• The Overachiever: Delivers quantity over quality, often driving teams into burnout without meaningful results.
• The Product Martyr: Regularly takes excessive personal responsibility, visibly burdened and seeking recognition for their sacrifices.

These negative archetypes typically stem from insecurity - product management's intangible impact makes demonstrating value challenging. Product managers' contributions are indirect, realised through their teams, making it difficult to quantify their personal effectiveness clearly.

Product managers differ from product owners and programme managers, but the specifics vary enormously between organisations. Generally, distinctions are context-dependent rather than standardised; clarity emerges only from explicit communication within each organisation. Roles with ambiguous titles ("Ambiguously Descriptive Product Roles") should focus less on definitions and more on collaborative clarity around goals and responsibilities.

Ultimately, "every single product job on every single team at every single company is a little different. The sooner you truly embrace this, the sooner you can get to the hard work of doing your specific product job as best you, specifically, can."

Chapter 2: The Core Skills of Product Management

Because the product management role is broad and variable, the specific skills required can be difficult to pin down. Product management commonly sits at the intersection of UX, technology, and business, but it's important to recognise that there's no "one size fits all" skill set. Product managers aren't expected to master every discipline individually; instead, they must skilfully align and connect expertise across these areas.

The role requires mastering four core skills: Communication, Organisation, Research, and Execution (CORE):

Communication: The guiding principle is clarity over comfort. Clear communication involves creating alignment among diverse stakeholders, often navigating uncomfortable conversations to ensure shared understanding. Discomfort often signals ambiguity or misalignment. Great product managers actively embrace and resolve these challenges.

Questions for assessing your communication skills include:

• Am I facilitating conversations for clarity?
• Am I proactively coordinating with other teams?
• Do I respond promptly and thoughtfully?
• Am I clearly presenting options and trade-offs?

Organisation: The guiding principle is make yourself obsolete. Great product managers set up systems, processes, and teams that operate effectively without constant oversight. Organisation involves scaling effective communication and decision-making processes. The goal is sustainable team autonomy, allowing them to function smoothly even in your absence.

Questions for assessing your organisation skills include:

• Could my team prioritise and deliver without me?
• Can everyone clearly articulate what they're working on and why?
• Is our work transparently documented for external stakeholders?
• Am I proactively addressing ineffective processes?

Research: The guiding principle is live in your user's reality. Research connects product teams to real user needs, beyond internal business priorities. It includes formal methods (user interviews, testing) and informal methods (conversations, observations). Effective product managers deeply understand their users' broader contexts and motivations, rather than simply pursuing feature parity with competitors.

Questions for assessing your research skills include:

• Are we continuously learning directly from users?
• Are product decisions balanced between business and user needs?
• Does my team regularly use our own and competitors' products?
• Are we accurately reflecting user needs, or just business assumptions?

Execution: The guiding principle is all efforts in service of outcomes. Effective execution focuses efforts directly toward achieving defined business and user outcomes. It requires ruthless prioritisation, flexibility in responsibilities, and a willingness to engage at all levels: from tactical details to strategic negotiations. Product managers measure success by outcomes, not by effort or busyness.

Questions for assessing your execution skills include:

• Do we start from desired impacts rather than features?
• Are strategic objectives central during tactical work?
• Is my personal prioritisation aligned with team goals?
• Do I openly communicate capacity constraints?

While traditionally considered "soft skills," these CORE skills are crucial for product management success and should be valued accordingly. The excessive emphasis on "hard skills," especially technical expertise, can be misleading. Product managers don't necessarily need deep technical knowledge, but they must cultivate curiosity and openness toward technical topics to collaborate effectively with technical teams.

Ultimately, successful product management depends on applying these connective, facilitative CORE skills to align diverse stakeholders, deliver impactful outcomes, and continuously engage with user realities.

Chapter 3: Showing Up Curious

Curiosity is the single most critical trait for successful product managers. Taking a genuine interest in colleagues' work builds trust, provides essential context, and creates bridges before they're urgently needed. Reaching out proactively, with openness, expands your network and sets a collaborative tone.

"I'm curious to learn more about the work that you do" is the most powerful sentence at your disposal as a product manager, whether it's your first day or you've been working in the field for decades."

Three benefits of genuine curiosity include:

• Understanding specialised skills contextually from colleagues directly.
• Building relationships before asking for help.
• Expanding your network of trust across the organisation.

Cultivating a growth mindset transforms failures into learning opportunities. Product managers must move away from defensively protecting their self-image and instead embrace challenges, recognising that being wrong is an essential step toward finding better solutions. Adopting a growth mindset shifts your attitude away from defending your own ideas and toward choosing what is best for shared organisational goals.

Staying off the defensive is essential because defensiveness undermines team alignment and effective decision-making. Four practical approaches help manage defensiveness:

• Present multiple options rather than yes/no arguments.
• Pause anxiety-driven impulses overnight to gain perspective.
• Respond positively ("OK, great!") to defuse immediate tension and buy time.
• Proactively ask for help from difficult colleagues, creating cooperation instead of conflict.

Product managers must separate product failures from personal failures. Products can fail without you failing personally. Accepting product limitations objectively prevents burnout and clarifies areas for growth.

Curiosity is contagious. Spreading curiosity involves modelling it yourself, encouraging cross-team learning, and regularly sharing work widely within the organisation. Structuring opportunities like demo days and cross-functional pairing reinforces curiosity as a core value, making the work more collaborative, transparent and engaging.

Best checklist points to remember:

• Reach out proactively to understand colleagues' work.
• Connect with people before you need their assistance.
• Cultivate a growth mindset, openly embracing challenges and admitting when you're wrong.
• Offer multiple solutions rather than engaging in defensive arguments.
• Respond constructively when criticised or questioned.
• Create a clear distinction between product outcomes and personal worth.
• Encourage and actively facilitate curiosity within your team through structured knowledge-sharing activities.

Chapter 4: The Art of Egregious Overcommunication

Effective product management hinges on clear, proactive, and fearless communication. Under-communication can lead to serious misunderstandings with significant consequences, whereas over-communication typically results in minor annoyance at worst. When unsure, always err on the side of communicating more.

Asking the "obvious" questions (questions others might avoid out of embarrassment) is crucial because assumptions frequently differ. By explicitly clarifying seemingly obvious points, teams avoid costly misalignments.

Product managers should be direct and avoid deflection or passive-aggressive language. Clearly state your needs and expectations instead of hedging with phrases like "It would be great if..." which deflect responsibility. Directness ensures clarity and maintains healthy relationships built on mutual understanding.

Taking responsibility is important, but not everything that goes wrong is your fault personally. Acknowledge when issues arise, but use these situations as opportunities for team reflection and improvement. Conversations should emphasise outcomes rather than assigning personal blame or evaluating intentions.

The phrase "looks fine" is dangerous. It typically indicates disengagement or passive approval rather than genuine commitment. Avoid superficial approvals by structuring communications to demand active participation, using clear choices or open-ended questions to provoke meaningful feedback.

The "Disagree and Commit" technique helps teams surface hidden disagreements early by explicitly requiring stakeholders to affirmatively commit to decisions. Practical tips for implementation include:

• Introducing "disagree and commit" formally before applying it.
• Interpreting silence as disagreement rather than consent.
• Using quick "pulse checks" in large meetings.
• Experimenting with time-bound commitments and follow-ups to test decisions.

Recognise and accommodate different communication styles:

• Visual communicators: Understand better through visual representations rather than detailed written explanations.
• Offline communicators: Prefer time to think independently before responding publicly; provide them advance notice of discussion points.
• Confrontation-averse communicators: Inclined to avoid conflict by giving shallow agreement; encourage detailed, open-ended responses instead of simple affirmations.

Avoid common communication traps:

• Do not seek superficial consensus ("looks fine") or ambiguous approval.
• Don't get locked into arbitrary deadlines without exploring underlying problems.
• Avoid "design by committee" by aligning decisions around goals rather than preferences.
• Don't impose processes without ensuring team buy-in or dismiss feedback by promising future improvement without collaboration.

Finally, remember that communicating clearly and regularly is fundamental to your role - there is no need to apologise for doing your job effectively. Meetings and emails aren't inconveniences; they are vital opportunities for alignment. Work with your team to make these interactions valuable and outcome-oriented.

Chapter 5: Working with Senior Stakeholders

Working with senior stakeholders effectively often means shifting your mindset from 'influencing' to 'informing'. Your role is not to manipulate senior leaders into agreeing with you, but to provide them with clear information and articulate the trade-offs involved in decisions. Even when the outcome isn't what you prefer, an informed decision is always a win. Accept that an answer you don't like is still valuable. Knowing why a decision was made helps you adapt and respond strategically.

Avoid creating an 'us-versus-them' culture with your team. Openly communicate the rationale behind leadership decisions, even those you personally disagree with. Rather than trauma-bonding by criticising senior leaders, acknowledge disagreements transparently, but quickly move the team's focus toward solving the challenge positively within existing constraints. This maintains trust and aligns everyone with organisational goals instead of undermining authority.

Never surprise senior stakeholders in big meetings. Incremental buy-in is key; socialise ideas one-on-one beforehand. This avoids catching stakeholders off-guard and lets you address objections privately rather than publicly. Gradual communication helps senior stakeholders feel informed and reduces political tension.

Stay user-centric despite internal politics. Senior stakeholder satisfaction alone isn't enough; ultimately, you must deliver genuine user value. Practical tips for remaining user-focused include:

• Letting user feedback and data support your proposals.
• Clearly connecting user needs directly to business objectives.
• Regularly prompting senior stakeholders about their understanding of user needs.
• Ensuring user perspectives remain central in all discussions and decisions.

When managing senior stakeholders, common pitfalls include defensive responses, immediately agreeing or disagreeing without exploring motivations, and misinterpreting stakeholder input as demands rather than signals of misalignment. Instead:

• Apologise and seek clarity when stakeholders feel out of the loop.
• Be curious about the reasons behind stakeholder requests, rather than defensively debating details.
• Clarify and validate their assumptions by asking thoughtful questions instead of assuming bad intent.

Remember, senior stakeholders are human too. They have their own pressures and priorities. Your role is to support their decision-making process thoughtfully and transparently, ultimately aligning their success with the success of your users and your organisation.

Chapter 6: Talking to Users

Effectively talking to users is a critical yet surprisingly challenging skill for product managers. Unlike interactions with senior stakeholders (where your goal is typically to influence, align, and gain buy-in), user conversations require you to adopt a completely different mindset. Rather than explaining or impressing users with your expertise, the goal is to immerse yourself fully in their reality, adopting a stance of genuine curiosity and even "playing dumb" to uncover deeper insights.

Product managers often struggle initially because it feels unnatural not to showcase their knowledge. However, presenting yourself as an expert can shut down the valuable openness needed from users. It's crucial not to pitch your ideas or guide users too directly; instead, observe how they naturally engage with your product or problem space. Users' actions and unprompted behaviours often reveal far more valuable insights than direct responses to overly specific or leading questions.

Good user research practices include asking about specific past instances ("Tell me about the last time you did this") rather than abstract generalisations ("What do you typically do?"). Avoid getting overly excited when users confirm your assumptions, it may prematurely close off deeper insights. Critically, never rely on users to define product solutions directly. Your job is to understand their needs clearly enough to identify solutions yourself, illustrated by the example of OXO's "read from above" measuring cup, which addressed a real but unarticulated user need.

User personas are valuable but easily misused. Effective personas must be based on actual research, refreshed regularly, and complemented by "anti-personas" to clarify whom the product is explicitly not intended for. Beware of relying excessively on "power users" or vocal minorities; they may not represent broader market realities. Listening exclusively to enthusiastic early adopters can obscure more crucial feedback from less engaged or sceptical user segments.

Collaboration between product and research teams is essential but often strained. Product managers must openly and calmly discuss constraints (timelines, budgets, business goals) rather than dismiss inconvenient insights outright. Important findings should never be buried in lengthy slide decks, communicate them clearly and directly. Involving the entire product team in user research sessions can significantly improve understanding, alignment, and practical responsiveness to user insights.

Ultimately, becoming skilled at talking to users means acknowledging the difficulty of the task, deliberately practising curiosity and openness, and consistently challenging your own assumptions.

Chapter 7: The Worth Thing About Best Practices

Focusing too much on "best practices" from admired companies can inadvertently lead product managers astray. While it's appealing to adopt the techniques of successful organisations, treating these methods as guaranteed recipes for success overlooks the unique challenges, constraints, and context of your own company. This mindset can breed incuriosity, unrealistic expectations, and deep frustration when practices inevitably fail to replicate the successes seen elsewhere.

It's essential to avoid being seduced by idealised narratives of industry leaders. "Best-in-class" companies often selectively promote practices as recruiting tools rather than presenting the complex realities product managers actually face. Real-world teams, even at the most admired companies, struggle with internal politics, resource constraints, and product challenges much like your own.

Instead of trying to directly copy another organisation's methods, product managers should thoughtfully adapt practices to their own context. Doing this effectively requires first clearly understanding your organisation's current situation, constraints, and specific needs. Visualising or mapping out how your team actually works today can reveal hidden obstacles or opportunities more clearly than abstract frameworks.

Recognising the reality of your organisational constraints, rather than constantly pushing against them, allows you to focus on delivering the greatest value within those constraints. Rather than railing against an organisation for "doing it wrong," effective product managers learn how to deliver meaningful outcomes even in less-than-ideal environments. This approach, described as "falling in love with reality," helps product managers navigate challenges pragmatically, prioritising user and business value over theoretical perfection.

Frameworks and models should be viewed as "useful fictions" rather than literal prescriptions. While no theoretical model perfectly fits real-world complexity, they can provide valuable tools for clarifying thinking, facilitating difficult conversations, and aligning teams. Approach these tools with curiosity about how they might be adapted, not rigidly applied.

Implementing change should happen incrementally. Starting with small, manageable steps allows your team to see clear results, learn what works, and adjust as you go. Avoid overwhelming your team by introducing too many changes at once or rigidly imposing methods from previous workplaces. What worked effectively elsewhere may fail without adapting to your current team's unique context.

Process-averse team members often resist changes they perceive as arbitrary or overly bureaucratic. To engage these individuals, involve them early as collaborators who help shape any proposed changes. Document their concerns openly, frame changes as time-bound experiments rather than permanent shifts, and focus adjustments on future initiatives rather than disrupting ongoing work.

Ultimately, best practices are valuable starting points, not guarantees of success. Stay attentive to the actual outcomes, adapt your approach based on real experiences, and continuously align your practices with the genuine needs of your team, your organisation, and your users.

Chapter 8: The Wonderful, Horrible Truth About Agile

Despite its widespread adoption, Agile is frequently misunderstood and misapplied. Three common myths distort perceptions: Agile is mistakenly seen as a rigid methodology, a way to simply do more work faster, or a direct determinant of a product manager's role. Originally intended as a flexible set of values (prioritising individuals, interactions, collaboration, responsiveness to change, and working software), Agile has often devolved into overly prescriptive practices that lose sight of these values.

Agile failed when teams replaced thoughtful adaptation with rigid adherence, treating guidelines as rules and rituals as mandatory. This "proprietisation of common sense" turned intuitive ideas (like collaborating regularly or adapting to feedback) into overly complex frameworks, leading many organisations astray.

Alistair Cockburn distilled Agile's core into four simple actions:

• Collaborate (work closely together)
• Deliver (frequently produce working value)
• Reflect (regularly assess team effectiveness)
• Improve (continuously refine based on reflection)

This simple framework emphasises Agile's intended flexibility, highlighting that regular reflection and improvement, not strict adherence, is the key to effective Agile practice.

Ironically, teams often improve their outcomes by deviating from orthodox Agile methods. Rigid Agile rituals, such as daily stand-ups or meticulous user story grooming, can sometimes impede collaboration or user-centricity. Teams find success when they adjust these practices thoughtfully to their own context, documenting reasons for changes clearly and continually evaluating effectiveness. Adopting Continuous Discovery Habits (such as integrating user research into daily team activities) is one powerful example of doing Agile "wrong" but achieving better results.

Agile debates can become repetitive and fruitless. There are seven conversations about Agile that teams should move past:

• Product managers working in Agile aren't real product managers: Strategic value comes from individual actions, not from adherence to any framework.
• We can't really do Agile because we're [regulated/an enterprise/etc.]: Agile values can adapt to virtually any context.
• Agile is outdated: we need a new manifesto!: New labels won't fix fundamental misunderstandings; clarity and continuous improvement matter more.

Ultimately, Agile is neither inherently good nor bad. The ambiguity and complexity of product work remain, and Agile is only as valuable as its practical implementation. Product managers must continuously reflect, refine, and adapt Agile practices to their team's unique context, always prioritising real outcomes over rigid methodology.

Chapter 9: The Time Suck of Documentation (Roadmaps)

Much of a product manager's most valuable work is intangible: clarifying confusion, refocusing conversations, and navigating complex trade-offs. Documentation, though often necessary, is not inherently valuable, and the most impressive documents are frequently the least useful. Product managers must resist the temptation to create overly detailed roadmaps or product specs simply as proof of productivity. Good documentation is concise, actionable, and serves as a starting point for meaningful team conversations.

Product managers do not solely own the roadmap. Absolute ownership can lead to roadmaps created in isolation, detached from reality, resulting in misalignment and lost credibility. Instead, roadmaps should be approached as strategic communication documents, designed explicitly to facilitate team discussions, align expectations, and articulate strategic direction without rigidly prescribing outcomes.

Teams must explicitly define how roadmaps will be used internally and externally. Clarifying questions include:

1. How far ahead does the roadmap project?
2. Are short-term and long-term plans differentiated?
3. Who sees the roadmap? Customers, the public, or internal only?
4. How often is the roadmap reviewed, and who participates?
5. How are roadmap changes communicated?
6. What commitments are implied by short-term versus long-term roadmap items?

Writing a "roadmap readme" can help teams and stakeholders explicitly understand expectations before the roadmap itself is even crafted. Introducing roadmaps incrementally and labelling early versions explicitly as works-in-progress (e.g., "Version 0") helps manage expectations and build alignment over time through frequent retrospectives on their use.

Product specs, like roadmaps, are not products. Bad product specs attempt completeness without input, becoming detailed and rigid, while effective specs remain intentionally incomplete, engaging teams in shared problem-solving. As Raghu Garud, Sanjay Jain, and Philipp Tuertscher argue: "Rather than pose a threat, incompleteness acts as a trigger for action. Even as actors try to complete what has been left incomplete, they generate new problems as well as new possibilities that continually drive the design." In other words, bringing incomplete things to your team doesn't just mean that you are working together to solve a problem, it means that you are continually and collaboratively reshaping the problem as you work together to solve it. How cool is that?

Complex, detailed product specs can negatively impact products by delaying user feedback and detaching product managers from implementation realities. Instead, the first draft of any documentation should be limited to one page and one hour of effort. Documents should then be refined collaboratively, in real-time, maximising alignment and engagement.

Templates are useful only if lightweight, flexible, and regularly revised. They should help structure thinking without imposing inflexible constraints. Product managers should personally complete templates multiple times before sharing, ensuring practicality and preventing unnecessary complexity.

Finally, proprietary knowledge-management tools or elaborate roadmapping platforms do not inherently improve outcomes. Simpler tools are typically sufficient, especially initially. Teams should only adopt more complex solutions when specific limitations are identified.

Ultimately, documentation should always support effective team communication and collaboration. As Alan Wilson Watts succinctly reminds us: "The menu is not the meal." The roadmap or spec document is never the end goal; the true goal remains delivering value to users.

Chapter 10: Vision, Mission, Objectives, Strategy etc

Many product managers get caught up in confusion about terms like vision, mission, objectives, and strategy. Different experts offer conflicting definitions, making product managers anxious about doing it 'right.' Rather than worrying about finding the single correct definition, the key is to clearly articulate two fundamental questions: What are you trying to achieve, and how do you intend to achieve it? Remember that the purpose of all these big fancy words is to help your team understand what goals you are working toward and how you intend to achieve those goals. Stay focused and keep it simple.

A common challenge is balancing outcomes (the results and impact your team delivers) and output (specific features and deliverables). Many teams mistakenly see outcomes and output as opposites. Instead, think of outcomes and output as a connected system, not an either-or choice. If your desired outcomes are broad and vague, your stakeholders will inevitably demand detailed outputs and deadlines. Conversely, setting highly specific, measurable goals (like 'Increase conversion rates by 10% within three months') gives teams greater freedom to experiment with different outputs and approaches.

Without clear, specific goals, product managers often fall into the trap of measuring success through workload or product ownership alone, resulting in burnout, competition, and ineffective prioritisation. Frameworks like: SMART goals, CLEAR goals, and OKRs help bring the necessary specificity. While SMART (Specific, Measurable, Achievable, Relevant, Time-bound) emphasises clear measurement, CLEAR (Collaborative, Limited, Emotional, Appreciable, Refinable) encourages team buy-in. OKRs balance qualitative objectives with quantitative results, providing both inspiration and measurable direction.

Good strategy is fundamentally tied to execution. An effective strategy helps teams consistently make better decisions. Strategies disconnected from day-to-day execution become meaningless. Keep strategy simple, straightforward, and closely linked to your team's daily decisions. Richard Rumelt emphasises that good strategy is simple and obvious; it shouldn't require lengthy presentations. A good test is whether team members can easily summarise your strategy, whether it clearly defines what not to build, and whether it feels outdated after some time, signalling responsiveness to real-world changes.

When prioritising decisions, teams should establish a hierarchy of critical questions, moving from high-level company goals down through product strategy, roadmaps, team capacity, and finally tools and processes. Addressing these questions systematically ensures clarity and alignment. If ever unclear about what's being asked (vision, mission, strategy), product managers should simply request concrete examples, clarifying expectations rather than guessing.

Ultimately, effective goal-setting and strategy aren't about finding the 'perfect' definitions or producing impressive documentation. Instead, keep it simple, specific, actionable, and directly connected to your team's daily execution and decision-making.

Chapter 11: Data, Take the Wheel

Many product managers aspire to be "data-driven," yet often misunderstand what this means. The word "data" itself is frequently misused, lending a false sense of certainty without clarifying what specific information is being discussed. Instead of vague appeals to data, always explicitly state what information you're using, how you gathered it, and the conclusions you draw from it. This specificity leads to clearer communication and better decision-making.

Effective use of data starts by identifying the decisions you need to make, then seeking out relevant information rather than the other way around. Often, product managers feel stuck because they lack the "right" data. Instead, they should focus on defining the decisions clearly, then find alternative sources of information, proxies, or qualitative insights. Your intuition or hypotheses can guide you, but always establish clear feedback loops to validate assumptions.

When selecting metrics, focus on those directly tied to your product goals and strategy rather than obsessing over vanity metrics. Vanity metrics might look impressive or concerning, but without a clear connection to your business objectives, they're meaningless distractions. For example, the same metric, like "page views", can indicate success or failure depending on your strategic goals. Clearly define both your key metrics and their related "countermetrics" (such as acceptable losses when changing pricing or features) to understand and communicate realistic expectations.

Effective experimentation means focusing on creating genuine value, not simply proving points internally. Run experiments designed to provide immediate benefit to users, rather than using data merely to settle internal debates or political conflicts. How you communicate experiments matters greatly: frame your findings as collaborative discoveries rather than victories over colleagues. Clearly define expectations upfront, including both what success and failure look like, to avoid confusion and conflicts later on.

"Accountability" is often misunderstood as hitting specific numerical goals, which can cause product managers to disengage when outcomes seem out of their control. Instead, accountability should be reframed around aligning your team's actions with clear quantitative goals. Product managers have six core responsibilities related to accountability:

1. Clearly identify key metrics and their connection to overall goals.
2. Set specific targets for these metrics.
3. Continuously monitor the current status of these metrics.
4. Identify the root causes behind changes in these metrics.
5. Decide which issues can be effectively addressed by your team.
6. Develop and maintain a prioritised action plan to address these issues.

This approach ensures product managers stay actively engaged in driving meaningful outcomes, even if those outcomes are influenced by factors outside their immediate control.

Ultimately, being "data-driven" does not mean avoiding difficult decisions or relying solely on numerical evidence. Instead, it means thoughtfully using relevant information to guide better decision-making, clearly communicating your methods and conclusions, and consistently striving to create value for your users.

Chapter 12: Prioritisation

Prioritisation means deciding what to build, how much to build, and what not to build. It's where goals, strategy, and data intersect but rarely neatly. Often, the information is incomplete or contradictory, and no prioritisation framework can fully remove subjective judgment. Recognise that any formal prioritisation framework is still going to rely upon subjective concepts like "impact" and "must-build." No matter which framework you choose, if any, you will still need to navigate the stomach-churning feeling of making an important decision with incomplete information.

Think of your company's goals, strategies, and user insights as a messy layer cake rather than a neat cascade. Your job is to select the best possible slice with every decision. You won't always find perfect alignment between corporate objectives and immediate product tasks. When in doubt, clearly articulate why you've chosen one approach over another based on the information available and your team's goals.

Every decision involves trade-offs. Adding functionality to help one type of user might frustrate another. To navigate these trade-offs thoughtfully:

1. Start small: Prioritise incremental steps that gather feedback and enable adjustments.
2. Segment and prioritise user needs: Focus on specific user personas instead of general compromises.
3. Document assumptions clearly: Be transparent with your team to facilitate easier course-correction.
4. Recognise all costs: Every feature built has hidden costs, such as increased complexity or maintenance.

It's tempting to prioritise features within your direct control rather than coordinating across multiple teams. However, impactful improvements often cross team boundaries. To keep the entire user experience in mind:

• Regularly use your product to complete full user journeys, rather than isolated tests.
• Start cross-team collaboration from shared user-centric goals, not technical dependencies.
• Consider subtractive solutions removing or simplifying features can significantly improve user experience.

When stakeholders propose new feature ideas, don't reflexively dismiss them. Understand why stakeholders are excited about the requests they make. Stay open to ideas. Even seemingly irrelevant suggestions can reveal valuable insights about user needs or motivations, and exploring them can increase team engagement and identify innovative solutions.

"Emergencies" frequently disrupt prioritisation. Instead of immediately acting, have stakeholders answer structured questions to evaluate urgency, such as:

• What exactly is the issue?
• Who reported it?
• How many users are affected?
• How does this affect key goals like revenue?
• What happens if it's not fixed immediately, or within six months?

Often, simply requiring thoughtful responses reduces the volume of "emergency" requests significantly.

Ultimately, effective prioritisation means breaking big decisions into smaller steps, making clear assumptions, and regularly reassessing based on feedback and outcomes. Prioritisation never offers certainty, only thoughtful choices that move your team forward.

Chapter 13: Remote Work

• Trust is built intentionally in remote teams - not through informal office interactions but deliberate efforts such as clear communication agreements and explicit expectations. Misunderstandings about response times, workload, and inbox overwhelm are common; having a simple "Comms Manual" or shared operating agreement clarifies these points and avoids unnecessary stress.
• Effective remote communication requires preparation and specificity. Avoid vague "quick pings"; instead, clearly state what you need, why you need it, and when you expect a response. For high-stakes discussions, structure meetings as a "synchronous sandwich": send a pre-read beforehand, hold a focused synchronous session, and follow up promptly afterwards.
• Informal communication must be deliberately recreated in remote environments. Rather than awkward forced social events, provide low-effort opportunities for teams to naturally share personal interests or weekend activities. Accept that remote work is different - not better or worse - and requires constant attention to team dynamics and communication practices.

Chapter 14: Product Leadership

Becoming a product leader means shifting from individual execution to guiding others. Good product management skills do not guarantee strong leadership. Leadership demands letting go of habits like personal heroics or excessive involvement in details. Product leaders must focus on empowering teams by clearly communicating goals, providing strategic guardrails, and maintaining short feedback loops.

Effective product leadership is not defined by titles or status, but by consistently enabling others to succeed. Leaders set standards through their own actions, modelling healthy work-life balance, responsiveness, and openness to feedback. They recognise that promotion isn't earned by entitlement, but by demonstrating how additional responsibility helps the company achieve greater outcomes.

Leaders proactively externalise their knowledge, creating shared resources to help teams independently make good decisions. Rather than stepping in and "fixing" problems themselves, product leaders coach their teams through difficult situations, avoiding common traps like undermining team autonomy or engaging in organisational politics. By clearly defining outcomes, communicating transparently, and focusing on the broader goals of the business, product leaders empower their teams and themselves to succeed sustainably.

Chapter 15: In Good Times and Bad

Most products don't reach explosive success, yet effective product management consistently delivers value, even without dramatic results. Success as a product manager doesn't mean an absence of conflict or challenges; instead, it's defined by openly addressing disagreements, actively embracing new perspectives, and continually seeking opportunities for improvement when things seem stable.

A significant risk arises when teams enter "autopilot mode," settling for incremental successes and becoming resistant to change. Regularly challenging team assumptions, prototyping bold new ideas, and actively exploring user needs helps avoid stagnation. The healthiest product organisations are energised by these challenges, not afraid of them.

Product managers also risk becoming martyrs or heroes, feeling entirely responsible for all the organisation's issues. Recognising the limits of your influence, delegating important tasks, and consistently engaging in team-building rituals protect against burnout and strengthen team cohesion.

Finally, product managers must avoid the tendency to become overly cautious based on past experiences. Always imagine working at the best possible organisation, courageously proposing new ideas, sharing difficult truths openly, and giving colleagues the chance to grow beyond previously assumed constraints. By doing so, product managers not only foster greater psychological safety but also create opportunities for meaningful, lasting change.

Whatever It Takes

Having the title "product manager" provides no formal authority, no automatic control, and no guarantee of influence over products or people. Instead, authority comes from continuously earning trust through partnership, transparency, and accountability: day after day.

Mistakes are inevitable. Product management requires humility, resilience, and a willingness to admit when you're wrong. It demands that you translate your words into actions, respect the contributions of your peers, and grow not just professionally, but personally.

Ultimately, the role’s ambiguity is both its challenge and its reward. Each day might feel different, unclear, even overwhelming. Yet the answer to the question of what a product manager does remains constant: you do whatever it takes.