This book will help you learn how great products can be built!

A must read for every aspiring/existing product manager :)

Why this book?

If you have already read this book, I hope the takeaways summarized below serve as a refresher;

If you haven’t read this book, here’s why you should read it:

• Pick ANY blog or article suggesting lists of must read books for product managers, this book would definitely be on it
• The author, Marty Cagan is an accomplished and well established voice in the product management and tech community
• Most importantly, this book presents well organized and easy to read content; providing practical advice that we can use to build better products

That being said, let’s dive right in.

My key takeaways from the book

1. Mercenaries vs Missionaries

There’s this banger of a quote in the initial pages of the book —?“It doesn’t matter how good your engineering team is if they are not given something worthwhile to build”

Absolutely.

• Great products are built by missionaries who have the customer at the top of their mind and focus on solving real problems, not just shipping features that originate from “business” users;
• Mercenaries build whatever they’re told to build; while missionaries are true believers in the vision and are committed to solving problems for their customers.

A missionary would see the end product quite differently from a mercenary.

While a mercenary just looks at the backlog of features to be delivered and the associated timeline, a missionary sees something different:

The product is not just a packaged set of features, but:

• The underlying technology that enables the features to work seamlessly
• The user experience design that presents this functionality to end users
• The business model to monetize the product
• How we would attract, acquire, onboard and serve users and customers; Even, offline experiences surrounding the customer journey as they discover, purchase and use the product etc.

Clearly, the missionary sees the product as more than just a sum of its parts.

2. The art of product discovery

As mentioned earlier, the key to building great products is to discover real customer problems, and align the technology and design required to solve those problems, all in a way that works for the larger business.

In a nutshell: We need to discover the product to be built, and we need to deliver that product to market.

If your product team has a good ‘product discovery’ framework to follow, that leads to a validated product backlog, which informs what gets built and when.

Of course, product discovery is a continuous activity, and true agility of your team is a reflection of how rapidly you can address the needs of end customers as they evolve.

There are 2 key aspects to the process:

Solutioning

• What does the customer solution needs to be? Is there enough demand for this solution
• How would a single solution work for multiple customers?
• This stresses the need to test out multiple ideas quickly and efficiently

Delivery

• We need to ensure that the solution identified can be released with confidence by the team, as a robust and scalable implementation that customers can depend on, for consistently reliable value
• The product is scalable and performant to the degree necessary; It has a strong suite of automated regression tests; It is instrumented to collect the necessary analytics; It has been internationalized and localized where appropriate; It is maintainable; It is consistent with the brand promise; And, most important, it is something the team can release with confidence.

Ultimately, if you want to solution great products, it really is essential that you get your ideas in front of real users and customers early and often.

If you want to deliver great products, you want to use best practices for engineering and try not to override the engineers’ concerns.

The key risks that should always be on a product manager’s mind during the discovery and delivery process:

• value risk?(whether customers will buy it)
• usability risk?(whether users can figure out how to use it)
• feasibility risk?(whether our engineers can build what we need with the time, skills, and technology we have), and
• business viability risk?(whether this solution also works for the various aspects of our business — sales, marketing, finance, legal, etc.).

3. What should a product manager aspire to be?

This was eye opener for me — in terms of the responsibilities a product manager carries; and the work need to do justice to the role.

A PM should aspire to be someone who -

• Evaluates opportunities, owns what gets built and delivered through the product backlog/roadmap/vision; i.e. define clearly, the WHAT & WHY
• Gains deep knowledge of the customer — their issues, pains, desires, how they think/how the product will work for them/how they will buy and use it; i.e. qualitative learning (to understand why our users and customers behave the way they do), and quantitative learning (to understand what they are doing)
• Understands the data; i.e. how customers are using the product, and the associated KPIs based on the nature of the product
• Gains deep knowledge of the business; i.e. knowing who your various stakeholders are and especially learning the constraints they operate under
• Gains deep knowledge of the market/industry; i.e. includes not only your competitors but also key trends in technology, customer behaviors and expectations, following the relevant industry analysts, and understanding the role of social media for your market and customers

Why is all this important — because, if the product a PM ships has to be great:

• It needs to be substantially better and create stickiness; feature parity doesn’t work due to switching costs.
• No product lives in isolation; it needs to fit into an ecosystem of products and play well with them.
• Industries and technologies are constantly moving, and we must create products for where the market will be tomorrow, not where it was yesterday.

Accordingly to Marty, the successful product manager must be the very best versions of smart, creative, and persistent.

Quite a tall order, right?

Closing thoughts

Product management is quite the cross functional discipline, and the great thing is that — there is always more to learn about it; there will never be a perfect way to get the PM role right or build great products every time, but books like “Inspired” certainly help move the needle in developing this art, and helps build communities that will keep innovating to push boundaries and products for ever eager customers.

If you’d like to get more into the details of the aspects discussed in this article including frameworks for discovery, ideation, prototyping, validation and much more, I would highly suggest reading this book.