What is an Autonomous Product Team?
In Building Outstanding Product Organizations, I listed four main principles to guide organizational design. One them, Autonomous Product Teams, is one that frequently comes up in conversations with product leaders attempting to assess their organizational design and efficacy.
An Autonomous Product Team is a cross-functional team that works closely together to efficiently build solutions to maximize customer outcomes while minimizing risks.
In this article, I will elaborate on the characteristics of these teams and why they are important to drive innovation and success.
Characteristics covered are:
-
Cross-Functional
-
Long-Lived, Right-Sized
-
Outcome-Driven
-
Owns Full Value Stream
- Minimally Dependent on Others
1. Cross-Functional Team
The first characteristic of autonomous product teams is that they include all the skills necessary to identify, prioritize, and solve the problems (or outcomes) assigned to them. While there will be exceptions requiring specialized skills or authority outside of the team, the vast majority of their work should be viable to perform with limited direct outside assistance. You might also call them ‘self-contained’.
By minimizing the need for outside help, the team can optimize its own work without being constrained by external dependencies creating efficiency. Further, cross-functional collaboration is known to increase creativity in problem-solving.
The specifics of the inter-disciplinary skills required may vary based on the nature of the business and the product being developed, however, most teams require the following members.
Product Manager
A Product Team should have a single product manager. She brings the necessary market and business perspective into the team. A deep understanding that enables prioritizing problems while representing the customer and the business perspective.
When working in Scrum, this Product Manager would act as the Product Owner role and be specifically responsible for maintaining the backlog. Scrum describes this role separately from the Development Team but many organizations are now treating them together as the Product Team.
Designer(s)
The Designer(s) is responsible for user experience, user interface design, interaction design, information architecture, and some graphic design. Some very technical back-end products do not need a full-time Designer so they lean on another member of the team or an occasional external resource.
Often the Product Manager and Design share the responsibilities for persona definitions and user research. The exact split depends on the skills and culture of the organization but should be tailored to the people on the team.
In the past, many organizations did not have a designer on each team. That is a leftover from waterfall methodologies that expected all design work to be accomplished upfront in a project. Today, Design is considered a highly iterative practice used to discover products, test design alternatives, and continuously improve the user experience. This requires a deep engagement with the team on a full-time basis to achieve the best results.
Engineer(s)
Each product team must include 1 or more engineers (typically around 5-7). They are responsible for the architectural design, coding, and unit test implementation.
For cloud-based offerings, they should also perform the DevOps functions of Deploying and Releasing, usually in coordination with Product Management, into Production environments.
In a perfect world, we might have every engineer be a perfect full-stack engineer that can work effectively on any component of the software product equally. In practice, this is a difficult way to staff a team, so there tends to be a little bit of specialization on specific technologies or capabilities of the product. Still, the goal is to minimize unique specializations on the team as they tend to create bottlenecks over time.
Additional automated testing is typically performed by experts outside the team but built upon the unit and other tests created by the team engineers.
Additional team members may include the following:
Data Scientist(s)
For data products or those that rely heavily on data, the role of Data Scientist is becoming more popular as a core team member. They have a deep understanding of how to work with data and apply analytics to derive valuable insights. Further, Data Scientists may be a key part of the development process for developing AI and other advanced analytic products.
Sometimes Data Scientists will be further complemented with mathematicians when pushing the boundaries of existing or developing novel mathematical models, processes, and methodologies.
Subject Matter Expert(s)
For the vast majority of products, the teams will want to collect all of their domain expertise directly from the market, its customers, and users. However, in certain highly complex domains, it is common to include subject matter experts (SMEs) directly on the product team. This includes highly regulated and technically advanced fields such as Tax Law, Investment Banking, Pharmaceuticals, and Aerospace.
The SME can both help translate the language of the market to product teams and assist product marketing efforts out to the market. Critically, when SMEs have engaged for long periods in rapidly changing markets – they need to keep closely connected with those markets or their value inside the team will diminish over time.
2. Long-Lived Teams
Team development takes time. One of the top anti-patterns of team design according to Team Topologies, is organizations that constantly change teams around, adding and removing members, plus changing their focus. Simply stated, teams work best when they work together for long periods of time.
Why? This goes back to the forming–storming–norming–performing model for group development that was identified by Bruce Tuckman in 1965. The longer they work together, the more they build shared trust, respect, communication efficiencies, and generally perform.
3. Outcome-Driven
The most successful teams need to be given a mission and find their way to achieve it using all the tools at their disposal. In the past, product organizations would hand down a list of prioritized initiatives that product managers would translate into prioritized features for delivery in the next 6-12-18 months. Product Managers would do their best to break these into features that their engineering partners could estimate and commit to on a roadmap.
This history reflects a command-and-control, feature-driven organization. We have learned through years of failed roadmap commitments, underused features after delivery, and an inability to operate with the agility that this approach is broken.
The best practice today is to give teams objectives and the autonomy to find solutions that can achieve them. Here are two of the key practices of outcome-driven product teams:
Product Vision & Strategy
For a product team to be effective make good decisions on a day-to-day basis, they must be guided by a clear Product Vision. This is the ultimate acid test of whether or not they are heading in the right direction.
The Product Strategy is the high-level plan, a sequencing of major milestones, that will get a product from where it is now to the vision of the future. When done correctly, the Product Strategy provides the necessary guardrails to help teams maintain focus as they drive progress without heavy-handed oversight.
Empowered teams are given the autonomy to execute within this vision and strategy. Teams without an established and communicated strategy end up continually getting revised priorities and output to deliver.
Outcome Focused Roadmaps
Outcome-Driven Development is based on prioritized outcomes for customers and the business is becoming the ultimate sign of an outcome-driven organization. Very simply, outcomes are what product teams should care about. Therefore, roadmaps should reflect a plan of attack on outcomes over time
In a feature-driven roadmap you might have a feature called “Add #Tags to Comments”. In an outcome-driven roadmap, the product team would be given an outcome target to “Significantly reduce time to discover similar comments”.
The difference is that the feature approach gives the team no flexibility in how to solve the problem, while the outcome approach gives the team full flexibility to discover the best possible way to address the need.
Once teams are aligned around outcomes they are empowered to perform product discovery work that leads to optimally achieving the desired outcomes.
OKRs
Objectives and Key Results (OKRs) are a public management tool for guiding team behavior. Objectives are generally set in an aligned way by business management, and teams then negotiate reasonable Key Results that can be used to measure their progress toward that business objective.
Importantly, Key Results are aligned with the outcomes that product teams are working on with their roadmap. This ensures that teams are working on bringing solutions to market that support and align with the Objectives set by the business.
4. Owns Full Value Stream
In very small organizations, with a single product team, they have complete ownership of the entire product value stream.
As organizations grow, teams are split up in a variety of ways to allow them to focus on a specialized domain and drive scalability. Such a division of responsibilities is the natural consequence of a growing and successful organization. Unfortunately, the division of teams is not always optimized along with the value stream.
The most effective teams are given a product scope that includes the complete value stream. The value stream is all the activities related to developing, delivering, and maintaining some business value to customers. Simply, this means that all features, deployment, and maintenance of the product should be under the responsibility of a single team.
This enables a long-lived team the ability to deeply learn their users, tackle technical debt in a smart way, enhance and maintain code most efficiently. Traditional break-downs that split out new feature teams, DevOps, and maintenance are sub-optimal as they create too many hand-offs.
5. Minimally Dependent on Others
As products become more complex and organizations grow, it becomes necessary to create additional teams that may overlap or serve multiple teams aligned around value streams. The problem is that each of these teams creates dependencies with the work and timelines of other teams.
Even when leveraging a best practice like OKRs, if not aligned across teams, these points of dependency become points of conflict as various teams work against different priorities. This can drive delays and inaction.
Each dependency incrementally erodes the autonomy of a team decreasing their agility. Smart organizational design acts to minimize the number and risk of dependencies on product teams.
Closing
Building Autonomous Product Teams is an ideal that, unfortunately, too few organizations have yet to achieve. These are some characteristics can drive better outcomes for your customers, business and employee job satisfaction.
If the gap for your organization is large, start by taking small steps to adjust your practices. For many, the first step is to identify a single product team that is most isolated from others. Move that team towards autonomy, learn and build momentum, then spread the success.