Having spent so much time focusing on the “core skills” for Scrum Masters & Coaches, we’d forgotten how important it was to our own success as coaches to be able to work with Product Owners on refining their backlogs.
Coaches usually focus on skills like facilitation, team formation, and conflict resolution. In this episode, Peter and Richard argue that none of those things matter if a team doesn’t get product ownership right, so coaches need to be fluent in product skills and able to coach their clients to get better in that area.
Learn More
80/20 Product Backlog Refinement (online, self-guided)
Episode Transcription
Richard Lawrence
Welcome to the Humanizing Work Show!
In this episode, we’re talking about why it can be particularly useful for coaches to develop product management skills, even if they don’t specialize in that area.
Peter Green
Before we get to that… We want to encourage you to help us shape the Humanizing Work Show to be even more useful to you. So, send us an email at mailbag@humanizingwork.com with a challenge or question you’d love to hear us address on the show. We read every email our listeners send us.
Richard
And just a quick reminder to please rate and review the Humanizing Work Show in your podcast app, or if you’re watching on YouTube, please subscribe, like, and share today’s episode if you find it valuable. Your help spreading the word is super meaningful to us!
Peter
You can also get access to more free content we produce, not just the show—sign up for our newsletter where we share one key idea every week. Visit humanizingwork.com and use the form at the bottom of any page on the site. Now, on to today’s topic…
When we’re teaching and learning new skills, we often go fairly narrow in order to focus on skill development. For example, in our courses for ScrumMasters and Coaches, we focus on skills like facilitation, One on One coaching, conflict resolution, and leading change among others. That approach has the obvious upside of building skill in the areas that are relevant to the job. But there’s often a hidden downside to that level of focus.
Richard
We recently spun up a Customer Advisory Board to give us feedback and input on the beta of our new 80/20 Product Backlog Refinement course. We were surprised at the number of coaches and ScrumMasters who signed up, relative to the number of Product Owners and Product Managers. And then, during the reviews of the beta lessons in the course, we were surprised at how valuable the course content was to those coach participants. Having spent so much time focusing on more “core skills” or obvious skills for those roles, we’d forgotten how important it was to our own success as coaches to be able to work with Product Owners on refining the backlog better.
Peter
Ya, Richard, I think you’ve mentioned this before, but I wanted to check on this; you actually developed all of the Product Owner skills that you teach today, in your role as a coach—not actually by playing a Product Owner role. Is that right?
Richard
It’s true. I actually discovered the importance of Product Ownership as a coach. I started out in extreme programing as a developer, and so a lot of my coaching early on was focused on things like collaboration on the team and engineering practices and just getting better at delivering software every iteration, and a few years into that, I was working with a team where they went from struggling to delivering every week, in weekly iterations in about six weeks, and then we realized nobody wanted the thing that the team was building.
Up to that point, I think I’d gotten good Product Ownership for free, by just having good product people around me, and for that particular team, we couldn’t assume that, and this was also about the time I was getting into Eli Goldratt’s work, The Theory of Constraints, and I realized that if we look at the constraints for a typical product team, like software teams are, the first constraint on actually producing value, is having something valuable to build, so if you don’t get the Product Owner stuff in good shape, if you don’t have a backlog with meaningful slices of value on it, it doesn’t matter how well the team collaborates, it doesn’t matter how good your working agreements are, how good your engineering practices are, like the whole catalog of things that we might coach, and that others in the agile coaching or business coach world would coach, are all sort of downstream of resolving that constraint around product management.
So, I ended up getting into Product Ownership or product management, that direction, because I realized this is a problem that I’m going to have to address for any team that I work with, including my own, if we’re going to be successful.
Peter
Did you ever become a Product Owner on those teams, then?
Richard
I became a Product Owner on some of my own projects. I’ve been a Product Owner for software things over the years, like side projects and startups and things like that, but I didn’t want to just get in there and become the Product Owner for one of my client teams because great Product Owners need both domain expertise and product management expertise. You have to know your customer and know what to build, and you have to know how to get that information and how to work with a team– and so there’s two sets of skills you have to have, and a lot of times I didn’t have the domain expertise, but I could coach people who did, and help them develop the product skills that, when combined with their domain expertise, could be really powerful.
And some of the best Product Owners I have worked with have been people who have come from the domain. They’re an expert in healthcare or music production or something like that where I may not have a lot of domain expertise or, if I do, it doesn’t really matter as much. I can help them develop the skills to use their own domain expertise. Now, we talked back in episode 64, 7 Skills All Great Coaches Master, where we were talking about the Silsbee model and the different roles or voices a coach can take, and one of those is what Silsbee called the guide voice, where you are teaching a model; so it might be teaching the story splitting patterns from my story splitting poster. But when I am coaching Product Owners, I’m not just staying in that mode, like just purely teaching tools.
I think I’m most effective coaching Product Owners when it’s, “Here’s a tool, now let’s move to some of these other voices. What are some opportunities you see in using this for your domain? Let’s try some of it. Let me reflect how that’s working and ask you questions about it.” So you still do everything you would do as a coach, but you’re bringing these tools to bear in that guide role as a coach. You just can’t stay there.
Peter
Right.
Richard
Now I usually think of Product Owner coaching that I do as being really focused on those product skills and more or less domain agnostic. I know you find a little more value in using domain expertise when you have it, or maybe I do and I’m just less conscious of it. When it comes to coaching on the product side of things, what are some of the benefits and tradeoffs that you see for a coach having domain expertise in the thing they’re coaching?
Peter
I think the biggest benefit to having domain expertise is that it can get you permission to coach. I can think of a lot of clients—I’ve done a lot of work with people, organizations and teams that build audio software. I’ve got a lot of domain expertise in that space. That was my original job, right? I was building audio software. So I know that gets me in the door a lot with companies like that. And then, I’ve got to sort of manage that domain expertise in a mindful way the same as any coach who has expertise in a domain. I think of the episode we did where we interviewed Lee on how he coaches mountain biking. And Lee realized– and I realized the same thing– which is that if we just tell the person what to do, because we know that this is the right decision to make, that does not build any expertise for them. It’s not a skill build for them. You really do need to go back to those coaching tools that you mentioned in the Silsbee model. And so I think the primary upside is sort of a reputational one. To say, “All right. We’ll pay attention to what this guy has to say, because he’s done this—you know. He has expertise that goes back a long way.”
But then, you have to go into what Silsbee calls the role of master. The master coach is really a mastery, a mindfulness approach; to say, “I would love to jump in and just solve this problem for them, because that would probably be a quick win, but that is not coaching, because it’s not building that expertise.” So that’s the downside to it.
I’m curious what Product Owner-related skills coaches of agile teams really need in order to be successful. I can think of just all kinds of things that you could focus on as a coach in the Product Owner domain. I’m curious: What are some of the ones that you would put kind of at the top of the list? If you could only guarantee one or a few skills for any agile coach to have, which ones would you guarantee?
Richard
I think I ended up developing almost all of the skills and tools that I teach in this area based on client needs.
For example, the original story splitting flow chart; the thing that most people associate with my work, was actually originally a coaching tool. I had written the “patterns for splitting user stories” article, and then over the next few years, as I was coaching people to use the patterns, I realized I was asking the same sequence of questions and I could give that to them or give that to other coaches or ScrumMasters, and the flow chart was really just the virtual story splitting coach.
So, (1) I think story splitting is one of those essential skills. If a team you are working with as an agile coach is struggling with finding small vertical slices of value, then they’re probably struggling with everything else in an agile approach because, as we’ve talked about before, it’s the keystone habit. It’s the thing that makes everything else work and, in its absence, almost nothing else works. So that’s the number one skill. And if you don’t have that, that’s a place to get fluent.
Similarly, (2) feature mining is something I developed to help coach clients who needed to start a big complex initiative and wanted to do it with a small slice and get value learning—risk mitigation.
And (3) the PO board, which we’ve talked about on the show before, was something I created to coach overwhelmed Product Owners I was working with at the time to get just enough detail, right when they need it. So those are three of the core things that we teach in our new 80/20 Product Backlog Refinement course and, while it’s targeted at Product Owners, and I’m teaching in those lessons as if I’m talking to Product Owners, it gives coaches who take it all the same core tools that we use when we’re coaching product people in our work, and it’s hard to imagine not having those in my toolbox now, when I work with a client.
Peter
Yeah. Very true. As you were describing those, it occurred to me that in addition to kind of the tools and techniques that we teach in the 80/20 course, I think that there are sort of some underlying ways of thinking that those are just examples of, and then the lessons in the course, to some extent, are just illustration after illustration of those core mental models or ways of thinking. For example, a lot of what we cover in 80/20 is really focused on how complexity impacts product backlog refinement. If you’re managing a backlog made up of things that have complexity and uncertainly to them, that’s a different approach to how you would refine a backlog that’s made up primarily of predictable, complicated things. And I think most of the advice out there on backlog refinement that I sort of look at as naïve or maybe even cringy, is not naïve or cringy, it’s just the thing that you would do if your backlog was all predictable things, and so understanding what to do related to managing and refining the backlog when the work is complex is something that I think underlies all of the lessons in the 80/20 course.
Richard
If your go-to move is better analysis and more comprehensive specifications—like “We gotta get all of the acceptance criteria—we gotta write all of the stories.” That might be useful in the complicated domain when you’re in the space of analysis, but that’s not where most of our clients are working when they’re building interesting, valuable things; and so, being able to identify when you’re in more of the complex space, and bringing the right tools to bear are super important for a coach.
Peter
And then, we mentioned this a little bit in actually in the last episode, when we were talking about this idea that you really can split anything, but, when things are complex, it’s even more important, I think, to start with a small thing, so that we get a little bit of learning from it, and for a coach, I see how 80/20 can build confidence that, “Hey as a team, I can help them figure out how to split and refine anything that might come our way, no matter how complex it is, and then the coach’s confidence in that can sort of carry the Product Owner and the team, until the team and the Product Owner learn how to do that, they develop a similar confidence in that, and it’s really become a habit that this is just how we split things now.
Richard
It’s similar to the good facilitator carrying a group through the “groan zone” of exploration. Like having the faith for the whole group that we’re going to get through this and be successful and, if you’re trying to do that around something like story splitting, you don’t want to be bluffing that confidence. You want to be showing up as somebody who has done this in a lot of domains, you know the patterns inside and out and you really believe you can take them through it. And when you have that, it also makes space for the team and the Product Owner to be in it together, wrestling with the challenge of figuring out how to do this, versus kind of taking adversarial positions in a debate about how to split things or whether it’s even possible, like the Product Owner pushing for splitting and the team pushing back, you get to be the one making it possible for them to wrestle with the problem as one team, and I think that carries a lot of value too.
Peter
And then, the other underlying theme that I noticed throughout this, when you were talking about, “Well why don’t I just turn this into a poster?” or, “Hey, the POs are struggling, why don’t I create this PO board model?” is something that we just say over and over again, because of how valuable it’s been to us– which is, “If something is tricky, visualize it.” And there are dozens of examples of visualizing tricky problems in the course, to help make sense of them for the Product Owners, for the team, for the stakeholders—whoever needs to see it. And so, I think coaches will no doubt want to borrow some of our visualization things that we’ve worked out, some of those patterns, but I also think that coaches—this is true for me—is that I’ll often look at somebody else’s visual and that will—I won’t copy it exactly, but it will inspire a variation on that. And I hope that coaches who go through the 80/20 course will be inspired by the visualizations and want to create some of their own, to solve their own tricky problems that are specific to their teams or their organizations.
Richard
So, if you’re a coach and you see room to level up your product skills to be able to help your clients more in this area, I can’t recommend strongly enough checking out our new course 80/20 Product Backlog Refinement. It’s a collection of the product tools and skills we use the most with our clients, and I think they’ll be valuable in your coaching toolbox too.
Peter
Ya, I’m really proud of the way that this course has turned out, and excited for people to start using it and to benefit from it. It’s one of the things that is hard for us to do in our normal business model, which is we can focus really deep with a few people at a time. And we’re really excited to get this out there in a format that allows it to go really broadly with lots of people and so we’re excited for everyone to check out the course and to really get these benefits whether you’re a Product Owner or a product manager, which is sort who we thought we were building the course for and who it will serve well, but also for coaches and ScrumMasters and folks who are coaching people in these roles, we look forward to hearing from you how this might benefit you, so thanks for tuning in today.
Last updated