20,99 €
Mehr erfahren.
- Herausgeber: John Wiley & Sons
- Kategorie: Fachliteratur
- Serie: Silicon Valley Product Group
- Sprache: Englisch
Learn to design, build, and scale products consumers can't get enough of
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 most 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.
Filled with the author's own personal stories¯and profiles of some of today's most-successful product managers and technology-powered product companies, including Adobe, Apple, BBC, Google, Microsoft, and Netflix¯INSPIRED will show you how to turn up the dial of your own product efforts, creating technology products your customers love.
The first edition of INSPIRED, published ten years ago, established itself as the primary reference for technology product managers, and can be found on the shelves of nearly every successful technology product company worldwide. This thoroughly updated second edition shares the same objective of being the most valuable resource for technology product managers, yet it is completely new¯sharing the latest practices and techniques of today's most-successful tech product companies, and the men and women behind every great product.
Sie lesen das E-Book in den Legimi-Apps auf:
Seitenzahl: 409
Veröffentlichungsjahr: 2017
Ähnliche
Table of Contents
Cover
Preface to the Second Edition
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
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
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
CHAPTER 22: The Problems with Product Roadmaps
CHAPTER 23: The Alternative to Roadmaps
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
CHAPTER 28: The OKR Technique
CHAPTER 29: Product Team Objectives
CHAPTER 30: Product Objectives @ Scale
CHAPTER 31: Product Evangelism
CHAPTER 32: Profile: Alex Pressland of the BBC
PART IV: The Right Process
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
CHAPTER 35: Opportunity Assessment Technique
Business Objective
Key Results
Customer Problem
Target Market
CHAPTER 36: Customer Letter Technique
CHAPTER 37: Startup Canvas Technique
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
CHAPTER 41: Customer Interviews
CHAPTER 42: Concierge Test Technique
CHAPTER 43: The Power of Customer Misbehavior
CHAPTER 44: Hack Days
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
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
CHAPTER 58: Discovery Sprint Technique
CHAPTER 59: Pilot Team Technique
CHAPTER 60: Weaning an Organization Off Roadmaps
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
Acknowledgments
About the Author
Learning More
Index
End User License Agreement
List of Illustrations
Chapter 6
FIGURE 6.1 Root Causes of Failed Product Efforts
Chapter 8
FIGURE 8.1 Continuous Discovery and Delivery
Guide
Cover
Table of Contents
Begin Reading
Pages
i
ii
iii
iv
v
vi
ix
x
xi
xiii
xvii
xviii
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
351
“INSPIRED is the authority on how to build a product that customers actually want. It's not about hiring product managers ‐ it's about establishing a culture that puts the user first, and builds the organization and teams around that customer to ensure that you are building the best product possible. From CEOs to APMs, this is required reading.”
—Amanda Richardson, Chief Data and Strategy Officer, HotelTonight
“We first started working with Marty when ImmobilienScout was entering growth‐stage, and he helped us set the organization up to rapidly scale and grow to become one of the largest and most successful technology startups in Germany. He remained a friend and advisor to the company for many years. His book INSPIRED helped people from all across the company, and the new version is sure to help many more companies.”
—Jürgen Böhm, Co‐Founder, Immobilien Scout GmbH
“It does not matter if you are a seasoned product leader or a new product manager, INSPIRED will make you realise that you have the best job in the world and can have incredible impact ‐ especially if you follow Marty Cagan's words of wisdom. His book has been the bible of our industry for the past decade, and it will no doubt continue to be so with this latest update containing the most exciting best‐in‐class product practices.
—Tanya Cordrey, former Chief Digital Officer at Guardian News & Media
“Building a great product that nails Product/Market Fit is always a key first step to any successful start‐up. However, organizing the product and engineering teams, in ways that ensures scalability, speed, and quality is usually the next biggest challenge. Marty's insights and lessons learned can be applied to build highly productive teams to manage through dependencies, and build a culture that is positioned to scale. This applies whether your business is in need of a serious course correction, or on a rocket ship.”
—Scott Sahadi, Founder and CEO, The Experience Engine
“Marty offers actionable advice on product management without being too prescriptive, making his wisdom applicable in many contexts. He draws from a wealth of experience, illustrating his advice with dozens of real‐world stories. If you want to create digital products that people love, this book will get you started on the right path.”
—Teresa Torres, Discovery Coach
“We have worked closely with Marty shaping product and building product management organisations in several of our portfolio companies. Marty's insight and advice is leading‐edge and world‐class.”
—Harry Nellis, Partner, Accel
“Early in my career in Product Management, I had the good fortune of meeting Marty Cagan. Since then, he has been an incredible mentor for me and the teams I've led. I have seen, firsthand at multiple companies, how Marty transforms product teams and unlocks sustained innovation and growth. Marty literally and figuratively wrote the book on Product Management for today's technology industry.”
—Sarah Fried Rose, Product Leader and COO
“I've been lucky to work with some of the best product managers and product minds in the business. In my experience Marty Cagan is hands down the absolute best product management mind alive today. This book packs years of experience into 250 pages.”
—Marty Abbott, CEO, AKF Partners, former CTO, eBay
“Great products delight customers. Marty Cagan has led and inspired countless product teams and in INSPIRED, you will learn how to build those products, both strategically and tactically.”
—Shripriya Mahesh, Partner, Omidyar Network
“CEOs, Chief Product Officers, and anyone who cares about creating great products, must read this book. Your customers will love you for it.”
—Phil Terry, Founder and CEO of Collaborative Gain, co‐author, Customers Included
“Marty is not only a seasoned expert on all aspects of the often ambiguous discipline of product management, his book also provides inspiration, tools and techniques, and really practical help.”
—Judy Gibbons, Startup Advisor and Board Member
“Building great products is hard. Marty gives great insight into best practices and skills that really can only be discovered after years of experience and study. Just about every product person I respect learned product management from INSPIRED.”
—Jason Li, CEO and Founder, Boolan, Shanghai
“If you want your customers to love your products, INSPIRED is an 'everyone in the company' must read book.”
—Jana Eggers, CEO, Nara Logic
“What I really love about working with Marty is that his techniques are applicable to building really great enterprise products ‐ not just new consumer apps. INSPIRED is our true north. Anytime I feel the organization moving sideways, it's time to read it again!”
—Jeff Trom, Founder and CTO, Workiva
“I've known Marty for nearly 20 years. By now, you'd think I'd have heard everything he has to say. And yet, every time I see him, his continued interest in learning about our field means that he always new ideas to share. And with honesty, humanity, frankness, and most of all…perspective that never fails to give me fresh energy and a new approach. Thrilled that he's bottled it for us once more in this new edition of INSPIRED!”
—Audrey Crane, Partner, DesignMap
“Marty's practical approach to building great products transformed the way we approached product development for the radical betterment of the Company and our customers. Just as importantly, his methodology helped shape multiple people's career trajectories both inside the Company and outside of it as they've gone on to drive product development in other organizations ‐ from Fortune 500 companies to other VC backed high growth companies. If you're in a leadership role or on the product team at an organization trying to build products your target audience loves, this should be the next book you read.”
—Shawn Boyer, Founder, Snagajob and goHappy
“When I needed to stand up a productive, scalable product management function at Etsy, I turned to Marty. His playbook for establishing product management as a distinct discipline is invaluable for any team working on products powered by software and made by engineers.” Rarely is a business book so clearly written and packed full of concrete advice. We used it as our product management guide in scaling Etsy, and I've used it in every company since.”
—Maria Thomas, Board Member and Investor
“The art of Product Management is the art of life itself. Surround yourselves by great people, focus on your mojo, build great stuff with integrity, hold strong opinions but lightly. And Marty is one of the best teachers of this art.”
—Punit Soni, Founder and CEO, Robin, Former Google APM
“Marty was a coach and mentor for my early years in product management and the book INSPIRED became the go to guide whenever I needed some clarity on the product manager's role, skill set or the daily challenges from product discovery to execution. And it still was a solid reference while stepping up to a product leadership role. Now, in my role as discovery coach, I recommend the book to every new client. It's not a methodology book; this book helps product people to get the right mindset regardless of the frameworks and techniques they are using.”
—Petra Wille, Discovery Coach
“Marty's 2nd Edition builds on an amazing base of knowledge and experience, and provides even more insights, lessons, and frameworks that are imperative to every product‐based company.”
—Chuck Geiger, CTO/CPO Chegg
“Marty has a way of elegantly simplifying decades of experience leading and teaching product organizations to excel in value creation for their customers into one actionable, inspiring, quick read. From organizational assessments, tools for aligning teams against a real user need, to the nitty gritty of pulling off continuous product discovery & delivery, INSPIRED is my go‐to reference and recommendation for any Product Leader looking to up their game for the sake of building winning products.”
—Lisa Kavanaugh, Executive Coach
“Marty is legendary among the best product leaders for cutting to the heart of where their teams need to improve. His advice is practical, actionable and will excite you and your team to better address customer needs immediately. Your engineers and customers will thank you for reading this book.”
—Hope Gurion, Product Leader
“Marty is the go‐to expert for how to build great products. He has personally trained and educated product managers from all over the world across every industry. Marty has coached and guided some of the most successful Internet companies of our time. This second edition shares even more from his vast expertise and knowledge about how the best companies in the world are able to build products that their customers love.”
—Mike Fisher, CTO, Etsy
“Marty reminds us of the importance of why we build products. The product mindset and focusing on our customers, builds better entrepreneurs, companies and better solutions for all of us. This mindset is the foundation of building successful product companies at any stage.”
—Erin Stadler, Discovery Coach, Boomtown Accelerator
INSPIRED
HOW TO CREATE TECH PRODUCTS CUSTOMERS LOVE
SECOND EDITION
MARTY CAGAN
Founder, Silicon Valley Product Group
Copyright © 2018 by Wiley. All rights reserved.
Published by John Wiley & Sons, Inc., Hoboken, New Jersey.
Published simultaneously in Canada.
No part of this publication may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, scanning, or otherwise, except as permitted under Section 107 or 108 of the 1976 United States Copyright Act, without either the prior written permission of the Publisher, or authorization through payment of the appropriate per-copy fee to the Copyright Clearance Center, 222 Rosewood Drive, Danvers, MA 01923, (978) 750-8400, fax (978) 646-8600, or on the web at www.copyright.com. Requests to the Publisher for permission should be addressed to the Permissions Department, John Wiley & Sons, Inc., 111 River Street, Hoboken, NJ 07030, (201) 748-6011, fax (201) 748-6008, or online at www.wiley.com/go/permissions.
Limit of Liability/Disclaimer of Warranty: While the publisher and author have used their best efforts in preparing this book, they make no representations or warranties with respect to the accuracy or completeness of the contents of this book and specifically disclaim any implied warranties of merchantability or fitness for a particular purpose. No warranty may be created or extended by sales representatives or written sales materials. The advice and strategies contained herein may not be suitable for your situation. You should consult with a professional where appropriate. Neither the publisher nor the author shall be liable for damages arising herefrom.
For general information about our other products and services, please contact our Customer Care Department within the United States at (800) 762-2974, outside the United States at (317) 572-3993 or fax (317) 572-4002.
Wiley publishes in a variety of print and electronic formats and by print-on-demand. Some material included with standard print versions of this book may not be included in e-books or in print-on-demand. If this book refers to media such as a CD or DVD that is not included in the version you purchased, you may download this material at http://booksupport.wiley.com. For more information about Wiley products, visit www.wiley.com.
Library of Congress Cataloging-in-Publication Data is Available:
ISBN 9781119387503 (Hardcover)
ISBN 9781119387541 (ePDF)
ISBN 9781119387565 (ePub)
Cover Design: Wiley
Cover Image: © John Lawson/Getty Images
This book is dedicated to my father, Carl Cagan. In 1969, he received the first PhD in computer science in the United States (prior to that computer science was part of electrical engineering programs), and he authored the first book on databases (Data Management Systems, in 1973, also by John Wiley & Sons).
In addition to being a terrific father, he taught me to program a computer when I was nine years old—decades before this became a thing—and he instilled in me a love of technology when so many of the technologies we depend on today were just being conceived.
Preface to the Second Edition
When I first considered publishing an update to the first edition of my book INSPIRED, I estimated that maybe I would modify something like 10–20 percent of the content. That's because there was very little of the first edition that I wished I could change.
However, once I got started, I quickly realized that this second edition would require a complete rewrite. Not because I regretted what I had written, but because I believe I have much better ways of explaining these topics now.
I had no idea that the first edition would be as successful as it has been. Thanks to the book, I have made friends all over the globe. The book has been translated into several languages, and despite being nearly 10 years old as of this writing, sales continues to grow, all by word of mouth and reviews.
So, if you have read the first edition, I thank you, and hope you enjoy the second edition even more. If you are new to INSPIRED, I am hoping this new edition accomplishes its objective even better.
When I wrote the first edition, it was before Agile was well established in product companies, and before Customer Development and Lean Startup nomenclature became popularized. Today, most teams have been using these techniques for several years and are more interested in what's beyond Lean and Agile, which is what I focus on here.
I have kept the basic structure of the book intact, but the techniques I describe have improved significantly over the past decade.
Beyond changing how I explain the topics and updating the techniques, the other major change to the book is that I now go into detail on what I refer to here as Product @ Scale.
In the first edition, I focused more on startups. In this edition, however, I wanted to expand the scope to look at the challenges of growth‐stage companies and how product can be done well at large, enterprise companies.
There's no question that scale introduces serious challenges, and over the past decade, much of my time has been spent coaching companies through rapid growth. Sometimes we call that surviving success, if that gives you an indication of how hard it can be.
I've received a lot of great feedback from readers of the first edition, and there are a couple of important things I've learned that I would like to address here.
First, there really is a critical need to focus on the specific job of the product manager. In the first edition, I talked a lot about product management, but I tried to speak to product teams more broadly. Today, there are many excellent resources for product designers and engineers, but precious little available specifically for product managers who are responsible for technology‐powered products. So, in this edition I decided to concentrate on the job of the technology product manager. If you are a product manager at a technology company, or if you aspire to be one, I am hoping this will become your go‐to resource.
Second, there are many people looking for a recipe for product success—a prescriptive guide or framework to how to create products customers love. While I understand the desire, and I know I'd likely sell many more copies if I positioned this book that way, the unfortunate truth is that's just not how great products are created. It is much more about creating the right product culture for success, and understanding the array of product discovery and delivery techniques so that you can use the right tool for the specific issue you are facing. And, yes, this means that the job of the product manager is not in any sense easy, and truth be told, not everyone is equipped to succeed in this job.
All that said, the tech product management job is today one of the most desired jobs in our industry, and is the leading source—the proving ground—of startup CEOs. So, if you've got the desire and are willing to put in the effort, I'd like nothing better than to help you succeed.
PART ILessons from Top Tech Companies
In the mid‐1980s, I was a young software engineer working for Hewlett Packard on a high‐profile product. It was a time (the first time) when artificial intelligence was all the rage, and I was fortunate enough to be working at what was then one of the industry's best technology companies, as part of a very strong software engineering team (several members of that team went on to substantial success in companies across the industry).
Our assignment was a difficult one: to deliver AI‐enabling technology on a low‐cost, general‐purpose workstation that, until then, required a special‐purpose hardware/software combination that cost more than $100,000 per user—a price few could afford.
We worked long and hard for well over a year, sacrificing countless nights and weekends. Along the way, we added several patents to HP's portfolio. We developed the software to meet HP's exacting quality standards. We internationalized the product and localized it for several languages. We trained the sales force. We previewed our technology with the press and received excellent reviews. We were ready. We released. We celebrated the release.
Just one problem: No one bought it.
The product was a complete failure in the marketplace. Yes, it was technically impressive, and the reviewers loved it, but it wasn't something people wanted or needed.
The team was of course extremely frustrated with this outcome. But soon we began to ask ourselves some very important questions: Who decides what products we should build? How do they decide? How do they know that what we build will be useful?
Our young team learned something very profound—something many teams have discovered the hard way: It doesn't matter how good your engineering team is if they are not given something worthwhile to build.
When trying to track down the root cause of our failure, I learned that the decisions about what to build came from a product manager—someone who generally resided in the marketing organization and who was responsible for defining the products we built. But I also learned that product management wasn't something HP was particularly good at. I later learned that most companies weren't good at this either, and, in fact, most still aren't.
I promised myself that never again would I work so hard on a product unless I knew the product would be something that users and customers wanted.
Over the next 30 years, I have had the very good fortune to work on some of the most successful high‐tech products of our time—first at HP during the rise of personal computers; then at Netscape Communications during the rise of the Internet, where I worked as vice president of platform and tools; later at eBay during the rise of e‐commerce and marketplaces, where I served as the senior vice president of product and design; and then as an adviser to startups working with many of what have become today's most successful technology product companies.
Not every product effort has been as successful as others, but I am happy to say that none were failures, and several became loved and used by millions of people around the world.
Soon after I left eBay, I started getting calls from product organizations wanting to improve how they produced products. As I began working with these companies, I discovered that there was a tremendous difference between how the best companies produced products and how most companies produced them.
I discovered that there was a tremendous difference between how the best companies produced products and how most companies produced them.
I realized that the state of the art was very different from the state of the practice.
Most companies were still using old and inefficient ways to discover and deliver products. I also learned that there was precious little help available, either from academia, including the best business school programs, or from industry organizations, which seemed hopelessly stuck in the failed models of the past—just like the one I worked in at HP.
I have had some great rides, and I am especially thankful that I have had the chance to work for and with some of the best product minds in the industry. The best ideas in this book are from these people. You will find a list of many of them in the acknowledgments. I have learned from them all, and I am grateful to each one of them.
I chose this career because I wanted to work on products that customers love—products that inspire and provide real value. I find that most product leaders also want to create inspiring and successful products. But most products are not inspiring, and life is too short for bad products.
My hope in writing this book is that it will help share the best practices of the most successful product companies and that the result will be truly inspiring products—products that customers love.
CHAPTER 1Behind 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.
This book is intended for these people.
Within modern technology product teams, the product manager has some very specific and very challenging responsibilities. It's a tremendously difficult job, and anyone who tries to tell you otherwise is not doing you any favors.
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.
The product manager role is usually very much a full‐time assignment. I don't personally know many who are able to do what they need to do in less than 60 hours a week.
It's great if you're a designer or an engineer who also wants to serve as a product manager—there are some real advantages to that. But you'll find out pretty quickly that you're taking on an immense amount of work. If you're up for that, however, the results can be impressive.
A product team is comprised of at least a product manager and usually somewhere between 2 and 10 engineers. If you're creating a user‐facing product, you would expect to have a product designer on your team as well.
In this book, we explore the situation wherein you might have to use engineers or designers in a different location or from an agency or outsourcing firm. But regardless of how you assemble your team, this job and this book assume you have a team assigned to work with you to design, to build, and to deliver a product.
CHAPTER 2Technology‐Powered Products and Services
There are many kinds of products out there, but in this book, I concentrate exclusively on products that are powered by technology.
Some of what we explore in this book may help you if you're building non‐tech products, but there are no guarantees in that case. Frankly, there are already a wide variety of readily accessible resources for non‐tech products such as most consumer packaged goods, and for product managers of these non‐tech products.
My focus is on the unique issues and challenges associated with building technology‐powered products, services, and experiences.
Some good examples of the sweet spot that we explore are consumer‐service products, such as e‐commerce sites or marketplaces (e.g., Netflix, Airbnb, or Etsy), social media (e.g., Facebook, LinkedIn, or Twitter), business services (e.g., Salesforce.com, Workday, or Workiva), consumer devices (e.g., Apple, Sonos, or Tesla), and mobile applications (e.g., Uber, Audible, or Instagram).
My focus is on the unique issues and challenges associated with building technology‐powered products, services, and experiences.
Technology‐powered products do not need to be purely digital. Many of the best examples today are blends of online and offline experiences—like finding a ride or a room for the night, getting a home loan, or sending an overnight package.
It's my belief that most products today are transforming into technology‐powered products, and the companies that don't realize this are rapidly being disrupted. But, again, I'm only focused here on technology‐powered products, and those companies that believe they must embrace technology and consistently innovate on behalf of their customers.
CHAPTER 3Startups: Getting to Product/Market Fit
In the technology world, we generally have three stages of companies: startups, growth‐stage, and enterprise companies. Let's briefly consider how we characterize each one of these stages, and the challenges you are likely to face in each.
I loosely define startup as a new product company that has yet to achieve product/market fit. Product/market fit is an extremely important concept that I'll define in the pages that follow, but for now, let's just say that the startup is still trying to come up with a product that can power a viable business.
In a startup, the product manager role is usually covered by one of the co‐founders. Typically, there are fewer than 25 engineers, covering a range of from one product team up to maybe four or five.
The reality of startup life is that you're in a race to achieve product/market fit before you run out of money. Nothing else much matters until you can come up with a strong product that meets the needs of an initial market, so most of the focus of the young company is necessarily on the product.
Startups usually have a limited amount of early funding, intended to determine if the company can discover and deliver the necessary product. The closer you come to running out of money, the more frantic the pace and the more desperate the team and the leadership becomes.
While money and time are typically tight, good startups are optimized to learn and move quickly, and there's normally very little bureaucracy to slow them down. Yet the very high failure rate of technology startups is no secret. The few that succeed are usually those that are really good at product discovery, which is a major topic of this book.
Nothing else much matters until you can come up with a strong product that meets the needs of an initial market.
Working at a startup—racing toward product/market fit—is usually stressful, exhausting, and risky. But it can also be an amazingly positive experience, and if things go well, a financially rewarding one too.
CHAPTER 4Growth‐Stage Companies: Scaling to Success
Those startups skilled and fortunate enough (it usually takes both) to get to product/market fit are ready to tackle another equally difficult challenge: how to effectively grow and scale.
There are many very significant challenges involved in growing and scaling a startup into a large, successful business. While it's an extremely difficult challenge, it is, as we say, a good problem to have.
In addition to hiring lots more people, we need to figure out how to replicate our earlier successes with new, adjacent products and services. At the same time, we need to grow the core business as fast as possible.
In growth stage, we typically have somewhere between about 25 and several hundred engineers, so there are many more people around to help, but the signs of organizational stress are everywhere.
Product teams complain that they don't understand the big picture—they don't see how their work contributes to the larger goals, and they're struggling with what it means to be an empowered, autonomous team.
While it's an extremely difficult challenge, it is, as we say, a good problem to have.
Sales and marketing often complain that the go‐to‐market strategies that worked for the first product are not so appropriate for some of the new products in the portfolio.
The technology infrastructure that was created to meet the needs of the initial product is often bursting at the seams, and you start to hear the term “technical debt” from every engineer you speak with.
This stage is also tough on leaders because the leadership style and mechanisms that worked while the company was a young startup often fail to scale. Leaders are forced to change their roles and, in many cases, their behaviors.
But the motivation to overcome these challenges is very strong. The company is often in pursuit of a public offering or, perhaps, becoming a major business unit of an existing company. As well as the very real possibility of having a significant and positive impact on the world can be very motivating.
CHAPTER 5Enterprise Companies: Consistent Product Innovation
For those companies that succeed in scaling and that want to create a lasting business, some of the toughest challenges still lie ahead.
Strong tech‐product companies know they need to ensure consistent product innovation. This means constantly creating new value for their customers and for their business. Not just tweaking and optimizing existing products (referred to as value capture) but, rather, developing each product to reach its full potential.
Yet, many large, enterprise companies have already embarked on a slow death spiral. They become all about leveraging the value and the brand that was created many years or even decades earlier. The death of an enterprise company rarely happens overnight, and a large company can stay afloat for many years. But, make no mistake about it, the organization is sinking, and the end state is all but certain.
Strong tech‐product companies know they need to ensure consistent product innovation.
It's not intentional, of course, but once companies reach this size—often becoming a publicly traded company—there are a tremendous number of stakeholders throughout the business working hard to protect what the company has created. Unfortunately, this often means shutting down new initiatives or ventures that could re‐create the business (but potentially put the core business at risk), or putting up so many obstacles to new ideas that few people are willing or able to drive the company in a new direction.
The symptoms of this are hard to miss, starting with diminished morale, the lack of innovation, and how much slower it is for new product work to get into the hands of customers.
When the company was young, it likely had a clear and compelling vision. When it achieves enterprise stage, however, the company has largely achieved that original vision and now people aren't sure what's next. Product teams complain about the lack of vision, lack of empowerment, the fact that it takes forever to get a decision made, and product work is turning into design by committee.
Leadership is likely frustrated, too, with the lack of innovation from the product teams. All too often, they resort to acquisitions or creating separate “innovation centers” to incubate new businesses in a protected environment. Yet this rarely results in the innovation they're so desperate for.
And you'll also hear lots of talk about how it is that large, enterprise companies such as Adobe, Amazon, Apple, Facebook, Google, and Netflix have been able to avoid this fate. The organization's leadership team wonders why they can't do the same. The fact is they could do the same. But they'll need to make some pretty big changes, and that's what this book is about.
CHAPTER 6The Root Causes of Failed Product Efforts
Let's start by exploring the root causes of why so many product efforts fail.
I see the same basic way of working at the vast majority of companies, of every size, in every corner of the globe, and I can't help but notice that this is not close to how the best companies actually work.
Let me warn you that this discussion can be a little depressing, especially if it hits too close to home, so if that's the case, I'll ask you to hang in there with me.
Figure 6.1 describes the process that most companies still use to create products. I'll try not to editorialize yet—let me first just describe the process:
FIGURE 6.1 Root Causes of Failed Product Efforts
As you can see, everything starts with ideas. In most companies, they're coming from inside (executives or key stakeholders or business owners) or outside (current or prospective customers). Wherever the ideas originate, there are always a whole bunch of things that different parts of the business need us to do.
Now, most companies want to prioritize those ideas into a roadmap, and they do this for two main reasons. First, they want us to work on the most important things first, and second, they want to be able to predict when things will be ready.
To accomplish this, there is usually some form of quarterly or annual planning session in which the leaders consider the ideas and negotiate a product roadmap. But in order to prioritize, they first need some form of a business case for each item.
Some companies do formal business cases, and some are informal, but either way it boils down to the need to know two things about each idea: (1) How much money or value will it make? and (2) How much money or time will it cost? This information is then used to come up with the roadmap, usually for the next quarter, but sometimes as much as a year out.
At this point, the product and technology organization has its marching orders, and they typically work the items from the highest priority on down.
Once an idea makes it to the top of the list, the first thing that's done is for a product manager to talk to the stakeholders to flesh out the idea and to come up with a set of “requirements.”
These requirements might be user stories, or they might be more like some form of a functional specification. Their purpose is to communicate with the designers and engineers what needs to be built.
Once the requirements are gathered up, the user experience design team (assuming the company has such a team), is asked to provide the interaction design, the visual design, and, in cases of physical devices, the industrial design.
Finally, the requirements and design specs make it to engineers. This is usually where Agile finally enters the picture.
Anyway, the engineers will typically break up the work into a set of iterations—called “sprints” in the Scrum process. So maybe it takes one to three sprints to build out the idea.
Hopefully the QA testing is part of those sprints, but if not, the QA team will follow this up with some testing to make sure the new idea works as advertised and doesn't introduce other problems (known as regressions).
Once we get the green light from QA, the new idea is finally deployed to actual customers.
In the majority of companies that I first meet, large and small, this is essentially how they work, and have worked, for many years. Yet these same companies consistently complain about the lack of innovation and the very long time it takes to make it from idea to customers' hands.
You might recognize that while I mentioned Agile, and while almost everyone today claims to be Agile, what I've just described is very much a waterfall process. In fairness to the engineers, they're typically doing about as much Agile as they can, given the broader waterfall context.
Okay, so that may be what most teams do, but why is that necessarily the reason for so many problems? Let's connect the dots now, so we can clearly see why this very common way of working is responsible for most failed product efforts.
In the list that follows, I'm going to share what I consider to be the top‐10 biggest problems with this way of working. Keep in mind that all 10 of these problems are very serious issues, any one of which could derail a team. But many companies have more than one or even all of these problems.
Let's start at the top—the
source of ideas
. This model leads to sales‐driven specials and stakeholder‐driven products. Lots more to come on this key topic, but for now, let me just say that this is not the source of our best product ideas. Another consequence of this approach is the lack of team empowerment. In this model, they're just there to implement—they're mercenaries.
While almost everyone today claims to be Agile, what I've just described is very much a waterfall process.
Next, let's talk about the fatal flaw in these
business cases
. To be clear, I'm personally in favor of doing business cases, at least for ideas that need a larger investment. But the way most companies do them at this stage to come up with a prioritized roadmap is truly ridiculous and here's why. Remember those two key inputs to every business case? How much money you'll make, and how much it will cost? Well, the cold, hard truth is that, at this stage, we have no clue about either of these. In fact, we
can't
know.
We can't know how much money we'll make because that depends entirely on how good the solution turns out to be. If the team does an excellent job, this could be wildly successful and literally change the course of the company. The truth, however, is that many product ideas end up making absolutely nothing. And that's not an exaggeration for effect. Literally nothing (we know this from A/B testing).
In any case, one of the most critical lessons in product is knowing what we can't know, and we just can't know at this stage how much money we'll make.
Likewise, we have no idea what it will cost to build. Without knowing the actual solution, this is extremely hard for engineering to predict. Most experienced engineers will refuse to even give an estimate at this stage, but some are pressured into the old t‐shirt sizing compromise—just let us know if this is “small, medium, large, or extra large.”
But companies really want those prioritized roadmaps, and to get one, they need some kind of system to rate the ideas. So people play the business case game.
An even bigger issue is what comes next, which is when companies get really excited about their
product roadmaps
. I've seen countless roadmaps over the years, and the vast majority of them are essentially prioritized lists of features and projects. Marketing needs this feature for a campaign. Sales needs this feature for a new customer. Someone wants a PayPal integration. You get the idea.
But here's the problem—maybe the biggest problem of all. It's what I call the two inconvenient truths about product.
The first truth is that at least half of our ideas are just not going to work.
The first truth is that at least half of our ideas are just not going to work
