A summary of INSPIRED by Marty Cagan
It’s been a while since I’ve read INSPIRED by Marty Cagan.
Yet, I still remember the feeling when at the end, I closed the book and thought to myself: “This is the best book on Product Management I’ve ever come across!”. When I finished “How to escape the build trap” by Melissa Perri two months ago, I liked it so much that I started to question this.
To be fair and to be sure, there was only one way forward, I needed to re-read and summarize INSPIRED too…
So, what’s “INSPIRED” about? The book is mainly about Product Management in a growth stage company, where signs of organizational stress are everywhere. While it primarily looks at why so many product teams fail and how successful product teams work, it also provides accompanying sections that address questions of how-to better scale Product Management or personal stories of successful Product Managers that provide insights into real-life product organizations such as Apple, Google, and Netflix (watch Marty’s corresponding Mind the Product talk).
Part I: Lessons from top tech companies
Note: If you prefer videos, this “Mind the Product” talk might be an excellent alternative to the following sections. Otherwise, read on…
How bad product teams work
The book starts with how most product teams work and why it’s a problem. Marty explains his reasoning along the “typical” development process that most teams tend to work by (see the following illustration):
The consequence of this process, as Marty often states throughout the book, is that teams act as mercenaries, not missionaries, which means they focus on output, not outcome. Marty claims that this is because of the inconvenient truth about Product, based on the following:
- Half of our ideas don't work (no value, aren’t usable, aren’t feasible, aren’t viable).
- It takes several iterations for things to work and until they deliver value, but the business usually fears the time-to-money
To Marty, products build according to this waterfall and not agile process are projects that put risk validation at the end and where user validation for that reason happens way too late. Conversely, real products are about outcomes, which Marty describes as the summary of functionality, technology, user experience, monetization, and acquiring users & customers.
How the best product teams work
In contrast to the previous waterfall-like approach, Marty then raises the question of how the best product teams work and lists the following main differentiators:
- They deal with risk (value, usability, feasibility, business viability) before they build their solutions
- They define the product collaboratively (i.e., Design, Engineering, and Product Management work side-by-side)
- Their solutions solve underlying problems and bring business results, not features
He explains that another big difference is the process these teams use, which is a combination of continuous discovery and delivery, illustrated by the following image:
This process became known as dual-track development and adds an upstream step to your already familiar delivery work.
Discovery of “what to build” means tackling related risks early on through experimentation and separating good ideas from bad ideas by asking questions such as:
- Will the user pay for it? (value)
- Can the user figure out how to use it? (usability)
- Can we build it? (feasibility)
- Can our stakeholders support it? (business viability)
Delivery of products to the market (not much new here)
Part II: The right people
Marty starts with a list of the core characteristics of such a team:
- A team of missionaries, not mercenaries
- True believers of the mission/vision and committed to solving the underlying user and related business problems, given objectives
- True collaborators and accountable for their results
- Cross-functional and between 8 and 12 people (two pizza rule)
Following a high-level overview of successful teams and successful Product Managers, Marty provides detailed descriptions of roles you’d usually find on such a product team and describes their interdependencies. Since I am a Product Manager, I'll only cover this role here.
Product Manager
Marty describes a Product Manager’s job by the following two statements:
“…working tirelessly, leading the product team to combine technology and design to solve real customer problems in a way that meets business needs…”
and
“…evaluating opportunities to determine what gets build and delivered and provides evidence that it’s worth building…”
In Marty’s opinion, successful PMs have a passion for their product, while they respect the product team. They deeply understand their business and their customers. This means they know about issues, pains, desires, how customers think, how they work, and how they decide to buy.
Successful PMs are proficient with data and have qualitative and quantitative skills to, for example, analyze sales- and usage analytics.
They also have market and industry know-how, which means they know their competitors and future technology trends. Their key traits are being intelligent, creative, and persistent.
But how do they relate to other roles? Marty describes a PM’s interdependencies as follows:
- Designers: Sit next to them! Include them from the beginning and when interacting with customers. Provide them with feedback, not your ideas! Encourage them to iterate early and often as well as to explore alternatives.
- Engineers: Appreciate the complexity of their work and engage with them often. Share with them what you know about customers and their pains. Involve them with discovery and delivery questions. Give them space to figure things out. Make them feel like missionaries, not mercenaries.
- Marketing: Work with them to figure out your go-to-market strategy. They help you with positioning. Include them to represent the market.
People@Scale
To scale, Marty mainly addresses the responsibility of senior roles in the company. For instance, he defines the part of leadership as “to recruit, develop and retain talent”. They're the ones who need to have a holistic view of the product, they need to connect the dots between teams and help resolve conflicts. For instance, “The single most important role of any VP product is to develop a strong team of Product Managers”. According to Marty, this role should take care of team development, vision and strategy, the ability to execute consistently, a strong product culture, and the right experience in the team.
However, the last, and to me most important part of this section, is about principles of structuring product teams, where for me, the most important are:
- Alignment with investment strategy and team structure reflects it
- Minimize dependencies means helping teams move fast and be autonomous, and think of max leverage (shared services and whether you need them)
- Ownership, a team of empowered and accountable members
- Align your business to all sell to the same customer
- Your structure is a moving target and will constantly change
Part III: The right product
The primary question related to finding the right product is “What should a product-team work on?”. Marty refers to product roadmaps that try to answer this question and argues that “typical roadmaps are the root cause of most waste and failed efforts in product organizations”.
To him, they most often are a prioritized list of features and projects that focus on outputs, not objectives and results.
Marty lists two reasons for this.
- Roadmaps are often top-down
- They don’t contain the little but time-consuming things like bugs and tasks, which is why they’re wrong so often.
But why do roadmaps exist in the first place? Marty claims this is because Management wants to ensure we work on high-value things first. They need to be able to plan (i.e., coordinate marketing efforts, resolve salesforce dependencies, etc.).
Marty then compares how good and bad product teams deal with roadmaps. In his opinion, bad product teams “plod through roadmaps throughout the year and ship features” because they're output-focused.
Conversely, strong product teams are outcome-focused. They tackle risks early while they iterate fast and cheaply. They conduct product discovery to test ideas in hours, not months and focus mainly on solving customer and business problems.
Moreover, Marty explains that the problem with roadmaps isn’t the ideas put on them but the commitments the teams give to building them, even if they don’t solve the underlying customer and business problems.
To avoid this, Marty advocates having a roadmap that lists prioritized business problems while minimizing such commitments. Nevertheless, Marty acknowledges the need for a few “high-integrity” commitments but also warns to only make them after you tackle the related risks during discovery work.
As a solution to all this, Marty suggests that leaders should focus on providing business context and direction. This means instead of providing a prioritized list of solutions and ideas, they should provide a compelling product vision and strategy, accompanied by prioritized business objectives and key results. The latter defines how to measure whether you achieved your objectives (e.g., reduce the time you onboard customers by three hours or less). And only when context and direction are provided can the team figure out how to contribute to the bigger picture, which, according to Marty, will lead to motivated teams that deliver solutions, not features.
Business context and direction
To Marty, product vision has a time horizon of 5–10 years and “is a pervasive piece to describe the future that inspires the teams to make this vision reality”. For this, he provides principles. To me, the most important are “start with the why”, “fall in love with the problem, not the solution”, “Be stubborn on the vision but flexible on details”, and “Evangelize continuously and relentlessly”.
A product strategy, according to Marty, is a sequence of products and releases to get closer to the product vision. The goal of it is to come up with the smallest deliverable possible to make this target group successful! To better differentiate strategy from vision, Marty provides the analogy of leadership (vision) and management (strategy). While the former inspires you to do so, the latter gets you there. He also lists product strategy principles, where the most important is to “align product efforts with sales and go-to-market efforts” and to “obsess over customers, not competitors”.
Besides vision and strategy, Marty provides a whole chapter about Objectives and Key Results (OKRs), a goal-setting framework famously known by Intel and Google. However, I need to point out that he recently started to discourage their use on the SVPG blog, which is why according to his most recent contribution, you should only use it when your organizational culture allows it. My main takeaways from the section are:
- Using OKRs is when performance is measured by results.
- It takes a while to get there.
- Objectives are qualitative; they inspire while
- Key results are quantitative, they measure business success and results.
- Using the Product Managers focus more on organization and product objectives and less on output and tasks.
Objectives @Scale
To scale, Marty notes that having a clear understanding of product-level objectives is one of the most crucial things. In general, he points out how vital it is that leadership identifies gaps between team objectives and helps them align higher-level goals with product goals. Marty underlines that this is most true for platform teams that support other teams and who need special attention and help to set their priorities.
To make tracking the given commitments easier, he suggests installing the role of a Release Manager who then coordinates and connects the dots.
And finally, he advocates to do Product Evangelism, which means “selling the dream”, and names it as an important skill and asset of leadership/PMs to scale objectives successfully.
Part IV: The right process
Product Discovery
According to Marty, discovery should be the primary focus of a Product Manager. For instance, he suggests spending only 1 hour daily on delivery and the rest on discovery work. The goal of discovery work is to answer what solution needs to build and whether there is a demand for it. Marty explains that for this to happen, a Product Manager needs to spend time with the team, stakeholders, and customers while making sure that the final solution works for all the customers, not just for one.
Marty further describes that Product Managers need to test ideas quickly to separate the good ones from the bad ones, to make sure building the solution won’t be wasted engineering efforts, and to release with confidence.
Marty points out that the key here is to have access to customers and to get your ideas in front of them early and often to address underlying risks such as:
- Will the customer buy It? — proof value
- Will users figure out how to use it? — check usability
- Will we be able to build it? — ask about the feasibility
- Will our business benefit from it, and will we cover the costs? — verify viability
In short, good teams solve problems, while the customer will pay for it. They address all risks up-front as well as they prove value qualitatively and quantitatively (statistically or evidence-based), while learning quickly.
What I found very helpful is the list of tips that Marty provides for product discovery. The most important to me are:
- Don’t build what customers want since they don’t know what’s possible
- Create value from problems such that people pay for it
- Know what we can’t know! Discover! And keep in mind that most ideas fail! Therefore, we need to be open to solving problems in many ways.
- Validate (multiple) ideas with users before you build fast, cheap, and often because we don’t know their reaction
- Most importantly: Achieve Shared learning!
To make discovery work more tangible, Marty further lists and explains the techniques used, such as Framing, Planning, Ideation, Prototyping, and Testing, in detail.
Framing
The goal of framing is that all agree on the business objective, the related user problems, and the users we're solving it for. Thus, it should align all around a clear purpose and should be done for more significant problems to identify their risks.
- Opportunity assessment (for features), where you ask questions such as “What are the business objectives?”, “What are the expected key results?”, “What’s the customer problem?”, or “What is the target market/persona/customer?”
- Customer letter (for larger projects): working backward (e.g., AMAZON press release or a letter to the CEO telling how your product improved the life of a customer.
- Startup canvas (for new products)
Discovery Planning techniques:
- Story Mapping: a first step is putting your user journey (i.e., user activities) on a horizontal axis from left to right over time.
In a second step, add or “map” stories to these activities along the vertical axis. To Marty, using two dimensions lets you see how individual stories fit into the bigger picture and aids the problem of flat backlogs.
The vertical axis allows you to better bundle and release stories together such that they provide value. Marty points out that Story Mapping is very helpful with prototyping, where he encourages you first to use Story Mapping to come up with ideas and then create and test your prototypes based on such maps. The maps then can also be used to document which of these prototypes proved valuable by updating them with feedback gathered from your customers before you move these ideas into your backlog. - Reference customer: To Marty, reference customers are the leading indicator of future success and “the single best tool to sell your product”. They provide access to users, let you test early versions, give you real input, and serve as a public reference.
He believes it’s the PM’s job to develop 5–6 such customers to gather their direct feedback, which helps to find your product/market fit and gives you the confidence to start investing in marketing efforts later on.
According to Marty, reference customers are usually developed for bigger bets (i.e., new products), not for single features, and should be developed for a single target market at a time.
But who should be a reference customer? Marty recommends picking customers who “feel immediate pain” and “who are desperate to get your solution”. He suggests considering customers that heavily use your APIs and who build their solutions on top of yours. Also, consider internal customers who use your product as a tool (e.g., “Drinking your own champagne”) as reference customers.
Discovery Ideation techniques
Marty lists the following techniques to ideate during discovery.
- Customer interview: can be formal or informal (e.g., contextual inquiry) and help you answer questions about your customers such as “Are your customers who you think they are?”, “Do they have the problem you think they have?”, “How does the customer solve this problem today?”, or “What would be required for him to switch to your solution?”.
Marty suggests doing interviews with people in the target market for 2–3 hours weekly and in their environment. To Marty, it’s essential first to confirm or contradict your thoughts about what the customer’s problem is.
For the interview, Marty advocates asking open-ended questions to get real insights and to do them together with the lead developer and the UX designer, which makes debriefing more effective! And also suggests following up the interview with a user test to try out product ideas. - Concierge Test: means to do the customer’s job manually for them and check whether the outcome is appreciated. Marty promotes this technique, as it allows you to cheaply try out ideas while not already having to deal with scalability issues. This puts you in their shoes and lets you learn a lot about your customers to provide them with a better solution.
- Customer Misbehavior: Find out how customers use your product (also your API) for unintended use cases. Or to monitor what customers want to do but can’t do due to problems. You watch for bigger patterns throughout your customer base.
- Hack days: directed (with given goals, customer problems) or undirected, which has the advantage of strongly including developers in the ideation phase.
- Prototyping: comes in many forms, where its main purpose is to tackle product risks, and it can be used as a communication tool for what needs to be built. The main idea of prototyping, as Marty describes, is to “learn at minimum cost and time”, to uncover issues, and “to think a level deeper than just talking about it”.
Another goal of prototyping, as Marty mentions, is to reach “shared understanding through collaboration”.
He generally promotes doing higher-level prototypes at a higher fidelity only when needed. The book lists and explains the different types of prototypes, such as feasibility prototypes or user prototypes.
Types of Testing
As Marty points out, you test to separate good from bad ideas and to tackle value, usability, feasibility, and business viability risks.
- Usability testing: do it before you build, where Marty provides an extensive set of instructions on how to conduct them also on the Prototype testing SVPG blog post, and there are lots of other books that — as Marty states himself — do a better and more extensive job at describing it.
- Value testing: for this, Marty mentions a fake door test, where you provide the user with an appealing call-to-action, which leads to another page that follows up with the customer and explains that you are planning to implement this feature depending on its demand. The click-through rate of these pages then gives you an indication of the demand.
- Qualitative value testing: when you combine a user interview and a usability test to make sure people aren’t just nice and learn rapidly. In the interview, you could ask whether the user would be willing to pay for it, recommend the product, sign-up for it, or to develop it together with you. And iterate depending on their received answers.
- Quantitative value testing: when you want to prove your ideas in a statistically significant way (e.g., A/B testing, early adopters, ref. customers). You test this way to track the feature usage and to measure the product progress in terms of outcomes to inform your decisions.
- Viability testing: costs vs. revenue. You consider all other expenditure and revenue-related departments and stakeholders (e.g., marketing, sales, finance,…) to ensure the solution is viable.
But how can you transform into this style of work?
Marty names two approaches to transforming your work style from being a feature team to a truly empowered product team.
First, he promotes Design sprints, which, to him, is one famous method to include and empower your developers fully. Marty describes Design Sprints as a weeklong sprint of discovery work, where the whole team prototypes or develops an MVP solution to tackle big risks and solve big business problems.
And second, he encourages leveraging Pilot teams, which is a team limited to the people who are motivated to try this way of working and who first demonstrate the shared value.
In the end, Marty stresses that an essential ingredient to get from roadmaps to business outcomes is to think of how to best provide visibility into what you work on. Because only when management gets the feeling, you’re working on the most important things will they trust and support you.
Note: A perfect addition to this can be found in a more recent post by Marty on the SVPG blog called “The most important things”. In this post, he answers what’s the one thing you should pick when trying to change the way you work and move in the direction of a product team.
Process @Scale
Marty mentions stakeholder management and shared learnings to be key when scaling processes.
Stakeholder Management: the PM must understand the considerations and constraints of their stakeholders and bring them to the product team to guarantee that discovered solutions work for both customers and stakeholders. In this respect, Marty advocates establishing trust by demonstrating you’re knowledgeable and by, sharing your learnings, and spend
To do so, Marty suggests spending 2–3 hours per week in 1:1s with them and might use lunch or coffee breaks for such meetings. While such meetings allow you to be open and transparent about potential solutions and show them using high-fidelity prototypes, it will enable them to give you feedback and raise their concerns. Should discussions arise, then Marty advocates moving them from opinions to data.
Shared Product learnings: Share your learnings in all-hands meetings, where you exchange what worked and what didn’t. According to Marty, such sharing needs to be short and on point, which is why he recommends only senior roles do them. Furthermore, these learnings have to be big, not minor improvements, which ensures that useful learnings also make it to your leaders. Culturally, this promotes that innovation comes from rapid experimentation and shared learning of the results. In the end, such meetings should make transparent that the product organization isn’t there to serve but to find solutions to customer problems, which also work for the business.
Part V: Culture
This last part of the book is about how to get the right culture, which in my opinion, mainly tries to answer the following three questions:
- What’s a good product team?
- What’s a good organization?
- What are the reasons for a slow velocity?
What constitutes a good product team? To answer this question, Marty lists various positive characteristics of a good product team. For instance, good product teams get their ideas from customer problems. They then test lots of ideas together with their end-users to immediately see their response and to find a working solution, while they know that many of their ideas will ultimately fail. In this process, they have enough time to try out new technology to solve their customer’s problems. Another thing that differentiates good from bad teams is that they celebrate outcomes, not features and that they obsess over their customers.
What constitutes a good organization? To me, the most crucial aspect listed by Marty is that the organization has empowered product teams. These are regularly exposed to customer pains and, for that reason, are customer-centric. Such organizations not just have time to innovate and take risks but also “serve customers in ways that meet the needs of the business”.
What are the reasons for a slow velocity? Marty explains that this occurs when your organization doesn’t have a proper vision and strategy and when your PMs mainly do Delivery Management instead of product discovery. And in the meantime, doing so accrue more and more technical debt. Marty also observed that slow organizations often suffer from constantly changing priorities and a consensus culture.
Conclusion
I enjoyed reading the book a second time and have to acknowledge that I see things differently now. After 2+ years of being a PM, I now understand many things so much better and know why a friend of mine recommended this book so enthusiastically back then.
Please leave me a comment on whether some parts could be improved, are missing something, or when you liked the summary.
Looking for more on Product Management?
Check out my curated list to find other great resources that I’ve come across and that I usually recommend to others.
Two other famous books I summarized:
