@DanLebrero.

software, simply

Book notes: Inspired: How to Create Tech Products Customers Love

  • Thu, 11 May 2023

Book notes on "Inspired" by Marty Cagan

These are my notes on Inspired: How to Create Tech Products Customers Love by Marty Cagan.

If you liked Accelerate, The DevOps Handbook, Sooner, safer, happier or other similar books, you will want to buy this book for your Product Manager.

Key Insights

  • Root cause of failed product efforts: Waterfall process from ideas to deploy.
    • Causes:
      • Source of new product ideas: sales or stakeholders.
      • Assuming you can guess the cost and benefit.
      • Getting excited about product roadmaps:
        • Truth:
          • Half to 3/4 of ideas are not going to work.
          • It takes several iterations for an idea to deliver the business value.
      • PM, design, engineering, agile, and customer validation come in late in the game.
      • Project centric (== outputs).
  • Principles:
    1. Risk tackled up front.
      • Product discovery: output is validated product backlog:
        • Will the user buy this? Value risk.
        • Can the user figure out how to use it? UX risk.
        • Can engineers built it? Feasibility risk.
        • Can stakeholders support it? Business viability risk.
    2. Products are defined and designed collaboratively.
    3. Solve problems, not implement features.
  • 10-20 experiments per week.
  • MVP: minimum viable prototype.
  • Cross-functional long-lived teams.
  • Missionaries, not mercenaries.
  • The Product Manager:
    • Responsible and accountable for the success of the product.
    • Decide what gets built.
    • Not a 9-5 job.
  • Ensure senior engineers are participating and contributing to product discovery.
  • Typical roadmaps are the root cause of most waste and failed efforts in product organizations.
    • We need to solve the underlying problem, not deliver a feature.
  • Outcome-based roadmaps (objective list) are good, as long as not all items have a deadline.
  • High-integrity commitments:
    • Make commitment once value, UX, feasibility and business viability are clear.
  • Product vision must inspire, product strategy must focus.
  • Principles of Product Vision:
    • Fall in love with the problem, not with the solution.
    • Don’t be afraid to disrupt yourselves because if you don’t, someone else will.
    • Be stubborn on vision but flexible on the details.
    • Realize that any product vision is a leap of faith:
      • If you could truly validate a vision, then your vision is not ambitious enough.
  • Principles of Product Strategy:
    • Focus on one target market or person at a time:
      • Product will likely be useful to others, but at least will be loved by some, and that’s key.
    • Obsess over customers, not over competitors.
  • If you are a PM and not good at evangelism, there is a strong chance that your product efforts will get derailed before they see the light of the day.
  • Most product teams have a better understanding on how to accomplish quality, rather than speed.
  • Key to effective product discovery is getting access to our customers without pushing quick experiments into production.
  • Customer (and executives or stakeholders) cannot tell us what they want, because:
    1. They don’t know what is possible.
    2. Nobody knows what they want until they see it.
  • UX is harder and more critical than engineering.
  • Product discovery and validation only when there is significant risk.
  • Customer discovery program:
    • Favourite leading indicator of future success.
    • Aim for 6 reference customers:
      • Desperate for a solution, or a technologist.
      • Willing to spend time with product team and testing prototypes.
      • Not building features for all reference customers, but a single solution that works for all of them.
    • If you cannot recruit even 4 or 5, you are probably chasing the wrong problem.
  • Opportunity Assessment Technique, answer:
    1. What business objective is this work intended to address? (Objective - Should match an OKR).
    2. How will you know if you’ve succeeded? (Key result - Should match an OKR).
    3. What problem will this solve for our customers? (Customer problem).
    4. What type of customer are we focused on? (Target market).
    • It is responsibility of the PM to answer these questions.
  • Jeff Patton’s Story Map Summary.
  • Customer interviews:
    • Mindset: understand and learn. Not prove.
    • At least 2-3 hours per week.
  • Prototypes: can serve as a spec on what to build.
  • Testing Usability:
    • Objective: trying to figure out how your user thinks about the problem.
    • Avoid leading. Act like a parrot.
  • Qualitative Value Testing Techniques:
  • The single most important discovery activity.
  • User willing to pay with money, reputation or time.
  • Head of product to highlight big learnings at all-hands. Not more than 30 mins.
  • Only a few companies are strong both at innovation and execution.

TOC

Part I: Lessons from Top Tech Companies

Chapter 1: Behind Every Great Product

  • Book is for Product Managers (PM).
  • PM is a full time job.

Chapter 3: Startups: Getting to Product/Market Fit

  • One of the founders acts as the PM.
  • Less 25 engineers in 1-5 product teams.

Chapter 4: Growth‐Stage Companies: Scaling to Success

  • 25 to hundreds of engineers.
  • Product teams complains:
    1. Cannot see the big picture.
    2. How they contribute to goals.
    3. What means to be empowered, autonomous.
  • Sales and marketing: go-to-market strategies not appropriate for new products.
  • IT full of technical debt.

Chapter 5: Enterprise Companies: Consistent Product Innovation

  • Symptoms:
    • Lack of innovation.
    • Diminished morale.
    • Slow product delivery.
    • No clear vision.

Chapter 6: The Root Causes of Failed Product Efforts

  • Root cause: Waterfall process from ideas to deploy.
  • Causes:
    • Source of new product ideas: sales or stakeholders.
    • Assuming you can guess the cost and benefit.
    • Getting excited about product roadmaps:
      • Truth:
        • Half to 3/4 of ideas are not going to work.
        • It takes several iterations for an idea to deliver the business value.
    • PM, design, engineering, agile, and customer validation come in late in the game.
    • Project centric (== outputs).

Chapter 7: Beyond Lean and Agile

  • Principles:
    1. Risk tackled up front.
    2. Products are defined and designed collaboratively.
    3. Solve problems, not implement features.

Chapter 8: Key Concepts

  • Holistic Product == Functionality + tech + UX + monetization + user/customer acquisition + offline experience.
  • Continuous Discovery and delivery.
  • Product discovery: output is validated product backlog:
    1. Will the user buy this? Value risk.
    2. Can the user figure out how to use it? UX risk.
    3. Can engineers built it? Feasibility risk.
    4. Can stakeholders support it? Business viability risk.
  • 10-20 experiments per week.
  • MVP: minimum viable prototype.

Part II: The Right People

  • It is all about the product team.

Chapter 9: Principles of Strong Product Teams

  • Cross-functional long-lived teams.
  • Missionaries, not mercenaries.
  • Prefer collocated.

Chapter 10: The Product Manager

  • Responsible and accountable for the success of the product.
  • Decide what gets built.
  • Key responsibilities:
    • Deep knowledge of:
      • the customer.
      • the data.
      • the business.
      • the market and industry.
  • Traits:
    • Smart, creative, persistent.
    • Passion for products and solving customer problems.
  • Not a 9-5 job.

Chapter 11: The Product Designer

  • Responsibilities:
    1. Product discovery: measured on the success of the product.
    2. Holistic UX, including email, marketing, sales process, …
    3. Prototypes.
    4. Continuous user testing.
    5. Interaction and visual design.

Chapter 13: Product Marketing Managers

  • Usually not a full-time, dedicated member.
  • Business viability.

Chapter 14: The Supporting Roles

  • Not a full-time decided member.
  • User researchers:
    • Help to learn the most from user testing.
  • Data Analysts.
  • Test automation engineers.

Chapter 16: The Role of Leadership

  • Primary job: recruit, develop and retain strong talent.
  • While growing, keep a holistic view of product.

Chapter 17: The Head of Product Role

  • Most senior product role, peer to CTO.
  • Competencies:
    1. Develop a strong team of PM.
    2. Product vision and strategy:
      1. Only when the CEO is not the product visionary.
    3. Execution.
    4. Product culture.

Chapter 18: The Head of Technology Role

  • Objective: remove tech barriers and broadening what is possible.
  • Responsibilities, in order of importance:
    • Organization: people.
    • Leadership: strategic direction.
    • Delivery.
    • Architecture.
    • Discovery: ensure senior engineers are participating and contributing to product discovery.
    • Evangelism.

Chapter 19: The Delivery Manager Role

  • Project managers, and typically Scrum Masters.
  • Remove impediments.

Chapter 20: Principles of Structuring Product Teams

  • Principles:
    1. Team structure should follow investment strategy.
    2. Minimize dependencies.
    3. Ownership and autonomy.
    4. Maximize leverage:
      • Shared services.
      • But brings dependencies, reduces autonomy.
    5. Follow production vision and strategy.
    6. 3-12 people.
    7. Follow architecture (which should follow production vision).
    8. Align with user/customer:
      • Team to serve one type of user.
    9. Align with business units.
    10. Structure is a moving target:
      • Review at least yearly.

Part III: The Right Product

  • Typical roadmaps are the root cause of most waste and failed efforts in product organizations.

Chapter 22: The Problems with Product Roadmaps

  • Product discovery is the most important core competency of a product organization.
  • Issue with roadmap is that is treated as a commitment.
  • We need to solve the underlying problem, not deliver a feature.

Chapter 23: The Alternative to Roadmaps

  • Valid roadmap purposes:
    1. Ensure teams are working on the highest business value items.
    2. To track a date-based commitment, if there is any.
  • Product teams need business context (clarity in intent based leadership).
  • Two main components to provide business context:
    1. Product vision and strategy.
    2. Business objectives (not product ideas).
  • Outcome-based roadmaps (objective list) are good, as long as not all items have a deadline.
  • Deadlines:
    • Minimize them.
    • Issue is that the commitment is made too early (== not enough information).
    • High-integrity commitments:
      • Make commitment once value, UX, feasibility and business viability are clear.

Chapter 24: Product Vision and Product Strategy

  • Product vision must inspire, product strategy must focus.

Chapter 25: Principles of Product Vision

  1. Start with why:
    • Product vision articulate your purpose.
  2. Fall in love with the problem, not with the solution.
  3. Don’t be afraid to think big.
  4. Don’t be afraid to disrupt yourselves because if you don’t, someone else will.
  5. Needs to inspire.
  6. Determine and embrace relevant and meaningful trends.
  7. Skate to where the pack is heading, not to where it was.
  8. Be stubborn on vision but flexible on the details.
  9. Realize that any product vision is a leap of faith:
    • If you could truly validate a vision, then your vision is not ambitious enough.
  10. Evangelize continuously and relentlessly.

Chapter 26: Principles of Product Strategy

  1. Focus on one target market or person at a time:
    • Product will likely be useful to others, but at least will be loved by some, and that’s key.
  2. Needs to be aligned with business strategy.
  3. Needs to be aligned with sales and go-to-market strategy.
  4. Obsess over customers, not over competitors.
  5. Communicate the strategy across the org.

Chapter 27: Product Principles

  • Complement vision and strategy.
  • Production principles: nature of the products you want to build.

Chapter 28: The OKR Technique

  • Two fundamental principles:
    1. Tell people what to do, not how.
    2. Measure by result.
  • OKR = Objectives and Key Results:
    • Management + focus + alignment.
    • Objectives qualitative.
    • Results quantitative. Outcomes.
    • Typical cadence: org yearly, team quarterly.
    • 1-3 objectives, 1-3 key results.
    • Track weekly.
    • Team accountable.
    • Org-wide consistent evaluation/scoring.
    • Be transparent.
    • High-integrity commitments are binary.

Chapter 30: Product Objectives @ Scale

  • Large burden on leadership and management to ensure that the org is truly aligned, that each and every product team understands how they fit into the mix, and what they are there to contribute.

Chapter 31: Product Evangelism

  • If you are a PM and not good at evangelism, there is a strong chance that your product efforts will get derailed before they see the light of the day.

Part IV: The Right Process

  • Product discovery:
    • Single solution that works for many customers, and not a series of specials.
    • Learn fast + release with confidence (speed vs quality).
    • In this book product == production ready.
    • Most product teams have a better understanding on how to accomplish quality, rather than speed.
    • Key to effective product discovery is getting access to our customers without pushing quick experiments into production.

Chapter 33: Principles of Product Discovery

  1. Customer (and executives or stakeholders) cannot tell us what they want, because:
    1. They don’t know what is possible.
    2. Nobody knows what they want until they see it.
  2. Most important thing is to establish compelling value.
  3. UX is harder and more critical than engineering.
  4. Functionality, design and technology are intertwined.
  5. Many ideas won’t work, and the ones that do require several iterations.
  6. We must validate our ideas on real users and customers.
  7. Aim to validate ideas the fastest, cheapest way possible.
  8. Shared learning by the whole team.
  • Aim for 10-20 iterations per week.

Chapter 34: Discovery Techniques Overview

  1. Discovery framing techniques:
    • To quickly identify the underlying issues that must be tackled during product discovery.
    • Objective:
      1. Agree on the problem.
      2. Identify big risk to be tackled ruing discovery work.
    • Product discovery and validation only when there is significant risk.
  2. Discovery planning techniques:
    • To scope out and plan the discovery efforts.
    • Customer discovery program:
      • Loads of work.
      • Favourite leading indicator of future success.
  3. Discovery ideation techniques.
  4. Discovery prototyping techniques:

    • Different forms of prototypes, each suited to testing different things.

      Plan to throw one away, you will anyhow. Fred Brooks
  5. Discovery testing techniques:
    • Usual test order:
      1. Value.
      2. Usability.
      3. Feasibility.
      4. Business Viability.
    • Value and usability usually tested with the same users at the same time.
  6. Transformation techniques:
    • Way of work.

Discovery framing techniques

Chapter 35: Opportunity Assessment Technique

  • Answer:
    1. What business objective is this work intended to address? (Objective - Should match an OKR).
    2. How will you know if you’ve succeeded? (Key result - Should match an OKR).
    3. What problem will this solve for our customers? (Customer problem).
    4. What type of customer are we focused on? (Target market).
  • It is responsibility of the PM to answer these questions.

Chapter 36: Customer Letter Technique

  • For larger efforts.
  • Write an imagined press release.
  • Write an imagined letter from a happy customer to the CEO.

Chapter 37: Startup Canvas Technique

  • When trying to figure out the new product:
  • Typically, value is the most risky risk.

Discovery Planning Techniques

Chapter 38: Story Map Technique

Chapter 39: Customer Discovery Program Technique

  • Simple best tool for marketing and sales is the happy reference customer:
    • Real (not family/friends).
    • In production.
    • Paying.
    • Willing to tell others.
  • Discovery and developing a set of reference customers in parallel with discovery and developing the actual product.
  • Substantial effort.
  • Aim for 6 reference customers:
    • Same market.
    • Recruit 8.
    • Desperate for a solution, or a technologist.
    • Willing to spend time with product team and testing prototypes.
  • Not building features for all reference customers, but a single solution that works for all of them.
  • They do not pay in advance, it is a partner.
  • If you cannot recruit even 4 or 5, you are probably chasing the wrong problem.
  • Variations:
    • API/Platform products:
      • Reference apps instead of customers.
    • Customer-Enabling tools:
      • Well respected and influential internal users/employees.
    • Consumer products:
      • 10-50 users.
      • Supplement with much broad testing.

Discovery Ideation Techniques

Chapter 41: Customer Interviews

  • Try to understand:
    1. Are your customers who you think they are?
    2. Do they really have to problem you think they have?
    3. How does the customer solve this problem today?
    4. What would be required for them to switch?
  • Tips:
    • At least 2-3 hours per week.
    • Mindset: understand and learn. Not prove.
    • About 1 hour.
    • On their native habitat.
    • Be clear on the problem you think they have, and how you will either confirm or contradict that.
    • PM (takes notes) + engineer (listens) + product designer (leads).
    • Open-ended questions, learn what they are doing today.
    • Debrief with colleagues.

Chapter 42: Concierge Test Technique

  • Do your customer work.

Chapter 43: The Power of Customer Misbehavior

  • Encourage customers to use our product to solve problems other than what we planned for and officially support.
  • Not a useful technique for all companies.
  • Open API.

Chapter 44: Hack Days

  • Undirected: any problem related to mission.
  • Directed: a specific problem:
    • Facilitates the inclusion of engineers.
    • Help building a team of missionaries.

Discovery Prototyping Techniques

Chapter 45: Principles of Prototypes

  1. Cheap learning.
  2. Think deeper about the problem.
  3. Build shared understanding.
  4. Right level of fidelity.
  5. Tackle on or more product risks.
  • Can serve as a spec on what to build.

Chapter 46: Feasibility Prototype Technique

  • Just enough code to mitigate risk.

Chapter 47: User Prototype Technique

  • It is not good for proving anything.

Chapter 48: Live‐Data Prototype Technique

  • It is not okay for the PM to tell engineers that the prototype is good enough for production.

Chapter 49: Hybrid Prototype Technique

  • Wizard of Oz:
    • High fidelity FE and actual person manually performing the task.

Discovery Testing Techniques

Chapter 50: Testing Usability

  • This is not rocket science.
  • Key points:
    • Prefer high-fidelity user prototype.
    • PM + Designer + Engineer.
    • Prepare set of tasks to test.
    • Ask for candid feedback, good or bad.
    • Keep the users in “use mode” and out of “critique” mode.
      • What matters is whether users can easily do the tasks.
    • Keep quiet while the user is doing the task.
      • Avoid leading. Act like a parrot.
    • Objective: trying to figure out how your user thinks about the problem.
    • Summarize the learnings.

Chapter 51: Testing Value

  • Test demand, value qualitatively and quantitatively.

Chapter 52: Demand Testing Techniques

  • Testing for demand is easy.
  • Fake door demand testing:
    • Add button to new functionality but do not build anything.
    • Check click-through rate.
    • Ask in the fake page for volunteers to talk about the feature.
  • Same idea: landing page demand test but for whole product.

Chapter 53: Qualitative Value Testing Techniques

  • Not for proving anything but for quick learnings and big insights.
  • The single most important discovery activity.
  • 2-3 per week.
  • Don’t hire a firm to do this.
  • Steps:
    1. Customer interviews.
    2. Usability test.
    3. Value test, check if they are willing to pay:
      1. Money: give you credit card details or sign a non-binding letter of intent to buy.
      2. Reputation: Recommend to friends, in social media, workmates.
      3. Time: work with you for a significant time.

Chapter 54: Quantitative Value Testing Techniques

  • To collect evidence.
  • Types:
    1. Live-data prototype.
    2. A/B testing:
      • 1% or fewer users.
      • High volume traffic.
    3. Invite-only testing:
      • For risk-adverse or low volume.
    4. Use clients from the customer discovery program.

Chapter 56: Testing Business Viability

  • Stakeholders:
    • Marketing.
    • Sales.
    • Customer Success.
    • Finance.
    • Legal.
    • Business development.
    • Security.
    • CEO/COO/GM.

Transformation Techniques

Chapter 58: Discovery Sprint Technique

  • One week time-box of product discovery work to tackle a substantial risk.
  • Sprint: how to solve big problems and test new ideas in just five days.
  • Use when:
    1. Something big/critical/difficult to tackle.
    2. When learning product discovery.
    3. When moving too slow.

Chapter 59: Pilot Team Technique

  • To avoid freaking out the laggards.

Chapter 60: Weaning an Organization Off Roadmaps

  • Highlight the business outcome the feature is intended to help.
    • Celebrate if it does.
    • In not; emphasize that the feature was delivered but the result was not.

Process @ Scale

Chapter 61: Managing Stakeholders

  • Stakeholder: has vote power.
  • PM responsibility:
    • Understand considerations and constraints of stakeholders.
    • Commit to find solutions that also work for the stakeholders.
  • Success in stakeholder management == trust.
    • Trust comes from knowledge in customer, analytics, tech, industry and specially your business.
    • Gain trust by openly sharing what we learn.
  • Spend 1-2-1 time during discovery.
  • Group settings is not the forum for designing strong products.

Chapter 62: Communicating Product Learnings

  • Head of product to highlight big learnings at all-hands. Not more than 30 mins.

Part V: The Right Culture

Chapter 64: Good Product Team/Bad Product Team

  • Bad teams show the prototypes to engineers during sprint planning so they can estimate.
  • Speed comes from the right techniques and not forced labor.
  • Bad teams consider analytics and reporting a nice to have.
  • Good teams obsess over their reference customers. Bad teams obsess over their competitors.
  • Good teams celebrate impact. Bad teams celebrate when they finally release something.

Chapter 65: Top Reasons for Loss of Innovation

  • Missing one or more of:
    • Customer-centric culture.
    • Compelling product vision.
    • Focused product strategy.
    • Strong product managers.
    • Stable product teams.
    • Engineers in discovery.
    • Corporate courage.
    • Empowered product teams.
    • Time to innovate.
    • Product mindset.

Chapter 66: Top Reasons for Loss of Velocity

  • Tech debt.
  • Lack of strong PM.
  • Lack of delivery management.
  • Infrequent releases.
  • Lack of product vision and strategy.
  • Lack of co-located, durable product teams.
  • Not including engineers early enough during product discovery.
  • Not utilizing product design in discovery and instead having them try to do their work at the same time the engineers are trying to build.
  • Changing priorities.
  • A consensus culture.

Chapter 67: Establishing a Strong Product Culture

  • Two dimensions:
    1. Consistently innovate:
      • Experiments.
      • Open mind.
      • Empowerment.
      • Technology.
      • Business and customer-savvy teams.
      • Team diversity.
      • Discovery techniques.
    2. Consistent execution:
      • Urgency.
      • High integrity commitments.
      • Empowerment.
      • Accountability.
      • Collaboration.
      • Results (vs output).
      • Recognition.
  • Most companies that are exceptionally strong at execution are pretty tough places to work.
  • Only a few companies are strong both at innovation and execution.
Did you enjoy it? or share!

Tagged in : book notes