Book Review: INSPIRED

INSPIRED

Author(s)

Marty Cagan


My Rating

star star star star star
"Cagan masterfully show us how leading organisations build the best tech products... and how we can, too."

Amazon, Netflix, Ebay... Marty Cagan has deep inside knowledge of how leading tech-powered organisations operate. In this second edition of Inspired, Cagan shares all of that knowledge to show us how we can build innovative product organisations like the very best.

The renewed focus of this second edition is product innovation at scale - how to build an innovative product culture in large enterprise organisations. Quite possibly the biggest challenge facing every tech company, certainly in my experience.

Surely an impossible topic to cover faithfully in a single book? There are so many aspects of creating great products, and an infinite number of obstacles. But somehow Cagan has done it. This book is special.

Product Discovery is the Differentiator

Inspired is split into five broad sections, covering the major areas of building innovative product companies: people, process, product, and culture. Across all of them, however, is one vital theme that Cagan believes is a major differentiator: continuous discovery.

The best innovative product cultures Cagan has witnessed all had a strong discovery culture. Continuously talking to customers and testing ideas out with them before they are built. 

Alongside that belief, another strong opinion repeated consistently throughout the book is that the whole team should be involved in discovery - the whole team should be part of user research and the whole team should have the autonomy to suggest new features and decide what they should work on.

I could not agree more with these opinions. I have been part of strong discovery teams and it has completely transformed my mindset as an engineer. In saying that, the examples and techniques Cagan talks about in the book have taught me I still have lots more to learn about discovery.

In particular, the section on discovery techniques was a real eye opener covering value testing, usability testing, feasibility testing, and business viability testing. The chapters discussing team structure were also very enlightening.

Broad Product Culture Coverage 

When you write a book, you have to make trade-offs about how much detail to include in order to keep the page count low and avoid writing a textbook that nobody reads. Clearly with this book Cagan has gone for broad coverage of many topics, lacking a lot of depth.

It would be unreasonable to expect all of the topics to be covered in full depth. The book would be over a thousand pages. However, there are very few examples of the techniques talked about in the book. Cagan talks about a lot of prototypes for example, but doesn't show any. He talks about startup canvases and story maps, but doesn't show any.

This means there are two things you have to acknowledge as a reader. Firstly, you have to take a leap of faith and trust Cagan on some of his opinions and ideas. And secondly, you have to read more books to go in detail on specific topics.

It didn't take much of a leap of faith for me, though. I was consistently able to verify a lot of Cagan's opinions and experiences with my own and other books. So I feel confident to treat all of his opinions with high credibility. In my opinion, you should, too.

The Final Word

Many organisations I've with and heard about are weak at product discovery and empowering their teams to make product decisions. It's no coincidence they were poor innovators.

Cagan shows us another way in Inspired and we should all be making efforts to drive as many of these ideas in our organisations as possible.

I wholeheartedly recommend this book to anyone working in tech organisations, especially senior management.

Highlights

"on the best teams, the engineers and designers want to see some evidence that what you're asking to build is truly worth building."


"A product team is not about reporting relationships—it has an intentionally flat organizational structure. Usually, everyone on a product team is an individual contributor, and there are no people managers."


"a few product teams out there that have modified their product roadmaps so that each item is stated as a business problem to solve rather than the feature or project that may or may not solve it. These are called outcome‐based roadmaps."


"Good teams are skilled in the many techniques to rapidly try out product ideas to determine which ones are truly worth building. Bad teams hold meetings to generate prioritized roadmaps."


"Good teams understand who each of their key stakeholders are, they understand the constraints that these stakeholders operate in, and they are committed to inventing solutions that work not just for users and customers, but also work within the constraints of the business. Bad teams gather requirements from stakeholders. "


You may also like...

Sprint

Hooked

Lean UX

My Books

Designing Autonomous Teams and Services
Patterns, Principles and Practices of Domain-Driven Design
The Strategic Practices of Domain-Driven Design