Inspired

Marty Cagan

2017

How to Create Tech Products Customers Love

Part I - Lessons from Top Tech Companies

Chapter 1 - Behind Every Great Product

Chapter 2 - Technology-Powered Products and Services

Chapter 3 - Startups: Getting to Product / Market Fit

Chapter 4 - Growth-Stage Companies: Scaling to Success

Chapter 5 - Enterprise Companies: Consistent Product Innovation

Chapter 6 - The Root Causes of Failed Product Efforts

Chapter 7 - Beyond Lean and Agile

Chapter 8 - Key Concepts

Product Discovery

• 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?

Prototypes should require at least an order of magnitude of less time and effort than building a product. Test 10-20+ product ideas per week.

We use prototypes to conduct rapid experiments in product discovery, and then delivery, we build and release products in hopes of achieving product / market fit, which is a key step on the way to delivering on the company's product vision.

An MVP should never be an actual product; the MVP should be a prototype, not a product.

Part II - The Right People

Product Teams

Chapter 9 - Principles of Strong Product Teams

• Team Composition
• Team Empowerment and Accountability
• Team Size
• Team Reporting Structure
• Team Collaboration
• Team Location
• Team Scope
• Team Duration
• Team Autonomy
• Why It Works

Chapter 10 - The Product Manager

• deep Knowledge of the Customer
• deep Knowledge of the Data
• deep Knowledge of Your Business
• deep Knowledge of Your Market and Industry

Chapter 11 - The Product Designer

Interaction Design vs. Visual Design

• have your designer sit next to you
• include your designer from the very inception of every idea
• include your designer in as many customer and user interactions as possible
• give your designer as much room as possible to solve the design challenges himself
• encourage your designer to iterate early and often and to explore several alternative solutions to the problem

Chapter 12 - The Engineers

• engage directly with your engineers every workday
• solicit their ideas and input for the items you're working on in discovery
• answer clarifying questions on the items they're working on delivering to production
• give your engineers as much latitude as possible in coming up with the best solution
• make them feel like *missionaries* and not *mercenaries*: involve them deeply in the customer pain you are trying to solve and in the business problems you face
• involve as much as possible as much as you can in discovery activities, at least the tech lead

Chapter 13 - The Product Marketing Manager

• represents the market to the product team:
  • the positioning
  • the messaging
  • a winning go-to-market plan
• deeply engaged with the sales channels and know their:
  • capabilities
  • limitations
  • current competitive issues
• plays essential role in:
  • discovery
  • delivery
  • go-to-market

Chapter 14 - The Supporting Roles

• User Researchers
• Data Analysts / Business Intelligence Analysts
• Test Automation Engineers (higher-level testing than QA which is usually integrated in the engineering team)

People @ Scale

Chapter 16 - The Role of Leadership

• Leaders of Product Management ensure a holistic view of how the entire system fits together from a business point of view (product vision, strategy, functionality, business rules, and business logic)
• Leaders of Product Design are responsible for the holistic user experience (everything going on with the product that is going to be visible to the user)
• Leaders of Technology Organization are responsible for the holistic view of the system implementation (architecture and systems design of all the software (proprietary and third-party), technical debt)

Chapter 17 - The Head of Product Role

Competencies

• team development
• product vision
• execution
• product culture:
  • communicates the importance of continuous and rapid testing and learning
  • communicates the need to make mistakes in order to learn, but to make them quickly while mitigating the risks
  • communicates the importance for continuous innovation

Chapter 18 - The Head of Technology Role

• organization
• leadership
• delivery
• architecture
• discovery
• evangelism

Chapter 19 - The Delivery Manager Role

A special type of project manager whose mission is all about removing obstacles for the team.

Chapter 20 - Principle of Structuring Product Teams

• alignment with investment strategy
• minimize dependencies
• ownership and autonomy
• maximize leverage
• product vision and strategy
• team size
• alignment with architecture
• alignment with user or customer
• alignment with business
• structure is a moving target

Part III - The Right Product

Product Roadmaps

Chapter 22 - The Problems with Product Roadmaps

Chapter 23 - The alternative to Roadmaps

Purpose for Roadmaps

• being sure that teams are working on the highest-business-value items first
• need for date-based commitments

Product teams need business context

• product vision and strategy
• business objectives (with measurable results)

Outcome-based Roadmaps

Commitments after Product discovery

Product Vision

Chapter 24 - Product Vision and Product Strategy

Chapter 25 - Principles of Product Vision

• start with why
• fall in love with the problem, not the solution
• don't be afraid to think big with vision
• don't be afraid to disrupt yourselves because, if you don't, someone else will
• the product vision needs to inspire
• determine and embrace relevant and meaningful trends
• skate to where the puck is heading, not where it was
• be stubborn on vision but flexible on details
• realize that any product vision is a leap of faith
• evangelize continuously and relentlessy

Chapter 26 - Principles of Product Strategy

• focus on one target market or persona at a time
• product strategy needs to be aligned with business strategy
• product strategy needs to be aligned with sales and go-to-market strategy
• obsess over customers, not over competitors
• communicate the strategy across the organization

Chapter 27 - Product Principles

Product Objectives

Chapter 28 - The OKR Technique

Objectives should be qualitative; key results need to be quantitative/measurable business results, not output/tasks

Track active progress (weekly) and feel accountable

Product teams come up with key results proposals for their objectives.

Chapter 29 - Product Team Objectives

Keep OKRs at product team level vs. cross-functional.

Product @ Scale

Chapter 30 - Product Objectives @ Scale

Chapter 31 - Product Evangelism

'Sell the dream!'

• use a prototype
• share the (customer) pain
• share the vision
• share learnings generously
• share credit generously
• learn how to give a great demo
• do your homework
• be genuinely excited
• learn to show some enthusiasm
• spend time with your team

Part IV - The Right Process

Product Discovery

Chapter 33 - Principles of Product Discovery

• Value Risk: Will the customer buy 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?

Chapter 34 - Discovery Techniques Overview

Discovery Framing Techniques

Chapter 35 - Opportunity Assessment Technique

• Objective: What objective is this work intended to address?
• Key Results: How will we know if we've succeeded?
• Customer Problem: What problem will this solve for our customers?
• Target Market: What type of customer are we focused on?

Chapter 36 - Customer Letter Technique

Chapter 37 - Discovery Planning Techniques

Discovery Planning Techniques

Chapter 38 - Story Map Technique

Chapter 39 - Customer Discovery Program Technique

A Reference Customer is a real customer (not friends or family), who is running your product in production (not a trial or prototype), who has paid real money for the product (it wasn't given away to entice them to use it), and, most important, who is willing to tell others how much they love your product (voluntarily and sincerely).

6 Reference Customers is the pivotal number. No more than 8.

Sean Ellis test.

Discovery Ideation Techniques

Chapter 41 - Customer Interviews

• 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?

Product Manager + Product Designer + one Engineer

Chapter 42 - Concierge Test Technique

Chapter 43 - The Power of Customer Misbehavior

Chapter 44 - Hack Days

Discovery Prototyping Techniques

Chapter 45 - Principles of Prototypes

Chapter 46 - Feasibility Prototype Technique

Chapter 47 - User Prototype Technique

"A user prototype is key to several types of validation [but not sufficient] and is also one of our most important communication tools."

Chapter 48 - Live-Data Prototype Technique

Very limited implementation (5-10% of ultimate productization), without all use cases, automated tests, analytics, internationalization, performance and scalability, SEO... in order to collect basic live usage data on real users.

Chapter 49 - Hybrid Prototype Technique

Wizard of Oz prototype

Discovery Testing Techniques

• Will the user buy this (or choose to use it)? (Value)
• Can the user figure out how to use this? (Usability)
• Can our engineers build this? (Feasibility)
• Can our stakeholders support this? (Business viability)

Chapter 50 - Testing Usability

Recruiting Users to Test

Preparing the Test

• high-fidelity user prototype
• product manager, product designer, and one engineer
• set of tasks to test
• one person administer the test and the other takes notes

Testing your Prototype

• only a prototype, no hurt feelings, no pass-or-fail: only candid feedback
• test your landing page
• keep it pure usage-focused, not critics-focused (users are not product experts)
• keep silent; do not help
• see if they ask for an email, hopefully early on in the process
• send short report to the team

Chapter 51 - Testing Value

“The customer must perceive your product to be substantially better to motivate them to buy your product and then wade through the pain and obstacles of migrating from their old solution.”

Chapter 52 - Demand Testing Techniques

“The demand-testing technique is called a fake door demand test [or landing page demand test]. What’s critical for this to be effective is that the users not have any visible indication that this is a test until after they click that button.”

Chapter 53 - Qualitative Value Testing

“The single most important discovery activity: two or three times a week”

• interview to make sure our user has the problem considered
• usability test to make the user familiarise with the current product
• specific qualitative value tests (making sure the user is not just being nice to you): money test, reputation test, time test, access test
• iterating the prototype

Chapter 54 - Quantitative Value Testing

A/B Testing

Invite-Only Testing

Customer Discovery Program

Analytics KPIs

• User Behavior analytics (click paths, time to close)
• Business analytics (active users, conversion rate, lifetime value, retention)
• Financial analytics (ASP, billings, time to close)
• Performance (load time, uptime)
• Operational costs (storage, hosting)
• Go-to-market costs (acquisition costs, cost of sales, programs)
• Sentiment (NPS, customer satisfaction, surveys)

Chapter 55 - Testing Feasibility

Give time to engineers to investigate feasibility. If time is needed to investigate, it means the problem might be solvable with new technology only. It also gives engineers an opportunity to shine.

Chapter 56 - Testing Business Viability

• Marketing (& go-to-market channels)
• Sales (direct vs. indirect)
• Customer Success (high-touch vs. low-touch)
• Finance
• Legal
• Business Development
• Security
• CEO/COO/GM

User Test vs. Product Demo vs. Walkthrough

Transformation Techniques

Chapter 58 - Discovery Sprint Technique

“A discovery sprint is a one-week time box of product discovery work, designed to tackle a substantial problem or risk your product team is facing.”

Discovery Coaches

Chapter 59 - Pilote Team Technique

Compare KPIs

Chapter 60 - Weaning an Organization Off Roadmaps

Progressively move focus towards business outcomes.

Processes @ Scale

Chapter 61 - Managing Stakeholders

Stakeholders defined

• the executive team (CEO and leaders of marketing, sales, and technology)
• business partners (to make sure the product and the business are aligned)
• Finance (to make sure the product fits within the financial parameters and model of the company)
• Legal (to make sure that what you propose is defensible)
• Compliance (to make sure what you propose complies with any relevant standards or policies)
• Business Development (to make sure what you propose does not violate any existing contracts or relationships)

Product Manager Responsibilities

“The Product manager has the responsibility to understand the consideration and constraints of the various stakeholders, and to bring this knowledge into the product team.”

Strategies for Success

“Success in terms of stakeholders management means that your stakeholders respect you and your contribution.”

• involve stakeholders in the product discovery process.
• in case of disagreement, rely on data
• keep them in the loop weekly sharing high-fidelity prototype

Chapter 62 - Communicating Product Learnings

“The big learnings are important to share broadly, especially when things don’t go as hoped.”

Part V - The Right Culture

Chapter 64 - Good Product Team / Bad Product Team

Chapter 65 - Top Reasons for Loss of Innovation

Missing one or more of the following attributes

• customer-centric culture
• compelling product vision
• focused product strategy
• strong product managers
• stable product teams
• engineers at discovery
• corporate courage
• empowered product teams
• product mindset
• time to innovate

Chapter 66 - Top Reasons for Loss of Velocity

• technical debt
• lack of strong product managers
• lack of delivery management
• infrequent release cycles
• 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

Strong innovation culture

• culture of experimentation
• culture of open minds
• culture of empowerment
• culture of technology
• culture of business
• culture of skill-set and staff diversity
• culture of discovery techniques

Strong execution culture

• culture of urgency
• culture of high-integrity commitments
• culture of empowerment
• culture of accountability
• culture of collaboration
• culture of results
• culture of negotiation