Tech @ Domain
Published in

Tech @ Domain

The one book all Product Managers should read.

Inspired: How to Create Tech Products Customers Love, Second Edition by Marty Cagan

The Book: Inspired, Second Edition by Marty Cagan

Inspired V2 is an update to one of the seminal texts on product management. This version has been radically reworked to bring it up to date and incorporate how product thinking has evolved in the 10 years since Marty first published Inspired: How to Create Tech Products Customers Love. The book provides insights into how successful product organisations discover and deliver technology products which consistently deliver business value and exceptional customer and user experiences. The book does this by describing four foundational elements required to build a successful product organisation: having the right people, the right product, the right process and the right culture.

My highlights

The book presents a clear articulation of the state of the art when it comes to developing tech products. The most important takeaways for me were:

The Minimum Viable Product Team

A “product team” should at a minimum include 1 Product Manager, 1 Designer, 1 Tech lead and between 2–8 Engineers. This is because you need Product Manager, Designer and Tech voices in equal measure to ensure ideas are de-risked to the greatest extent possible before a single line of code is written. If you are operating without one of these roles, it is highly likely that you will not address usability, feasibility, viability or value risks during your discovery process. The result: developer time will be wasted building products which never get used.

Create a shared understanding

Engineers are an amazing source of good ideas, because they often know what is just becoming technically possible and can apply that understanding to the problem which needs to be solved. However, to make the most of this, it is necessary for the team to have a shared understanding of the customer/user and their paint points. Co-location of the team, frequent sharing and discussion of ideas and problems, and giving the entire team the opportunity to observe user testing and research can really help create this shared understanding.

Outcome ≠ output

Historically, roadmaps have focused on output: that is features to be shipped. However, output does not equal outcome. Product teams should shift their focus to the delivery of business or user outcomes. This will enable a far higher degree of impact because it brings accountability, flexibility and empowerment. Accountability because you own a number which relates to business success. Flexibility because the focus when discussing with stakeholders is on the outcome achieved, not the features released, which creates space for the team to pivot and refocus. The combination of accountability and flexibility breeds empowerment.

Doing discovery right

There are a broad range of qualitative and quantitative techniques outlined in the book which can be used across the discovery journey. Qualitative techniques focus on learning quickly and discovering big insights, and are centred around talking with users and customers. Quantitative techniques focus on evidence, and assessing whether ideas are successful. As it is possible to quickly build a prototype and gain direct feedback from users or customers, product teams should be able to iterate and evolve an idea at a rapid rate before a single line of code is written (assuming a steady flow of participants can be found for user testing). Taking this approach helps ideas evolve quickly, and ensure that significant usability and value risks can be understood and mitigated as early as possible.

Most ideas suck, and that’s OK

High performing product teams are constantly testing new ideas: as many as 10–20 a week. However, most of these ideas suck. Product people need to be comfortable with this, put their egos to one side and focus on using discovery and evidence to validate or invalidate their hypotheses. Ultimately, the most important thing is the lessons a failed idea teaches us, so we can fail better in future.

What was missing

At times, the book felt like a utopian vision of the product process which was blind to some hard organisational realities. Staff turn-over, legacy systems and processes, cultural misalignment and constrained budgets and resources are are just some of the things which can make it difficult to get to the state described in the book. Since reading Marty’s first book, I’ve been inspired to shape the product organisations I work in to follow the core principles he outlines. However I believe more could have been done in this book to discuss the challenges which exist along the way and how to overcome these in search of product Utopia.

My rating

4.5/5 — I believe if there is one book product managers should read about the craft, it is this book.

More from Marty

Some good blogs by Marty Cagan for a taste of whats in the book:

Good Product Team / Bad Product Team

Innovation vs Execution Culture

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Julian Connor

Julian Connor

Product at Atlassian. Ex. SafetyCulture, Domain, Indeed & the Guardian. Recovering strategy consultant. @julianconnor on Twitter.