Review

Inspired is the Product Management bible. It covers the breadth of Product Management. Marty details the role, lists the common techniques and articulates the importance of product culture in organisations. Marty’s style is to contrast good with bad, which is helpful but can come across as a little pessimistic. 2008 is early for a Product Management book, but it still feels modern and on point today. It’s surprising to see how many companies still struggle with some of the problems outlined in this book.

A caution for PMs - Don’t read this book and feel like your learning journey is finished. You will need a deeper understanding of the subject matter (and a chunk of practice) before you’re a skilled practitioner (e.g. get stuck into product discovery techniques).

You Might Also Like…

Book Summary: Build by Tony Fadell

Get a comprehensive summary of the best-selling book "Build" by Tony Fadell, the father of the iPod. Learn about Tony's journey as an entrepreneur and innovator, and gain valuable insights on how to create and scale successful products.

andrewclark.co.uk

Book Review and Summary: Loved by Martina Lauchengco

Get a comprehensive review and summary of the best-selling book "Loved" by Martina Lauchengco, the self-help and personal development expert. Learn about the key principles and practices for building healthy and loving relationships with yourself and others

andrewclark.co.uk

Book Review and Summary: Empowered by Marty Cagan for Tech Professionals

Get a comprehensive review and summary of the best-selling book "Empowered" by Marty Cagan, the Silicon Valley product development expert. Learn about the key principles and practices for creating successful products and building high-performing teams

andrewclark.co.uk

Key Takeaways

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

• The root cause of most failed products is that many companies are still operating in a waterfall product development process (with agile software development at the end).
• Idea → Business case → Roadmap → Requirements → Design → Build →Test → Deploy
• The TWO inconvenient truths about product:
1. At least half of our ideas are just not going to work. Half of the ideas on your roadmap are not going to deliver what you hoped.
2. Ideas that have potential takes several iterations to get the implementation right. Time to money.

• 3 principles to take you beyond lean and agile:
1. Risks are tackled up front, rather than at the end
2. Products are defined and designed collaboratively, rather than sequentially
3. It’s about solving problems (and achieve outcomes), not implementing features

Important Definitions

• Holistic Product: Functionality, technology, user experience design, monetisation and how we attract and acquire users. Plus offline experience if that’s part of the produc.
• E.g. For an e-commerce site → the product is everything other than the physical goods being sold
• Continuous Discovery and Delivery: working in parallel to discover and deliver the product.
‣
Product Discovery: we need to discover the product to be built (PM + Design)
• Tackling various risks before we right code - to separate good ideas from bad
• Output = a validated product backlog
• 4 Key Questions:
• Will the user buy this / or choose to use it?
• Can the user figure out how to use this?
• Can our engineers build this?
• Can our stakeholders support this?
• Activities:
• Run quick and cheap experiments.
• Use prototypes (10x less time an effort to build than a finished product)
• Strong product teams test 10 to 20 product ideas each week
‣
Product Delivery: we need to deliver that product to market (Eng + PM + Design)
• Building the ideas validated in discovery - to production quality
• Something that you can sell and run a business on
• Performance, reliability, fault tolerant, secure, international,
• Product Market/Fit: the smallest possible actual product that meets the needs of a specific market of customers.
• Product Vision: The longer term objective of the product, 2-10 years out.
• We use prototypes to conduct rapid experimentation in product discovery, then in delivery - we build and release products with the aim of achieving product/market fit - which is a key step toward achieving the product vision
• MVP - Should stand for Minimum Viable Prototype (not product). Making it clear to stakeholders and customers what they’re getting. Building an actual product-quality deliverable to learn, even if it has minimal functionality, wastes time and money.

• It’s all about the product team - this is the most important concept in the book

• The product manager needs to be among the strongest talent in the company. They need to understand the technology, have business savvy, have credibility with executives, have deep customer knowledge, have a passion for the product and the respect of their product team.
• When the product succeeds - everyone did a good job. When the product fails → it’s the product managers fault
• Four Key Responsibilities you need to bring as a product manager (Customer, Data, Business, Market)
• Deep Knowledge of the Customer - issues, pains, desires, how they think. Quantitative (what) and Qualitative (why).
• Deep Knowledge of the Data - comfortable with data, analytics, a/b tests
• Deep Knowledge of your Business - stakeholders, constraints, economics, finance, operations
• Deep Knowledge of your Market and Industry - competitors, trends, customer behaviours, expectations, new technologies,
• Feature parity isn’t enough - you need to be substantially better for a customer to switch
• Occasionally you’ll have a domain expert to help you, if you’re in a gnarly environment (like healthcare or sciences)
• PMs need to be smart, creative and persistent.
• The time and effort required to do the role is hard to sustain, unless you’re passionate about the product

Team / Org Shapes

• Causing dramatic change in a large and profitable company is incredibly difficult.Every bone and muscle in that corporate body works to protect that revenue.

Product Roadmaps

• Typical roadmaps are the root cause of most waste and failed efforts in product organisations.
• Typical roadmaps are all about outputs and not outcomes - lists of features and projects
• Stakeholder-driven roadmaps → come down from management
• Management think they need roadmaps for 2 reasons:
• Prioritisation → checking the team is working on the most important things
• Scheduling → want to know when things are coming so they can plan and align
• Roadmaps bump into the two inconvenient truths.
• Most things won’t work.
• Things that do require many iterations. (time to money)
• Sometimes you need to commit to a delivery date. Try to minimise them → they are called high integrity commitments.

• Each team needs to know how they contribute toward the larger whole. The business should be prioritising the business results. Occasionally - teams should commit to high-integrity commitments → for situations where date and deliverables are important
• Benefits to working this way:
• Autonomy increases motivation → teams are see to solve problems how they like
• Teams are now responsible for solving business outcomes → not just shipping outputs
• This approach is robust to the teams initial results not working
• Teams are motivated and have autonomy → they are responsible for outcomes not outputs.
• These are called outcome-based roadmaps. Grounded in business objectives
• They are equivalent to OKRs.

Product Vision

• Product Vision is the future we’re trying to create, 2-5 years out
• It communicates the vision and inspires the teams who will make it a reality
• The product vision isn’t a spec, it’s a narrative or storyboard. It’s purpose is to inspire teams, stakeholders, customers and investors - to want to help make that vision a reality.

• Company Missions are longer term, and don’t say anything about how you’re going to get there

Product Strategy

• Sequence of products or releases we plan to deliver on the path to realising the product vision
• Construct a strategy around a series of product/market fits
• Consumer-focused → do it around persona
• Geography-focused → go after a region
• Hitting milestones in a logical and important order
• One of the most important things you can do is focus your work on a single market or customer at a time.

Product vision should be inspiring, the product strategy should be focused.

Prioritising Markets:

• TAM - Total addressable market
• Go-to-market (GTM) - channels and strategies.
• Time to market (TTM) - how long it will take

Product Discovery

• The purpose of product discovery is to address these risks:
• Value Risk → Will the customer but this, or choose to use it?
• Usability Risk → Can the user figure out how to use it?
• Feasibility Risk → Can we build it?
• Business Viability Risk → Does this solution work for our business?
• To do that we need to collect evidence.

Product market fit shows up as happier customers, lower churn, shortened sales cycles, and rapid organic growth.

Different Discovery Technique To Learn in more detail

Prototyping

• Feasibility Prototype
• User Prototype
• Live Data-Prototype
• Hybrid Prototype

Testing

• Fake Door Demand Test
• Landing page demand

• Specific value tests
• Iterating the prototype
• A/B testing
• Invite-only testing
• Customer Discovery Program

Transformation Techniques Mentioned:

• Discovery Sprint / Design Sprint
• Pilot team technique

Process at Scale

• Be careful when formalising and standardising how things are done in the name of reducing error or risk
• Don’t handle it like you do travel expenses
• Agile at scale processes can destroy innovation.

Managing Stakeholders

• A stakeholder: somebody who has veto power, or can otherwise prevent you from launching
• The Exec, business partners, finance, legal, compliance, business development
• PMs should understand the considerations and constraints of various stakeholders
• Convince each stakeholders you understand their issues. That you will fight for solutions that work for the customer and the stakeholders.
• Success: they respect and trust you (to come up with a solution that works for them, and to keep them informed). They give you room to come up with the solutions.
• To do this you need to have a good understanding of your customer, the analytics, the technology, your industry and your business.
• Demonstrate this knowledge by sharing openly what you’ve learnt
• Ask stakeholders to explain their constraints before you show them a solution, so you can get to a better solution
• Preview your solutions as early as possible with stakeholders during discovery
• In discovery - make sure your stakeholders will support the solution
• Don’t end up in an opinion battle with a stakeholder - get evidence and data
• Avoid big powerpoint presentations with many stakeholders. Use high-fidelity prototypes instead - and catch them all offline.
• Spend some time explaining what your product does - to avoid scaring stakeholders - don’t assume they know everything you do.
• Communicating Product Learnings → Share big things learnt each week, 15-30 mins at an all hands, senior presenter will keep it brief, helps keep teams in sync and shows the power of discovery. Be transparent and generous.

Product Culture

Good Product Teams…

• Compelling vision, pursued with passion.
• Inspiration from vision and objectives, from customers, from data, from applying new tech to solve real problems.
• Understand key stakeholders and their constraints, invent solutions that work for customers and stakeholders
• Rapidly try out ideas to determine which are worth building
• Have discussions with thought leaders from across the company
• Product, design and engineering sit side by side - embrace the tradeoffs between functionality, user experience and technology
• Constantly trying out new ideas - but protect revenue and brand
• Insist on having the right skill sets within their team
• Engineers have time to try prototypes in discovery
• Engage with end users every week
• Know many of their ideas won’t work, and those that do will need several iterations.
• Need for speed and know rapid iterations is the key to innovation
• Make high integrity commitments after checking the viability of the solution
• Instrument their work
• Release continuously
• Obsess over reference customers
• Celebrate when achieve significant results (not when they release something)

Innovation Multipliers

Velocity Sappers

Establishing a strong product culture

Deep Summary

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

Part I: Lessons from Top Tech Companies (8 Chapters)

• Marty worked on a product at HP that nobody bought - people didn’t want or need it
• It doesn’t matter how good your engineering team is - if they’re not given something worthwhile to build
• Mid 1980s - a product manager from marketing made the call to build the product at HP - HP weren’t good at product management
• HP → Netscape → eBay
• Discovered a big difference between the best product companies and the others. The state of the art was different from the state of the practice.

• Behind every great product → somebody who led the product team → bring design and technology together → to solve a real customer problem → technology and design to solve a real customer problem → in a way that met the needs of the business
• Product Management is a full role → 60 hours a week
• A product team: 1 PM, 2-10 Engineers and a designer if it’s a user facing product.
• About technology-powered products (don’t have to be purely digital)
• 3 types of company: Startups, growth-stage and enterprise
• Startup: a new company - in a race to achieve product-market fit before running out of money. Nothing else matters much until you come up with a product that meets the needs of an initial market
• Growth Stage: achieved product/market fit → now needs to effectively grow and scale. Go to market strategy, technical debt. Shooting for IPO.
• Enterprise: scaled, lasting businesses. Concerned with consistent product innovation. Might have achieved its original vision, making direction unclear. Leadership frustrated with the lack of innovation.
• The root cause of most failed products is that many companies are still operating in a waterfall product development process (with agile software development at the end).
• Idea → Business case → Roadmap → Requirements → Design → Build →Test → Deploy
• The TWO inconvenient truths about product:
1. At least half of our ideas are just not going to work. Half of the ideas on your roadmap are not going to deliver what you hoped.
2. Ideas that have potential takes several iterations to get the implementation right. Time to money.
• The waterfall process doesn’t work because….
• Customer validation happens way too late (the biggest flaw)
• It’s project centric - projects are about output, and product is about outcomes
• Design comes in too late - putting lipstick on a pig
• Product teams aren’t empowered - they’re just mercenaries that need to build things
• Business cases aren’t accurate - we don’t know the actual solution yet!
• Engineering gets brought in too late. Engineers are a great source of innovation
• Agile is brought in too late (you’re getting only 20% of the agile value this way
• Waste - very slow and expensive way to get to market + huge opportunity cost
• Source of ideas - Sales and marketing aren’t the best
• It’s no surprise that companies spend so much time and money and get so little return

• There is no silver bullet to create great products
• Lean and agile represent meaningful progress - but they’re not going to solve your problems
• Leverage the core principles of lean and agile - but move past them
• 3 principles to take you beyond lean and agile:
1. Risks are tackled up front, rather than at the end
2. Products are defined and designed collaboratively, rather than sequentially
3. It’s about solving problems (and achieve outcomes), not implementing features

Important Definitions

• Holistic Product: Functionality, technology, user experience design, monetisation and how we attract and acquire users. Plus offline experience if that’s part of the product.
• E.g. For an e-commerce site → the product is everything other than the physical goods being sold
• Continuous Discovery and Delivery: working in parallel to discover and deliver the product.
‣
Product Discovery: we need to discover the product to be built (PM + Design)
• Tackling various risks before we right code - to separate good ideas from bad
• Output = a validated product backlog
• 4 Key Questions:
• Will the user buy this / or choose to use it?
• Can the user figure out how to use this?
• Can our engineers build this?
• Can our stakeholders support this?
• Activities:
• Run quick and cheap experiments.
• Use prototypes (10x less time an effort to build than a finished product)
• Strong product teams test 10 to 20 product ideas each week
‣
Product Delivery: we need to deliver that product to market (Eng + PM + Design)
• Building the ideas validated in discovery - to production quality
• Something that you can sell and run a business on
• Performance, reliability, fault tolerant, secure, international,
• Product Market/Fit: the smallest possible actual product that meets the needs of a specific market of customers.
• Product Vision: The longer term objective of the product, 2-10 years out.
• We use prototypes to conduct rapid experimentation in product discovery, then in delivery - we build and release products with the aim of achieving product/market fit - which is a key step toward achieving the product vision
• MVP - Should stand for Minimum Viable Prototype (not product). Making it clear to stakeholders and customers what they’re getting. Building an actual product-quality deliverable to learn, even if it has minimal functionality, wastes time and money.

Part II: The Right People (12 chapters)

• It’s all about the product team - this is the most important concept in the book
• Principles of strong product teams
• Missionaries not mercenaries. Mercenaries build what they’re told. Missionaries believe in the mission, and are committed to solving problems for their customers.
• Composition. Product + Design + 10-12 Engineers.
• Optional roles: delivery, user research, QA, data analyst, product marketing manager
• Empowerment & Accountability. Solve hard problems, given clear objectives, they own delivering their objectives → they’re empowered to work out the best way to do it
• Size. Maximum 8-12 engineers. Minimum 2 engineers. The balance of skills is more important than the absolute size of the team.
• Reporting structure. Everyone is an individual contributor, no people managers. Team members should report to their functional (discipline) manager
• Collaboration. Working out solutions together. No hierarchy.
• Location. Locate in the same place.
• Scope. Clear understanding of type of work and scope of work. Especially if multiple teams working on the same product.
• Duration. Teams should be durable. Try to keep teams together - the magic comes when they know how to work together and trust each other. Don’t form and disband on a project basis - it’ll be hard to have the missionary mindset if you do
• Autonomy. Feel empowered - able to solve problems in the way they best see fit. Minimise dependencies between teams.
• Collaboration is built on relationships.
• Innovation requires expertise - which is stronger in durable product teams.
• Teams don’t just build what others determine might be valuable - they understand the customer, the business and they take ownership and responsibility for achieving an outcome.
• Understand the principles - as the techniques will change overtime.

The Product Management Role

• Clear ways a product manager can fail
• Escalate every issue up to the CEO
• Facilitate stakeholder meetings and let them fight it out
• The product manager needs to be among the strongest talent in the company. They need to understand the technology, have business savvy, have credibility with executives, have deep customer knowledge, have a passion for the product and the respect of their product team.
• Key Responsibility = Evaluating opportunities and determining what gets build and delivered to customers
• Is everything on the product backlog worth building? Where’s the evidence?
• When the product succeeds - everyone did a good job. When the product fails → it’s the product managers fault
• Four Key Responsibilities you need to bring as a product manager (Customer, Data, Business, Market)
• Deep Knowledge of the Customer - issues, pains, desires, how they think. Quantitative (what) and Qualitative (why).
• Deep Knowledge of the Data - comfortable with data, analytics, a/b tests
• Deep Knowledge of your Business - stakeholders, constraints, economics, finance, operations
• Deep Knowledge of your Market and Industry - competitors, trends, customer behaviours, expectations, new technologies,
• Feature parity isn’t enough - you need to be substantially better for a customer to switch
• Occasionally you’ll have a domain expert to help you, if you’re in a gnarly environment (like healthcare or sciences)
• PMs need to be smart, creative and persistent.
• The time and effort required to do the role is hard to sustain, unless you’re passionate about the product
• How to prepare to be a Product Manager
• Become an expert in your users and customers
• Establish a strong relationship with key stakeholders (understand constraints, bring solutions that will work within those constraints)
• Become an expert on your product and your industry
• Build and nurture the strong collaborative relationship with your product team
• Product Management is different from the other disciplines
• Product Managers like the CEO - need to deeply understand all aspects of the business
• True leadership separates good from great product managers
• Product Manager vs Product Owner
• PO is the person responsible for the product backlog in a scrum team.
• Product Managers should also be the PO - but the PO role is a small subset of the Product Management role

Other Roles

• Stakeholders will always have many reasons why a product shouldn’t be built. Take time to understand and overcome their objections.

Product Leadership Roles:

• Need to be great at:
• People: Recruit, develop and retain strong talent
• Product: A holistic view of the product (connecting the dots between teams)
• Review the work of the different product teams - identify and help resolve conflicts
• Head of Product: 4 Competencies: team development, product vision, execution and product culture
• VP of product: Develop a strong team of product managers. Somebody who has the proven ability to develop others. Identifying and producing talent.
• VP of product needs to compliment the CEO. You need to know if the CEO is a product-visionary or not.
• A great vision isn’t anything without execution - getting product teams to execute consistently, rapidly and effectively. Expert in product planning, customer discovery, product discovery and product development process. Know how to work and operate in your organisation.
• Product Culture → team understands the importance of continuous and rapid testing and learning. Make mistakes quickly and mitigate risks.
• Group Product Manager Role: Part individual contributor, part line manager

Principles of structuring Product Teams

• How do you split your product across your product teams? Factors to consider:
1. Alignment with investment strategy
2. Minimise dependencies
3. Ownership and autonomy
4. Maximise leverage (shared services - take on dependencies with care)
5. Product vision and strategy
6. Team size
7. Alignment with architecture (due to skillsets)
8. Alignment with user or customer (for things like double-sided markets)
9. Alignment with business
10. Structure is a moving target
• Autonomy at Scale (Alignment to a foundation or freedom to do what you want)
• Many companies have adopted the empowered, dedicated/durable, cross-functional, collaborative product team model
• Most of the benefits come from increased motivation and ownership
• Often leadership think they’ve created empowered teams, but they haven’t, for 1 of 2 reasons:
• Team isn’t yet trusted by management
• Teams want to change something leaders think is foundational
• There’s a tradeoff between product team autonomy and high leverage foundations.
• High leverage foundations → building a strong foundation that all teams can leverage to create amazing products and experiences much faster.
• Things to consider:
• Team skill level - experienced, b team, c team
• Importance of speed - (and efficiency, de-duplication vs autonomy)
• Importance of integration - (how tight your portfolio has to be)
• Source of Innovation - put autonomy where you plan to innovate (foundation or solution level)
• Company size and location - leverage becomes more important and harder as you grow
• Company culture - experienced teams will demand higher autonomy
• Maturity of tech - don’t standardise prematurely
• Importance of the business - not using a solid foundation can be risky.
• For teams to be successfully autonomous and accountable they need context → the product vision + specific objectives

• Causing dramatic change in a large and profitable company is incredibly difficult.Every bone and muscle in that corporate body works to protect that revenue.

Part III: The Right Product (10 chapters)

Product Roadmaps

• Typical roadmaps are the root cause of most waste and failed efforts in product organisations
• Typical roadmaps are all about outputs and not outcomes - lists of features and projects
• Stakeholder-driven roadmaps → come down from management
• Management wants product roadmaps for 2 reasons:
• Prioritisation → checking the team is working on the most important things
• Scheduling → want to know when things are coming so they can plan and align
• Roadmap Problems
• 2 inconvenient truths.
• Most things won’t work.
• Things that do require many iterations. (time to money)
• Reasons products can fail … Usability, Feasibility or Viability
• Stakeholders view roadmaps as commitments!
• Sometimes you need to commit to a delivery date. Try to minimise them → they are called high integrity commitments.
• Roadmap Alternatives:
• The Product Vision and Strategy
• Big picture the org is trying to accomplish
• The plan for making it happen
• Focus areas for different product teams
• The Business Objectives
• The specific, prioritised business objectives for each product team
• Tell the team what you need them to accomplish - and how the results will be measured → let them figure out how to get there
• Each team needs to know how they contribute toward the larger whole.
• The business should be prioritising the business results.
• Occasionally - teams should commit to high-integrity commitments → for situations where date and deliverables are important
• Benefits to working this way:
• Autonomy increases motivation → teams are see to solve problems how they like
• Teams are now responsible for solving business outcomes → not just shipping outputs
• This approach is robust to the teams initial results not working
• Teams are motivated and have autonomy → they are responsible for outcomes not outputs.
• These are called outcome-based roadmaps. Grounded in business objectives
• They are equivalent to OKRs.

High Integrity Commitments

• Don’t make them too early
• Before you know wether you can deliver on them
• Before you know they’re going to solve a customer problem
• Ask executives for discovery time (agree viability, usability, feasibility) - then make a commitment in return
• Delivery managers then track the commitments and the dependencies

Product Vision

• Product Vision: the future we’re trying to create, 2-5 years out
• Company Missions are longer term, and don’t say anything about how you’re going to get there
• The product vision isn’t a spec, it’s a narrative or storyboard. It’s purpose is to inspire teams, stakeholders, customers and investors - to want to help make that vision a reality.
• Product vision: Communicates the vision and inspires the teams who will make it a reality

Product Strategy

• Sequence of products or releases we plan to deliver on the path to realising the product vision
• Construct a strategy around a series of product/market fits
• Consumer-focused → do it around persona
• Geography-focused → go after a region
• Hitting milestones in a logical and important order
• One of the most important things you can do is focus your work on a single market or customer at a time.
• Use your product strategy to align with sales and marketing
• For a product team to be empowered with autonomy they need context - starting with the product vision and strategy.

Product vision should be inspiring, the product strategy should be focused.

Prioritising Markets:

• TAM - Total addressable market
• Go-to-market (GTM) - channels and strategies.
• Time to market (TTM) - how long it will take

Principles of a Product Vision

• Start with why → articulate your purpose, everything flows from that
• Fall in love with the problem, not the solution
• Think big
• Disrupt yourself before somebody else
• Make it exciting and inspirational
• Embrace relevant and meaningful trends
• Skate to where the puck is heading
• Be stubborn on the vision, but flexible on the details.
• Know it’s a leap of faith.
• Evangelise continuously and religiously

Principles of Product Strategy

• Focus on one target market or persona at a time
• Align with business strategy
• Align with sales and GTM strategy
• Obsess over customers, not competitors
• Communicate the strategy across the organisation

Product Principles

• Product principles speak to the nature of the products you want to create
• May inspire features, but it’s more about what the product teams think is important
• Ebay: In cases where the needs of the buyer and the sellers conflict, we choose the buyer, because that’s actually the most important thing we can do for sellers.

Product Objectives

• Empowerment and motivation: “Never tell people how to do it - tell them what to do and they will surprise you”
• How to meaningfully measure progress: “When performance is measured by results”

Product Team Objectives

• Focus OKRs at the product team level (OKRs shouldn’t be functional)
• Use them to align teams and communicate priorities

Product Objectives at scale

• Give people a very clear understanding of organisational objectives - the company need to be smart about which teams pursue which objectives.
• Platform product teams don’t serve customers directly. They’ll need help from leadership to prioritise incoming requests and dependencies
• Leadership need to reconcile OKRs → looking for gaps
• Lean on management to help connect the dots between teams
• High-integrity commitments need to be tracked - and communicated. Delivery managers help with that.

Product Evangelism

• 10 ways Product Managers can help sell the dream
1. Use a prototype
2. Share the customer pain you’re addressing
3. Share the vision
4. Share learning generously
5. Share credit generously
6. Learn how to give a great demo
7. Do your homework - know your business and your customers
8. Be genuinely excited - about your products
9. Learn to show some enthusiasm - enthusiasm is contagious
10. Spend time with your team

Part IV: The Right Process (30 chapters)

Product Discovery

• The purpose of product discovery is to address these risks:
• Value Risk → Will the customer but this, or choose to use it?
• Usability Risk → Can the user figure out how to use it?
• Feasibility Risk → Can we build it?
• Business Viability Risk → Does this solution work for our business?
• To do that we need to collect evidence.
• Core Principles of Product Discovery
1. We can’t count on our customers to tell us what to build
2. The most important thing is to establish compelling value
3. Coming up with a good user experience (usually harder than engineering)
4. Functionality, design and technology are inherently intertwined
5. Many of our ideas won’t work out - ones that do will require several iterations
6. We must validate our ideas on real users and customers
7. Our goal in discovery is to validate our ideas, in the fastest, cheapest way possible
8. We need to validate the feasibility of our ideas in discovery - not after
9. WE need to validate the business viability of our ideas during discovery - not after
10. It’s about shared learning

Discovery Techniques

• Discovery is complex - there are a number of techniques to cover
• Framing, planning, ideation, testing feasibility, testing usability, testing value, testing business viability, transformation techniques.

Framing Techniques

• Sometimes problems and opportunities are clear - sometimes they’re not.
• Goals of framing:
• Ensure the team have clarity or purpose and alignment
• the business objectives we’re focused on
• the problem we’re solving for customers
• Identify the big risks and need to be tackled during discovery
• Teams tend to neglect the harder risks to tackle - like value risk
• Business risk is complex: financial, partnership, marketing, sales, legal, ethical risks
• Use your discovery time and validation techniques for situations in which you know there’s a significant risk

Opportunity Assessment

• Ask four key questions about the discovery work you are about to undertake:
1. What business objectives is this work intended to address (Objective)
2. How will you know if you’ve succeeded? (Key results / measure of success)
3. What problem will this solve for customers (Customer problem)
4. What type of customer are we focused on? (Target markets)

Customer Letter

• If the opportunity assessment doesn’t bring clarity - try this
• Work backwards - starting from a pretend press release
• How does it improve the lives of customers?
• List customer benefits
• If people don’t see value after reading the press release - you’ve got something to think about
• Write a customer letter to the CEO from a happy customer. It’s more real than the press release. Anchored in the customers pain and then relief using the product.

Startup Canvas

• For when you’re being asked to invent a new product - that will create a new business.
• Close to the business model canvas, and the lean canvas.
• Looks at the product and the market
• Product: Problem, Solution, Key Metrics, Cost Structure, Value Proposition
• Market: Unfair advantage, channels, customer segments, revenue streams, Value Proposition

• Purpose is to highlight the biggest risks - be mindful that people will want to focus on the ones they know how to navigate
• The vast majority of teams aren’t solving truly new problems (they have a new solution or new technology)
• If the market is new - you need to validate it
• The biggest risk is often value risk - a solution that your customers want to buy and use
• it must be demonstrably and substantially better than the alternatives

Planning Techniques

• How to scope and plan your discovery efforts

Story Mapping Technique

• A framing and planning technique - also useful for ideation
• Great for working on prototypes and communicating things to your stakeholders
• Play a practical role in managing and organising your work
• A story map is helpful throughout product discovery and delivery
• Better than a flat backlog that lacks context - really hard to see what selection of stories would be meaningful → but story mapping solves that
• High fidelity prototype + story map = the go to techniques
• Use the story maps to define the prototypes - as you get feedback incorporate that back
• Book Recommendation → User Story Mapping

Customer Discovery

Reference Customers

• There are few things more powerful than reference customers.
• A real customer - who is running your product in production - who has paid real money and who is willing to tell others how much they love your product
• Reference customers are the single best sales tool you can have.
• We are discovering and developing a set of reference customers in parallel with discovering and developing the actual product.
• Takes a lot of effort. Single best leading indicator of future product success
• The most common objection to new products is that others want to see that other people or companies like them, have used it successfully
• 6 reference customers is a great number - but they have to be in the target market
• Go a vertical at a time - so get 6 retailers, then move onto financial services
• Don’t launch your product into a market place unless you have those 6 reference customers.
• How to recruit them?
• Recruit more than you need - assume a couple dropout
• Existing customers or prospects
• Have the problem - and be desperate for the solution
• Avoid those just interested in new technologies
• Time to test and give feedback
• Marquee names
• The relationship
• You get real input - they get a real solution
• You can go deep with a real customer
• They must agree to buy - OK for them to pay after they love it
• Make it clear you’re building a general product - not a bespoke solution
• Find a single solution that works for all six customers
• If they want references - say that’s why you’re working with them
• If you can’t recruit 4 or 5 - then you might be chasing a problem that’s not important
• Variations
• Product for business → as above
• Platform products (APIs) →reference applications not customers.
• Customer-enabling tools (by employees in company) → influential internal users not customers
• Building products for consumers → 10-50 consumers instead - influencers / press - also need additional testing

Product market fit shows up as happier customers, lower churn, shortened sales cycles, and rapid organic growth.

• Sean Ellis test → survey those that got to the aha! moment, and that have used your product a couple of times recently. Ask them how they’d feel if they could no longer use this product. If 40% or more choose very disappointed - then you’re onto something.

Discovery Ideation Techniques

• How to generate ideas that help us solve business problems that our leaders have asked us to?

Customer Interviews

• Four great things to learn:
• Are your customers who you think they are?
• Do they really have the problems you think they have?
• How does the customer solve this problem today?
• What would be required for them to switch?
• How to get the most out of customer interviews:
• Frequency - establish a regular cadence, do 2-3 hours a week
• Purpose - don’t try and prove anything just to understand quickly
• Recruiting users and customers - talk primarily to people in your target market
• Location - their habitat is best
• Preparation - what problem do you think they have? How can you contradict or confirm that?
• Who should attend? - interviewer, note taker and developer observer
• Afterward - debrief, share insights
• This hour is a consistently good use of your time.
• You can follow up interviews with a usability test

Concierge Test

• Do the customers job for them, manually and personally
• You become the concierge - you can learn about the customer problem and the customer response - and the value of the interaction

Power of customer misbehaviour

• Allow and encourage customers to use our products to solve problems other than what we planned for and officially support
• eBay used an everything else category - great information category

Hack Days

• Directed or undirected.
• A good technique for building a team of missionaries
• Directed hack day - select a customer problem or a business problem ‘reduce churn’
• Goal: create a prototype that can be evaluated
• Benefit: practical ideas and results but also the cultural benefits of getting everyone evolved.

Prototyping Techniques

Plan to throw one away, you will anyhow Fred Brooks

Principles of prototypes

• Learn something with 10x less time and effort than building out a product
• Helps you think through the problem - expose unforeseen issues
• Develops shared understanding - good for collaboration
• Adapt the fidelity level for the purpose
• Primary goal is to tackle product risk (value, usability, feasibility, viability)
• Also helps communicate to developers what to build - prototype as spec

Feasibility Prototype

• Concerns about algorithms, performance, scalability, fault tolerance, new technology, new 3rd party, dependency on new work from other teams
• Goal: write just enough code to mitigate feasibility risk
• Expectation is that it will be throwaway code

User Prototype

• Really powerful tool
• A simulation, smoke and mirrors, its all a facade
• Low fidelity → wireframes, doesn’t look real. Helps you think through the problem.
• High fidelity → looks and feels real, data you see is realistic - but it’s not live
• A user prototype doesn’t prove anything - especially value risk

Live-Data Prototype

• For when you need to collect some actual usage data
• Search relevance, game dynamics, social features and product funnel work → all benefit from this
• Substantially smaller than the product - none of the robustness or things that allow a product to scale
• Key is to send limited amount of traffic and collect analytics on how it’s being used
• Don’t handle all edge cases, don’t tackle performance or scalability
• Should take between 5-10% of the total product effort to build
• Limitations - engineers need to create it, not commercially shippable (and don’t be tempted)

Hybrid Prototype

• Wizard of Oz → high fidelity front end, actual person doing the automation or backend
• Building something that doesn’t scale - to learn

Testing Techniques

Testing Usability

• Very mature discipline - we can do it in discovery using prototypes before things are ready in production
• Recruiting users
• User users from your customer discovery program
• Advertise for test subjects on craigslist
• Email users
• Get volunteers from your website
• Go where your users congregate
• Compensate them for their time or buy them a coffee where it’s convenient for them
• Preparing the Test
• Use high fidelity user prototypes
• Define set of tasks you want to test - concentrate on primary takss
• Train everyone on how to conduct themselves.
• Start tests before the team fall in love with their ideas
• Administrator and a note taker
• Formal testing labs will have recordings
• Test in their environment if you can
• Or use tools for remote testing
• Testing
• Before doing the test - learn a little about them (do a mini customer interview)
• We want to learn if the user has the problems we thing they have and how they solve these problems today, and what it would take for them to switch
• Tell them its a prototype - its not real - you can’t pass or fail
• Can they tell what you do from your landing page?
• Keep your users in ‘use mode’ not ‘critique mode’
• What matters is if they can complete the tasks - don’t ask them what they’d want to change!
• Keep quiet - watch them struggle - deflect questions
• Looking for
• Task success - no issues
• Task success - some issues
• Task fail
• Avoid giving help or leading the witness.
• Prompt them - I see you’re looking at the list - what are you thinking?
• Trying to understand how they think about the problem - and wether that’s consistent or inconsistent with the product
• Body language and tone will tell you a lot too
• Identify the friction points so you can fix them

Testing Value

• Customers only buy if they perceive real value
• Just because somebody can use your product - doesn’t mean they’ll choose to
• Especially true if you want to get them to switch - you need to be significantly better, feature and value parity aren’t enough

Demand testing

• The biggest possible waste of time and effort is to design, build, test and release a product that nobody buys
• If they don’t want to sign up for a trial - there’s a tremendous and fatal problem
• This problem can happen at feature level and product level

Fake Door Demand Test

• Button or menu that looks like it goes somewhere but doesn’t → instead explains you’re thinking of doing it - add email to register interest
• You get the click-through numbers, and some customers to follow up with

Landing Page demand

• Build the entire landing page - with a call to action (that leads to register interest)
• Good evidence of demand + list of users ready and willing to talk with you

Testing in risk adverse companies

• If you stop innovating - you will die
• You need to do it in a responsible way
• Protect your revenue + protect your brand
• Use A/B testing (go to 1%)
• Invite only tests
• NDA customer discovery program customers
• Inform your colleagues so they aren’t blindsided

Qualitative Value Testing Techniques

• Quantitative - tells us what ; qualitative - tells us why
• Qualitative - isn’t about proving anything, it’s about learning big insights quickly
• Qualitative testing of your product ideas with real customers is the most valuable discovery technique
• Interview first → check the user has the problem we think they have - see how they solve them today - and what would it take for them to switch
• Value tests should proceed usability tests
• Qualitative testing is easy and effective.
• As a product manger - get in on as many as you can

Specific Value Tests

• People are nice - they don’t want to tell you what they’re really thinking
• All tests need to make sure they’re not just being nice to you
• Money → See if the user is willing to pay for it - even if you have no intention or means of charging for it. You can ask them to sign a non-binding letter of intent to buy
• Reputation → Would they pay with their reputation? Would they recommend it to 10 people? Ask them to share on social media
• Time → Ask to schedule some significant time to work on this
• Access → Ask them if they’re willing to login to competitor and migrate right now

Iterating the prototype

• Rapid learning - not proving anything
• As soon as you have a problem, or try a different approach - go for it
• If people give you a different response - work out why

Quantitative Value Testing

• All about collecting evidence
• If you collect enough data you can reach statistical significance
• Data below that mark can still be considered useful evidence
• More suitable for larger companies - who have users and time

A/B testing

• The gold standard. The user doesn’t know what variant they’re on
• Optimisation A/B testing is different
• Discovery A/B testing is sending 1% of people to the prototype

Invite-only testing

• Invite a few customer to a new problem.
• Likely early adopter types.
• Often these will fail - because the product is a miss
• All we know is that they’re not using it - we don’t know why

Customer Discovery Program

• Collecting usage data
• Give them frequent updates
• Speak to them to understand why

The Role of Analytics

• PMs expected to be comfortable with data and know how to leverage it to learn and improve quickly
• Volume of data has increased
• Tools have gotten better quickly
• 5 Ways to use analytics
• Understand user and customer behaviour → e.g. web analytics
• Measure product progress → e.g. Key Results, KPIs
• Prove whether product ideas work → A/B tests
• Inform product decisions → data beats opinions
• Inspire product work → spot product opportunities
• Analytics sources
• User behaviour
• Business analytics (activation, conversion, retention, LTV)
• Financial (ASP, revenue, time to close)
• Performance (load time, uptime)
• Operational costs (storage, hosting)
• GTM costs (acquisition, cost of sales)
• Sentiment (NPS, customer satisfaction, surveys)
• Too many teams are still flying blind - not instrumenting or not doing enough.
• Start from the position that you must have this data - then work out how to get it.

Testing Feasibility

• Key questions engineers are trying to validate the following, with regards to building the solution…
• How would we approach it?
• Skills in team?
• Time to build?
• Architectural changes to enable?
• New components?
• Dependencies?
• Performance?
• Scale?
• Infrastructure?
• Cost to provision?
• Time?
• It’s not about - Can you do this? It’s → What’s the best way to do this? How long would it take?
• Downsides to a feasibility prototype are obvious (opportunity cost and time)
• Upsides to a feasibility prototype:
• Some problems are only now possible to solve
• They may find a better way to solve the problem
• Motivating work, they can learn and shine
• In hardware → the consequences of a mistake in terms of time and money are much more severe. So tackle the value, usability, feasibility and viability risks aggressively

Testing Business Viability

• This is what is really meant by being the CEO of the product
• Make sure the business model is viable. Cost to produce, market and sell your product must be less than the revenue your product generates. Must be lawful, honour partnership agreements. Fit within the brand promise of your company.
• Marketing → enabling sales, brand and reputation
• Sales → products need to be designed around strengths and limitations of sales channels
• Customer success → high-touch or low-touch
• Finance → can you afford to build, sell and operate your new product
• Legal → privacy, compliance, IP, competition issues.
• Business development → partner relationships
• Security → key for tech companies
• CEO/COO/GM → make sure the thing you’re designing and building will work within the constraints of the business.

Transformation Techniques.

Discovery Sprint / Design Sprint - GV Style

• One week time-boxed, tackle a different problem or risk your team is facing.
• Others use the term ‘Design Sprint’ or ‘Discovery Sprint’
• A week of intense discovery - you explore dozens of ideas or approaches - all in aid of solving a business problem
• End your week by validating a solution with real customers.
• Result → big learning and insights → that can change the trajectory of your product and company.
• Book Recommendation: Sprint by Jake Knapp, John Zeratsky and Braden Kowitz
• Intense 5 day week:
• Framing the problem
• Mapping the problem space
• Picking the problem to be solved and the target customer
• Different approaches to the solution
• High fidelity prototype
• Test with users
• When to do a design sprint:
• When the team have something big and important to tackle
• Helps a team learn how to do discovery
• When things are moving too slow - recalibrate on how fast they could be moving

Pilot team technique

• Roll out change to a pilot team, look for one that’s going to volunteer to try out something new.
• Let them run for a quarter or two → look at success measures
• If things go well, other teams will ask to adopt.
• Carefully consider the people involved, their location, autonomy, how open to new ways of working they are

Weaning an Organisation off Roadmaps

• Do it over 6/12 months
• Each time you show the roadmap - anchor in business outcomes
• Shift the thinking from features and dates to business results.
• Point out what’s working and what isn’t → what you learned, what your next ideas are
• Alternative to roadmaps is → working on pre-prioritised business objectives + high-integrity commitments when needed

Process at Scale

• Be careful when formalising and standardising how things are done in the name of reducing error or risk
• Don’t handle it like you do travel expenses
• Agile at scale processes can destroy innovation.

Managing Stakeholders

• A stakeholder: somebody who has veto power, or can otherwise prevent you from launching
• The Exec, business partners, finance, legal, compliance, business development
• PMs should understand the considerations and constraints of various stakeholders
• Convince each stakeholders you understand their issues. That you will fight for solutions that work for the customer and the stakeholders.
• Success: they respect and trust you (to come up with a solution that works for them, and to keep them informed). They give you room to come up with the solutions.
• To do this you need to have a good understanding of your customer, the analytics, the technology, your industry and your business.
• Demonstrate this knowledge by sharing openly what you’ve learnt
• Ask stakeholders to explain their constraints before you show them a solution, so you can get to a better solution
• Preview your solutions as early as possible with stakeholders during discovery
• In discovery - make sure your stakeholders will support the solution
• Don’t end up in an opinion battle with a stakeholder - get evidence and data
• Avoid big powerpoint presentations with many stakeholders. Use high-fidelity prototypes instead - and catch them all offline.
• Spend some time explaining what your product does - to avoid scaring stakeholders - don’t assume they know everything you do.

Communicating Product Learnings

• As companies scale you need to think about sharing - it doesn’t happen as naturally
• Take 15-30 minutes every week or two to explain what has been learnt. The big things - not the little things.
• Having a senior person do it keeps it high level.
• Helps keep product teams up-to-date with what each other are working on
• Useful learnings make it to leaders
• Keep focus on big learnings - not minor experimentation
• Helps the org understand discovery and innovation is about experiments and learning from results
• Be transparent and generous.

Part V: The Right Culture (4 chapters)

Good Product Team / Bad Product Team

Good Teams:

• Compelling vision, pursued with passion.
• Inspiration from vision and objectives, from customers, from data, from applying new tech to solve real problems.
• Understand key stakeholders and their constraints, invent solutions that work for customers and stakeholders
• Rapidly try out ideas to determine which are worth building
• Have discussions with thought leaders from across the company
• Product, design and engineering sit side by side - embrace the tradeoffs between functionality, user experience and technology
• Constantly trying out new ideas - but protect revenue and brand
• Insist on having the right skill sets within their team
• Engineers have time to try prototypes in discovery
• Engage with end users every week
• Know many of their ideas won’t work, and those that do will need several iterations.
• Need for speed and know rapid iterations is the key to innovation
• Make high integrity commitments after checking the viability of the solution
• Instrument their work
• Release continuously
• Obsess over reference customers
• Celebrate when achieve significant results (not when they release something)

Innovation multipliers

1. Customer-centric culture
2. Compelling product vision
3. Focused product strategy
4. Strong product managers
5. Stable product teams
6. Engineers in discovery
7. Corporate courage
8. Empowered product teams
9. Product Mindset
10. Time to innovate

Velocity sappers

1. Technical debt
2. Lack of strong product managers
3. Lack of delivery management
4. Infrequent release cycles
5. Lack of product vision and strategy
6. Lack of co-located, durable product teams
7. Not including engineers early enough in discovery
8. Not utilising design in discovery
9. Changing priorities
10. Consensus culture

Establishing a strong product culture

• What is a strong product culture?

1. Experimentation
2. Open minds
3. Empowerment
4. Technology
5. Business
6. Skill-set and diversity
7. Discovery techniques
8. Urgency
9. High-integrity commitments
10. Empowerment
11. Accountability
12. Collaboration
13. Results
14. Recognition