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 recently sat down with fellow Product Talk coach and instructor Hope Gurion to discuss how leaders can hold empowered product teams accountable to outcomes.
You can watch the video of our conversation or check out a lightly edited version of the transcript below.
Full Transcript
Teresa Torres: Welcome everybody. I’m Teresa Torres.
Hope Gurion: And I’m Hope Gurion.
Teresa Torres: We’re going to discuss today what it looks like to be an empowered product team and especially for leaders, how to hold empowered product teams accountable to their outcomes. This is a challenge that comes up a lot in our work, and I’m going to talk with Hope about it in particular because she does both leadership coaching—so she gets to work with leaders on this on a regular basis—and she also teaches our Defining Outcomes class, so she gets to see it from the individual contributor side as well. So she’s got a pretty well-rounded perspective. To kick us off, Hope, do you want to just say a little bit about what’s an empowered product team and why it’s becoming a more common concept?
What Is an Empowered Product Team?
Hope Gurion: Yeah, sure. I’d be happy to. When I think about empowered product teams, I kind of feel like it’s on this spectrum of where teams are. And there’s probably multiple points on this spectrum that I’m going to miss, but there’s the delivery team, feature team. The one that I wouldn’t particularly say is empowered has sort of low discretion over what they work on.
And maybe at the opposite end of that spectrum might be completely autonomous product teams. Sometimes certain teams or companies might aspire to be truly autonomous teams, but I feel like more often than not—and I don’t know if it’s maybe slightly skewed to this end of the spectrum—there’s this concept of an empowered product team.
And when I think about that, this is a team that has clarity of purpose. They have a clear measure of success that is an outcome that they’re working towards, usually over some longer period of time. Not like this week it’s this outcome and next week it’s that outcome. And they really are the ones deciding how to spend their time so they’re not totally autonomous in that they can do whatever they want, but they’re working towards something that the company, the leadership has agreed is incredibly important. It’s a measure of success. So they’re an outcome-oriented team, but they do have quite a bit of discretion about how they decide how to spend their time to be able to create that outcome, that measure of success.
An empowered product team has clarity of purpose. They have a clear measure of success that is an outcome that they’re working towards, usually over some longer period of time. – Tweet This
Autonomous vs. Empowered Teams: What’s the Difference?
Teresa Torres: Yeah, that’s great. I want to kind of highlight some of the things that you said. So I think traditionally product teams have been feature teams where stakeholders are dictating: ‘Build these specific solutions’ and the team goes off and builds those things.
And that’s where we get kind of traditional roadmaps where they have a list of features to deliver by a fixed deadline. And then we’ve sort of started to look at let’s move more towards giving those teams more decision-making power. In theory, they’re closest to the customer if they’re doing good discovery work. And also it just gives us scale. Like a leader can’t define what 40 teams should do.
But I love your distinction between autonomous teams and empowered teams. Because I think too many people interpret this as, ‘Oh, we get to work on whatever we want, and if somebody outside of our team is telling us anything, then we’re no longer autonomous.’ Do you want to just touch on that key difference between empowered and autonomous a little bit?
Hope Gurion: For me, it implies that they are really sort of isolated, siloed from what the rest of the organization wants, expects, needs. An empowered product team should have a lot of discretion about how they spend their time and what they work on and should have a way that their team’s decision-making and delivery choices are evaluated in terms of their contribution to the company by solving the needs of the customers they most need to serve.
But that doesn’t necessarily mean that a hundred percent of their time and attention is always going to go to that outcome. Sometimes there’s high-integrity commitments. Depending on the org structure design, there may be some inter-team dependencies. There could be a security risk or threat that the team is going to have to remedy or mitigate in some way.
So it’s not that these teams are totally autonomous, doing whatever they want, but they recognize their contribution to the company’s value streams and they have high amounts of decision-making power to decide what they work on, but they’re not completely siloed from any of the expectations of the organization.
Empowered teams aren’t totally autonomous, doing whatever they want, but they recognize their contribution to the company’s value streams and they have high amounts of decision-making power. – Tweet This
Focusing on Outcomes and Strategic Impact
Many product teams think being empowered means you’re completely autonomous, but there’s always some “keep the lights on” work you have to do.
Teresa Torres: I think you’re hitting on a key point, which is the expectations of the organization, and some of that is set through the outcome, right? We’re going to say, look, you are empowered to make decisions as long as whatever you do has this impact that we’ll measure with this outcome. But I think what I’m hearing in your response is, there’s more to it than that.
And I think Marty Cagan would talk about it as leaders are setting the strategic context and then the empowered team is reaching their outcome in a way that’s consistent with that strategic context. And that strategic context could be things like the product vision, any strategic objectives that are sort of relevant in the organization at that moment in time. And so then that kind of gives us this middle ground between we want to push decision-making down, we want to have scale by letting our teams make more of the decisions. And I think Marty talks about missionaries versus mercenaries—have more missionaries rather than mercenaries. But it’s not really just go do whatever you want whenever you feel like it.
Leaders are setting the strategic context and then the empowered team is reaching their outcome in a way that’s consistent with that strategic context. – Tweet This
Hope Gurion: And I have worked with a lot of companies that thought that was the ideal. And then they kind of move to that and all of a sudden the pendulum swings right back. So that’s why I mentioned it’s on a spectrum. And even teams who are on a mission and have an outcome that they’re working towards, they may not spend a hundred percent of their time working towards that outcome.
And I think for some teams that can be difficult to navigate because they’re either missing the strategic context that helps them understand why they can’t necessarily spend a hundred percent of their time towards that outcome, or they feel like they’re becoming a feature team if they don’t spend a hundred percent of their time working towards the outcome.
I think that’s something that every product team has to navigate and the product leader in that organization has to help their teams recognize that being an empowered product team means delivering value to the company by solving the needs of customers, but maybe not a hundred percent of the time.
Teresa Torres: Yeah. There’s still sort of the ‘keep the lights on’ work. There’s still—and this is something we hear a lot from teams—where they feel like it has to be all or nothing. And I think what we see is it’s never all or nothing, right? So you might have your outcome, you’re going to spend a good chunk of your time working towards that outcome. There will be times where your leaders are still going to say, no, we need this solution. Maybe it’s because of a regulation or some compliance issue. Maybe it’s just a really strategic thing and your leaders have already decided we’re doing this.
And I think people think, oh, that means we’re no longer empowered. Whereas I like this idea that it is a spectrum. It may not be a hundred percent of your time. There’s some flexibility here. We want to push decision-making down, but we also want to make sure we’re staying aligned as a company and that everybody’s working together.
Hope Gurion: That’s a great way to summarize it.
How Do You Hold Empowered Teams Accountable?
Holding regular “discovery demo” meetings gives teams the chance to share their messy work and learning that’s still in progress.
Teresa Torres: Okay, so I can see in the old world where I managed my product teams by a fixed roadmap with features and release dates, I could evaluate their effectiveness by just asking: Did they build what we asked them to? And then: Did they deliver it on time? And of course, I can look at whether it’s on budget or whatever. In this new world where it’s a little messier, you’ve got an outcome, you’ve got some strategic context, you’re spending some chunk of your time just doing whatever it takes to reach that. How are we holding those teams accountable?
Hope Gurion: For me, what I found to be most effective was something I’ve called discovery demos. They don’t have to be long, they don’t have to be very formal, right? All we’re trying to do is see what has the team learned lately that is helping them advance progress towards their outcome. And this could be in the structure of an opportunity solution tree, really at any level.
Discovery demos are short, informal meetings where all we’re trying to do is see what has the team learned lately that is helping them advance progress towards their outcome. – Tweet This
If we’ve set the outcome, if this is an outcome that the team has been working towards for a long time, we might zoom right into an opportunity that they’re working on solving and some assumption tests that they’re doing that might be the right moment that they’re focused on. If this is a brand-new outcome for a team, then in those first few discovery demos, it might be that we’re looking at what opportunities have they discovered or how are they sizing those opportunities.
What each team focuses on in those discovery demos is going to be very specific to where that team is in relation to their outcome, how much they’ve learned, how much they’ve delivered in the past towards that outcome, how impactful that’s been.
But the way that I would structure these is I would do them every two weeks. You could do it as a different cadence, but I did them every two weeks, discovery delivery demos, and the team was either demoing, this is what we’ve learned lately. They start with the why. This is the outcome we’re working towards, this is what we’ve done lately and what we’ve learned from it. Here’s what we’re doing next.
And it wasn’t just for my benefit, it was for all the other teams. And again, every company could do this differently. It could be that you’re inviting other stakeholders, other leaders to come in, but for the most part, I found that it was really the other members of the product and design engineering organization who participate because they also learn from what each other are doing, and they can coach and offer suggestions and help the other team members expedite their progress.
It just had this really nice benefit of not only sharing progress, but expediting progress amongst the different teams towards their outcomes. So for me, that is a very helpful ritual to replace the: What did you deliver? Are there any blockers? Next?
Teresa Torres: I’ve seen this work really well in several different companies where—and again, it’s not a deep dive. It’s: Get all the teams together, however many there are. And I know for larger companies, maybe they’re doing this in the guild or tribe or whatever the right Spotify model term is, right? It doesn’t have to be every product team in your company. It can be tailored based on the group that’s relevant, but it’s cross-product team sharing of—take a chunk of time, like every two weeks, every three weeks, every four weeks, whatever the right cadence is—here’s what we learned.
What I love about this is it sets the norm that this is how we work. Discovery and learning is an important part of what we do here. And then I’ve also seen a lot of really effective cross-learning and serendipity and just other teams sparking ideas from hearing about what other teams are learning.
Holding regular discovery demos sets the norm that this is how we work. Discovery and learning is an important part of what we do here. – Tweet This
So, we’ve got a bunch of teams, we’re tasked with outcomes. We’re meeting every two weeks. We’re sharing what we’re learning. The other thing I love about this is it’s really consistent with an idea Christina Wodtke wrote about in Radical Focus where she has this one-page template her teams fill out, here’s our outcome, here’s our OKR, here’s the progress we’ve made, here’s our confidence in it. So many teams set an outcome and then don’t revisit it until the very end of the quarter, so this keeps it ever present as well.
We’ve got a bunch of teams. They’ve got outcomes. They’re meeting every two weeks, sharing their discovery demos. Is there anything else that they’re doing or that the leader is doing to hold the team accountable?
Hope Gurion: We’re seeing progress towards the outcome so that they are ready by the end of the quarter, which goes with another form of accountability to share what typically is in a product review. Like here’s how much progress we made towards the outcome. Here’s what we learned, here’s what we’re gonna do next. But it’s more at that quarter view.
Teresa Torres: So by every other week check-ins on what we learned, it’s sort of like a sprint retrospective, but discovery focused. And then there’s sort of this quarterly review of let’s take a step back across the quarter: What did we learn about the opportunity space? How much impact did we have on our outcome? What does that mean for what we might do next quarter?
What I love about this is it kind of matches what we do in our coaching when we’re working with teams. We meet with them every week, and so we can get a view of if they are making as much progress as we would expect. I know I’ve seen teams sort of spin their wheels and not make progress.
What have you seen that works effectively when it’s just clear from a team’s demos that they’re not learning what they should be? Or we’ve all been in that situation where experiment after experiment just fails or we’re not getting a rich opportunity space. What are your tips for helping a team get back on track?
How Do You Help Teams Get Unstuck?
Hope Gurion: If you’re not making progress—and this is why those bi-weekly discovery demos become so helpful, because you’re not seeing it for the first time at the end of the quarter and then the end of the next quarter, you’re seeing this pattern of, huh, they’re not making as much progress. Sometimes it’s in discovery. It’s the opportunity they’ve chosen or the data they’ve chosen or who they’ve interviewed or how they structured that assumption test.
But if you’re seeing how they’re approaching learning it, usually we can correct that before they make the mistake. Sometimes they have a blind spot that only other members of the team see. And this is why I like it as a leader. It’s not just on me. The other people on the team can see it. But when you have to present your results and what you’ve learned every week, if you aren’t making progress over time, it does become uncomfortable.
We end up having a more frank conversation. Usually we do that outside of these public forums so that we can really root cause it and get to like a five whys or something else that helps us figure out why this is. Maybe it’s the wrong outcome and we actually have given them an outcome that they can’t make progress towards. Or maybe there’s something else that they’re being tasked with or spending time on. So it’s hard for me to say all the things to do to diagnose when a team isn’t making progress, but the more that you’re having these rituals, the more you and other members can help spot why the team isn’t making progress and offer suggestions to help them succeed.
The more that you’re having rituals like discovery demos, the more you and other members can help spot why the team isn’t making progress and offer suggestions to help them succeed. – Tweet This
Teresa Torres: What I love about this is it’s really consistent with this ethos of working out loud and showing your work. I think it’s so easy, especially for leaders that are managing a lot of teams, that when a team isn’t making progress towards their outcome, to conclude it’s a performance issue—and sometimes it’s a performance issue. But I think most of the time it’s that we’re learning. When we’re in learning mode, we’re not always going to learn what we expect.
So it could be that we have the wrong outcome. It could be that we’re not working on the most important opportunity. It could be our value proposition. Our strategy isn’t resonating with the customer segment. And I think one of the things that’s hardest to do in discovery is to have real intellectual honesty about the work that we’re doing and how we interpret our results.
And I think doing this in a shared forum helps us rely on our teammates, not our immediate trio mates, but like our broader product team and engineering and design teams to help hold us accountable to that intellectual honesty. Because if I go two or three two-week periods in a row, where I’m not making progress, I’m going to hope one of my colleagues points that out because I might have a blind spot to it, right? I want somebody to call me out and say, ‘Hey, this has been six weeks, so it looks like you’re spinning your wheels. Do you need to take a step back?’
And I think that requires a culture that focuses on learning and not performing. And the irony is, I think when we have a learning culture, we do perform. But a performing culture does not always result in performing, and it rarely results in learning. So I love this model of: It’s not just the trio that’s a team, it’s the whole broader product design and engineering organization that is the team responsible for holding that accountability.
The irony is, I think when we have a learning culture, we do perform. But a performing culture does not always result in performing, and it rarely results in learning. – Tweet This
Hope Gurion: And I’ve had that experience where in one particular instance I’m remembering it was actually something that the team was trying to get into a live data prototype to run an experiment. And they were delayed on being able to get this experiment out. And it was a junior engineering lead on the team who needed coaching from other engineering leaders who had seen that challenge before and they had remedied it. And so, again, this is why it’s a cross-functional experience, because sometimes it’s something in discovery, sometimes it’s something in delivery. And when you have those experienced perspectives in the room, again, it’s just about expediting progress towards that outcome. And if that’s the mindset of everybody in the room, then it really becomes even more of a team sport to make progress on those outcomes.
Actionable Guidelines for Leaders: How to Hold Your Teams Accountable
Teresa Torres: Okay. So I’ve heard a couple things. I want to end with some really actionable guidelines for leaders. I know we’ve talked about this every other week demo, this quarterly review. That’s a potential solution. Leaders could take that and implement that in their organization, but we know there’s not one right way to do this.
Do you want to generalize a little bit? If you were going to give a leader—you’ve probably done this in your coaching many times—if you were going to give a leader some guiding principles, you might have to adapt the tactics for your own organization. But what are the sort of guiding principles to keep in mind as they try to do this in their own organization?
Hope Gurion: A lot of leaders struggle to set and agree on outcomes with their teams because they’re not sure it’s the right outcome for their team to be focused on. And they’re worried that this is our measure of success and maybe it’s not the right one.
Focus on teams’ belief in the outcome over perfection in that outcome. So again, it starts with having an outcome defined for your teams. And as you pointed out, we’ve got lots of resources to help people with good product outcomes for their product teams.
The second is when you’re trying to assess progress, you want to make sure that the team is willing, feels comfortable sharing both what is working for them and what has been challenging for them. Right? If you can’t get that level of honesty, then you can’t troubleshoot that as a leader and other members of your product and design engineering organization aren’t going to be able to offer really actionable advice.
You want to make sure that there isn’t this bias towards: We want our teams to always look good in case somebody else is looking in, you know, the CEO or somebody else is looking in. So you really want to make sure you’ve got that sort of psychological safety for your teams. And again, a culture that values, let’s just look at the progress we’re making for what it is and see if there’s ways that we can make more progress.
The third would be making sure that people feel accountability to their mission as opposed to feelings of accountability to their boss. That’s the other thing that I don’t think results in a healthy type of accountability. Like if there’s meaning in that mission, the team had a say in what their outcome was and they’re the ones making the decisions, let them measure how much progress they’re making towards that mission as opposed to feeling like, well I have to do this because I want to please my boss or make my boss look good or not be reprimanded by my boss.
Then finally, this is a little bit related to looking good, focus on substance. Who cares what those bi-weekly demos look like? Don’t have a lot of overhead and design and presentation—focus on substance over style because again, we want to get to the meat of what the teams are learning and what might be standing in the way of them making progress towards their outcomes so we can help them get there faster.
Teresa Torres: That last one really resonates with me. I know in my book I tried to focus on how do we use the same visuals we’re creating to stay aligned as a team to present to our stakeholders? Because the last thing we want is to have our teams lose a day creating slide decks. That’s not very valuable.
I also love your comment about who you invite to this meeting is going to have a really big impact on the culture of the meeting. So if your CEO’s in the room, are people going to feel comfortable saying they didn’t learn, like they’ve kind of flailed for the last two weeks because they’re having a problem with something? Whereas that’s really what we want. So you want them to feel comfortable showing how the sausage is made. Like what went well, what didn’t go well? How do we course correct as needed?
Okay, so it sounds like if you’re a leader, you want to do this, you might have to experiment with the cadence, who you invite, how many teams. But really the key principles here are: Make sure it’s about the learning and not performing. Make sure that you’re not having them spend hours and hours on their presentation. Some of these ethos are really similar to what we see with sprint demos. It’s the same idea, right? Just show your work. This isn’t a big ta-da.
Let’s say I want to learn more. I’m inspired. This all sounds great. Is there somewhere I can find some more examples or other models that are similar to this?
Hope Gurion: You already mentioned Christina Wodtke’s Radical Focus book and she has a more, “Monday commitments Friday wins” type of a template that she does, which is more of a written way of assessing the team’s progress. There’s a great post from Reforge around operating rituals, which again, show and tell, show your work. And again, with all the continuous discovery habits, artifacts and the opportunity solution tree and assumption tests, there’s lots of ways that teams can show their work without perfect slide decks. And then also I have an episode from the Fearless Product Leadership podcast where I ask product leaders, what do you do to create accountability for product teams? So those are some of the resources that we can share with everybody.
Teresa Torres: Yeah, and I’ll add to that list my Business of Software talk where one of the things that I include in that is just some questions leaders can ask their teams to help stay out of this—when things go wrong, we want to jump back into outputs. So it just gives you some questions you can ask so that you’re not jumping back to what’s delivered when.
Hope Gurion: What I love about your PDF that you created about those questions is as a leader or for other leaders, depending on where the teams are—in terms of are they in the opportunity space or in the solution space or the outcome—those questions can help really make sure that they’re being the most helpful without being overly directive.
Teresa Torres: Exactly. And it’s such a hard balance. I think even at the end of that talk, I shared a story about how I even struggled with this, with the people that I work with. So we know this stuff is not easy. And so I think that’s a good place to end is just to remember that you’re not gonna be perfect at this. It’s really about how do you get a little bit better next week than you were last week. And be really nice to yourselves, because leading teams and being accountable for their outcomes is hard.
We’d love to see you in a future cohort of our Defining Outcomes course. Explore all the Product Talk Academy courses here.
