More on this book
Community
Kindle Notes & Highlights
by
Marty Cagan
Started reading
May 22, 2025
The reality of startup life is that you're in a race to achieve product/market fit before you run out of money.
While money and time are typically tight, good startups are optimized to learn and move quickly, and there's normally very little bureaucracy to slow them down.
In any case, one of the most critical lessons in product is knowing what we can't know, and we just can't know at this stage how much money we'll make.
(By the way, the really good teams assume that at least three quarters of the ideas won't perform like they hope.)
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.
Unfortunately, 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.
Risks are tackled up front, rather than at the end. In modern teams, we tackle these risks prior to deciding to build anything. These risks include 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.).
They must ensure that solution solves the underlying problem.
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?
This means the necessary scale, performance, reliability, fault tolerance, security, privacy, internationalization, and localization have been performed, and the product works as advertised.
product/market fit. This is the smallest possible actual product that meets the needs of a specific market of customers.
The MVP should be a prototype, not a product.
prototypes being used in discovery and products being produced in delivery.
“We need teams of missionaries, not teams of mercenaries.” Mercenaries build whatever they're told to build. Missionaries are true believers in the vision and are committed to solving problems for their customers.
In a dedicated product team, the team acts and feels a lot like a startup within the larger company, and that's very much the intention.
Team Empowerment and Accountability A big part of the concept of product teams is that they are there to solve hard problems for the business. They are given clear objectives, and they own delivering on those objectives. They are empowered to figure out the best way to meet those objectives, and they are accountable for the results.
the full team understands—needs to understand—the business objectives and context. And most important, the full team feels ownership and responsibility for the outcome.
the product manager must also be an undisputed expert on your actual product.
This means knowing who your various stakeholders are and especially learning the constraints they operate under.
This is one of the big reasons why it is not enough to have feature parity with a competitor. Rather, you need to be substantially better to motivate a user or customer to switch.
deep knowledge (1) of your customer, (2) of the data, (3) of your business and its stakeholders, and (4) of your market and industry.
How will customers first learn about the product? How will we onboard a first‐time user and (perhaps gradually) reveal new functionality? How might users interact at different times during their day? What other things are competing for the user's attention? How might things be different for a one‐month‐old customer versus a one‐year‐old customer? How will we motivate a user to a higher level of commitment to the product? How will we create moments of gratification? How will a user share his experience with others? How will customers receive an offline service? What is the perceived
...more
They've been able to get away with this, however, because the user is so often not the customer—the one that buys.
Encourage your designer to iterate early and often. The best way you can encourage this is to not get all nitpicky about design details with the very early iterations. More generally, encourage your designer to feel free not to just iterate on the particular design approach but to explore alternative solutions to the problem.
We need a product that our customers love, yet also works for our business. However, a very large component of what is meant by works for our business is that there is a real market there (large enough to sustain a business), we can successfully differentiate from the many competitors out there, we can cost‐effectively acquire and engage new customers, and we have the go‐to‐market channels and capabilities required to get our product into the hands of our customers.
qualitative learning, some of our research is generative, which is understanding the problems we need to solve;
and some of our research is evaluative, which is assessing how well our solutions solve the problem.
If projects are constantly getting stuck because product managers don't understand the implications of their decisions or product managers are constantly asking developers to look at the code to tell them how the system really works, then you're probably missing a principal product manager.
And if your software is a big mess of spaghetti and it takes forever to make even simple changes, you're probably suffering from significant technical debt.
Second, you should always be trying to develop more of these people, and each of them should have at least one person they're working to develop into a strong second.
I know a few organizations that have tried hard to achieve this, but I have never seen this succeed. The systems always seem to grow in complexity and size much faster than anyone can document, and with software, the definitive answer always lives in the source code itself (at least the current answer—not usually the rationale or the history).
The single most important responsibility of any VP product is to develop a strong team of product managers and designers.
Realize that developing great people requires a different set of skills than developing great products,
For this position, you need to ensure you hire someone who has proven ability to develop others. They should have a track record of identifying and recruiting potential talent, and then working actively and continuously with those people to address their weaknesses and exploit their strengths.
Good product organizations have a strong team, a solid vision, and consistent execution. A great product organization adds the dimension of a strong product culture.
A strong product culture means that the team understands the importance of continuous and rapid testing and learning. They understand that they need to make mistakes in order to learn, but they need to make them quickly and mitigate the risks.
their primary product responsibility: ensuring that the engineers have a product worth building.
A big goal is to minimize dependencies. This helps teams move faster and feel much more autonomous.
Some level of interdependencies will always chip away at the sense of ownership.
As organizations grow, we often find common needs and the increased importance of shared services. We do this for speed and reliability. We don't want every team reinventing the wheel. Realize, however, that creating shared services also creates dependencies and can impinge on autonomy.
strategy,
What is our (WW) strategy?
Architectures drive technologies, which drive skill sets.
For larger companies, especially, it's typical to have one or more teams that provide common services to the other product teams. We often label these teams common services, core services, or platform teams, but they primarily reflect the architecture. This is very high‐high leverage, which is why so many companies have these types of teams at scale. However, it is also a difficult type of team to staff because these teams are dependencies (by design) of all the other teams, as they are there to enable the other teams. Be sure to staff these common services teams with strong and highly
...more
Each product team can go very deep with their type of customers rather than have them try to learn about all types of customers.
Who are our "first" customer?
Some companies try to deal with this with the center of excellence concept in which leverage is focused on teams in a physical location. Others try stronger holistic roles. Yet others add process.
It is also important to acknowledge the role that an emphasis on autonomy versus leverage plays in team culture.
the users don't use it (the usability isn't there).
it turns out to be much more involved to build than we first thought, and we simply can't afford the time and cost to deliver (the feasibility isn't there).
The issue is that anytime you put a list of ideas on a document entitled “roadmap,” no matter how many disclaimers you put on it, people across the company will interpret the items as a commitment.
