One of my colleagues dropped into my office before Christmas and handed me a book. I usually graciously accept book suggestions and then veer off to read the highest priority item in my list instead as my reading time with two kids at home is precious and scarce. However, this book intrigued me from the start: Inspired: How to Create Tech Products Customers Love by Marty Cagan. At Singlewire, we’re currently setting up an effective Product Management practice within our development group. I just hired our first Technical Product Manager and UX Lead. They are both doing an amazing job, but it takes time and an entire organization to develop a process to create tech products customers love. To be honest, a couple influential and well-meaning parts of our business are not yet sold on what a Product Manager and great Product Management process can do for the business, but to their credit, they’re letting us experiment and spin up a process that we’re happy with. I procrastinated on the book for a coupe of weeks until, serendipitously, I caught up with a friend of mine who is now leading a 170-person program at Salesforce. He asked me if I knew about Marty Cagan and when I showed him the book sitting on my desk, he said, “Read it immediately!” So I did.
What Inspired Me?
Inspired is like a how-to manual for building products. Marty Cagan is the founder of the Silicon Valley Product Group and has built products for Hewlett Packard, Netscape, and eBay. I honestly hadn’t heard of him, but when I started reading, it was immediately clear that he knows his sh*t. After a brief discussion of why the product development process fails in many organizations, Marty dives into everything I needed to hear in this moment. What makes a team successful? What does a good Product Manager need? Which questions should we be asking during discovery? What roles should you have in your product organization and how do you organize them? How do you know you’re building the right product? How do you organize teams around a shared vision and strategy? Which techniques are best suited for each stage in the product process? Much of what this book is about, I’d heard and sometimes used, but never before have I seen it all laid out like this. It was the right book at the right time for me.
What Do Successful Teams Do?
Successful teams:
- Tackle risks up-front (value risks, usability risks, feasibility risks, and business viability risks)
- Design products collaboratively with representation from product, design, and engineering
- Focus on solving problems, not building features
Key concepts that he lays out are building holistic products, continuous discovery and delivery, prototyping (strong teams test 10-20 ideas PER WEEK), minimizing dependencies, developing product/market fit, and understanding/building towards the product vision.
Focus on Outcomes
If there’s one key item I took away from Inspired, it is that product teams must be focused on outcomes. I can’t tell you how much time we spend slogging through customer feature requests each week, only to come up with an eclectic list of things our customers think they need, not a focused list of things that will actually, holistically solve our customers’ problems. To be fair, some of our features do move the needle, quite a bit, but we’re bad at stopping to ask ourselves, “What’s the problem we’re actually trying to solve?” And we’re not alone.
Teams need business context, which means:
- A cohesive, inspiring product vision and a strategy, or, plan to achieve that vision
- Clear business objectives
Cagan, like me, is a fan of Objectives and Key Results (OKRs), which you can find out more about in Measure What Matters by John Doerr. He also throws out something a little bit more radical. Instead of roadmapping, keep a list of business results that you’re trying to attain and let the teams figure out how to get there. A good business result might be to reduce subscription customer churn by 8%, which allows customer success, sales, marketing, and the product organization a lot of room to come up with the best way to achieve that result. The business doesn’t care how you get there, what it really cares about is that you get there.
High Integrity Commitments
The idea of not having a roadmap is extremely unsettling for most product teams and executives. What do you mean we can’t map out the entire year and give our customers dates?? Enter something that Cagan calls High Integrity Commitments. For a few of the items the business needs, the product team asks for a little more time to validate an idea (with customers, engineers, and stakeholders) before making a timing commitment. By going through some de-risking activities up-front, we have a much better sense not only that the work will get done on time, but that the work is the right work to be focused on. These are high integrity commitments and if you sprinkle these in with your outcome-based objectives, this, Cagan argues, is the right way to steer a product organization.
Product Discovery, Prototyping, and Testing
The rest of the book is focused on specific examples of tried and true techniques for validating and testing products. Many of these will be familiar to you already and some aren’t even covered in detail (Cagan assumes you know where to go get the information if needed). But it’s a fantastic reminder of how to go about creating products that will be successful.
The Verdict?
There is so much more in this book than I can even scratch the surface on here. I took 3.5 pages of notes and already want to re-read it so I can improve how we create tech products. My verdict? This book is brilliant. Read it immediately!
