Inspired: How to Create Tech Products Customers Love (Silicon Valley Product Group)

by Marty Cagan

Who decides what products we should build? How do they decide? How do they know that what we build will be useful?

It doesn't matter how good your engineering team is if they are not given something worthwhile to build.

I discovered that there was a tremendous difference between how the best companies produced products and how most companies produced them.

life is too short for bad products.

Strong tech‐product companies know they need to ensure consistent product innovation. This means constantly creating new value for their customers and for their business. Not just tweaking and optimizing existing products (referred to as value capture) but, rather, developing each product to reach its full potential.

The death of an enterprise company rarely happens overnight, and a large company can stay afloat for many years.

one of the most critical lessons in product is knowing what we can't know,

at least half of our ideas are just not going to work.

even with the ideas that do prove to have potential, it typically takes several iterations to get the implementation of this idea to the point where it delivers the necessary business value. We call that time to money.

if you're just using your engineers to code, you're only getting about half their value. The little secret in product is that engineers are typically the best single source of innovation; yet, they are not even invited to the party in this process.

projects are output and product is all about outcome.

The biggest flaw of the old waterfall process has always been, and remains, that all the risk is at the end, which means that customer validation happens way too late.

The key principle in Lean methods is to reduce waste, and one of the biggest forms of waste is to design, build, test, and deploy a feature or product only to find out it is not what was needed.

Risks are tackled up front, rather than at the end.

Products are defined and designed collaboratively, rather than sequentially.

In strong teams, product, design, and engineering work side by side, in a give‐and‐take way, to come up with technology‐powered solutions that our customers love and that work for our business.

it's all about solving problems, not implementing features. Conventional product roadmaps are all about output. Strong teams know it's not only about implementing a solution. They must ensure that solution solves the underlying problem. 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. Specifically, this means getting answers to four critical questions: Will the user buy this (or choose to use it)? Can the user figure out how to use this? Can our engineers build this? Can our stakeholders support this?

in the product world, we strive to achieve product/market fit. This is the smallest possible actual product that meets the needs of a specific market of customers.

while the P in MVP stands for product, an MVP should never be an actual product (where product is defined as something that your developers can release with confidence, that your customers can run their business on, and that you can sell and support). The MVP should be a prototype, not a product.