2017 InspiredHowtoCreateTechProducts
- (Cagan, 2017) ⇒ Marty Cagan. (2017). “Inspired: How to Create Tech Products Customers Love.” John Wiley & Sons.
Subject Headings: Software Product Management, Technology Product.
Notes
- Publisher book space:
https://www.oreilly.com/library/view/inspired-2nd-edition/9781119387503/
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
;
| Author | volume | Date Value | title | type | journal | titleUrl | doi | note | year | |
|---|---|---|---|---|---|---|---|---|---|---|
| 2017 InspiredHowtoCreateTechProducts | Marty Cagan | Inspired: How to Create Tech Products Customers Love | 2017 |
- ↑ https://www.oreilly.com/library/view/inspired-2nd-edition/9781119387503/c07.xhtml
- ↑ https://www.oreilly.com/library/view/inspired-2nd-edition/9781119387503/c08.xhtml
- ↑ https://www.oreilly.com/library/view/inspired-2nd-edition/9781119387503/c23.xhtml
- ↑ https://www.oreilly.com/library/view/inspired-2nd-edition/9781119387503/c24.xhtml