More on this book
Community
Kindle Notes & Highlights
by
Marty Cagan
Read between
October 27 - December 3, 2019
two inconvenient truths about product. The first truth is that at least half of our ideas are just not going to work. The first truth is that at least half of our ideas are just not going to work.
Risks are tackled up front, rather than at the end.
Products are defined and designed collaboratively, rather than sequentially.
Finally, it's all about solving problems, not implementing features.
It's about business results.
The purpose of product discovery is to quickly separate the good ideas from the bad. The output of product discovery is a validated product backlog.
The purpose of product delivery is to build and deliver these production‐quality technology products, something you can sell and run a business on.
So, we use prototypes to conduct rapid experiments in product discovery, and then in delivery, we build and release products in hopes of achieving product/market fit, which is a key step on the way to delivering on the company's product vision.
The MVP should be a prototype, not a product.
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.
To summarize, these are the four critical contributions you need to bring to your team: deep knowledge (1) of your customer, (2) of the data, (3) of your business and its stakeholders, and (4) of your market and industry.
The first inconvenient truth is that at least half of our product ideas are just not going to work.
the second inconvenient truth is that, even with the ideas that do prove to be valuable, usable, feasible, and viable, it typically takes several iterations to get the execution of this idea to the point where it delivers the expected business value that management was hoping for.
The product vision describes the future we are trying to create, typically somewhere between two and five years out.
The product strategy is our sequence of products or releases we plan to deliver on the path to realizing the product vision.
Be stubborn on vision but flexible on the details.
Focus on one target market or persona at a time.
If you deploy OKRs for your product organization, the key is to focus your OKRs at the product team level.
When using OKRs at scale, there's a larger burden on leadership and management to ensure that the organization is truly aligned, that each and every product team understands how they fit into the mix, and that they are there to contribute.
Customers don't know what's possible, and with technology products, none of us know what we really want until we actually see it.
the hardest part of all is creating the necessary value so that customers ultimately choose to buy or to use. We can survive for a while with usability issues or performance issues, but without the core value, we really have nothing. As a result, this is generally where we'll need to spend most of our discovery time.
One of the most common traps in product is to believe that we can anticipate our customer's actual response to our products.
I believe the major risk facing most efforts is value risk.
There are few things more powerful to a product organization than reference customers.
We are discovering and developing a set of reference customers in parallel with discovering and developing the actual product.
We don't want to turn on the sales or marketing machine until we have evidence that we can help them be successful, and the reference customers are our best evidence.
We are looking for prospective customers that truly feel the pain and are near desperate for the solution we want to build.
It's critical to explain to each prospective member of the program that your job is to come up with a general product
Your job is to dive deep with each of the six customers and identify a single solution that works well for all six customers.
if you find you are having real trouble recruiting even four or five prospective customers for this effort, then it's very possible you're chasing a problem that isn't that important, and you will almost certainly have a very hard time selling this product.
In product discovery, we're essentially trying to quickly separate the good ideas from the bad as we work to try to solve the business problems assigned to us.
One of the biggest possible wastes of time and effort, and the reason for countless failed startups, is when a team designs and builds a product, yet, when they finally release the product, they find that people won't buy it.
The most important point for technology companies: If you stop innovating, you will die.
While qualitative testing is all about fast learning and big insights, quantitative techniques are all about collecting evidence.
If the feature you're working on is to add PayPal as a payment method, and the reason is to increase conversion, then be sure to always show the current conversion rate and the result you're hoping to achieve. Most important, after the feature goes live, be sure to highlight the impact on that conversion rate.
Good teams have a compelling product vision that they pursue with a missionary‐like passion. Bad teams are mercenaries.
“Customers are always beautifully, wonderfully dissatisfied, even when they report being happy and business is great. Even when they don't yet know it, customers want something better, and your desire to delight customers will drive you to invent on their behalf.”
In an IT‐mindset organization, the product teams exist to serve the needs of the business. In contrast, in a product‐mind set organization, the product teams exist to serve the company's customers in ways that meet the needs of the business. The resulting differences between these mind sets are many and profound.
