Product Managers, Coaches
We understand the reasons for our work.
Every team has a purpose: a reason for its existence and expectations about its output. But, far too often, that purpose isn’t communicated to the team. Instead, team members are told a lot of details about what to do…but not why they’re going to do it, or how it helps the company achieve its goals.
The Purpose practice is about making sure everyone understands the big picture, not just the details.
Before a product has a team, someone in the company has an idea. Suppose it’s someone in the Wizzle-Frobitz company. (Not a real company.) “Hey!” they exclaim, knocking their coffee off their desk. “We could frobitz the wizzles so much better if we had software to sort the wizzles first!”
Okay, it’s usually not that dramatic. The point is, a team’s purpose starts out as an idea focused on results. Sell more hardware by bundling better software. Attract bigger customers by scaling more effectively. Sell more cloud services by providing machine learning technology. These are all real examples from teams that I’ve worked with.
Somewhere in the transition from idea to team, the compelling part—the vision of a better future—often gets lost. Details crowd it out. You have to staff a team with programmers, domain experts, and UX designers. You have to define features, plan releases, and report on progress. Hustle, people, hustle!
That’s a shame, because nothing matters more than delivering the vision. If the goal is to sell more cloud services through machine learning, then even the most amazing machine learning product is no good unless it’s part of the cloud platform. If you’re scaling so you can attract bigger customers, you’ve got to make sure the way you scale fits with those new customers’ needs. Conversely, if you figure out a way to attract those customers that barely involves scaling at all, does it really matter how you did it?
The money for your team comes from somebody’s budget. They’re typically called the team’s executive sponsor. Although the sponsor technically has final say over the team’s purpose, it’s not always so cut and dry. They’re influenced by a variety of people, called key stakeholders, whose support is also necessary for your team to succeed.
Somebody has to unify all their ideas into a coherent purpose. They need to make sure the executive sponsor is enthusiastic about the purpose, the team understands it, key stakeholders agree with it, and other stakeholders accept it. As the “Whole Team” practice discusses, these skills are called “product management,” and at least one person who has those skills should be part of your team.
If there’s one clear visionary, the best approach is for that visionary to act as the product manager directly. As long as the vision is both worthwhile and achievable, the visionary’s day-to-day involvement as product manager greatly improves the team’s chances of delivering an impressive product.
If the visionary isn’t available to participate fully, as often happens, someone else must act as product manager. Try to get someone who is as close to the key stakeholders as possible. Like the children’s game of telephone, every step between the product manager and the key stakeholders reduces their ability to maintain and promote the team’s purpose.
In some cases, your team will actually have multiple purposes. If key stakeholders’ visions are significantly different, and they all have to be fulfilled, you can create a purpose for each one. Work on one at a time, switching between them periodically.
Product managers, as you talk with the sponsor and key stakeholders, refine their ideas into a draft purpose document. The goal of your conversations is to create alignment about what the team should work on, why it’s working on it, and what success looks like. Your purpose document is a living document that reflects that joint understanding. You’ll revise it regularly.
Your draft purpose document is the first rough take at documenting that conversation. It’s used to help drive the conversation forward. The format of the document depends on your company’s standards. Some companies like to use Key Performance Indicators (KPIs) or Objectives and Key Results (OKRs). Whatever the format, it ultimately needs to answer three questions:
Vision. Why is the team’s work valuable? Describe how the world—or, at least, your small part of it—will be different when the team is successful. Clarify why this is important to the company and its customers. Think long-term and focus on value.
Mission. In the next three to six months, how will the team help achieve the vision? Describe what the team is expected to accomplish and what’s out of scope, but only at a high level. Leave plenty of room for the team to work out the details. Focus on outcomes and value before deliverables. It can be helpful to think of concrete deliverables first, but work backward from there to start with the why, not the what.
Indicators. How will team members know they’re on the right track? Describe up to five high-level success indicators. Be concrete and unambiguous. Avoid talking about specific features (such as “ship feature X on date Y”). Instead, talk about the business results stakeholders expect. Explain how the indicator shows the mission’s value is being achieved. If this is difficult, it may mean your mission isn’t focused on value.
The purpose document is a guide, not a set of hard and fast rules. It’s a way of helping people understand what the team is trying to achieve. As such, it represents people’s best understanding of the situation as it exists today. If the indicators are missed, that doesn’t mean the team is penalized. If they’re achieved, that doesn’t mean everybody stops working.
Remember the Agile Manifesto: “Customer collaboration over contract negotiation.” The purpose document is a vehicle for collaboration, not a contract. As work progresses and everyone gains new insights about the market, the team’s purpose will change.
After you’ve created a draft purpose document and validated it with key stakeholders, you’re ready to discuss it with the rest of the team. This will typically happen during a chartering session, also called a liftoff, after the book of the same name [Larsen2016]. For details about how to plan the session, see “PLANNING YOUR CHARTERING SESSION”.
Your chartering session typically represents the launch of your new effort, but it’s also valuable for any team that wants to better understand the big picture, even if it has already been working for years. It’s also fine for a chartering session to precede the team’s actual start date by a few weeks.
The chartering session starts with a discussion of the team’s purpose.11 Begin by presenting the draft vision. It’s best if the person who led the creation of the draft is the one to present it. Typically, this will be the team’s product manager.
When you present the purpose, don’t just read it; explain the thinking behind it. The conversations that occurred. The trade-offs that were made. The compromises needed. This background will help everyone understand the “why” of the purpose better.
After reviewing the purpose, conduct a consent vote on the vision. (See “Seek consent”.) The vision is owned by the sponsor, so it’s not likely to change, but conducting a consent vote will expose any major objections. If changes are needed, the sponsor will have to approve them. If the sponsor isn’t available, the person who led the creation of the draft purpose can act as their proxy in the meantime.
Although the vision is owned by the sponsor, the mission is owned by the team. It’s responsible for making the mission happen, so the team needs to take ownership.
To help create that ownership, solicit feedback from team members about the mission. (Not the indicators, yet. Just the mission.) Ask for reactions and comments, then break into small groups, each with a cross-functional mix of team members and stakeholders. Each group will make improvements to the mission, which can range from minor wording fixes to major changes.
When time is up, each group presents their changes, their reasoning, and the rest of the group offers feedback. The facilitator then helps everyone consolidate their ideas back into a single mission. This might require another round of small-group sessions. Sometimes mixing up the groups can help.
Once the team has a revised mission, it’s time for another round of consent votes. Does the revised mission still meet the vision? Are the stakeholders satisfied that the mission will meet their needs? Is the team ready to take ownership and accountability for achieving the mission? As you conduct these votes, emphasize that the mission doesn’t need to be perfect. It will change over time. It just needs to be good enough for now.
Finally, it’s time to revise the indicators. This part can be the most contentious because they’re the most concrete. Good indicators are unambiguous. That can be a little scary.
Remind everyone that the indicators are not a contract. They’re a guide. A way of checking if the team is on track or not. If your team isn’t on track to meet the indicators, it means you need more help or lower expectations. If you’ve exceeded the indicators, it means you’re ready to raise your expectations and shoot higher. The indicators will be iterated, just like everything else, and they’re not the only business metrics worth paying attention to.
To revise the indicators, break up into small cross-functional groups again. Divide the indicators among the groups. For each indicator, make sure it can be used to check progress toward achieving the mission, that it has a clear “yes” or “no” answer, and that the team is able to make it happen. Review the changes in the larger group, check consent, and continue revising until all objections are resolved.
As the group works on each piece, you may discover new things that cause you to go back and revise earlier parts of the purpose. That’s okay, and expected. It’s an iterative process.
When you’re done, conduct a final consent vote. Does everyone present agree that the purpose is clear, valuable, and achievable? If so, it’s time to commit. Ask everyone present to record their commitment, either with a physical signature (if in person) or electronically (if remote).
After the purpose is ratified, ask your sponsor to return, if they aren’t already present. Review the changes to the purpose, ask them to commit to supporting it, and get their signature.
If your chartering session includes both purpose and context (see “Context”), you can wait to bring your sponsor back until after discussing context.
Once the purpose is ratified, make it a constant touchstone. Use it to evangelize the team’s work to stakeholders. Refer to it when explaining your plans and priorities. Post a copy prominently in your team room, and refer back to it in planning sessions.
Be sure to continue to include your sponsor and other key stakeholders as work progresses. Invite them to visual planning sessions. Make sure they see demos, even if that means a private showing. Solicit their feedback about progress and ask for their help in improving your plans.
Involving your key stakeholders may be difficult, but make the effort. Stakeholders’ passion and excitement communicates far more clearly than any document can. If team members interact with their key stakeholders frequently, they’ll understand their purpose better, and they’ll come up with more ideas for increasing value and decreasing cost.
If the mountain won’t come to the team, then the team must go to the mountain. In other words, if stakeholders don’t want to come to the team’s planning sessions, then the team’s product managers need to bridge the gap. Share the plan, get feedback, and conduct private demos. This is less effective than involving stakeholders directly in planning, and you need to make sure your product managers are able to effectively communicate stakeholders’ perspectives back to the team. If you don’t have anyone who can do that, talk to your executive sponsor about the risks of building the wrong thing. Your team might be better off doing something else until the stakeholders are available.
The team’s purpose will change over time. Indicators will age out and the team will learn new things about its stakeholders, customers, and market. Eventually, you’ll need to update the purpose. It’s a living document.
Set a specific time to revisit and revise the purpose. Every three or six months is a good idea. When you do, create a new draft and conduct another chartering session. It’s likely to go more quickly than your first one. Typically, the vision won’t change much, the mission will need some revision, and the indicators will need to be updated or replaced.
Can the whole team participate in the draft purpose discussions?
Absolutely. It’s a great way for team members to gain insight into their stakeholders. Typically, some team members will be more interested than others. Discuss how to divide the work as a team, deferring to team members with more stakeholder experience.
Discussing our purpose has led to contentious arguments, and there’s no agreement in sight. Should we proceed anyway?
You don’t need every stakeholder to agree on your team’s purpose, but you do need your key stakeholders to agree. Even if conversations about the team’s purpose lead to a lot of arguments, you should still pursue a unified vision and purpose. Otherwise, you’re likely to release software that’s equally fragmented and unsatisfactory.
It may be possible to split the purpose into multiple pieces that the team can execute serially. If that doesn’t work, consider engaging the services of a professional facilitator to help mediate the discussion.
Our sponsor is constantly changing their mind. How can we get them to pick a direction and stick with it?
Rapidly shifting goals tend to be common with entrepreneurial sponsors. It isn’t due to lack of vision or consistency; instead, they see a variety of opportunities and change direction to match.
If the purpose is constantly changing, it may be a sign that what you think of as the team’s purpose is actually a temporary strategy in a larger, overarching purpose. Take your concerns to the sponsor and stakeholders and try to identify that larger purpose.
If you succeed in discovering the larger purpose, adaptive planning can help you keep up with your sponsor. Optimizing fluency may be a good fit as well. Its emphasis on learning and taking advantage of opportunities will fit in perfectly with your sponsor’s entrepreneurial spirit.
Your sponsor may continue to shift direction more quickly than you can implement their ideas. Your product managers should act as a buffer in this case, protecting the team from rapid shifts and explaining to your sponsor what the team can reasonably accomplish.
Every team needs a purpose. It doesn’t have to be in the format described here, but every team needs to know what’s expected from it and why. Identifying that purpose—correctly—can be tricky. It takes stakeholder buy-in and people with strong product management skills.
If you don’t have someone with the needed skills, your company is at risk of wasting a lot of money on the wrong results. Ask your executive sponsor to help resolve that risk before continuing.
When your team has a clear, compelling purpose that’s shared by the team and its stakeholders:
Prioritizing features is easy.
Product managers have no trouble justifying their prioritization decisions to stakeholders.
Developers contribute to planning discussions by suggesting ways to increase value while reducing cost.
Key stakeholders trust that the team is building what they need.
The organization supports the team’s efforts.
Ultimately, this practice is about making sure everyone is on the same page about the high-level what and why of the team’s work. The exact way you achieve that agreement isn’t important. You can use a chartering session and purpose document as I’ve described here, but you can also try other approaches.
One startup I worked with started out with a normal purpose document, but they found that their business changed too rapidly for that to be useful. Instead, they maintained a wall of sticky notes with business priorities, in several categories (“BizDev,” “Cost Control,” “Capacity,” and “Risk Reduction”), and assigned each team to one or two of the priorities. The board was a central part of the founders’ weekly strategy review.
Some companies are so small and tightly knit that the team’s purpose may seem obvious to everyone involved. Even these teams can benefit from discussing their purpose in some form. Putting a team’s purpose in concrete terms tends to clarify people’s thinking and provides a forum for new ideas.
Liftoff, Second Edition: Start and Sustain Successful Agile Teams [Larsen2016] is a comprehensive guide to Agile chartering. It’s the basis for this book’s Purpose, Context, and Alignment practices. Its guidance about preparing and facilitating chartering sessions is particularly useful.
Impact Mapping [Adzic2012] has a nice discussion of how to discover goals and create good indicators (the author calls them “measurements”) in the “Creating an Impact Map” chapter.
11 This agenda is based on [Larsen2016] (ch. 5), with some small changes.