A Product Thinking Book Review of Inspired by Marty Cagan

As I’ve moved through my product management journey, there has always been something a little amiss in the roles I’ve been in. I’ve spent my time working in product organizations across various sizes and industries – from enterprise companies to companies with less than 150 headcount, and in industries ranging from finance, audio software/hardware and loyalty to name a few. 

In each of those roles I’ve, at times, felt little influence and ownership over what I was delivering, yet all the responsibility and stress. Roadmaps were subject to change quickly without full context, critical projects would be spun up or wound down, and as a Product Manager I would have to put on my Project Manager hat and encourage the team, often whilst feeling discouraged myself.

Recently, however, I picked up Inspired by Marty Cagan, and I had several eureka moments. In the book, he talks about how you create, structure, and enable your product teams, and whether you treat them as mercenaries—paying them to execute and providing top down orders—or as missionaries giving them a vision and problem and letting them fix and share that vision with the world.

In this article, I’ll discuss the four key takeaways from Inspired that I wish I had known about when I first started my journey in product management, as well as what those insights actually mean to me and why they’ve been useful. I’ll be focusing on discovery and innovation work, as that’s the gap I typically see in organizations and projects as part of my work, as well as when talking to peers.

1. There are four key risks you have to design for

1. Desirability – Does this provide value to customers
2. Feasibility – Can we build it
3. Viability – Will it work for the business
4. Usability – Can customers use it

Understanding the four key risks is a critical framework for product builders vetting the many ideas that come our way. Whether it’s someone from sales claiming X client won’t sign with us because we don’t have Y, or whether it’s the CEO saying that Z is a great idea and how can we build it, focussing on the four risks above allows us to pause and consider the why behind what we’re building, and also what the key risks are and how we can plan for it.

At the heart of what we do as product managers, we are problem solvers not project managers. If an idea or feature is not desirable, if it can’t be built (or if it’s impractically expensive), or if there are legal or brand ramifications, then showing stakeholders this framework and clarifying the risks to them enables our product teams to call out these problems. For example, it’s fine for app review complaints to say users wish they had Y, but if we added it how many people would actually find it valuable? That’s where product discovery comes in.

2. Discovery and Delivery – Dual Track

At its core, Discovery is about identifying and tackling risks around desirability, viability, feasibility, and usability. Here we do things that don’t scale—write throwaway code for prototypes and knock on user’s doors to gather evidence on why it’s something worth building.

Delivery on the other hand is about delivering production quality products you can sell and run a business on. This is when we’ve gathered sufficient evidence that we’re on the right track, and we focus on how we can scale the product or solution.

The separation of the two streams has been eye-opening for me in terms of framing and understanding my roles and responsibility as a Product Manager. For a lot of my career, my responsibility has fallen in the delivery stream of work—focusing on relentless execution, optimizing teams, gathering requirements, writing user stories, providing clarity, addressing blockers, and ensuring products will scale. 

While delivery work is absolutely essential and invaluable, discovery provides the insights, evidence, and direction for product managers to rally a team towards. The reason why we feel like mercenaries or project managers is because we were told to deliver a project, instead of solving for a key problem and objective. I expand on some of the key frameworks and tools of discovery in the next section, and through these tactics we can arm ourselves with ammunition to influence for or against the right bets to invest in. Most critically, with discovery we can avoid investing years of effort and millions of dollars into a project which may not solve for any meaningful user or business problems.

It’s also important to recognize that although the two streams of work are inherently different, they shouldn’t be done separately. For example as we build out scalable solutions, we should continue to talk to our users and understand what the key problems are that they face, and ideate on how we can add features or solutions to our product or platform to benefit the user and the business.

3. Discovery

There are a number of challenges with discovery work: customers don’t necessarily know what they want, the potential lack of alignment on research objectives, the pressure of moving as fast as possible to validate ideas with users, and synthesizing and sharing all the learnings with the team and your organization. Inspired mapped out many of the key components for great discovery work, three of which I think are critical to any Product Manager.

Discovery Framing

It’s important to pause and align on the goals and objectives of whatever you’re trying to achieve—it’s hard to know what success looks like without a defined finish line. The goal of discovery framing is to ensure the team is on the same page. 

In the case where ‘solutions’ are handed down from senior stakeholders, discovery framing provides a framework that allows us to clarify the underlying problem to be solved, tease out risks, and ensure we understand how this work fits with other teams. This process may in turn open up questions or assumptions which require further investigation. 

The key things to consider as part of discovery framing are:

• Identify the key risks (Is it Feasibility, Desirability, Viability)
• Opportunity assessment
  • What is the business objective?
  • How do we know we’re successful? (What are our key metrics)
  • What problem is this solving for our customer or what job is this fulfilling?
  • What type of customer are we focused on?

Customer Interviews

The main objective with customer interviews is around understanding. Put simply: Are our customers who we think they are? Do they really have the problems we think they have? What products, tools, or hacks do they use to solve the problem today? What would require them to switch to your new product?

User research is an entire field in itself and it’s important to be cognizant of that, as there is so much nuance and bias for ourselves and our users. That said, we don’t always have the luxury of having access to a dedicated user researcher on our teams or companies, but there are still a couple of key things which can get us started down the right path.

Some things to consider:

• Build a culture in the team that places importance on the act of talking to users and gaining insights. This reduces the burden of “we gotta get it right” because more interactions provide more opportunities to learn.
• Ensure you’re clear on who the target users are and that you’re talking to them.
• Be clear on your objectives. 
• Get your team involved. It’s different when people see first hand what users are saying vs. summarized insights.
• Make sure you schedule time soon after the interview to internally debrief, follow up on anything with the customer, and synthesize your notes and learnings.

Testing

The methods you use will vary depending on the risks you are testing for. For example, testing for feasibility will mean gathering an understanding around dependencies, performance, infrastructure and, know-how from an engineering team perspective. On the other hand, testing usability will require recruiting users, building high-fidelity prototypes, and planning in advance to understand key tasks you want to test.

A few high-level principles:

• Desirability:
  • When testing demand you want to see how much a user is willing to invest either reputationally, financially, or in time to get a true signal. This could be getting the user to put in their boss’ email to recommend a product. Remember, humans are nice and we want to please, so verbal signals are often not enough.
  • You should have an understanding of what success looks like in terms of the key metric, as well as the target. For example, if you had 10% of users actually submit their email on an indicated interest page for a new idea you’re testing, is that enough? 
• Feasibility:
  • Having a weekly meeting and asking engineers to estimate without context won’t work well. Bringing engineers along during the entire discovery process will ensure they are considering feasibility at all points. “What’s the best way to do this and how long will it take” instead of “can you do this”.

4. Good product team vs. Bad product team

If you’re not familiar, this section is a homage to a now 20+ year old document written by Ben Horowitz, a cofounder of A16Z a Venture Capital firm: [Good Product Manager/Bad Product Manager – Andreessen Horowitz] (https://a16z.com/2012/06/15/good-product-managerbad-product-manager/) which is absolutely worth a read in its entirety. In it, Horowitz talks about the distinction between what makes a good PM, and a bad one. Cagan has created his variant on it based on his own principles, and I’ve included a few key ones below.

Good teams…

…gain inspiration and ideas come from vision and objectives, from seeing customers struggle, analyzing customer data, and applying new tech to solve real problems.

…understand each of their key stakeholders and constraints, while creating solutions for customers and stakeholders.

…engage with end users and customers every week to better understand their needs and desires

…have product, design, and engineering all involved in both delivery and discovery to embrace the give–take between functionality, experience, and technology.

Bad teams…

…blindly accept requirements from stakeholders

…silo product design and engineering, making requests in forms of documents and meetings.

…show engineers prototypes during sprint planning so they can estimate effort without context

…build exactly what’s on the roadmap

…obsess over competitors

---

As a closing note, I firmly believe all advice sums to 0, and for every piece of advice, there is an equally valid counter-advice showing why that’s wrong. The reality is that you, as a practitioner understand your organization and culture the best, and a big part of the challenge is finding the compromise between the ideal and the reality. Knowing and understanding the parts that make the ideal, can help us all as PMs strive to ensure we’re building products that truly solve our users’ and our business’ most important needs, and to energize and empower our organization as part of that journey.