Building Autonomous Product Teams
Background: Applying the Available Tools
Marty Cagan’s second book, “Empowered,” is an essential read for anyone in a product leadership position and describes at length what’s necessary to create and maintain “empowered product teams.” These teams are empowered in that they are free to discover, build and iterate on the customer’s behalf without constant oversight from upper management, or tops-down roadmaps, while still being held accountable for delivering business results. The premise of the book is that empowered teams are still not common in many tech enabled product companies and he continues to say:
“The leaders don't trust the teams. Specifically, they don't believe they have the level of people on their teams they need to truly empower them.”
I agree 100% with all of the content in the book, however I see a lot of companies struggle trying to implement all of the best practices it contains. At the core, I believe that the necessary lens or angle most places are missing is answer this simple question:
“What would it take for me to trust this team to be autonomous? What would it take for senior leadership to be ok with them being left to work for six months or a year without management direction and trust that they would likely still deliver a positive outcome for the company?”
The person asking could be the CEO, their direct reports, or the leader of the product org, but the reason for asking is the same. You can have best practices for hiring, coaching, developing a vision, strategy, org design - but they are all just tools that need to be adapted to the situation. They also miss out on the perception of others and historical information flow. Asking what it would take for the company to trust a team to be left alone to work (yes, iteratively) for six months or a year forces you think hard about trust as Marty points out, and specifically how that relates to judgment, context, and communications. Call it the “working from the moon” test. I’m not suggesting a radical decentralized management philosophy, rather just a stress test to force hard conversations. If the answer is “I’d never trust one of our teams to operate alone that long no matter what,” then I might suggest the issue is not with the team. :-)
In terms of audience for this post, I’d say the target is Product Directors, though honestly anyone in product management will find this applies. Marty Cagan states in Empowered:
“If you want to have truly empowered product teams, then your success depends very directly on these first-level people managers.”
Typically the Product Director, or sometimes Group PM in larger companies, are in many ways the most critical role in the team as they have to be the link between an individual contributor’s abilities and the needs and constraints of the business.
Judgment
I believe very strongly that judgment and decision making abilities are key to success as a product manager and yet they are seldom discretely covered in interview processes or employee development and coaching in enough depth. As product director or VP, you want people on your team who you can trust to make thousands of decisions per year that you’ll never know about. That’s the point of having them on your team. If you have to be involved in every decision your team won’t scale and you won’t be successful at your job. You’ll obviously discuss the big decisions, but every day they will be making tons of calls that over time add up to be the measure of that team’s success.
Judgment or decision making ability in product management can be broken down into a few attributes:
Process - does the person follow some basic hygiene around the decision making process and appropriately scale up and down the process for the size of the decision?
Awareness of Bias - do they understand the basics of biases that can enter into decision making and adjust accordingly?
Data Orientation - The primary driver behind any decision is data and analysis at a sufficient level of detail
Open Mindedness - The person is open to new ideas, is constantly looking for disconfirming information and is not afraid to change direction mid-course if that is what the data says is the right course of action
First, think about the product managers on your team and ask each of these questions. If something is lacking, ask whether it’s a skill the person needs to develop and how to help them do it or if the person is being pushed into bad behavior because of the environment. Is solid data hard to come by? Is unnecessary time pressure forcing important decisions to be made too quickly. Secondly, ask if everyone else in the company likely has the same answers or enough exposure to them to accurately assess each of these. This gives you the first insight into whether your product managers can truly run autonomously or if additional coaching or change in responsibility is required.
Context
Everyone always says context is so helpful, yet it can be hard to find sometimes. For an IC product manager, appropriate context is really a mix of understanding the business goals, metrics and timing (revenue, growth, gross margin, etc) along with the “fence posts” provided by the product vision and strategy. Drawing from the list in the previous section, I see commonly see senior leaders who own numbers (CEOs, CFOs, and senior Sales & Marketing leaders) failing to trust product managers because they appear to be operating in a bubble, solving problems for the customer, but without a strong enough link back to how that will drive business results.
As a product leader it’s your responsibility to make sure your team has the appropriate context to operate autonomously. The first step is making sure all of these elements exist, are agreed to by senior leadership, are written down somewhere, and the team knows where to find them. Secondly, you need to discuss the materials with each of them to ensure they understand how it applies to them, their work, their goals, and their team.
Crucially, I see a lot of product managers lack the necessary context into how to make business-impacting trade offs. They know how to prioritize things in the backlog based on customer urgency, or potentially even return as measured by a single KPI, however they struggle knowing how much they can trade off gross margin for growth. Are we trying to hit the revenue targets any way possible, or is it beneficial to the company financials if we focus on annual vs monthly billing?
Make sure all of the appropriate context is documented, but also work through some examples and scenarios with your people. Ensure they know how to use the context in their day to day decision making processes. If possible try to give each person a single or small set of metrics to drive, but if the team is not large enough for narrow bands of responsibility, then be certain they know how to trade off different business impacts the same way the CEO and CFO would in their seat. In my experience one of the most common reasons senior leadership does not trust an IC product manager is sensing that that person’s ability to make the right business trade off is lacking. They don’t know if it’s because they simply don’t know or if they just aren’t capable, but either way, something the person says or does gives a cue that their decision making only considers delivering maximum value for the customer (or worse, some other reason), but not appropriately balanced with the needs of the business. This is strongly tied with the topic of ownership, and how having a broader sense of responsibility can help product managers grow into business leaders.
Communications
Time for business cliches, and frankly statements of reality: everyone is busy, and the amount of new information they receive everyday is probably twice what they can process. If there are trust issues with a product manager, or the team broadly, a third potential driver after judgment and context is lack of frequent, appropriate, communications that fall into two categories.
The first is typically what’s accomplished by a product roadmap - providing a high level look into “what’s coming.” The problem, as everyone has probably experienced at least once, is that roadmaps too easily become a gantt chart, with most of the page real estate taken up with inaccurate schedule details, a feature name, and an estimated ship date. The context of why we are doing it, for which customer segment, why it’s important, and why it’s going to help the business are often not present. If the rest of the company thinks of product & engineering as “black box” then you need to A) have a roadmap or some similar format and B) explain why these things are on the list. It’s a lot easier to trust something when you can see how it works. By dropping all of the schedule nonsense and showing that you have a clear customer target and their pain points and have thought through how you think this maps back to critical business metrics, everyone else can see how the decision making and prioritization works. More importantly, over time, they’ll come to trust it.
The second category is more focused on the individual. It’s very possible you have a capable product manager that “no one has ever heard of” who is taking on some larger or new responsibility. Even junior product managers have a lot of relative responsibility and while you as their manager may trust them implicitly, you also interact with them a lot more than anyone in senior leadership. Part of your role as a product leader is to of course highlight the successes of the people on their team, however sometimes you can overcome trust issues cropping up by doing some brand marketing on their behalf. In your regular check-ins with senior leadership talk up your people even if they are not directly working on something that is critical to that person at the moment. Build awareness of who they are and the fact they are competent. PMs change assignments all of the time, and you don’t want to have to suddenly convince everyone to trust someone in a job they’ve already taken. Secondly, this helps to build broader trust in the product organization, and that it is staffed with awesome people who “get it” and deliver.
It’s also very common for product managers without a strongly developed sense of empathy to miss the mark on what needs to be communicated internally. Different audiences care about different things even if we all agree it’s the right thing to do. If you don’t understand your audience, it’s easy for a very competent product manager to come across as disconnected in some way. Part of building trust is open communication and transparency, but the message has to be appropriately tuned to the audience.
Summary
If you want to get to empowered teams, keep asking yourself what would be required to set this product manager and team off by themselves with little to no direction for months on end and believe there would be a good outcome. What would it take to get everyone in the company comfortable with that decision? Break that question down into an assessment of the product manager’s judgment, the context they have about the business, and the level of visibility everyone has into the workings of the product team and that individual's prior performance.
