Creating a strong product culture
The best product teams have strong cultures based on discovery and delivery. These teams value and practice experimentation, risk mitigation, compelling product vision/strategy, and collaboration.
Product management takeways: If you’re looking for an all-in-one product management book which shows how the best product teams operate, this is it. Cagan covers a lot of ground in Inspired but it’s based on a small number of key principles. You can start reading anywhere in the book and pick up actionable advice for managers and individual contributors immediately. Many chapters of the book can serve as team-assessment checklists.
Marty Cagan largely re-wrote his popular first edition of Inspired. The second edition contains 67 chapters of product management techniques, principles and frameworks. At the core of the book are a handful of principles that define strong, modern product teams (approach to risk, not doing waterfall, and outcomes not output).
Key concepts for modern product teams
Focus on the holistic product
The product manager must ensure a business outcome, not just ensure a product gets defined.
Modern product teams take into account the functionality, technology, user experience, monetization, and customer acquisition. Implementing a feature or features is only part of a successful product. The team must take into account, and design, the way customers are introduced and onboarded to the product as well as how the product fits into the company (financial and operational considerations).
Continuous discovery and delivery
This is a key element of Cagan’s product management framework. He portrays this principle as a flow beginning with objectives which leads to discovery and then to delivery. One key difference between this framework and the traditional waterfall method is that here the discovery and delivery activities are both ongoing and done in parallel. The goal of discovery is to answer the questions related to the four types of risk (value, usability, feasibility, and viability).
The purpose of product discovery is to quickly separate the good ideas from the bad. The output of product discovery is a validated product backlog.
Another key aspect of discovery is finding and building relationships with reference customers. Cagan defines a reference customers as a real customer who is using the product in production, has paid money for the product, and is willing to tell others how much they love the product. Reference customers are critical because you are developing customers at the same time as your product.
Excelling in both the discovery and delivery dimensions is difficult because they represent different skillsets. Discovery is fundamentally about innovation and finding valuable solutions for customers. Delivery is about execution. Discovery culture includes experimentation, empower, testing ideas, business constraints, and openness to new ideas. Delivery culture is focused on urgency, high-integrity commitments, accountability, collaboration, and results. Cagan suggests assessing your team in these two attributes and evaluating where you are today versus where you’d like to be.
It doesn’t matter how great the ideas are if you can’t get a productized, shippable version delivered to your customers.
The overarching purpose of any form of prototype is to learn something at a much lower cost in terms of time and effort than building out a product.
Prototypes enable teams to tackle the biggest risks first and enable learning. Cagan likes to pair prototypes with story maps as framing and planning techniques.
Product Vision and Product Strategy
Product vision is what brings talent to the company and inspires product teams on a daily basis.
In truth, buying into a vision is always a bit of a leap of faith. You likely don’t know how, or even if, you’ll be able to deliver on the vision.
A product strategy identifies the set of products or releases which the team intends to deliver on the path to the product vision.
The difference between vision and strategy is analogous to the difference between good leadership and good management. Leadership inspires and sets the direction, and management helps get us there.
The product vision and strategy are the key components of the context which is required for empowered and effective product teams. Cagan writes that the most important benefit of a product strategy is that “you decided to focus your product work on a single target market at a time.” When evaluating how to sequence your target markets, Cagan says to consider total addressable market, go-to-market strategies, and time to market.
Principles of modern product teams
Risk are tackled up front
A key theme in Inspired is a set of four types of risk which need to be addressed before building anything. Cagan writes frequently about discovery and deliver–exploring these four risks is discovery work.
- Value risk – will customers buy it?
- Usability risk – can users figure out how to use it?
- Feasibility risk – can the engineering team build it with the available time, skills, and technology
- Business risk – does it work for the company as a whole (e.g., sales, marketing, finance, legal, support, operations)
Inspired contains nearly 20 chapters dedicated to various types of testing and validation. It’s a great inventory to draw from and Cagan provides criteria for using each along with a short description. As part of the discovery and delivery tracks, testing and validation begin with the initial questions about an idea to high fidelity models such as live-data prototypes used for specific risk mitigation.
Products are developed collaboratively, not sequentially
Modern product teams have moved beyond the waterfall method where product managers gather requirements, document them in a specification, hand them off to design, then hand the design off to engineering, and finally hand off the solution to QA. Strong teams bring the best of each discipline (product management, engineering, design) to solve a business problem and use techniques like prototypes to reduce the four risks identified above.
Solve problems; don’t implement features
Modern product teams don’t take a feature given to them by management and simply implement it. Strong teams are challenged to find solutions to business problems and are accountable for business results, not outputs.
The role of the product manager
When a product succeeds, it’s because everyone on the team did what they needed to do. But when a product fails, it’s the product manager’s fault.
Because the product manager is responsible for identifying what the product team builds, the product manager role is critical.
[As a product manager] you need to become an acknowledged expert on the customer: their issues, pains, desires, how they think–and for business products, how they work, and how they decide to buy.
Cagan believes that a product manager should have deep knowledge of the customer, data, your business, and your market and industry.
Succeeding in the job of product means convincing each key stakeholder that you understand their constraints and that you are committed to only delivering solutions that you believe are consistent with those constraints.
The problem with product roadmaps
The issue is that anytime you put a list of ideas on a document entitled ‘roadmap,’ no matter how many disclaimers you put on it, people across the company will interpret the items as a commitment.
Traditional roadmaps pose several problems. First, a roadmap measures success by feature delivery (output) rather than by business outcome. Second, roadmaps force teams to deliver previously decided features rather than work collaboratively to solve a business issue and measure results. As a result, they take product leadership off the hook from identifying and articulating business objectives.
Typical roadmaps are the root cause of most waste and failed efforts in product organizations.
Cagan agrees that often teams must make high integrity commitments to the company. However, modern product teams operate with business objectives and business context to provide value.
He acknowledges that executive teams ask for roadmaps because they want to know that the product team is working on the highest value things first and they need to be able to plan dependencies and coordinate cross-company initiatives.
The alternative to roadmaps
It’s a constant struggle between those executives and stakeholders who are trying to run the business and the product team that is understandably reluctant to commit to dates and deliverables.
Cagan diagnoses the root issue with roadmaps as when the date commitment is made. He says the compromise is to allow teams time for product discovery before making commitments. Once value, usability, feasibility and viability have been addressed, a high integrity commitment can be made.
We need to learn fast, yet also release with confidence.
In addition to addressing the four risks mentioned above, product teams need to keep several product discovery principles in mind:
- It’s not possible to rely on customers or stakeholders to tell you what to build
- The critical thing is to establish compelling product value
- Functionality, design and technology choices cannot be separated
- The truth is that many ideas just won’t work, and those that do will require several iterations
- Strong product teams validate ideas with real users and customers
- The best product teams emphasize shared learning
Our goal in discovery is to validate our ideas the fastest, cheapest way possible.
Inspired describes a number of discovery framing tools including the product opportunity assessment, the customer letter, and the startup canvas. Cagan’s other favorite discovery tools include story maps and reference customers.
Good product teams, bad product teams
Cagan provides a lengthy list of attributes of good and bad product teams including the top reasons for lack of velocity and innovation. It’s another good checklist included in the book for assessing your team. Some common themes in great product teams include
- Obsessing over your reference customers instead of obsessing over competitors
- Celebrating achievement of significant business impact instead of celebrating releasing features
- Getting inspiration from vision, objectives, customer observation, and customer data instead of sales and customer requirements
- Having many skills for validation instead of having meetings to generate prioritized roadmaps