Inspired - How to Create Tech Products Customers Love
📖

Inspired - How to Create Tech Products Customers Love

‣
Book Blurb

How do today's most successful tech companies—Amazon, Google, Facebook, Netflix, Tesla—design, develop, and deploy the products that have earned the love of literally billions of people around the world?

Perhaps surprisingly, they do it very differently than most tech companies.

In INSPIRED, technology product management thought leader Marty Cagan provides readers with a master class in how to structure and staff a vibrant and successful product organization, and how to discover and deliver technology products that your customers will love—and that will work for your business.

With sections on assembling the right people and skillsets, discovering the right product, embracing an effective yet lightweight process, and creating a strong product culture, readers can take the information they learn and immediately leverage it within their own organizations—dramatically improving their own product efforts.

Whether you're an early stage startup working to get to product/market fit, or a growth-stage company working to scale your product organization, or a large, long-established company trying to regain your ability to consistently deliver new value for your customers, INSPIRED will take you and your product organization to a new level of customer engagement, consistent innovation, and business success.

Filled with the author's own personal stories—and profiles of some of today's most-successful product managers and technology-powered product companies, including Adobe, Apple, BBC, Google, Microsoft, and Netflix—INSPIRED will show you how to turn up the dial of your own product efforts, creating technology products your customers love.

The first edition of INSPIRED, published ten years ago, established itself as the primary reference for technology product managers, and can be found on the shelves of nearly every successful technology product company worldwide. This thoroughly updated second edition shares the same objective of being the most valuable resource for technology product managers, yet it is completely new—sharing the latest practices and techniques of today's most-successful tech product companies, and the men and women behind every great product.

The Book in 3 Sentences

An important retrospective clarification: this is a textbook about Product Management, not a regular old book. There are so many ways one could go about summarizing this treasure chest of knowledge, so please don’t take this review as all encompassing. As with all textbooks, there are many “terminology/framework > definition > how to do it well” examples throughout the book, but for the purpose of this summary I chose not to focus on those streams of knowledge, and instead focused on what I found to be the 3 most generalizable and applicable topics that I believe would benefit any reader.

  1. It’s a product managers job to make sure that a solution being delivered solves an underlying problem, which can only be done successfully if the idea/solution proves to be (1) valuable - will the customer buy this, or choose to use it? (2) usable - can the user figure out how to use it? (3) feasible - can we build it? (4) viable - does this solution work for our business?
  2. ‘Product/market fit’ was mentioned 36 times in this book, while ‘product-led growth’ (which is a more recent buzzterm) was not mentioned at all, but they are both used to explain a similar idea: everything depends on strong products. Without strong products, marketing programs require customer acquisition costs that are too high; the sales organization is forced to get “creative,” which drives up cost of sales, lengthens the sales cycle, and puts downward pressure on price; and the customer success organization is forced to take it on the chin every day with frustrated customers
  3. Most of what Marty speaks about in this book can be umbrella’d under the idea of creating the right product culture; he describes how great companies think, organize, and operate. Here’s a very detailed list of what separates good product teams vs. bad ones:
    4. ‣
    Click here for the list
    “Good teams ... ”
    “Bad teams ... “
    have a compelling product vision that they pursue with a missionary‐like passion
    are mercenaries
    get their inspiration and product ideas from their vision and objectives, from observing customers' struggle, from analyzing the data customers generate from using their product, and from constantly seeking to apply new technology to solve real problems
    gather requirements from sales and customers
    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
    gather requirements from stakeholders
    are skilled in the many techniques to rapidly try out product ideas to determine which ones are truly worth building
    hold meetings to generate prioritized roadmaps
    love to have brainstorming discussions with smart thought leaders from across the company
    get offended when someone outside their team dares to suggest they do something
    have product, design, and engineering sit side by side, and they embrace the give and take between the functionality, the user experience, and the enabling technology
    sit in their respective silos, and ask that others make requests for their services in the form of documents and scheduling meetings
    are constantly trying out new ideas to innovate, but doing so in ways that protect the revenue and protect the brand
    are still waiting for permission to run a test
    insist they have the skill sets on their team, such as strong product design, necessary to create winning products
    don't even know what product designers are
    ensure that their engineers have time to try out the prototypes in discovery every day so that they can contribute their thoughts on how to make the product better
    show the prototypes to the engineers during sprint planning so they can estimate
    engage directly with end users and customers every week, to better understand their customers, and to see the customer's response to their latest ideas
    think they are the customer
    know that many of their favorite ideas won't end up working for customers, and even the ones that could will need several iterations to get to the point where they provide the desired outcome
    just build what's on the roadmap, and are satisfied with meeting dates and ensuring quality
    understand the need for speed and how rapid iteration is the key to innovation, and they understand this speed comes from the right techniques and not forced labor
    complain they are slow because their colleagues are not working hard enough
    make high‐integrity commitments after they've evaluated the request and ensured they have a viable solution that will work for the customer and the business
    complain about being a sales‐driven company
    instrument their work so they can immediately understand how their product is being used and make adjustments based on the data
    consider analytics and reporting a nice to have
    integrate and release continuously, knowing that a constant stream of smaller releases provides a much more stable solution for their customers
    test manually at the end of a painful integration phase and then release everything at once
    obsess over their reference customers
    obsess over their competitors
    celebrate when they achieve a significant impact to the business results
    celebrate when they finally release something

Impressions 🤔

I take notes on all the books I read, but as I started putting this review together I realized that I had basically highlighted the entire book 😅  The amount of value compressed into this one book is ridiculous.

I am currently reading Antifragile by Nassim Taleb and highlighted his comment: “Practitioners don’t write; they do.” That is exactly how I felt reading Inspired because of Marty’s many years of experience in the tech scene - every bit of advice that he shared in this book was through his reflective experience of do-ing, not observing.

That being said, as someone who is not in a product role at the time of reading this, I did find that I lost my excitement to continue reading at times because of my lack of involvement in my organizations product development. Although I could directly apply a lot of these learnings in my role as a Customer Success Manager (mostly in product discovery), I was still slightly limited based on the scope of my role. I will definitely be coming back to my notes as a sort of manual or refresher when I become a Product Manager.

Who Should Read It❓

For the purpose of this book, by ‘read’, it could just mean “go to the table of contents and go directly to the topic that you want to learn more about”.

  • If you are involved in any part of product development at your organization
  • As I mentioned above, I will be using many parts of this book as a sort of ‘guide’ as I maneuver through my career in tech & product, so anyone in a leadership product role who feels that they could take a step back and re-frame what they’re currently working on. This means CEOs, CTOs, COOs, CPOs, and most of their reports
  • If you are an an entrepreneur or building a company
  • If you read ‘Sprint’ and enjoyed it, or it helped you in your career - Marty stated that it is a “must read book for product managers” and that he highly recommends it

How the Book Changed Me 💯

💡
How my life / behaviour / thoughts / ideas have changed as a result of reading the book.
  • I have a deeper understanding of the importance of a company’s product culture
  • I have tried to make my product counterparts lives a lot easier by doing as much product discovery work as I can in my role as a CSM
  • I listen much better in conversations with various stakeholders
  • I have a better eye for catching a lack of consistency in my company’s output and product mission - which has helped me frame how I speak to users/customers
  • I’ve learned to limit the weight & validity I put on my opinions; data > opinions

My Top 5 Quotes 🗣

“Life is too short for bad products”
“Fall in love with the problem, not the solution”
“It is all about outcome rather than output”
“When a product succeeds, it’s because everyone on the team did what they needed to do. But when a product fails, it’s the product manager’s fault”
“Data is not everything, but data beats opinion” AND “Data will shine a light on what is happening, but it won’t explain why. We need our qualitative techniques to explain the quantitative results”
LinkedInInstagram