2017 InspiredHowtoCreateTechProducts

From GM-RKB
(Redirected from Cagan, 2017)
Jump to navigation Jump to search
  • (Cagan, 2017) ⇒ Marty Cagan. (2017). “Inspired: How to Create Tech Products Customers Love.” John Wiley & Sons.

Subject Headings: Software Product Management, Technology Product.

Notes

Cited By

Quotes

Book Overview

How do today’s most successful tech companies—Amazon, Google, Facebook, Netflix, Tesla—design, develop, and deploy the products that have earned the love of literally billions of people around the world? Perhaps surprisingly, they do it very differently than the vast majority of tech companies. In INSPIRED, technology product management thought leader Marty Cagan provides readers with a master class in how to structure and staff a vibrant and successful product organization, and how to discover and deliver technology products that your customers will love—and that will work for your business.

With sections on assembling the right people and skillsets, discovering the right product, embracing an effective yet lightweight process, and creating a strong product culture, readers can take the information they learn and immediately leverage it within their own organizations—dramatically improving their own product efforts.

Whether you’re an early stage startup working to get to product/market fit, or a growth-stage company working to scale your product organization, or a large, long-established company trying to regain your ability to consistently deliver new value for your customers, INSPIRED will take you and your product organization to a new level of customer engagement, consistent innovation, and business success.

Table of Contents

   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
           Holistic Product
           Continuous Discovery and Delivery
           Product Discovery
           Prototypes
           Product Delivery
           Products and Product/Market Fit
           Product Vision
   PART II: The Right People
       Product Teams
           Overview
       CHAPTER 9: Principles of Strong Product Teams
           Team of Missionaries
           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
           Key Responsibilities
           Deep Knowledge of the Customer
           Deep Knowledge of the Data
           Deep Knowledge of Your Business
           Deep Knowledge of Your Market and Industry
           Smart, Creative, and Persistent
           Product Manager Profiles
       CHAPTER 11: The Product Designer
           Product Discovery
           Holistic User Experience Design
           Prototyping
           User Testing
           Interaction and Visual Design
           The Absence of Product Design
       CHAPTER 12: The Engineers
       CHAPTER 13: Product Marketing Managers
       CHAPTER 14: The Supporting Roles
           User Researchers
           Data Analysts
           Test Automation Engineers
       CHAPTER 15: Profile: Jane Manning of Google People @ Scale
           Overview
       CHAPTER 16: The Role of Leadership
           Leaders of Product Management
           Leaders of Product Design
           Leaders of Technology Organization
           Holistic View Leadership Roles
       CHAPTER 17: The Head of Product Role
           Competencies
       CHAPTER 18: The Head of Technology Role
           Organization
           Leadership
           Delivery
           Architecture
           Discovery
           Evangelism
       CHAPTER 19: The Delivery Manager Role
       CHAPTER 20: Principles of Structuring Product Teams
       CHAPTER 21: Profile: Lea Hickman of Adobe
   PART III: The Right Product
       Product Roadmaps
           Overview
       CHAPTER 22: The Problems with Product Roadmaps
       CHAPTER 23: The Alternative to Roadmaps
       Product Vision
           Overview
       CHAPTER 24: Product Vision and Product Strategy
           The Product Vision
           The Product Strategy
       CHAPTER 25: Principles of Product Vision
       CHAPTER 26: Principles of Product Strategy
       CHAPTER 27: Product Principles
       Product Objectives
           Overview
       CHAPTER 28: The OKR Technique
       CHAPTER 29: Product Team Objectives
       Product @ Scale
           Overview
       CHAPTER 30: Product Objectives @ Scale
       CHAPTER 31: Product Evangelism
       CHAPTER 32: Profile: Alex Pressland of the BBC
   PART IV: The Right Process
       Product Discovery
           Overview
       CHAPTER 33: Principles of Product Discovery
       CHAPTER 34: Discovery Techniques Overview
           Discovery Framing Techniques
           Discovery Planning Techniques
           Discovery Ideation Techniques
           Discovery Prototyping Techniques
           Discovery Testing Techniques
           Testing Feasibility
           Testing Usability
           Testing Value
           Testing Business Viability
           Transformation Techniques
       Discovery Framing Techniques
           Overview
       CHAPTER 35: Opportunity Assessment Technique
           Business Objective
           Key Results
           Customer Problem
           Target Market
       CHAPTER 36: Customer Letter Technique
       CHAPTER 37: Startup Canvas Technique
       Discovery Planning Techniques
           Overview
       CHAPTER 38: Story Map Technique
       CHAPTER 39: Customer Discovery Program Technique
           The Power of Reference Customers
           Single Target Market
           Recruiting the Prospective Reference Customers
           The Relationship
           Platform/API Products
           Customer‐Enabling Tools
           Consumer Products
           Summary
       CHAPTER 40: Profile: Martina Lauchengco of Microsoft
       Discovery Ideation Techniques
           Overview
       CHAPTER 41: Customer Interviews
       CHAPTER 42: Concierge Test Technique
       CHAPTER 43: The Power of Customer Misbehavior
       CHAPTER 44: Hack Days
       Discovery Prototyping Techniques
           Overview
           Feasibility Prototypes
           User Prototypes
           Live‐Data Prototypes
           Hybrid Prototypes
       CHAPTER 45: Principles of Prototypes
       CHAPTER 46: Feasibility Prototype Technique
       CHAPTER 47: User Prototype Technique
       CHAPTER 48: Live‐Data Prototype Technique
       CHAPTER 49: Hybrid Prototype Technique
       Discovery Testing Techniques
           Overview
       CHAPTER 50: Testing Usability
           Recruiting Users to Test
           Preparing the Test
           Testing Your Prototype
           Summarizing the Learning
       CHAPTER 51: Testing Value
           Testing Demand
           Testing Value Qualitatively
           Testing Value Quantitatively
       CHAPTER 52: Demand Testing Techniques
       CHAPTER 53: Qualitative Value Testing Techniques
           Interview First
           Usability Test
           Specific Value Tests
           Iterating the Prototype
       CHAPTER 54: Quantitative Value Testing Techniques
           A/B Testing
           Invite‐Only Testing
           Customer Discovery Program
       CHAPTER 55: Testing Feasibility
       CHAPTER 56: Testing Business Viability
           Marketing
           Sales
           Customer Success
           Finance
           Legal
           Business Development
           Security
           CEO/COO/GM
       CHAPTER 57: Profile: Kate Arnold of Netflix
       Transformation Techniques
           Overview
       CHAPTER 58: Discovery Sprint Technique
       CHAPTER 59: Pilot Team Technique
       CHAPTER 60: Weaning an Organization Off Roadmaps
       Process @ Scale
           Overview
       CHAPTER 61: Managing Stakeholders
           Stakeholder Defined
           Product Manager Responsibilities
           Strategies for Success
       CHAPTER 62: Communicating Product Learnings
       CHAPTER 63: Profile: Camille Hearst of Apple
   PART V: The Right Culture
       CHAPTER 64: Good Product Team/Bad Product Team
       CHAPTER 65: Top Reasons for Loss of Innovation
       CHAPTER 66: Top Reasons for Loss of Velocity
       CHAPTER 67: Establishing a Strong Product Culture

Chapter 1 - Behind Every Great Product

It is my strong belief, and the central concept driving this book, that behind every great product there is someone—usually someone behind the scenes, working tirelessly — who led the product team to combine technology and design to solve real customer problems in a way that met the needs of the business.

These people usually have the title product manager, but they might be a startup co‐founder or CEO, or they might be someone in another role on the team who stepped up because they saw the need.

Further, this product management role is very distinct from the design, engineering, marketing, or project manager roles.

...

CHAPTER 2: Technology‐Powered Products and Services [1]

https://www.oreilly.com/library/view/inspired-2nd-edition/9781119387503/c02.xhtml

There are many kinds of products out there, but in this book, I concentrate exclusively on products that are powered by technology.


...

...

Chapter 7 [1]

https://www.oreilly.com/library/view/inspired-2nd-edition/9781119387503/c07.xhtml

People are always searching for a silver bullet to create products, and there is always a willing industry—ready and waiting to serve with books, coaching, training, and consulting. But there is no silver bullet, and inevitably people figure this out. That's when the backlash begins. As I write this, it's in vogue to criticize both Lean and Agile.

I have no doubt that many people and teams are in some measure disappointed with the results from their adoption of both Lean and Agile. And I understand the reasons for this. That said, I am convinced that Lean and Agile values and principles are here to stay. Not so much the particular manifestations of these methods that many teams use today, but the core principles behind them. I would argue that they both represent meaningful progress, and I would never want to go backward on those two fronts.

...

Chapter 8 - Key Concepts [2]

https://www.oreilly.com/library/view/inspired-2nd-edition/9781119387503/c08.xhtml

...

Continuous Discovery and Delivery

I explained previously that most companies still have a process that is essentially waterfall at its core, and I told you that what we do in a modern team is very different.

...

...

Most of the time your engineers will review your product ideas and tell you that they have no real concerns about feasibility. This is because they have likely built similar things many times before. However, there are several situations wherein your engineers may identify a significant feasibility risk involved in solving a particular problem they are working on. Common examples include: Algorithm concerns Performance concerns Scalability concerns Fault tolerance concerns Use of a technology the team has not used before Use of a third‐party component or service the team has not used before Use of a legacy system the team has not used before Dependency on new or related changes by other teams The idea is to write just enough code to mitigate the feasibility risk. The main technique used for tackling these types of risks is for one or more of the engineers to build a feasibility prototype. An engineer will create the feasibility prototype because it is typically code (as opposed to most prototypes created by special‐purpose tools intended to be used by product designers). A feasibility prototype is a long way from a commercially shippable product—the idea is to write just enough code to mitigate the feasibility risk. This typically represents just a small percentage of the work for the eventual shippable product. Further, most of the time the feasibility prototype is intended to be throwaway code—it's okay and normal to be quick and dirty with this. It is intended to be just enough to collect the data, for example, to show that performance would likely be acceptable or not. There is usually no user interface, error handling, or any of the typical work involved in productization. In my experience, building a feasibility prototype requires usually just a day or two of time. If you're exploring a major new technology, such as a new approach leveraging machine‐learning technology, then the feasibility prototype could very well take significantly longer. The amount of time the feasibility prototype is estimated to take comes from the engineers, but whether or not the team takes that time depends on the product manager's judgment call as to whether it's worth pursuing this idea. She might say many other approaches to this problem don't have the technology feasibility risk, so she would rather skip this idea. While it's the engineers who do this feasibility prototyping work, it is considered discovery work and not delivery work. It's done as part of deciding whether to even pursue this particular approach or idea. In terms of lessons learned, I have seen many teams proceed to delivery without adequately considering the feasibility risk. Whenever you hear stories of product teams that grossly underestimated the amount of work required to build and deliver something, this is usually the underlying reason. It may be that the engineers were simply too inexperienced with their estimates, that the engineers and product manager had an insufficient understanding of what was going to be needed, or that the product manager did not give the engineers sufficient time to truly investigate.

...

PART II: The Right People

Product Teams

Overview

CHAPTER 9: Principles of Strong Product Teams

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

...

Product companies moved to this model several years ago, and it's now one of the pillars of modern, strong product organizations. There are several reasons why this model has been so effective. First, collaboration is built on relationships, and product teams—especially co‐located teams—are designed to nurture these relationships. Second, to innovate you need expertise, and the durable nature of product teams lets people go deep enough to gain that expertise. Third, instead of just building what others determine might be valuable, in the product team model the full team understands—needs to understand—the business objectives and context. And most important, the full team feels ownership and responsibility for the outcome.

...

CHAPTER 10: The Product Manager

           Key Responsibilities
           Deep Knowledge of the Customer
           Deep Knowledge of the Data
           Deep Knowledge of Your Business
           Deep Knowledge of Your Market and Industry
           Smart, Creative, and Persistent
           Product Manager Profiles

CHAPTER 11: The Product Designer

           Product Discovery
           Holistic User Experience Design
           Prototyping
           User Testing
           Interaction and Visual Design
           The Absence of Product Design

CHAPTER 12: The Engineers

CHAPTER 13: Product Marketing Managers

CHAPTER 14: The Supporting Roles

           User Researchers
           Data Analysts
           Test Automation Engineers

CHAPTER 15: Profile: Jane Manning of Google People @ Scale

Overview

CHAPTER 16: The Role of Leadership

...

Leaders of Product Design

...

Leaders of Technology Organization

...

Holistic View Leadership Roles

...

CHAPTER 17: The Head of Product Role

Competencies

CHAPTER 18: The Head of Technology Role

...

Organization

...

Leadership

...

Delivery

...

Architecture

...

Discovery

...

Evangelism

CHAPTER 19: The Delivery Manager Role

...

CHAPTER 20: Principles of Structuring Product Teams

...

CHAPTER 21: Profile: Lea Hickman of Adobe

...

PART III: The Right Product

Product Roadmaps

Overview

CHAPTER 22: The Problems with Product Roadmaps

CHAPTER 23: The Alternative to Roadmaps [3]

https://www.oreilly.com/library/view/inspired-2nd-edition/9781119387503/c23.xhtml

In this chapter, I describe the alternative to product roadmaps. It's a big topic, and it touches on issues beyond product roadmaps, such as product culture, morale, empowerment, autonomy, and innovation. But my hope is to lay the foundation here and provide the details in the chapters that follow.

Before we jump into the alternative, however, we need to remind ourselves that roadmaps have existed for so long because they serve two purposes, and these needs don't go away:

  • The first purpose is because the management of the company wants to make sure that teams are working on the highest‐business‐value items first.
  • The second purpose is because—since they're trying to run a business—there are cases where they need to make date‐based commitments, and the roadmap is where they see and track those commitments (even though in most companies, they rarely trust the dates anymore).

So, to be accepted in most companies, any alternative approach to roadmaps must address these needs at least as well as they are addressed today.

In the empowered product team model this book is predicated on, the teams are themselves equipped to figure out the best ways to solve the particular business problems assigned to them. But for this to happen, it's not enough to have strong people equipped with modern tools and techniques. The product teams need to have the necessary business context. They need to have a solid understanding of where the company is heading, ...

...

The second driver is the occasional need for committing to a hard date. We address this with the concept of high‐integrity commitments, used for those situations where we need to commit to a date or a specific deliverable.

There are several benefits to this way of working:

  • First, the teams are much more motivated when they are free to solve the problem the best way they see fit. It's the missionary versus mercenary thing again. Moreover, the teams are designed to be in the best position to solve these problems.
  • Second, the team is not off the hook just by delivering a requested feature or project. The feature must solve the business problem (as measured by the key results); otherwise, the team needs to try a different approach to the solution.
  • Third, no matter where the idea for the solution comes from, or how smart that person is, very often the initial approach doesn't work out. Rather than pretending this is not the case, this model embraces that likelihood.

It is all about outcome rather than output.

There are a few product teams out there that have modified their product roadmaps so that each item is stated as a business problem to solve rather than the feature or project that may or may not solve it. These are called outcome‐based roadmaps.

In general, when I see these, I'm pretty happy because I know the product teams are stepping up to solve business problems rather than build features. Outcome‐based roadmaps are essentially equivalent to using a business objective–based system such as the OKR system. It's the format that's different more than the content.

There is a tendency, however, with outcome‐based roadmaps to put a deadline date on every item, rather than only on the items with a true date constraint. This practice can have cultural and motivation implications to the team.

...

Product Vision - Overview

...

CHAPTER 24: Product Vision and Product Strategy [4]

https://www.oreilly.com/library/view/inspired-2nd-edition/9781119387503/c24.xhtml

The Product Vision

The product vision describes the future we are trying to create, typically somewhere between two and five years out. For hardware or device‐centric companies, it's usually five to 10 years out.

Note that this is not the same as the company mission statement. Examples of mission statements are “organize the world's information” or “make the world more open and connected” or “enable anyone anywhere to buy anything anytime.” Mission statements are useful, but they don't say anything about how we plan on accomplishing that. That's what the product vision is for.

Note also that the vision is not in any sense a spec. It's mainly a persuasive piece that might be in the form of a storyboard, a narrative such as a white paper, or a special type of prototype referred to as a visiontype.

Its primary purpose is to communicate this vision and inspire the teams (and stakeholders, investors, partners—and, in many cases, prospective customers) to want to help make this vision a reality.

Its primary purpose is to communicate this vision and inspire the teams to want to help make this vision a reality.

When done well, the product vision is one of our most effective recruiting tools, and it serves to motivate the people on your teams to come to work every day. Strong technology people are drawn to an inspiring vision—they want to work on something meaningful.

You can do some amount of testing of the vision, but it's not the same ...

...

The Product Strategy

CHAPTER 25: Principles of Product Vision

CHAPTER 26: Principles of Product Strategy

CHAPTER 27: Product Principles

Product Objectives
Overview

CHAPTER 28: The OKR Technique

CHAPTER 29: Product Team Objectives

Product @ Scale
Overview

CHAPTER 30: Product Objectives @ Scale

CHAPTER 31: Product Evangelism

CHAPTER 32: Profile: Alex Pressland of the BBC

...

...

CHAPTER 54: Quantitative Value Testing Techniques

A/B Testing

Invite‐Only Testing

Customer Discovery Program

CHAPTER 46: Feasibility Prototype Technique

Most of the time your engineers will review your product ideas and tell you that they have no real concerns about feasibility. This is because they have likely built similar things many times before.

However, there are several situations wherein your engineers may identify a significant feasibility risk involved in solving a particular problem they are working on. Common examples include: Algorithm concerns Performance concerns Scalability concerns Fault tolerance concerns Use of a technology the team has not used before Use of a third‐party component or service the team has not used before Use of a legacy system the team has not used before Dependency on new or related changes by other teams The idea is to write just enough code to mitigate the feasibility risk.

The main technique used for tackling these types of risks is for one or more of the engineers to build a feasibility prototype.

An engineer will create the feasibility prototype because it is typically code (as opposed to most prototypes created by special‐purpose tools intended to be used by product designers). A feasibility prototype is a long way from a commercially shippable product—the idea is to write just enough code to mitigate the feasibility risk. This typically represents just a small percentage of the work for the eventual shippable product. Further, most of the time the feasibility prototype is intended to be throwaway code—it's okay and normal to be quick and dirty with this. It is intended to be just enough to collect the data, for example, to show that performance would likely be acceptable or not. There is usually no user interface, error handling, or any of the typical work involved in productization. In my experience, building a feasibility prototype requires usually just a day or two of time. If you're exploring a major new technology, such as a new approach leveraging machine‐learning technology, then the feasibility prototype could very well take significantly longer. The amount of time the feasibility prototype is estimated to take comes from the engineers, but whether or not the team takes that time depends on the product manager's judgment call as to whether it's worth pursuing this idea. She might say many other approaches to this problem don't have the technology feasibility risk, so she would rather skip this idea. While it's the engineers who do this feasibility prototyping work, it is considered discovery work and not delivery work. It's done as part of deciding whether to even pursue this particular approach or idea. In terms of lessons learned, I have seen many teams proceed to delivery without adequately considering the feasibility risk. Whenever you hear stories of product teams that grossly underestimated the amount of work required to build and deliver something, this is usually the underlying reason. It may be that the engineers were simply too inexperienced with their estimates, that the engineers and product manager had an insufficient understanding of what was going to be needed, or that the product manager did not give the engineers sufficient time to truly investigate.

...

CHAPTER 47: User Prototype Technique

...

CHAPTER 48: Live‐Data Prototype Technique

...

CHAPTER 49: Hybrid Prototype Technique

...

CHAPTER 54: Quantitative Value Testing Techniques

A/B Testing

Invite‐Only Testing

Customer Discovery Program

CHAPTER 55: Testing Feasibility

When we talk about validating feasibility, the engineers are really trying to answer several related questions:

  • Do we know how to build this?
  • Do we have the skills on the team to build this?
  • Do we have enough time to build this?
  • Do we need any architectural changes to build this?
  • Do we have on hand all the components we need to build this?
  • Do we understand the dependencies involved in building this?
  • Will the performance be acceptable?
  • Will it scale to the levels we need?
  • Do we have the infrastructure necessary to test and run this?
  • Can we afford the cost to provision this?

I don't want to scare you. With most product ideas that your engineers review in discovery, they will quickly consider these points and simply say “No problem.” That's because most of our work is not all that new, and engineers have usually built similar things many times before.

However, there are definitely ideas where this is not the case, and some or many of these questions can be very difficult for the engineers to answer.

One very common example right now is that many teams are evaluating machine‐learning technology, considering build/buy decisions, and assessing whether the technology is suitable for the job at hand — and, more generally, trying to understand its potential.

Here's some very practical and important advice for you to consider. Holding a weekly planning meeting where you throw a bunch of ideas at the engineers — and demand they give you some sort of estimate either in time, story points, or any other unit of effort — is almost certain to go badly. If you put an engineer on the spot, without time to investigate and consider, you are very likely to get a conservative answer, partly designed to make you go away.

If, however, the engineers have been following along as the team has tried out these ideas with customers (using prototypes) and seen what the issues are and how people feel about these ideas, the engineers have probably already been considering the issues for some time. If it's something you think is worthwhile, then you need to give the engineers some time to investigate and consider it.

The question isn't, “Can you do this?” Rather, you are asking them to look into it and answer the question, “What's the best way to do this and how long would it take?”

...

CHAPTER 56: Testing Business Viability

...

References

;

 AuthorvolumeDate ValuetitletypejournaltitleUrldoinoteyear
2017 InspiredHowtoCreateTechProductsMarty CaganInspired: How to Create Tech Products Customers Love2017