More on this book
Community
Kindle Notes & Highlights
by
Marty Cagan
Read between
July 16 - September 30, 2022
We say if you're just using your engineers to code, you're only getting about half their value.
Unfortunately, projects are output and product is all about outcome. This process predictably leads to orphaned projects.
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.
Finally, while we're busy doing this process and wasting our time and money, the biggest loss of all usually turns out to be the opportunity cost of what the organization could have and should have been doing instead.
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.
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.
Another reason to have a deep understanding of the competitive landscape is that your products will need to fit into a more general ecosystem of other products, and ideally your product is not only compatible with that ecosystem but adds significant value to it.
UX is any way that customers and end users realize the value provided by your product.
All three situations are serious problems because they rarely provide good results.
We need design—not just as a service to make our product beautiful—but to discover the right product.
The single most important responsibility of any VP product is to develop a strong team of product managers.
Instead, there are some critical core principles, and the key is to understand those principles and then weigh the options for your particular circumstances.
The critical context is comprised of two things: The overall product vision The specific business objectives assigned to each team
To Lea, there was no such thing as over‐communication. A continuous stream of prototypes helped keep people excited about what this new future would bring.
One of the key themes of this book is focusing on outcome and not output. Realize that typical product roadmaps are all about output. Yet, good teams are asked to deliver business results.
If we can prototype and test ideas with users, customers, engineers, and business stakeholders in hours and days—rather than in weeks and months—it changes the dynamics, and most important, the results.
The key is to understand that the root cause of all this grief about commitments is when these commitments are made. They are made too early. They are made before we know whether we can deliver on this obligation, and even more important, whether what we deliver will solve the problem for the customer.
So, the compromise is straightforward. The product team asks for a little time to do product discovery before commitments are made, and then after discovery, we are willing to commit to dates and deliverables so our colleagues can effectively do their jobs as well.
You can do some amount of testing of the vision, but it's not the same as the testing of specific solutions we do in product discovery. In truth, buying into a vision is always a bit of a leap of faith. You likely don't know how, or even if, you'll be able to deliver on the vision. But remember you have several years to discover the solutions. At this stage, you should believe it's a worthwhile pursuit.
For most types of businesses, I encourage teams to construct product strategy around a series of product/market fits. There are many variations on this (the strategy for the product strategy, if you will).
In terms of prioritizing markets, all I said above was to prioritize your markets and focus on them one at a time. I didn't say how to prioritize them. There is no one right way to do this, but there are three critical inputs to your decision:
The first is market sizing, usually referred to as total addressable market (TAM). All things considered equal, we like big markets rather than small markets. But, of course, they're not equal. If the largest market would require two years of product work, yet several of the somewhat smaller but still significant markets are much closer in terms of time to market, most likely everyone in your company from the CEO and head of sales on down would prefer you to deliver on a smaller market sooner. The second factor concerns distribution, usually referred to as go to market (GTM). Different markets
...more
These are the 10 key principles for coming up with an effective product vision.
Start with why.
Fall in love with the problem, not with the solution.
Don't be afraid to think big with vision.
Don't be afraid to disrupt yourselves because, if you don't, someone else will.
The product vision needs to inspire.
Determine and embrace relevant and meaningful trends.
Skate to where the puck is heading, not to where it was.
Be stubborn on vision but flexible on the details.
Realize that any product vision is a leap of faith.
Evangelize continuously and relentlessly.
Obsess over customers, not over competitors. Too many companies completely forget about their product strategy once they encounter a serious competitor. They panic and then find themselves chasing their competitor's actions and no longer focusing on their customers. We can't ignore the market, but remember that customers rarely leave us for our competitors. They leave us because we stop taking care of them.
Product principles are not a list of features, and they are not tied to any one product release. The principles are aligned with the product vision for an entire product line. A good set of principles may inspire some product features, but it's more about what the company and product teams believe is important.
Senior management (CEO and executive team) is responsible for the organization's objectives and key results. The heads of product and technology are responsible for the product team objectives (and ensuring they deliver on the organization's objectives). The individual product teams are responsible for proposing the key results for each objective they've been assigned. It is normal to have a give‐and‐take process each quarter as the OKRs are finalized for each team and for the organization.
In summary, 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 what they are there to contribute.
First, discovering in detail what the customer solution needs to be. That includes everything from making sure there are enough customers that even need this solution (the demand) and then coming up with a solution that works for our customers and for our business.
Second, we need to ensure we deliver a robust and scalable implementation that our customers can depend on for consistently reliable value. Your team needs to be able to release with confidence. While you'll never have 100 percent confidence, you should not have to release and pray.
The purpose of product discovery is to address these critical risks: Will the customer buy this, or choose to use it? (Value risk) Can the user figure out how to use it? (Usability risk) Can we build it? (Feasibility risk) Does this solution work for our business? (Business viability risk) And it's not enough that it's just the product manager's opinion on these questions. We need to collect evidence.
We know we can't count on our customers (or our executives or stakeholders) to tell us what to build. Customers don't know what's possible, and with technology products, none of us know what we really want until we actually see it. It's not that customers or our executives are necessarily wrong; it's just that it's our job to make sure the solution we deliver solves the underlying problem. This is probably the most fundamental principle in all of modern product. Historically, in the vast majority of innovations in our industry, the customers had no idea that what they now love was even a
...more
The most important thing is to establish compelling value.
As hard and important as the engineering is, coming up with a good user experience is usually even harder, and more critical to success.
Functionality, design, and technology are inherently intertwined.
We expect that many of our ideas won't work out, and the ones that do will require several iterations.
We must validate our ideas on real users and customers.
Our goal in discovery is to validate our ideas the fastest, cheapest way possible.
We need to validate the feasibility of our ideas during discovery, not after.
We need to validate the business viability of our ideas during discovery, not after.
It's about shared learning.
