Moving at the Speed of Trust: How to Get Your Product Team Aligned
Introduction
Product teams move at the speed of trust, and trust can only be established when people know what they can expect from each other and what is expected of them — what I refer to as alignment. In the absence of alignment, product teams experience false starts, delays, and infighting. They also fail to identify and solve problems that matter and to execute their vision.
Unfortunately, misalignment is one of the most common ills product teams face. I recently asked product leaders at top tech companies what their top challenges are within their teams. A few themes stood out. While acknowledging the great work their teams do, each leader told me their teams struggle to make decisions and get work done. These issues are not uncommon, and each of them indicates a lack of alignment.
This article will introduce you to the Product Team Operating Model, a framework you can use to fight back against these issues and align your team.
The Product Team Operating Model
Simply put, a product team operating model describes how your team conducts its business. It includes eight components, each of which are outlined below.
1. Problem identification
Start by identifying the problems you are seeking to solve with your Model. For example, imagine your team is struggling to make decisions and is facing major delays in shipping new features. Call these problems out here; they will guide the rest of your Model.
2. Goals and measures of success
Your goals should be aimed at solving the problems you identified above, with quantifiable measures of success. Continuing with the example above, if your team is facing delays, your goal may be to ship faster by reducing cycle time by x%.
3. Team principles
Principles are powerful because they provide a guiding light for the team; simplify decision making in the absence of guidance; and set the tone for how your team works. Like your goals, your principles should focus on your problems. Going back to our example about our team that cannot make a decision, we may want to borrow Amazon’s ‘Disagree and Commit’ principle, which demands robust discussion and consideration of all viewpoints, while setting the expectation that the team will execute with its full force and intention once a decision has been made.
4. Development Process
Document your development process and high-level activities during each phase. Do not get too granular about key tasks and who is responsible for them; there is room for that in section 6. Below is an example I used on a previous team.
5. Workflow
This section describes how your team intakes, processes, tracks, and measures its work. There are countless ways of doing each of these things, and how you will do them will depend on which development methodology you subscribe to (e.g., Kanban, Scrum, etc.). While the specifics about these methodologies are outside the scope of this article, your workflow overview should include:
Work intake. How you intake work into your system/workflow.
Prioritization. Criteria you use to prioritize your work.
Costing. Measures for assessing a given work item’s cost (time, money, or otherwise).
Tracking. Statuses for tracking the phases of your work (e.g., To Do, Doing, Done).
Measuring. Metrics you will use to measure your progress (e.g., avg cycle time, avg. WIP time, velocity).
It is worth noting this is one of the more complex pieces of your operating model, but you do not want to make it complicated — there is a difference. Instead of using 10 weighted prioritization criteria, use the two or three that matter most. Likewise, instead of using 10 lanes on your Kanban board covering every stage of development, use three: To Do, Doing, and Done.
In my experience, the more complicated your processes, the more difficult it is to implement and sustain. To learn more about implementing simple, yet powerful workflows, I recommend Dominica DeGrandis’s book Making Work Visible: Exposing Time Theft to Optimize Work and Flow.
6. Activities
Much of the operating model thus far has focused on how your team does its work. This section focuses on the what. List your team’s key activities, when they occur, who is responsible for them, and each activity’s expected outcome. I like to break this section into themes, whether it be by work area or activity type (as I have done below).
7. Decision making
This is the most important section of your Model. If you capture nothing else, capture the when and how behind your decision making. If you get this right, you will likely resolve 80% of your ills. Document the following:
Who makes what decisions. At a minimum, identify who decides what you are going to build and who decides when software is ready to be shipped.
How to identify when you are stuck. Disagreement is healthy and is to be expected. But you cannot allow your disagreements to impede your progress. When you reach an impasse, the first step to unblocking yourself is to acknowledge you are stuck. On my team, we have reserved the phrase “Decision Point!” to acknowledge we have reached an impasse.
Who is responsible for breaking impasses. Acknowledging you are stuck is only half the battle; you also need to get yourself unstuck. To do this, identify someone who will break ties. This could be the most senior person on the team, a manager, or the person with the most expertise on a given subject. Whomever you choose, make sure it is documented.
How and where you will document decisions. Your team will make dozens of decisions a day. Many of these decisions will be somewhat inconsequential, while others will not. For the latter, create a place where you can document your decisions, including who made the decision, what it was about, and other alternatives that were rejected. My team created a #DecisionPoint channel where we document key decisions so we can easily reference them.
8. Communication
Lastly, you need to document the channels your team uses to communicate and how people should use them.
4 Best Practices
1. Create your team’s operating model collaboratively.
Your team needs to be included in the creation of your operating model if it is to succeed. This is especially important for creating your team’s principles and for deciding how decisions are made.
2. Start small
Humans generally have difficulty with change, and an operating model includes a lot of it. So do not try to implement it all at once. Start small. Focus on implementing the most important components (like your principles), and then refine and build as you go.
3. Make it concrete
Post your team’s operating model in a public space like a shared wiki. Not only will this let your team know what to expect, it will be visible to other stakeholders who may find it valuable. You can even create posters, stickers, and other swag with your team’s principles. While simple, these small reminders are effective at building alignment around a shared purpose.
4. Be flexible and keep things high-level
No plan or model will cover every contingency. And you would not want that, anyways. Your operating model is a guidepost, not a militaristic order about how things must be done. If part of your operating model is not working for you, do not force it. Revise or throw it out.
Similarly, if your model is too detailed, it will slow you down. Strike the balance between providing enough information to guide your team without being directive.
Conclusion
Championship crew teams spend a lot of effort selecting their team members. Each member must have the right skills and jive with the rest of the crew. But that is just the beginning. Once formed, a team spends thousands of hours learning how to work together and to literally row in the same direction. Your product team is no different. It, too, must get in sync and learn to row in the same direction. It can do so with a team operating model.
