What do you think?
Rate this book
Inspired: How to Create Tech Products Customers Love
The basic premise of Inspired is that the best tech companies create products in a manner very different from how most companies create products. The goal of the book is to share the techniques of the best companies. This book is aimed primarily at Product Managers working on technology-powered products. That includes the hundreds of "tech companies" like Google, Facebook, Amazon, Twitter and the like, as well as the thousands of companies moving to leverage technology (financial companies, media companies, retailers, manufacturers, nearly every industry). Inspired covers companies from early stage start-ups to large, established companies. The products might be consumer products or devices, business services for small businesses to enterprises, internal tools, and developer platforms.
Inspired is secondarily aimed at the designers, engineers, user researchers and data scientists that work closely with the product managers on product teams at these same companies.
Inspired is secondarily aimed at the designers, engineers, user researchers and data scientists that work closely with the product managers on product teams at these same companies.
349 pages, Hardcover
First published January 1, 2008
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 - 30 of 1,391 reviews
June 9, 2015
"Inspired" is a well-written, thorough, and down-to-earth work covering all aspects of product management at software companies.
To paraphrase/summarize: the job of the product manager is to discover a product that is useful, feasible, and valuable. They do this through understanding users and potential users in detail and evaluating opportunities to solve problems for those users. Once an opportunity is identified, they create a prototype, validate the prototype with users, then work with engineering to build the product, product marketing to launch the product, and sales and support to follow up on the success (or failure) of the product.
The book covers how product management fits in with other functions -- engineering, interaction design, visual design, project management, product marketing. The difference between product management and product marketing is often misunderstood, but Inspired explains it simply: product marketing is about understanding the marketplace (in aggregate), how your product fits into that, and how to explain it when it comes time to launch. Product management is about the content of the product -- understanding the users/customers (individually), how the product works, what it is for. Creating a product and explaining a product to the world require two very different skillsets that are rarely found in the same person.
There's also a great chapter on how to "manage up," meaning how to work most effectively with your manager.
Some excerpts and points:
- "Engineers think in terms of implementation models, but users think in terms of conceptual models."
- You need "one product manager for every 5 - 10 engineers," one interaction designer for every two product managers, and one visual designer for every four interaction designers.
- "As a product manager, you are responsible for defining the right product, and your engineering counterpart is responsible for builidng the product right."
- "Keep the focus on minimal product. Your job as product manager is not to defin the ultimate product, it's to defint he smallest possible product that will meet your goals."
- While most work the engineering teams do comes from product, engineering teams should reserve some amount of time (the author used 20% when he worked at eBay) for refactorings, rearchitecting, and other internal technical changes that are unrelated to product.
- Great product people may already exist in your organization if you look around. The author suggests that they often come from engineering.
- Product managers should be passionate and evangelize internally. They "inspire the rest of the product team, and the passion for a product is contagious."
- Empathize with your target market, but don't slip into the trap of thinking of yourself and your friends as being the target users, even if it's partially true. Related: "It can be dangerous for a product manager to have too much domain expertise, because they believe they can speak for the target customer, and that they are more like their target customer than they really are."
- Engineering knows what's possible, so they are an important input to the product discovery process.
- Product marketing knows of broad unaddressed needs in the marketplace, making them another important input to product opportunities.
- Good revenue vs bad revenue: the former enhances your Net Promoter Score and expands your market, the latter does the opposite -- for example, adding customized features for one banner customer, what the author calls "specials."
- Product management should be a top-level organization, not placed as a subset of engineering or marketing (two common org structures). The design team can be part of the product org.
- "Conduct the real meetings before your official meeting." Get buy-in from key stakeholders beforehand. "The formal meeting still has an important purpose, which is for every at the table to see that everyone else is on board."
- "Opportunities for new products exist all around us, in every market -- even mature markets. This is because what is possible is always changing."
- Product should always be working well-ahead of engineering, to keep engineering teams fed with new work when they finish their current projects.
- "Review the business performance of products that have launched, typically 3 - 6 months post-launch. This sort of accountability will help the council better understand which investments and decisions they made were good ones, and why."
- The author strongly favors high-fidelity prototypes (e.g., they look like the real thing, not a rough paper mockup) as they are cheap to create nowadays and give better results when validating the prototype with users. High-fidelity prototypes are also great for engineering teams, because it's extremely clear what needs to be implemented.
- On the importance of reference customers at launch time: "Potential customers need to know that this product really works for people like them."
- Building a customer advisor board of charter around six customers will help in the feedback process for a new product, and also provides real customer references at launch time. Think of these charter users as development partners, and treat them as colleagues.
- "Winning products come from the deep understanding of the user's needs combined with an equally deep understanding of what's just now possible."
- Use "personas," archetypes of an imaginary but plausible user that describes a particular customer segment you're targeting.
- If there are technical feasibility risks (e.g., something that might be hard or impossible for engineerings to implement), get with an engineer to address them early, during the prototype phase.
- Do your own user testing, ideally in person.
- Take care to avoid accidental "user abuse" -- surprising changes in your product, especially ones that create incompatibilities. Even releases too many changes in too short a time period ("change fatigue") can be a type of user abuse.
- "As a general rule, users don't like change. Sure, they want the software to be great, and they clamor for new functionality, but most people aren't excited about taking the time to learn a new way to do something they can already do."
- The author describes what he calls "gentle deployment," which is a way to cautiously and respectfully roll out changes to a large usercase. This includes techniques such as rolling out both the old and new versions alongside each other, with a link somewhere inviting users to try out the new version, long before the new version becomes the default.
- Make sure to reserve product, engineering, and design resources to follow up on feedback in the week or so following a big product or feature launch.
- Great ideas almost always come from the bottom up, not top-down product strategy. Use techniques like Google's 20% time or skunkworks teams to encourage this.
- "Build relationships before you need them."
- On working in large organizations: "Pick something worth fighting for, where the outcome truly matters. When you do fight, make sure you're fighting for your product and not against another person." And: "Triage your meetings ruthlessly." And: "Evangelize! Explain the vision and strategy, demo the prototype, and share customer feedback. Don't underestimate the importance of this internal sales function."
- "Knowing how to get feedback on product ideas is probably the single most important skill for product managers."
To paraphrase/summarize: the job of the product manager is to discover a product that is useful, feasible, and valuable. They do this through understanding users and potential users in detail and evaluating opportunities to solve problems for those users. Once an opportunity is identified, they create a prototype, validate the prototype with users, then work with engineering to build the product, product marketing to launch the product, and sales and support to follow up on the success (or failure) of the product.
The book covers how product management fits in with other functions -- engineering, interaction design, visual design, project management, product marketing. The difference between product management and product marketing is often misunderstood, but Inspired explains it simply: product marketing is about understanding the marketplace (in aggregate), how your product fits into that, and how to explain it when it comes time to launch. Product management is about the content of the product -- understanding the users/customers (individually), how the product works, what it is for. Creating a product and explaining a product to the world require two very different skillsets that are rarely found in the same person.
There's also a great chapter on how to "manage up," meaning how to work most effectively with your manager.
Some excerpts and points:
- "Engineers think in terms of implementation models, but users think in terms of conceptual models."
- You need "one product manager for every 5 - 10 engineers," one interaction designer for every two product managers, and one visual designer for every four interaction designers.
- "As a product manager, you are responsible for defining the right product, and your engineering counterpart is responsible for builidng the product right."
- "Keep the focus on minimal product. Your job as product manager is not to defin the ultimate product, it's to defint he smallest possible product that will meet your goals."
- While most work the engineering teams do comes from product, engineering teams should reserve some amount of time (the author used 20% when he worked at eBay) for refactorings, rearchitecting, and other internal technical changes that are unrelated to product.
- Great product people may already exist in your organization if you look around. The author suggests that they often come from engineering.
- Product managers should be passionate and evangelize internally. They "inspire the rest of the product team, and the passion for a product is contagious."
- Empathize with your target market, but don't slip into the trap of thinking of yourself and your friends as being the target users, even if it's partially true. Related: "It can be dangerous for a product manager to have too much domain expertise, because they believe they can speak for the target customer, and that they are more like their target customer than they really are."
- Engineering knows what's possible, so they are an important input to the product discovery process.
- Product marketing knows of broad unaddressed needs in the marketplace, making them another important input to product opportunities.
- Good revenue vs bad revenue: the former enhances your Net Promoter Score and expands your market, the latter does the opposite -- for example, adding customized features for one banner customer, what the author calls "specials."
- Product management should be a top-level organization, not placed as a subset of engineering or marketing (two common org structures). The design team can be part of the product org.
- "Conduct the real meetings before your official meeting." Get buy-in from key stakeholders beforehand. "The formal meeting still has an important purpose, which is for every at the table to see that everyone else is on board."
- "Opportunities for new products exist all around us, in every market -- even mature markets. This is because what is possible is always changing."
- Product should always be working well-ahead of engineering, to keep engineering teams fed with new work when they finish their current projects.
- "Review the business performance of products that have launched, typically 3 - 6 months post-launch. This sort of accountability will help the council better understand which investments and decisions they made were good ones, and why."
- The author strongly favors high-fidelity prototypes (e.g., they look like the real thing, not a rough paper mockup) as they are cheap to create nowadays and give better results when validating the prototype with users. High-fidelity prototypes are also great for engineering teams, because it's extremely clear what needs to be implemented.
- On the importance of reference customers at launch time: "Potential customers need to know that this product really works for people like them."
- Building a customer advisor board of charter around six customers will help in the feedback process for a new product, and also provides real customer references at launch time. Think of these charter users as development partners, and treat them as colleagues.
- "Winning products come from the deep understanding of the user's needs combined with an equally deep understanding of what's just now possible."
- Use "personas," archetypes of an imaginary but plausible user that describes a particular customer segment you're targeting.
- If there are technical feasibility risks (e.g., something that might be hard or impossible for engineerings to implement), get with an engineer to address them early, during the prototype phase.
- Do your own user testing, ideally in person.
- Take care to avoid accidental "user abuse" -- surprising changes in your product, especially ones that create incompatibilities. Even releases too many changes in too short a time period ("change fatigue") can be a type of user abuse.
- "As a general rule, users don't like change. Sure, they want the software to be great, and they clamor for new functionality, but most people aren't excited about taking the time to learn a new way to do something they can already do."
- The author describes what he calls "gentle deployment," which is a way to cautiously and respectfully roll out changes to a large usercase. This includes techniques such as rolling out both the old and new versions alongside each other, with a link somewhere inviting users to try out the new version, long before the new version becomes the default.
- Make sure to reserve product, engineering, and design resources to follow up on feedback in the week or so following a big product or feature launch.
- Great ideas almost always come from the bottom up, not top-down product strategy. Use techniques like Google's 20% time or skunkworks teams to encourage this.
- "Build relationships before you need them."
- On working in large organizations: "Pick something worth fighting for, where the outcome truly matters. When you do fight, make sure you're fighting for your product and not against another person." And: "Triage your meetings ruthlessly." And: "Evangelize! Explain the vision and strategy, demo the prototype, and share customer feedback. Don't underestimate the importance of this internal sales function."
- "Knowing how to get feedback on product ideas is probably the single most important skill for product managers."
February 1, 2014
I'm embarrassed to say I hadn't read this book until today. I's pretty a concise summary of all the other articles, books, and conversations that I've had in the field. You could probably save a lot of time by reading this book when you're first interested in PM, rather than after doing it for four years. (But re-read it then, too!)
I particularly liked that he discussed:
- Clear definition of role separation and responsibilities of marketing, PM, interaction design, development.
- The emphasis on the "Product Discovery" process. I think people underestimate how much of PM is a researching/incubating ideas role. You spend a lot of time sorting through information and considering what is/isn't relevant.
- The need for high fidelity prototypes. If I had to pick a single skill that would make me a better PM, being able to quickly produce a prototype would be it.
- Ways to do small usability tests as a PM. I think there's a lot of pushback from this in the industry - lots of people worry the PM can't detach / research will be useless. There's a lot to be said for small amounts of research.
- Discussion of "how to build a PM team" - I think he's completely right that there are often people throughout companies with the right skills (and attention to detail).
- Dealing with special requests from clients (and the hidden costs of those requests). I'd recommend it to anyone who is struggling with a few major customers, and has a CEO that wants to accommodate special requests. I've never personally had this challenge, but he seemed to have practical advice.
I particularly liked that he discussed:
- Clear definition of role separation and responsibilities of marketing, PM, interaction design, development.
- The emphasis on the "Product Discovery" process. I think people underestimate how much of PM is a researching/incubating ideas role. You spend a lot of time sorting through information and considering what is/isn't relevant.
- The need for high fidelity prototypes. If I had to pick a single skill that would make me a better PM, being able to quickly produce a prototype would be it.
- Ways to do small usability tests as a PM. I think there's a lot of pushback from this in the industry - lots of people worry the PM can't detach / research will be useless. There's a lot to be said for small amounts of research.
- Discussion of "how to build a PM team" - I think he's completely right that there are often people throughout companies with the right skills (and attention to detail).
- Dealing with special requests from clients (and the hidden costs of those requests). I'd recommend it to anyone who is struggling with a few major customers, and has a CEO that wants to accommodate special requests. I've never personally had this challenge, but he seemed to have practical advice.
January 26, 2016
Picked up this book after a great review in Economic Times. The content is very disappointing to say the least. The author has missed on several key responsibilities and challenges of product management and has only penned a theoretical and ideal world description. The book does not talk in examples and almost sounds like a boring lecture. Not for beginners and surely not for veterans either. Disappoint s.
June 18, 2013
Inspired is pretty high level and tends to focus more on the organizational challenges related to product development. I feel that there are some better resources out there (especially online blogs) if you as a product manager are looking for strong guidance at a more tactical level. Although, the SVPG website has some useful resources. I kept putting off reading this book, and after having experienced the growing pains as a PM and other major organizational transitions, most of the insights the book had to offer I had already learned the hard way. So if you think you’re like me, I wouldn’t beat yourself up for not having read it. However, the book was still a pleasant read and is filled with healthy reminders on the critical role of a product manager and proper perspectives on developing winning products.
April 15, 2019
It wouldn't be so sexy or approved by the marketing department, but a more accurate name for this book would be "Product Management 101". Recommended.
July 11, 2019
I don't know but the content seems to be dated.
Examples:
>> Once you've validated a product and delivered the specifications to engineering, you must make a fundamental mindset shift from product discovery to execution.
>> There should be no further changes to the product specifications after this.
1. This clear distinction between discovery and delivery seems very old thinking to me.
2. When do we write the specification?
3. No further changes to the product spec after this?
4. Lots of dedicated roles are mentioned in the book. I have seen successful products launch without all these roles.
---
>> To allow her UX design team to fully contribute, a product manager must let them complete their work before tasking engineers with building the product.
5. "tasking engineers" seems like telling them what to do. This is against Marty's usual approach to work on a strong vision and empower the teams.
---
>> This is because good designers want to experiment with multiple designs, but the engineering process is not agile enough to facilitate this.
6. Maybe it is now in 2019?
---
>> Use high-fidelity prototypes to convey product specs effectively and to test your product on real users.
7.
High-fidelity prototypes answer: "Can and would you use this".
High-fidelity prototypes don't answer: "Would you pay money for this" <-- Harder and more important question to answer.
This is a new concept and missing in that book
Examples:
>> Once you've validated a product and delivered the specifications to engineering, you must make a fundamental mindset shift from product discovery to execution.
>> There should be no further changes to the product specifications after this.
1. This clear distinction between discovery and delivery seems very old thinking to me.
2. When do we write the specification?
3. No further changes to the product spec after this?
4. Lots of dedicated roles are mentioned in the book. I have seen successful products launch without all these roles.
---
>> To allow her UX design team to fully contribute, a product manager must let them complete their work before tasking engineers with building the product.
5. "tasking engineers" seems like telling them what to do. This is against Marty's usual approach to work on a strong vision and empower the teams.
---
>> This is because good designers want to experiment with multiple designs, but the engineering process is not agile enough to facilitate this.
6. Maybe it is now in 2019?
---
>> Use high-fidelity prototypes to convey product specs effectively and to test your product on real users.
7.
High-fidelity prototypes answer: "Can and would you use this".
High-fidelity prototypes don't answer: "Would you pay money for this" <-- Harder and more important question to answer.
This is a new concept and missing in that book
February 23, 2015
tl;dr - products need prototypes, are grounded in answering emotions, and can always be improved.
Product management starts with this book. If you want be one, start here, then go find something that talks about the products in your field of interest, or describes the process by which you get yourself hired, or the way you raise capital to fund your own product. But, start here to learn what it means to build a product quickly and successfully.
Not that you're guaranteed success. Especially when you're working for somebody else, your ability to drive a product from an Idea to a Sale is going to require negotiation with every other part of the business. Most people are used to thinking that the idea in their head is the idea that will get delivered, even though there are a dozen people working on the product. And most companies aren't actually committed to the idea of having a person who owns the Idea of a product, allowing the role to be implied by a project manager or chief architect or lead engineer.
It's clear this is a book that was built from blog posts, because there's some repetition of phrasing which made me wonder if I'd misplaced my bookmark. Normally that feels like sloppy editing, but here it felt like a successful lecturer who returns to a few key phrases to remind you of the previous point and how it aligns with this next one.
I wish I'd read this book a year ago. It answers 90% of the questions I had at the time, long before I acquired the title of "product manager."
Product management starts with this book. If you want be one, start here, then go find something that talks about the products in your field of interest, or describes the process by which you get yourself hired, or the way you raise capital to fund your own product. But, start here to learn what it means to build a product quickly and successfully.
Not that you're guaranteed success. Especially when you're working for somebody else, your ability to drive a product from an Idea to a Sale is going to require negotiation with every other part of the business. Most people are used to thinking that the idea in their head is the idea that will get delivered, even though there are a dozen people working on the product. And most companies aren't actually committed to the idea of having a person who owns the Idea of a product, allowing the role to be implied by a project manager or chief architect or lead engineer.
It's clear this is a book that was built from blog posts, because there's some repetition of phrasing which made me wonder if I'd misplaced my bookmark. Normally that feels like sloppy editing, but here it felt like a successful lecturer who returns to a few key phrases to remind you of the previous point and how it aligns with this next one.
I wish I'd read this book a year ago. It answers 90% of the questions I had at the time, long before I acquired the title of "product manager."
May 18, 2019
This book has been a wake up call.
It presents a unified philosophy of what the job of a product manager is and how to do it well. It covers who the people should be, how the product should be built, what the process should be and what is the right culture. The book is structured into 67 short chapters and can be consumed in small bites or long binges. The style is concise and to the point.
I can't overstate how eye-opening it was. The role of the product management has always been slightly weird for me and I've often been slightly surprised what people in it do. Now it's starting to make sense, and I'm realizing how some of my past approaches have been counterproductive to building a great product. I feel fairly versed in Agile methodologies, but in some cases I've not managed to implement them to my satisfaction, without understanding why. This book gave me answers.
In short, it was amazing. I definitely learned a lot and picked many things that I can start applying to my job. Will definitely reread it soon.
It presents a unified philosophy of what the job of a product manager is and how to do it well. It covers who the people should be, how the product should be built, what the process should be and what is the right culture. The book is structured into 67 short chapters and can be consumed in small bites or long binges. The style is concise and to the point.
I can't overstate how eye-opening it was. The role of the product management has always been slightly weird for me and I've often been slightly surprised what people in it do. Now it's starting to make sense, and I'm realizing how some of my past approaches have been counterproductive to building a great product. I feel fairly versed in Agile methodologies, but in some cases I've not managed to implement them to my satisfaction, without understanding why. This book gave me answers.
In short, it was amazing. I definitely learned a lot and picked many things that I can start applying to my job. Will definitely reread it soon.
January 7, 2022
Some insights. But did it need that many words? Absolutely not
September 28, 2021
For context, I read this book after more than 1.5 years of being a product manager, so I'm familiar with most of the concepts mentioned in the book.
I think of this book as a reminder for me of all the challenges revolving around a PM, from working with stakeholders, implementing product discovery (instead of the feature-based roadmap), to testing the products. The fact that it's written by someone who has undergone almost all steps in the SDLC and also has closely observed the great PMs from giant companies gives me more confidence that those challenges are real and should be taken into serious consideration.
If you're starting out on a PM career path, this book will be a good guide. It lays out all the concepts for you to do more research later on. If you're like me with some hands-on experience, this book will be a good companion during your holidays or weekends.
*Personal opinion:* I keep one star from the review because this book largely touches on B2C products, and leaves out B2B ones. All the techniques and challenges mentioned in the book are highly relevant with tonnes of data and a huge pool of users to test/discover ideas, but might not necessarily be true/easy to implement for products that involve pro-longed sales cycles and lots of stakeholders from the customer side.
I think of this book as a reminder for me of all the challenges revolving around a PM, from working with stakeholders, implementing product discovery (instead of the feature-based roadmap), to testing the products. The fact that it's written by someone who has undergone almost all steps in the SDLC and also has closely observed the great PMs from giant companies gives me more confidence that those challenges are real and should be taken into serious consideration.
If you're starting out on a PM career path, this book will be a good guide. It lays out all the concepts for you to do more research later on. If you're like me with some hands-on experience, this book will be a good companion during your holidays or weekends.
*Personal opinion:* I keep one star from the review because this book largely touches on B2C products, and leaves out B2B ones. All the techniques and challenges mentioned in the book are highly relevant with tonnes of data and a huge pool of users to test/discover ideas, but might not necessarily be true/easy to implement for products that involve pro-longed sales cycles and lots of stakeholders from the customer side.
June 2, 2020
Overall: Maybe worth a skim for a new Product Manager.
The title "Inspired, how to create tech products customers love," does not align with the content. This book tells you how to be a product manager and talks nothing about building great products (aside from repeatedly mentioning to "talk to customers"). A better title would be "High level advice on being a Product Manager at a large internet company"
There is a lot of generic guidance on how to product manage in large scale consumer/enterprise internet companies. However, it is completely devoid of examples and reads more like a list of lessons. In the absence of examples, I found it hard to internalize most of the lessons in this book, except if I had directly experience in the matter.
The lessons are sound, I guess -- nothing ground-breaking or strongly opinionated. There's not a lot of tactical wisdom you can walk away with from the book, nor does it help you navigate the most difficult part of being a PM (working with colleagues, stakeholders, customers, etc). Also, its not as relevant if you're a PM at a small company or in government.
The title "Inspired, how to create tech products customers love," does not align with the content. This book tells you how to be a product manager and talks nothing about building great products (aside from repeatedly mentioning to "talk to customers"). A better title would be "High level advice on being a Product Manager at a large internet company"
There is a lot of generic guidance on how to product manage in large scale consumer/enterprise internet companies. However, it is completely devoid of examples and reads more like a list of lessons. In the absence of examples, I found it hard to internalize most of the lessons in this book, except if I had directly experience in the matter.
The lessons are sound, I guess -- nothing ground-breaking or strongly opinionated. There's not a lot of tactical wisdom you can walk away with from the book, nor does it help you navigate the most difficult part of being a PM (working with colleagues, stakeholders, customers, etc). Also, its not as relevant if you're a PM at a small company or in government.
February 27, 2017
Possibly one of very few books actually written all about Product Management, and it's a good one. I love how it starts with a bunch of things that people think are Product Management but which aren't. I also like the simple framework and definition of PM around valuable+useable+feasible, and how he builds up detail on achieving those qualities through the book. Got a bit dry as it came towards the end, but was a good length. Highly recommend for anyone in or thinking of moving into PM.
May 15, 2020
Высокоуровневый взгляд на работу продакта. Концептуальная книжка, с уклоном в идеологию продуктовой работы. В целом рассчитана на средние и крупные компании и задачи их уровня. Стоит прочитать в общем-то всем, хотя книга написана давно, а изменения быстрые
August 2, 2020
In the last few weeks I kept asking other product leaders what book they thought I should read to learn about product management. If I were to make a histogram of the responses, you’d need a magnifying glass to see what the other books than this one were.
Inspired is an easy read with lots of valuable advice. Cagan is a big fan of spelling out lists (here are the X things you need to consider for Y). I am an engineer who likes to put thoughts into boxes and order and reorder them until they fit, so hooray for a good list.
Most of them are very well-thought through and insightful. They will probably both make you sound smart if you parrot them to someone else and (more importantly) actually help you if you try to put them into practice. Only on a few occasions did I stumble over a list that was not MECE and felt lazily put together, that, if you ask me, Cagan could have just as well left out of the book with none the worse for it.
My two favorite lists in the book are the following.
The four product risks (a major theme in the book):
- Usability Risk
- Value Risk
- Feasibility Risk
- Business Viability Risk
The most important principles behind the “Lean” and “Agile” buzzwords:
- Tackle risks up front rather than at the end
- Define and design products collaboratively
- Focus on outcome over output
Inspired is an easy read with lots of valuable advice. Cagan is a big fan of spelling out lists (here are the X things you need to consider for Y). I am an engineer who likes to put thoughts into boxes and order and reorder them until they fit, so hooray for a good list.
Most of them are very well-thought through and insightful. They will probably both make you sound smart if you parrot them to someone else and (more importantly) actually help you if you try to put them into practice. Only on a few occasions did I stumble over a list that was not MECE and felt lazily put together, that, if you ask me, Cagan could have just as well left out of the book with none the worse for it.
My two favorite lists in the book are the following.
The four product risks (a major theme in the book):
- Usability Risk
- Value Risk
- Feasibility Risk
- Business Viability Risk
The most important principles behind the “Lean” and “Agile” buzzwords:
- Tackle risks up front rather than at the end
- Define and design products collaboratively
- Focus on outcome over output
February 7, 2019
One of the best books I have read in a while. It got me thinking about a lot of stuff that’s going on in our industry and it also helped me bridge the gap in my transition from a company oriented on providing services to clients to a company owning their own product and oriented towards keeping their customers happy and improving their product. Although I am not a Product Manager (which is the main intended audience), I would say that I am at the best point in my career to have read this book and would recommend it to anyone working on a tech product.
September 12, 2018
The best book on Product Management I've ever read. Not only you get a depth and years of experience and wisdom in your hand, but it's also so incredibly well structured! Definitely will come back to this book again and again. Must read for a PM.
March 30, 2016
The information in the book was good and useful to learn how things work or should work on a product team, but the delivery was a little slow and dry.
September 9, 2020
Some useful bits. But mostly a disconnected collection of best PM practices.
April 15, 2022
im a product genius now
Read
February 20, 2022No le pongo nota porque es un libro que no me interesa lo más mínimo, lo leí por mi trabajo y yo que sé, puede ser útil y tal para gente que trabaja en productos tecnológicos (sobre todo para Product Managers, CEOs y gente en posiciones más altas). Pero personalmente, aunque creo que tiene ideas interesantes, la filosofía del autor no me convence. Lo de tener que trabajar infinitas horas, estar enamorado del producto que vende tu empresa etc. me parece estúpido. Yo trabajo para tener dinero para hacer lo que me de la gana. No vivo para mi empresa ni lo haré nunca.
April 14, 2020
Really great book! It presents what's to be a Product Manager/Owner and how to do it well. It describes the whole puzzle in a product company, starting from the VPs, going through the engineers and designers and finishing with the product manager(s), marketing and sales departments.
There are several key points but the most vital one is to create a high-fidelity prototype, defining your customer personas and start talking and interviewing your customers/early-adopters.
It's important to mention here the role of the people's emotions, the different types of customers like Lovers, Irrationals and etc., and how the Product Manager could take an advantage of them. It's like the theory from "Crossing the Chasm" book, but instead of grouping them using the terms like Early-Adopters and etc, we are looking at them of the emotional state of their adoption of technology.
Overall, I would say it's a must-read for everyone who wants to become a Product Manager/Owner and/or want to improve his skills and abilities. However, I'm not very convinced it would be very helpful for startup owners and entrepreneurs.
There are several key points but the most vital one is to create a high-fidelity prototype, defining your customer personas and start talking and interviewing your customers/early-adopters.
It's important to mention here the role of the people's emotions, the different types of customers like Lovers, Irrationals and etc., and how the Product Manager could take an advantage of them. It's like the theory from "Crossing the Chasm" book, but instead of grouping them using the terms like Early-Adopters and etc, we are looking at them of the emotional state of their adoption of technology.
Overall, I would say it's a must-read for everyone who wants to become a Product Manager/Owner and/or want to improve his skills and abilities. However, I'm not very convinced it would be very helpful for startup owners and entrepreneurs.
July 23, 2018
4.5-5 stars
Don't mind the terrible title, this is a truly decent book on product management or even better - product-focused organizations.
Pros:
1. Marty himself - not an anonymous person, some sort of guru for angel investors, very credible; I've met him ~3 yrs ago in Budapest & he made a great impression of a person who clearly knows what he's speaking about
2. no bullshit -> short, focused chapters, each one with a clear point, without lengthy digressions & drifting around
3. this book doesn't try to depict ephemeral, passion-related aspects of product development - quite the contrary: it's very practical, easy to understand and map onto your organisation
4. it's an updated version of the original "Inspired" - I haven't read the 1st ed, but this one doesn't feel outdated at all, so I guess it has been significantly re-written
Really good stuff, maybe not a full compendium of product development, but truly a decent introduction to the topic. For me it was very refreshing, even keeping in mind I don't consider myself a beginner in that topic.
Don't mind the terrible title, this is a truly decent book on product management or even better - product-focused organizations.
Pros:
1. Marty himself - not an anonymous person, some sort of guru for angel investors, very credible; I've met him ~3 yrs ago in Budapest & he made a great impression of a person who clearly knows what he's speaking about
2. no bullshit -> short, focused chapters, each one with a clear point, without lengthy digressions & drifting around
3. this book doesn't try to depict ephemeral, passion-related aspects of product development - quite the contrary: it's very practical, easy to understand and map onto your organisation
4. it's an updated version of the original "Inspired" - I haven't read the 1st ed, but this one doesn't feel outdated at all, so I guess it has been significantly re-written
Really good stuff, maybe not a full compendium of product development, but truly a decent introduction to the topic. For me it was very refreshing, even keeping in mind I don't consider myself a beginner in that topic.
January 23, 2019
I wish it could have added more information about how to build the products. This book basically (most of the pages) talk about how to build teams, hire right people and other backoffice related information rather than focusing much on customer mindset, product life cycle, discovery, applying market research etc.
April 24, 2019
I'm frustrated with myself that I didn't read this many moons ago. This is the book for you if you are:
- An aspiring product manager
- Work with product managers (e.g. you're a software engineer or designer)
- You're building out a product team
- You are interested in how modern tech teams structure themselves
- An aspiring product manager
- Work with product managers (e.g. you're a software engineer or designer)
- You're building out a product team
- You are interested in how modern tech teams structure themselves
August 25, 2020
A must read for anyone involved in building digital products, not only Product Managers but also software engineers, tech leads, team leaders, engineering managers and so on. For every reading session I had lots of insights to share with our team!
June 30, 2022
Excellent book for some work o am doing. Easy to follow and a lot of sound ideas. I will be referring back to this one frequently.
January 16, 2023
This was a requirment where I work and I loved it.
July 26, 2022
Started this when I was interviewing and found it very useful to learn more about product and product culture. One of those practical, easy to digest business-y books that I’m sure I will come back to.
January 30, 2022
I can't help laughing every time the book says "you should check feasibility with your engineers but most of the time they have already done something similar". Sounds like a software engineer is just doing repeated work?
Very nice ideas and instructions on how what things tech company should be working on though.
Very nice ideas and instructions on how what things tech company should be working on though.
November 30, 2021
One of the best books ever on product management: simple ans actionable handbook. Worth reading!
Displaying 1 - 30 of 1,391 reviews