Product Teams: Empowering From the Top Down

Leaders within an organization play a role in realizing the vision for product teams, even as their place within the hierarchy is likely to change.

In my experience, the product team generates friction within the structures of traditional organizations. It can be difficult to set up a team to navigate this friction from the top, with or without product team experience. As we move up the organization, the pressure increases to conform to existing structures. The balance between roles found on the product team gives way to hierarchy amongst management chains. When transitioning an organization to embrace product teams, we have to educate, defend, push back, and demonstrate why product teams are preferred modes of production. It requires relinquishing “management by directives”, focusing instead on setting a vision and letting teams operate. It requires leaders to hold teams accountable in new ways while learning to be patient when dealing with increased unknowns. In most organizations the transition from traditional development to fully empowered product teams will take years. 

So how do we begin to support product teams from the top down?

Start with consent: Starting with consent situates affirmation and empowerment as constitutive elements for the team. Allowing people to opt-in or -out of the product team ensures that the right group has an opportunity to participate. Since consent is also ongoing, it sets the boundaries for moving out of the product team. Moreover, consent stands in contrast to the “command and control” posture of most organizations. People are routinely “voluntold” to participate in special initiatives, which reinforces domination. Identify people within your organization who practice mutuality, who are respected amongst their peers, who are capable of delivering, and who can communicate with other leaders. These folks can be a mix of senior high-performing folks and mid-level contributors that are frustrated with the current operating model. In a new formulation of production, consent introduces the space as protected for those willing and able to affirm their choice.

Define outcomes (& get comfortable with the unknown): Outcomes are critical for teams to operate with the autonomy needed to succeed. With the right set of core outcomes defined, a product team can identify leading indicators that they believe will impact those core outcomes. From a business perspective, these outcomes are simple to define — improved efficiency, increased revenue, decreased cost, and increased profit. From a technology perspective, they might include — reduced error rate, improved resiliency, decreased loading times, and reduced cycle time. Notice how the outcomes do not presume a particular implementation. By setting a wide frame, leaders can use outcomes to guide product teams towards what matters to the business. They carve out the space to explore both problems and solutions, which will maximize the team’s creative potential.

When leaders define outcomes, they will need to change how they measure progress and hold teams accountable. Traditionally, leaders could use fixed scopes and deadlines to give themselves the false sense of confidence that things were on the right track. This illusory control over a project prevents teams from weaving what they learn from user research or feedback into product decisions. It measures the success or failure of an initiative not by added value to the business, but rather by increasing features. Individual features cannot be used to track how well a team is doing mid-flight when outcomes are the primary goal, and their corollary success measures hold us accountable for progress. Leaders need to get comfortable with new ways of tracking a product during its lifecycle — deciphering traction in user interviews, measuring the cycle time between an idea and its build, and creating a feedback loop between the team’s leading indicators and the core outcomes. Practices like Insights & Action Items (post forthcoming) promote transparent learning for the team and stakeholders. The ways of tracking a product described above, are bit squishier than the binary existence of a feature. Leaders need to get comfortable with less tangible measures, as teams explore the right ways to impact their core outcomes. 

Leaders also need to own their portion of the success measures. A product team initially relies on their leadership to define the core outcomes that will move the business forward. What is often missing in the direction is how we measure these core outcomes. For example, we want to reduce cost or improve efficiency, which is a great start. How are we measuring cost or efficiency today? What is the baseline cost or rate that exists today? When leaders bring outcomes to the product team it is their responsibility to provide a complete picture of the situation. As leaders define core outcomes, success measures, and baselines they align themselves to the work product teams do with their outcomes. The two sides create a feedback loop through which success can be tracked collectively. Outcomes will feel uncomfortable for a traditional management team, but they are key to unlocking a product team’s potential.

Manage up & across: Product teams are fragile, especially when they are first stood up within an organization. It is likely they will be working in ways that put pressure on an organization’s information silos, the speed with which shared services can respond to requests, and the traditional ways product progress is measured. A leader of product teams needs to get out in front of objections from executive leadership. Leaders placed in the position of managing their superiors act in an analogous way to the product team managing up — they educate, defend, push back, and demonstrate why product teams are a preferred mode of production. Executive leadership needs to get comfortable operating without traditional forms of control. Start in a few places with executive leaders. For example, communicate the importance of user research and (in)validation, focus on outcomes, and defend the team from direct feature requests.

When managing across the organization, identify what shared services or resources you expect the product team will need. Build alignment with the leaders in these organizations. Identify what people the team may need to be in contact with to be successful. If you find their additional input or resources might be needed regularly, invite them into the product team, if temporarily, to reduce the feedback loop between groups. For example, a team may invite a QA Engineer or a Compliance Auditor to participate in story writing, acceptance testing, or user interviews to create fast feedback loops between the team’s output and any external sign offs. Organizations tend to move slowly and are often resistant to change, especially when shared services can hide behind ticketing systems and heavy-weight processes.  By its nature, the product team will pressure the parts of the organization that takes weeks, or even months, to turn requests around. Get ahead of this pressure by addressing objections, describing how the product team intends to interact, and inviting parts of the organization into the team.

It would be a mistake to presume that leaders should wait for product teams to ask for this support. It is imperative to do the groundwork, have the tough conversations, and set the team up for success independent of them pushing you. The product team has enough to worry about delivering a solid product; they should not need to babysit their leadership. In this case, it feels analogous to the “woke” white guy who needs to be told how to be anti-sexist by the women in his life. Putting the mental and emotional labor on the group you are trying to “support” does little and causes more harm. Understand where you are falling short today, put the time in to learn, and minimize the product team’s burden. I realize this is hard work, but as leaders, we have to find ways to add value that do not come at the cost of stressing the team.

Educate and train: Up to this point, the recommendations described have been relatively hands-off with the product team. Leaders create space for the team to maximize creative potential, monitor core outcomes, and remove potential issues within the organization. Each of these actions is critical, especially with a high-functioning product team. However, when product teams are first put together they may not have the right skill sets to be successful. Work with the team to encourage fast feedback loops in their build-measure-learn cycles. From a product/design perspective, this includes teaching user interview skills, synthesizing research, and working in small, iterative batches. For engineering, it can be teaching continuous integration and delivery, testing, and how to be comfortable delivering code in iterative increments. As is obvious by this list, a product team requires skilled individual practitioners. Teaching junior practitioners these skills is no small task, but a valuable one to the team’s growth.

Personally, I find hands-on pairing with practitioners an effective way to teach skills. By pairing, you can model how to perform a task and work with the team through multiple cycles to accomplish the twin goals of moving the product forward while skilling up individuals. Adjust the method according to the personalities on the team and the priority of the work. When a team works a lower value task, I may let them explore longer than for something of higher value. In terms of where to start, getting user inputs, and synthesizing the results is my highest priority on the product side. From the development perspective, I personally find teams that test well do things simplest and have the confidence to change their code frequently. As a product manager, I generally defer the right approach to engineering leadership. It demonstrates a commitment to the product team to invest in its people through education and skills.

Each of the four recommendations above attempts to move a team from operating in a traditional, top-down manner towards a high-functioning, self-directed product team. It requires energy and persistence to overcome obstacles, and there will be moments when the effort to push against the enterprise feels insurmountable. You are trying to reshape the organizational structure within which you operate — It is hard! Rest is indispensable; When you need a break — take a day off, restore your energy, and pick back up refreshed. Even when you make a breakthrough, the gains made can be ephemeral. There is always work to do, iteration, adjustment, and tuning to ensure the team’s stability. But carving out the space to explore a problem or solution creatively is worth the effort. And finally, those of us that have experience working on these kinds of product teams are here to support you.