Managing Product Teams for Success

Have you heard? My new book Continuous Discovery Habits is now available. Get the product trio's guide to a structured and sustainable approach to continuous discovery.

I’ve been thinking about the challenges of managing product teams by outcomes.

Most leaders want their teams to have the autonomy to go after an outcome, but they struggle with trusting that their teams will do the right things.

Most teams want that autonomy, but they struggle with communicating their progress toward an uncertain outcome.

These shortcomings create a vicious cycle. Managers struggle with teams asking to be left alone to achieve their outcome because the teams don’t have a history of delivering on outcomes. Teams struggle to communicate progress, because too often, managers micro-manage their work when they do.

Layer on top of this the fact that managers are used to controlling and dictating, product teams are used to being told what to do, and everyone is used to falling back on the org chart and functional silos to pass the buck, and it’s no surprise that truly autonomous teams are hard to come by.

So I started to wonder:

• How do we empower product teams?
• How do managers monitor and provide feedback without dictating and controlling?
• How do teams communicate progress without fear of being told what to do?

But before we get to those questions, let’s first explore why managing product teams by outcomes matter.

The Power of Managing Product Teams by Outcomes

Autonomous teams become a necessity when we shift from being output-oriented to being outcome-oriented.

With an output orientation, we manage our teams by requesting that they build specific things. The most obvious way to be output-oriented is to give your teams a roadmap that lists features and release dates and ask them to deliver against that roadmap.

But there are more insidious ways to be output-oriented. When we ask our teams to build an Android app or to develop a subscription offering, we are also being output-oriented.

What if our customers aren’t on Android? Or they prefer a mobile web experience to an app experience? What if they rarely use our service on the go? What if we learn that more of our customers are on Windows (I know, funny right?) than on Android?

What’s the intent? Are we trying to grow market share, engage our customers through more channels, or increase our daily active usage?

If we want to truly be outcome-oriented, we need to communicate the intent. – Tweet This

Now this doesn’t mean as leaders we also don’t get to weigh in on strategic decisions that help us reach those outcomes. It’s perfectly okay to say, your goal is to increase market share and we think the best way to get there is to develop an Android app.

This works only if it’s clear to the team that their task is to increase market share. They should explore offering an Android app as a way of growing market share, but they should also have the latitude to explore other options if they discover better ways to grow market share.

The value of this approach is that rather than having all of the decision-making power come from the leadership team, it gets diffused to the teams closest to your customers. This leads to better decisions.

But as we saw earlier, managing these types of teams is hard. It goes against the grain of all of our past experience managing product teams.

Managing Product Teams Effectively

I’ve never met a manager who was comfortable telling a team, “Here’s your goal. See you in three months. Good luck.”

This simply isn’t how humans work. We want to see progress along the way. We need to build confidence over time that we are getting there.

But many teams are reluctant to communicate progress because their decisions get nit-picked. They get into opinion battles, and we all know the HiPO (Highest Paid Opinion) will win. This is especially true when progress is slow or we backtrack.

If we want to get good at managing product teams, we need to find answers to the following questions:

• How do we empower product teams?
• How do managers monitor and provide feedback without dictating and controlling?
• How do teams communicate progress without fear of being told what to do?

And this is what my answer looks like.

How to manage product teams by outcomes.

In this model, leadership includes your org chart leaders—the people the product manager, the designers, and the software engineers report to. It also includes anyone in the organization more senior to them who are setting direction for the product teams.

The product team includes the product manager, the designers, the software engineers, and anyone else on the cross-functional team required to discover and deliver value to customers.

Let’s walk through it step by step.

Negotiating Desired Outcomes

It’s important that outcomes be set by a two-way negotiation between leadership and the product team.

Outcomes should be set by a two-way negotiation between leadership and the product team. – Tweet This

Too often I see one of two things:

1. Management sets the outcome with no input from the team.
2. The team sets the outcome with no input from management.

Neither works. We want to blend the experience and insights of both parties. Leadership has the “across the business” perspective and should provide strategic guidance. The product team is closest to the customer and the technology and is in the best position to assess what’s feasible and desirable.

I’m less concerned with who initiates the negotiation, as I am with both sides having input. It needs to be a collaborative effort.

However, if the product team is going to initiate the conversation, they need to be trained on how to set appropriate outcomes for a given time period.

How to set good outcomes is a book in and of itself, but at a minimum, make sure that:

• The team knows to focus on a measurable outcome.
• The outcome is appropriate for the time that they have to work on it.
• The outcome can change from time period to time period (e.g. quarter to quarter).
• The team knows how to determine the most important metric (the one that creates the most value right now).
• The outcome is narrow enough that it creates focus.

And finally, it’s leadership’s responsibility to make sure that the team has everything that they need to reach the outcome and it’s the team’s responsibility to communicate when this is not the case.

Good Discovery & Delivery Starts With Good Habits

I’m a firm believer that good product development practice starts with good habits.

The most important habits I like to see are a regular cadence of customer interviews, prototype tests, and assumption tests.

Good product teams have a regular cadence of customer interviews, prototype tests, and assumption tests. – Tweet This

Regular interviews help us continue to develop our understanding of our customers’ context. Regular prototype tests ensure that we co-create with customers and never get too far away from a desirable or usable solution. Regular assumption tests keep us honest and guard against building products that simply won’t work.

I love it when a team does all three every week. This cadence terrifies most teams, but I know many who are doing this every week, and some who are doing it even more frequently.

Many teams overemphasize one of these activities, but all three are needed.

I firmly believe that what you know about your customer is a competitive advantage. The closer you work with your customers, the better your products or services will be. So I push for an aggressive cadence.

If you want to see a great example of an aggressive cadence, watch this video.

I also like to see a regular cadence of zooming out to make sure there’s clarity around the big  picture—this might entail a map the challenge exercise or revisiting the opportunity solution tree.

And, finally, I want to see a regular cadence of generating alternative solutions and the development of test plans to help the team choose the best solution.

These latter two activities are critical for ensuring that the team doesn’t get stuck in the weeds of interviewing and experimenting where it’s easy to overcommit to a favorite idea or miss the forest for the trees.

In terms of managing product teams, it’s up to the team to execute on this cadence of activities, but a manager can and should monitor the frequency of these activities. If you see one of your teams go weeks between customer interviews or product experiments, then it’s safe to step in and help them get back on track.

I like to help teams troubleshoot by asking why they missed the activity that week. I listen for opportunities to remove obstacles and to help make it easier for the team to stick to this schedule than to not.

I don’t jump in every time a team misses an activity, but if I start to see a trend develop, then I want to help them course correct as soon as possible.

Charting the Uncertainty of Product Discovery

But it’s not just about activities. I know plenty of teams that do all the right research activities, but these activities don’t influence their product decisions. They set out to build the same solutions they intended to build before they did their research activities.

They might make some UI tweaks based on what they learned in usability testing, but they rarely make significant changes to their solutions or choose alternative opportunities to pursue. This is akin to putting lipstick on a pig.

I want to see discovery activities leading to work being thrown away, ideas abandoned, and new directions chosen. If this isn’t happening, then a manager should step in and help the team connect their research activities to their product decisions.

Discovery activities should lead to ideas being abandoned and new directions explored. – Tweet This

I teach this through the use of the opportunity solution tree. The opportunity solution tree acts as a discovery roadmap helping teams chart out where they think there is opportunity, map solutions to those opportunities, and put their experiments into context.

Teams should build their opportunity solution trees, but managers should use the tree to assess and give feedback on the team’s thinking.

Managers should question the links between the boxes on the tree.

• Does this opportunity really drive this desired outcome?
• Does this solution deliver on this opportunity?
• Does this experiment really test this solution?

Managers should also evaluate experimental results and help teams interpret results. It can help to get a perspective from someone who isn’t as close to the work to help make sure that sound conclusions are being drawn.

However, it’s critical that a manager evaluate the team’s thinking and not advocate for their own opinion.

And, ultimately, the manager should give feedback, not dictate. It should still be up to the team to determine their best route to their desired outcome.

The manager will get to be the ultimate judge when it’s time to evaluate the outcome.

Prioritizing Delivery

For too long, we’ve managed backlogs by committee. This is wrong.

Management should primarily focus their feedback on the discovery roadmap, not the delivery backlog.

For more junior product teams, a manager might jump in to help teach the team how to manage the backlog. But once they get the hang of it, the manager should back off.

The product team should own the delivery backlog.

For more senior product teams, management shouldn’t even look at the delivery backlog. If your team’s discovery roadmap looks good, leave the execution details to them. (Of course, there are always exceptions when a team is struggling to execute.)

When management is involved at this level, it slows development down and creates a mess.

Product leaders shouldn’t be involved in backlog management. – Tweet This

Evaluating Outcomes

Finally, at the end of the designated term (usually a quarter, perhaps as short as a month for more junior teams), the team should present and defend their progress toward their outcome to their leadership.

If the team has been communicating their progress throughout the term, there shouldn’t be any surprises here.

However, this is when leadership can weigh in and evaluate the outcome. Managers should not expect that a team will hit their outcome every term. This is unrealistic.

Nor should the outcome be the only measure of success. Teams should be evaluated by both how they performed against their outcome and their cadence of activities.

Teams can do all the right activities and, due to circumstances beyond their control, still miss their outcome. This should not be considered a failure.

However, if a team does all the right activities and consistently misses their outcomes, then leadership needs to step in and help evaluate where the disconnect is between the activities and the outcomes.

The fuzzy nature of outcome performance is one of the hardest parts of managing product teams. We should hold teams accountable, but we also should understand that things won’t always go according to plan.

There should always be an expectation that the team will hit their outcome, after all, that’s why we set the goal. But if the team is improving term over term, then I wouldn’t worry too much about whether or not they hit the exact number.

Focus on the overall trend of the team’s performance rather than a single term’s performance. This will give your team the confidence to take risks and will lead to better performance in the long run.

A Final Note

A key to making this work is that teams must feel comfortable sharing their progress toward their goal without fear of losing autonomy. Managers must learn to give constructive feedback rather than telling their teams what to do.

For a team to be truly autonomous, they must work with their managers to set a desired outcome, be given the resources they need to go after that outcome, and, most importantly, be given the freedom to pursue that outcome however they see fit.

Managers can and should give feedback. But their primary mechanisms for managing the team are negotiating the outcome and evaluating the final outcome.