More on this book
Community
Kindle Notes & Highlights
way: It doesn't matter how good your engineering team is if they are not given something worthwhile to build.
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.
product roadmaps. I've seen countless roadmaps over the years, and the vast majority of them are essentially prioritized lists of features and projects.
two inconvenient truths about product. The first truth is that at least half of our ideas are just not going to work.
the second inconvenient truth is that 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.
engineering gets brought in way too late.
engineers are typically the best single source of innovation; yet, they are not even invited to the party in this process.
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.
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. In modern teams, we tackle these risks prior to deciding to build anything.
Finally, it's all about solving problems, not implementing features.
We need teams of missionaries, not teams of mercenaries.
she thinks she should be hiring someone in her own image—or at least visionary like her. The result is typically an immediate clash and a short tenure for the VP product.
VP product needs to complement the CEO.
The hallmark of a great CTO is a commitment to continually strive for technology as a strategic enabler for the business and the products. Removing technology as a barrier, as well as broadening the art of the possible for business and product leaders, is the overarching objective. To that end, there are six major responsibilities of a CTO. We present them
looking at development plans for all the employees, the retention rate, and the evaluation of the managers
rapidly, reliably, and repeatedly deliver quality product to market.
CTO is the orchestrator of a company‐wide technology strategy.
we measure outages that impact our customers that are due to infrastructure or architectural issues.
senior engineering staff are participating actively and contributing significantly throughout product discovery.
In growth‐stage and enterprise companies, many product managers complain that they have to spend far too much of their time doing project management activities.
One of the most difficult issues facing every product organization at scale is just how to split up your product across your many product teams.
I always explain to them that there is no recipe. Instead, there are some critical core principles, and the key is to understand those principles and then weigh the options for your particular circumstances.
Some people like the three horizons model, while others take more of a portfolio management approach. The
A big goal is to minimize dependencies.
we want teams of missionaries and not teams of mercenaries.
it's really difficult for one product manager and product designer to keep more than about 10–12 engineers busy with good stuff to build.
Architectures drive technologies, which drive skill sets.
First, the teams feel like they are constantly fighting the architecture. Second, interdependencies between teams seem disproportionate. Third, and really because of the first two, things move slowly, and teams don't feel very empowered.
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 a...
This highlight has been truncated due to consecutive passage length restrictions.
reviewing your team structure every year or so makes sense.
true sense of ownership when teams feel more in control of their own destiny.
investing in a high‐leverage foundation.
One of the absolute hardest assignments in our industry is to try to cause dramatic change in a large and financially successful company.
focusing on outcome and not output. Realize that typical product roadmaps are all about output. Yet, good teams are asked to deliver business results
multi‐team efforts often called initiatives
Sometimes customers just aren't as excited about this idea as we are, so they choose not to use it or buy it (the value isn't there). This is the most common situation. Sometimes they do want to use it, and they try to use it, but it's so complicated that it's simply more trouble than it's worth, which yields the same result—the users don't use it (the usability isn't there). Sometimes the issue is that the customers might have loved it, but 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
...more
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. This is often referred to as time to money
product discovery as the most important core competency of a product organization.
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.
high‐integrity commitment
we need to solve the underlying problem, not just deliver a feature.
The difference is that they are now prioritizing business results, rather than product ideas.
high‐integrity commitments, used for those situations where we need to commit to a date or a specific deliverable.
each item is stated as a business problem to solve rather than the feature or project that may or may not solve it. These are called outcome‐based roadmaps
product teams are stepping up to solve business problems rather than build features. Outcome‐based roadmaps are essentially equivalent to using a business objective–based system such as the OKR system. It's the format that's different more than the content.
roadmaps to put a deadline date on every item, rather than only on the items with a true date constraint.
The difference between vision and strategy is analogous to the difference between good leadership and good management. Leadership inspires and sets the direction, and management helps get us there
