Inspired: How To Create Products Customers Love (by Marty Cagan) — Bullet Summary
Note: This bullet-point summary is part of a startup & product book series, take a look at the full list here.
Winning products come from the deep understanding of the user’s needs combined with an equally deep understanding of what’s just now possible
SUMMARY
This book provides a series of pointers on: 1. How to build a product-oriented culture and 2. How to build engaging products. Key takeaways:
- Focus on misery rather than technology — great ideas appear when you focus on the people you’re trying to help and solving their problems, instead of focusing on technology & solutions.
- Use high fidelity prototypes instead of Product Requirement Documents, and involve your developers early in the discovery phase.
- Lead by objective, not instruction — focus on outcomes not features.
- Manage by wandering around — develop active listening skills.
- Build a team of missionaries, not mercenaries — passion, integrity and empathy at the core of the team.,
BOOK STRUCTURE
- Part I: Lessons from top tech companies
- Part II: The right people
- Part III: The right product
- Part IV: The right process
- Part V: The right culture
PART I: LESSONS FROM TOP TECH COMPANIES
The Problem: A Linear Product Development Process
In this chapter Marty analyses the root cause of failed product efforts in the average company, usually underpinned by a linear product development process. This linear process is typically seen as following the following steps:
The author highlights 4 key problems with the linear process:
- Validation happens way to late: the first piece of customer feedback happens after you release your product
- Kills Innovation: You turn a team of Eng missionaries into mercenaries.
- Focus on output rather than outcome: getting features out Vs. impact
- Product Management becomes Project Management: passing along requirements, underutilizing the resource and hindering problem solving.
The Solution: A Continuous Discovery & Delivery Process
- Continuous discovery & delivery: Ensure you are always working in parallel on discovering what is of value to the customer, deliver it in small batches in a continuous fashion.
- Take product discovery seriously: Ensure you validate key risks (will they find this useful / spend $? is it understandable? can we build it?). You should end up with a validated backlog.
- Build prototypes: the author suggest teams to quickly build realistic prototypes using Sketch / Adobe XD / other tools (considering how cheap it has become to do so). A goodteam should be able to test ±15 per week.
- Distinguish between prototyping and delivery: clearly divide prototyping work from product delivery. An MVP should not be a delivery quality product, just a prototype.
- Create a proper product vision: and clearly communicate within and outside your team.
PART II — THE RIGHT PEOPLE
A strong team:
- Has all the different skills it needs
- Feels real ownership for a product (or a piece of it), and its members behave like missionaries, not like mercenaries.
- Is sized at a minimum of 2–3 people, and a maximum of 10–12 people
- Has clear objectives, with ownership over delivering these
- Does not have the PM as anybody’s boss on the team
- Is ideally co-located, with a preference towards actual employees
- Is responsible for all the necessary work (projects, features, bugs…)
- Is built to live long, not just put together for a short-term project
- Ideally has minimal dependencies to other teams
PART III & IV — THE RIGHT PRODUCT & PROCESS
- Roadmaps can be dangerous: it can lead to teams focusing on features rather than outcomes. Be mindful of this. Its shortcomings include 1. All product development ideas don’t work out 2. It usually takes a few iterations for ideas to devlier any value. These factors can lead your organisation to measure your success on delivering the roadmap, as opposed to delivering on solving an actual user problem.
- The solution — emphasize the product vision and set business objectives for every team (i.e. Obejctives & Key Results.
Product Discovery
Use the Product Opportunity Assessment framework — to determine if a product opportunity is worth the investment, a PM should answer:
- Exactly what problem will this solve? (value proposition)
- For whom do we solve that problem? (target market)
- How big is the opportunity? (market size)
- What alternatives are out there? (competitive landscape)
- Why are we best suited to pursue this? (our differentiator)
- Why now? (market window)
- How will we get this product to market? (go-to-market strategy)
- How will we measure success/make money from this product? (metrics/revenue strategy)
- What factors are critical to success? (solution requirements)
- Given the above, what’s the recommendation? (go or no-go)
High fidelity prototypes are a fantastic tool — it has become so cheap to use them that you should feel free to leverage these in favor of a traditional PRD (Product Requirements Document).
Use personas and principles to make decisions — personas will help you focus your efforts, principles should explain what is truly important to the product and enterprise strategy.
Get your prototype in front of real users fast — it will save you time, energy and resources and will help you quickly test assumptions. You can build a Client Program to do so, leveraging volunteers from existing clientele to help you test assumptions and get high fidelity signal.
PART V — THE RIGHT CULTURE
The key differences between a strong and a weak product team are:
- Strong teams = strong product vision + “missionary-like passion”.
- Strong teams derive their ideas from the vision, their objectives and direct customer interaction (feeling the customer’s struggle).
- Strong teams have “product, design, and engineering sit side by side”.
- Strong teams integrate Eng into product discovery every day and frequently try / iterate on prototypes.
Is this book worth my time?
Yes — this book provides a great overview of what a product organisation is and how it should operate (in the eyes of the author). Most importantly, the author provides an array of recommendations on how to build and improve your product team and culture, to hopefully build better products. IMO it would be particularly relevant to anyone looking to build a new product team.
