More on this book
Community
Kindle Notes & Highlights
by
Marty Cagan
Read between
December 3 - December 10, 2020
objectives, it is the responsibility of the leaders to decide which problems should be worked on by which product teams.
the strategy tells us which problems we need to solve, and the topology will imply which teams are best positioned to tackle each problem.
there is always what we call “keep‐the‐lights‐on” work involving fixing critical problems, responding to customer issues, providing assistance to other teams, technical debt work, and more.
else not expect anything beyond this overhead work, or they can look into ways of reducing this overhead burden. In the next chapter, we'll discuss one of the most important dimensions to a team objective, which is how
it's important to distinguish long‐term objectives from long‐term key results.
Having an objective that lasts for multiple quarters is not the least bit unusual or problematic.
A roof shot refers to a team being asked to be conservative and pursue lower‐risk, but also highly likely, tangible results.
a moon shot is when the team is asked to be very ambitious, such as going for a 10X improvement.
In all businesses there are occasional situations where something important must be delivered by a specific deadline date.
If you're used to conventional‐style Agile processes, you probably know that coming up with a high‐confidence date is very difficult if not impossible.
if you're used to the model of doing product discovery in parallel with product delivery, then you know that coming up with a high‐confidence date is not hard, so long as the company is willing to wait until the necessary product discovery work has been done before the date is provided (usually a few days).
High‐integrity commitments are intended for situations where you have an important external commitment or a very important and substantial internal commitment.
In some companies, the CTO must personally agree to each high‐integrity commitment because it is her reputation on the line.
empowered product teams are predicated on trust, and high‐integrity commitments are one of the important ways that product teams build trust with leadership.
high‐integrity commitments and deliverables should be the exception and not the rule.
shared team objective—when multiple teams share the same team objective.
This is especially common in the case of large, company initiatives, which are essentially problems large enough that they require help from many product teams.
Another form of shared team objective is when multiple teams temporarily combine their talents to solve a particularly hard problem.
In certain situations, the teams will co‐locate for a few days or a week in what is sometimes called a “swarm,” which is an intense, highly collaborative technique to dive deep together on either or both discovery and delivery work for a particularly challenging problem.
common objective—when multiple teams are asked to pursue the same problem, but each in their own way.
In this case, we may ask multiple teams to pursue the same problem and hope that at least one of those teams will be able to generate the necessary impact.
At a minimum, product teams stay on top of progress by discussing at weekly check‐ins where they are, what is upcoming, and where they might need help. These weekly team objective check‐ins are the key mechanism that teams use to track and manage their own progress.
First, the product manager specifically needs to communicate any important issues with her manager, so that the manager can have the chance to provide assistance where possible. Second, it's critical that each member of the product team get the ongoing coaching she needs to develop. And some of that coaching will pertain to the team objective‐related issues she faces.
alert management as early as possible in the event that there is a question as to the team's ability to deliver on a high‐integrity commitment.
if there is a dependency—such as on another product team—this dependency will need to be managed and tracked carefully.
it's also important to recognize that we will often need to help out our colleagues on other product teams, and we very likely have situations where we will depend on them helping us out as well.
when it comes to tech companies, we either all succeed, or none of us succeed. And it's not unusual to find yourself in the situation where you believe you must do something that's not in the best interest of your product team, but you see that it is in the best interest of the customer and of the broader organization.
The companion to empowerment is accountability.
accountability is directly related to ambition.
if the team was asked to be conservative (e.g., a roof shot), or even more important, if they were asked to make a high‐integrity commitment and they failed to deliver in this situation, then this is where accountability comes into play.
If a team fails substantially on their team objectives, then I encourage the team to treat this in much the same way we treat an outage.
These team objective postmortems are not fun for the team, but they are typically very constructive and helpful.
how would we hold teams accountable to results if many things are changing every day, and we don't know which changes by which teams are helping, which are hurting, and which make no difference? This is known as the product attribution problem,
The first, which depends on strong levels of traffic, is with an A/B test.
The second, which involves dividing up the various contributions to the relevant key result by channel or source, is referred to as slicing.
10 most important keys to effective team objectives:
The most important thing is to empower teams by assigning them problems to solve and then give the teams the space to solve them.
We love it when product teams volunteer to work on specific objectives, and we try to accommodate this when possible to leverage their motivation and enthusiasm for the problem.
deciding which team or teams works on each objective, is the explicit responsibility of product leadership.
the key results need to come from the team.
It's normal that there's a back and forth—not that the leaders doubt or question what the teams propose as their key results, but rather judging which investmen...
This highlight has been truncated due to consecutive passage length restrictions.
There is nothing wrong with assigning the same objective to multiple teams—each team tackling the problem from its own perspective and skills.
there is nothing wrong with asking multiple teams to collaborate on the same team objective.
For product teams to come up with key results, it's essential that they understand the level of ambition you want from them. We need to be clear with teams when we want them to be very ambitious (aka moon shot), when we want them to be conservative (aka roof shot), and when we need them to make a high‐integrity commitment.
Product teams can only be accountable to the results if they are empowered to figure out a solution that works and if they are the ones to come up with the key results.
The product leaders have to realize that while team objectives are critically important, they are not the only things that the product team is working on. Every team has some level of ongoing “keep‐the‐lights‐on” activities.
team objectives are created or updated every quarter.
There may be occasional situations where team objectives need to change during the quarter, but these should be the exception rather than the rule.
you don't have to choose between empathy and authority.
I needed to stop designing products in order to start designing a place where good design could happen. I had to design teams that could manage themselves.

