More on this book
Community
Kindle Notes & Highlights
This starts with a clear and compelling product vision, and the path to achieving that vision is the product strategy
product vision should be inspiring, and the product strategy should be focused
Prioritizing Markets
first is market sizing, usually referred to as total addressable market (TAM).
second factor concerns distribution, usually referred to as go to market (GTM).
third factor is a (very rough) estimation of how long it will take, referred to as time to market (TTM).
Fall in love with the problem, not with the solution.
Skate to where the puck is heading, not to where it was.
Be stubborn on vision but flexible on the details.
So many teams give up on their product vision far too soon. This is usually called a vision pivot
If you could truly validate a vision, then your vision probably isn't ambitious enough.
Evangelize continuously and relentlessly. There is no such thing as over‐communicating when it comes to explaining and selling the vision.
all corners of the company will at random times get nervous or scared about something they see or hear. Quickly reassure them before their fear infects others.
Obsess over customers, not over competitors.
but remember that customers rarely leave us for our competitors. They leave us because we stop taking care of them.
principles speak to the nature of the products you want to create
primary business objective management system we use is known as the OKR system—objectives and key results
two fundamental principles:
Patton quote I mentioned earlier: “Never tell people how to do things. Tell them what to do, and they will surprise you with their ingenuity.
“When performance is measured by results.”
The first principle is fundamentally about how to empower and motivate people to get them to do their best work, and the second is about how to meaningfully measure progress.
Key results should be a measure of business results, not output or tasks.
annually for an organization's objectives and quarterly for a team's objectives).
(one to three objectives, with one to three key results each is typical).
The objectives do not need to cover every little thing the team does, but they should cover what the team needs to accomplish
define a score of 0 (on a scale from 0 to 1.0) if you essentially make no progress, 0.3 if you just did the bare minimum—what you know you can achieve, 0.7 if you've accomplished more than the minimum and have really done what you'd hoped you would achieve, and 1.0 if you've really surprised yourselves and others with a truly exceptional result,
larger organizations to have on the order of 20 to 50 of these cross‐functional product teams,
OKRs become an increasingly necessary tool for ensuring that each product team understands how they are contributing to the greater whole, coordinating work across teams, and avoiding duplicate work.
is not very hard, but getting good results out of a medium—or, especially, large—organization can be truly challenging.
Moreover, at scale, it is very common to have some significant number of product teams that are there in support of the other product teams. These are often called platform product teams, or shared services product teams. They are very high leverage, but they are a little different in that they generally don't directly serve customers.
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.
Product evangelism is, as Guy Kawasaki put it years ago, “selling the dream.” It's helping people imagine the future and inspiring them to help create that future.
Absolutely be sincere, but let people see you're genuinely excited. Enthusiasm really is contagious.
Spend time with your team. If you're not spending significant face time with your designer and every engineer on your team, then they can't see the enthusiasm in your eyes.
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.
We need to learn fast, yet also release with confidence.
And, most important, it is something the team can release with confidence.
If you want to discover great products, it really is essential that you get your ideas in front of real users and customers early and often. If you want to deliver great products, you want to use best practices for engineering and try not to override the engineers' concerns.
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.
Today, we know that the technology drives (and enables) the functionality as much as the other way around.
“The most important thing is to know what you can't know.”
Discovery is about the need for speed.
We need to validate the business viability of our ideas during discovery, not after.
One of the keys to having a team of missionaries rather than a team of mercenaries is that the team has learned together. They
To set your expectations, teams competent in modern discovery techniques can generally test on the order of 10–20 iterations per week.
just human nature for people to think and talk in terms of solutions rather than the underlying problems.
to fall in love with the problem, not the solution
So much product work fails because it tries to please everyone and ends up pleasing no one.
Sean Ellis test.
