A nice succinct explanation of one of the best product design books - 'Inspired' by Marty Cagan.

Inspired - Design Great Products

It’s been a while since I read INSPIRED by Marty Cagan. Nevertheless, my fainted memories still echo that it was one of the best books I’ve ever read about Product Management. When I finished “How to…

personaldevelopment

Personal Development

communication

Communication

product

Product & Design

leadershipandmanagement

Leadership & Management

It’s been a while since I read <a href="https://www.amazon.de/INSPIRED-Create-Products-Customers-English-ebook/dp/B077NRB36N">INSPIRED by Marty Cagan </a>. Nevertheless, my fainted memories still echo that it was one of the best books I’ve ever read about Product Management. When I finished “How to escape the build trap” by Melissa Perri two months ago, I liked it so much that I started questioning this however and as a result, I wanted to see whether “Inspired” stands the test of time, which is why I reread and summarized it here.

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 in such environments. Another nice addition is that Marty included also personal stories of successful Product Managers that give some insights into real-life product organizations such as Apple, Google, Netflix. And no worries, I won’t summarize them, since watching <a href="https://www.youtube.com/watch?v=e0KJlYe2Rjk">Marty’s corresponding Mind the Product talk </a>is more fun and insightful.

Note: If you prefer videos then <a href="https://www.youtube.com/watch?v=9dccd8lihpQ">this “Mind the Product” talk </a>might be a good alternative to the following sections. Otherwise, read on…

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 such teams tend to work by, which is depicted in the following illustration (related problems in blue):

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 <a href="https://svpg.com/the-inconvenient-truth-about-product/">the inconvenient truth about Product </a>, based on the following:

<ul><li>Half of our ideas do not work (no value, aren’t usable, aren’t feasible, aren’t viable). </li><li>It takes several iterations for things to work and until they deliver value, but the business usually fears the time-to-money and is not patient to wait for that. </li> </ul>

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.

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 to answer his question:

<ol><li>They deal with risk (value, usability, feasibility, business viability) before they build their solutions </li><li>They define the product collaboratively (i.e., Design, Engineering, and Product Management works side-by-side) </li><li>Their solutions solve underlying problems and bring business results , not features </li> </ol>

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 also known as <a href="https://bit.ly/2Lf7FbW">dual-track development </a> and simply adds an upstream step to your already familiar delivery work.

Discovery of what to build. Means to tackle related risks early on through experimentation and to quickly separate good ideas from bad ideas by asking questions in order to tackle risks early (related risk in brackets):

<ul><li>Will the user pay for it? (value ) </li><li>Can the user figure out how to use it? (usability ) </li><li>Can we build it? (feasibility ) </li><li>Can our stakeholders support it? (business viability ) </li> </ul>

Delivery of products to the market (not much new here)

Marty starts with a list of the core characteristics of such a team:

<ul><li>A team of missionaries, not mercenaries </li><li>True believers of the mission/vision and committed to solving the underlying user and related business problems, given objectives </li><li>True collaborators and accountable for their results </li><li>Cross-functional and between 8 and 12 people (two pizza rule) </li> </ul>

Following a high-level overview of successful teams and successful Product Managers, Marty provides detailed descriptions of roles that you’d usually find on a product team and describes their interdependencies. Since I am a Product Manager, I will only cover the PM role here, read the book for others.

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… ”

“…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 theyrespect 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 as well as future technology trends. Their key traits are being smart, creative, and persistent.

In addition to this description, the most valuable tipps related to a PM’s interdependencies to other rules, provided by Marty, are the following:

<ul><li>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 </li><li>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 </li><li>Marketing: Work with them to figure out your go-to-market strategy. They help you with positioning. Include them to represent the market. </li> </ul>

To scale, Marty mainly addresses the responsibility of senior roles in the company. For instance, he defines the role ofleadership as “to recruit, develop and retain talent” . They are 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 essential part of this section, is about principles of structuring product teams, where to me the most important are:

<ul><li>Alignment with investment strategy , team structure reflects it </li><li>Minimize dependencies , means help teams to move fast and to be autonomous and think of max leverage (shared services and whether you need them) </li><li>Ownership , a team of empowered and accountable members </li><li>Align your business to all sell to the same customer </li><li>Your structure is a moving target and will constantly change </li> </ul>

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”.

Marty states that most roadmaps are a prioritized list of features and projects that focus on outputs, not objectives and results, and provides two reasons. First roadmaps are often top-down, and second, 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 that this is because Management wants to make sure we work on high-value things first and theyneed 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 are output focused. Conversely, strong product teams are outcome-focused. They tackle risks early, while they iterate fast and cheap. They do 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 that are 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 to have 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 tackled 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 is provided, can teams figure out how to contribute to the bigger picture, which, according to Marty, will lead to motivated teams that deliver solutions, not features.

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 is “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 <a href="https://svpg.com/vision-vs-strategy/">product strategy </a>, 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 later gets you there. He also lists product strategy principles, were to be 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 ( <a href="https://rework.withgoogle.com/guides/set-goals-with-okrs/steps/introduction/">OKRs </a>) , a goal-setting framework famously known from Intel and Google. However, I need to point out that <a href="https://svpg.com/team-objectives-overview/">he recently started to discourage their use on the SVPG blog </a>, which is why according to his most recent contribution you should only use it when your organizational culture allows it. My main take-aways from the section are:

<ul><li>Using OKRs is when performance is measured by results . </li><li>It takes a while to get there. </li><li>Objectives are qualitative, they inspire, while </li><li>Key results are quantitative, they measure business success and results. </li><li>Using them Product Managers focus more on organization and product objectives , and less on output and tasks. </li> </ul>

To be able 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 of 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.

According to Marty, discovery should be the primary focus of a Product Manager . For instance, he suggests spending only 1 hour a day 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 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:

<ul><li>Will the customer buy It? — proof value </li><li>Will users figure out how to use it? — check usability </li><li>Will we be able to build it? — ask about feasibility </li><li>Will our business benefit from it and will we cover the costs? — verify viability </li> </ul>

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:

<ul><li>Don’t build what customers want, since they don’t know what’s possible </li><li>Create value from problems , such that people pay for it </li><li>Know what we can’t know! Discover! And keep in mind that most ideas fail! Therefore, we need to be open to solve problems in many ways. </li><li>Validate (multiple) ideas with users before you build fast, cheap, and often because we don’t know their reaction </li><li>Most importantly: Achieve Shared learning! </li> </ul>

To make discovery work more tangible Marty further lists and explains techniques used, such as Framing , Planning , Ideation , Prototyping , and Testing in detail.

The goal of framing is that all agree on the business objective, the related user problems, and the users we are solving it for. Thus, it should align all around a clear purpose and should be done for bigger problems to identify their risks.

<ul><li><a href="https://svpg.com/assessing-product-opportunities/">Opportunity assessment </a>(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?” </li><li><a href="https://medium.com/@DanielYubi/internal-press-release-be41de94647f">Customer letter </a>(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. </li><li><a href="https://bit.ly/2SPjTMo">Startup canvas </a>(for new products) </li> </ul>

<ul><li><a href="https://www.jpattonassociates.com/user-story-mapping/">Story Mapping </a>: in a first step is putting your user journey (i.e., user activities) on a horizontal axis from left to right along time. In a second step, you 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 when used together with prototyping, where he encourages to first use Story Mapping to come up with the 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. </li><li>Reference customer: To Marty reference customers are the leading indicator of future success and “the single best tool to sell your product”. They provide you with 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. </li> </ul>

Marty lists the following techniques to ideate during discovery.

<ul><li>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 important to first 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. </li><li>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 so that you can provide them with a better solution. </li><li>Customer Misbehavior: is finding out how customers use your product (also your API) for unintended use cases. Or, to monitor what customers wanted to do but can’t due to problems. You watch for bigger patterns throughout your customer base. </li><li>Hack days: directed (with given goals, customer problems) or undirected, which has the advantage of strongly including developers in the ideation phase. </li><li>Prototyping: comes in many forms, where its main purpose is to tackle product risks, and which 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”. In general, he promotes to do higher-level prototypes at a higher fidelity only when needed, while in the book lists and explains the different types of prototypes such as feasibility prototypes or user prototypes. </li> </ul>

As Marty points out, you test to separate good from bad ideas and to tackle value, usability, feasibility, and business viability risks.

<ul><li><a href="https://svpg.com/prototype-testing/">Usability testing </a>: do it before you build, where Marty provides an extensive set of instructions of how to conduct them also on the <a href="https://svpg.com/prototype-testing/">Prototype testing svpg blog post </a>, and there is lots of other books that — as Marty states himself — do a better and more extensive job at describing it. </li><li>Value testing: for this, Marty, mentions a <a href="https://uxdesign.cc/how-we-run-a-fake-door-test-in-notino-ux-case-study-c7138940c1ec">fake door test </a>, 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. </li><li>Qualitative value testing: when you combine a user interview and a usability test to make sure people aren’t just nice and to learn rapidly. In the interview you could ask whether the user would be willing to pay for it, to recommend the product, to sign-up for it, or to develop it together with you. And iterate depending on their received answers. </li><li>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. </li><li>Viability testing: costs vs. revenue. Where you consider all other cost and revenue related departments and stakeholders (e.g., marketing, sales, finance,…) to make sure that the solution is viable. </li> </ul>

But how to transform to this style of work?

Marty names two approaches of how to start transforming your work style from being a feature team to being a truly empowered product team.

First, he promotes <a href="https://www.gv.com/sprint/">Design sprints </a>, which, to him, is one famous method to fully include and empower your developers. 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 to solve big business problems.

And second, he encourages to leverage <a href="https://svpg.com/pilot-teams/">Pilot teams </a>, which is a team limited to the people who are motivated trying 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 “<a href="https://svpg.com/the-most-important-thing/">The most important things </a>”. In this post, he answers what’s the one thing you should pick when trying to change the way you work and moving in the direction of a <a href="https://svpg.com/product-vs-feature-teams/">product team </a>.

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 to establish trust by demonstrating you’re knowledgeable and by sharing your learnings and to spend

To do so, Marty suggests spending 2–3 hours per week in 1:1s with them and to might use lunch or coffee breaks for such meetings. While such meetings give you the chance to be open and transparent about potential solutions and show them using high-fidelity prototypes, it allows them to give you feedback and raise their concerns. Should discussions arise, then Marty advocates to move 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 the point, which is why he recommends only senior roles to 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.

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:

<ul><li>What’s a good product team? </li><li>What’s a good organization? </li><li>What are the reasons for bad velocity? </li> </ul>

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 as a good organization? To me, the most important aspects, listed by Marty, are that the organization has empowered product teams. Teams who are regularly exposed to customer pain 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 bad 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 doing product discovery. And in the meantime, of doing so, accrue more and more technical debt.Something Marty also observed with slow organizations is that they often suffer from constantly changing priorities and a consensus culture.

I really enjoyed reading the book a second time and now have to acknowledge that I see things differently the second time.

After 2+ years of being a PM I have to say that I now understand many things so much better and also know why a friend of mine recommended this book so enthusiastically a few years ago.

It was and still is one of the fullest and most accurate pictures painted of how a Product Manager ideally works in order to INSPIRE and to build products people love.

In case you enjoyed this summary of INSPIRED, you might also want to check out <a href="https://medium.com/@t.ziegelbecker/a-summary-of-escaping-the-build-trap-by-melissa-perri-d247f943a7b3">another summary of mine </a>about a more recently published <a href="https://www.amazon.com/Escaping-Build-Trap-Effective-Management/dp/149197379X">book by Melissa Perri </a>, mentioned in the beginning.

Leave me a comment when you think some parts could be improved, are missing, or when you simply liked them.

A summary of INSPIRED by Marty Cagan

Inspired - Design Great Products

abhi47 n's ideas are part of this journey:

Related collections

Similar ideas