← Scrum Master Toolbox Podcast: Agile storytelling from the trenches
Scrum Master Toolbox Podcast: Agile storytelling from the trenches
Beyond Product Knowledge—The Hidden Skills Every Product Owner Needs | Shawn Dsouza
00:15:11
Shawn Dsouza: Beyond Product Knowledge—The Hidden Skills Every Product Owner Needs Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website:...
Loading summary
Transcript17 lines
- [00:04]
A
Hey there, agile adventurer, just a quick question. What if for the price of a fancy coffee or half a pizza, you could unlock over 700 hours of the best agile content on the planet? That's audio, video, E courses, books, presentations, all that you can think of. But you can also join live calls with world class practitioners and hang out in a flame war free and AI slop clean slack with the sharpest minds in the game. Oh, and yes, you get direct access to me, Vasko, your Scrum Master Toolbox podcast. No, this is not a drill. It's this Scrum Master Toolbox membership. And it's your unfair advantage in the agile world. So if you want to know more, go check out scrummastertoolbox.org membership. That's scrummastertoolbox.org Membership. And check out all the goodies we have for you. Do it now. But if you're not doing it now, let's listen to the podcast.
- [01:12]
B
Hello everybody. Welcome to our Friday DGIF and product owner episode this week with Sean De Souza. Hey Sean, welcome back.
- [01:21]
C
Hey Vasco, glad to join in. I've been waiting for this day.
- [01:24]
B
Absolutely, we've all been waiting for Friday. Happy Friday everybody. All right, cool. So product owner is the topic. We're going to talk about great product owners in a minute. But for now let's start with the opposite. Potentially the worst product owner anti pattern you've witnessed in your career, Sean.
- [01:42]
C
Okay, so one of the worst product owner anti pattern. What I have witnessed is something which I call the forced product owner or the accidental product owner. Right? So now this happened more often than people admit. Someone leaves the pure role and organization instead of grooming a proper replacement. What they do is they simply make the person with the highest product knowledge as the product owner and they say, hey, congratulations, you are now the product owner. On paper, I would say it sounds very logical. In reality, product knowledge isn't alone enough. So the PO role kind of requires a mixture of skills. So there's prioritization, there is stakeholder management and saying no whenever needed and making sure that the backlog is laser focused on value. So here's what happened. So in one of the teams which I joined, the PO had resigned and they appointed their QA as the new product owner. And don't get me wrong, this person knew the product inside and out from the testing perspective. But he had never been trained to prioritize strategically or negotiate scope or how to handle the stakeholders. Whenever the team had a question, his immediate response was that I'll get Back to you. It might sound harmless, but over the time it creates a lot of delays and acts as a bottleneck. This was frustrating. The team and I could sense this, but instead of directly going to the PO and telling him that you're not doing your job right, I kind of took my advice from the advice trap book and I started asking him some questions. What's making it hard to decide? What are our priorities right now? Whom do you reach out to whenever you need clarification? Is there a way that we can involve them a little early on? Or if at all we had to ship only one thing in the sprint, what would it be? I think these questions helped him reflect more on his pure responsibilities and he started thinking about the challenges that he was facing. A lightweight framework. Together we had a very frequent short refinements. We made sure that these were more focused on making sure the items were ready and satisfied the definition of ready. I also joined the stakeholders sync so that he didn't have to struggle as a middleman between the stakeholders and the team. And I was there to help him out. And we had some priority guardrails where we would say that, okay, this is what we can deliver and this is what we are going to do. Eventually, we both completed our certification together. I got my PSM and he got his PSPO certification. And over time, he became very confident and started pushing back on unplanned work and, you know, began proactively, you know, involving stakeholders before decisions became like bottlenecks for us. He was like our mini CEO. So it is one of those moments when you see someone grow into the role not because they were told to do, but they were, you know, guided with the right questions and given the right structure and, you know, supported through the transition. And when Michael Stainer puts this in this way, the advice trap, he says that change doesn't start with the answer, it starts with the question. And this is one takeaway from me to any organization that's listening. A product owner is more than just a product expert. You can have the deepest product knowledge in the room, but if you can't prioritize, align stakeholders and make timely decision, your product will stall. If you are appointing a product owner internally, don't just hand them the title. So give them the right training, support them, give him the set of skill set that he needs to be a great po. So that is what turns the product knowledge into actual product value.
- [06:04]
B
Absolutely. And I really like the phrase, the change doesn't start with the answer. It starts with the question. This is Brilliant. And a great example. Another great advertising for the advice trap. So make sure to check that book. There's also an episode on Tuesday where you can hear more about that. Sean, that was the anti pattern. But of course there are also some amazing product owners out there. So potentially the best product owner you've ever worked with. How did they work?
- [06:35]
C
And I worked with many product owners over the years, but every now and then, you know, you meet that one extraordinary person who completely changes the game. This particular po, her name is Emilia. She turned user story writing into a superpower, I would say. So there's a very famous quote and I'd like to put it this way. User story writing was an art. I would say she was the Picasso of it. Right. And every single story was so clear, so well structured, that our refinement meeting started to feel suspiciously shot because we would just go into the story, ask a couple of questions and then we were almost done. So it was not like, okay, what does the PO actually want from this? She wasn't writing the user stories on her own. It was more like co crafting the user stories with the team. It used to be very detailed. I remember in one, I remember when she was going on a long vacation, a three weeks vacation, so she made sure that we were so well prepared for it. We spent a lot of time on the refinement so that, you know, during her absence, I would say we didn't just survive, we thrived. So yeah, this is what set her apart. Right. She just didn't rely on her own brilliance. She leveraged some tools as well. I remember she used to tell me that she uses Claude to brainstorm edge cases and acceptance criteria and use scopeilot to refine descriptions so that the devs would get exactly what they wanted. Because her stories were so detailed, the team's mental load kind of dropped. I would say instead of burning energy deciphering the requirement, we could pour it into actual problem solving and delivering values. These are some of the highlights and what I would say of how the user stories were crafted. There was story slicing. Instead of having one big chunk of user story, we used to cut it down into thin vertical slices. Then whenever we had a lot of unknowns, we used to make use of spikes. Very often what happens is in the acceptance criteria there are long assays that are being returned. But here she made sure that she gives very real life examples. So this is what the situation is and if we complete this user story, this is how it's going to look for the end user that really helped. Eventually the velocity also improved, the defect rate also dropped, and the team's morale went up. What I would say is a great PO doesn't just dump work into the backlog. They craft it so they shape it into something the team can run with. It should be clear, it should be actionable, and it should be meaningful.
- [09:35]
B
I think this is a great example of how important the refinement and the refinement conversations are when we work in a team that is developing software. You said something there that I thought was really important. The team, instead of spending time and using energy to try to understand or decipher, I think was the word that you used, decipher the requirements. The team. Team was able to go straight into problem solving and delivering. And I really like the story of this product owner because it emphasizes this aspect of the product owner, right? Like the product owner is there working with the team, working with the stakeholders, whoever they need to work with. But is there to be able to translate something that is amorphous, abstract, that comes from the outside, a requirement, into something concrete that the team understands. Even slicing it down, as you said, vertical slices. Even slicing it down so that the team can deliver incrementally. And that's why so often here on the podcast, we talk about the product owner being the Batman to our Robin, right? It's like you need the dynamic duo, we need the Scrum master and the product owner to work well together. And what you were talking about with the antiparten also reminded us that sometimes we're working with POS that need coaching. And coaching is important, right? The change starts with the question, not the answer. And I'll put the link in the show notes for our course on how to coach pos and what topics to bring up and how to address them, because that's a very important aspect of the work that we do. Not all product owners are as excellent as Emilia was when they start, but they all can be as excellent as Emilia was when we are there to help them. So it's an important realization. Thank you for sharing that with us, Sean.
- [11:27]
C
Great to share my stories, Vasco.
- [11:29]
B
Absolutely, Sean. This was a great week, filled with insights and amazing stories, but we're getting close to the end now. For those of us who want to know more about the work that you're doing, where can we go?
- [11:44]
C
There are a couple of places. One is, of course, my LinkedIn page. I'm also working on one of my websites, so once it's ready, maybe I'll reach out to you and can maybe give that link so this would tell more about me. I'm also coming up with a lot of retrospective ideas which is more based on the Indian context. So based on some movies and a few traditions that is practiced in India, I'm trying to connect these to our retrospectives and trying to come up with something new. I recently came up with something new called the Three Idiots Retrospective, which is a very famous movie in Bollywood. So yeah, I'll share more about it in my website and yeah, absolutely, we'll.
- [12:26]
B
Put the link to all of those in the show notes. So everybody check out Sean's LinkedIn. Start up a conversation, explore one of the topics together. And why not maybe even have a coaching session. Sean, it's been a pleasure. Thank you very much for being with us and for being so generous with your time and your knowledge.
- [12:48]
C
Same here. Oscar, thank you so much for inviting me. It was great talking to you.
- [12:54]
A
All right, I hope you liked this episode, but before you hit next episode, here's the deal. This podcast is powered by people like you. The members who wanted more than just inspiration. They wanted real tools and real connection to people who are practicing agile. Every day we're talking access to over 700 hours of agile Gold, CTO level strategy talks, Summit keynotes, live workshops, E courses, Deep Dive interviews, books, and if you're into no Estimates, we got the pioneers of no Estimates in those Deep Dive interviews as well. Agile Business Intelligence, creating Product visions, coaching your product owner courses, you name it. You'll get invites to monthly live Q&As with agile pioneers and practitioners, plus a private Slack community which is free of all of that AI slop you see everywhere. And of course without the flame wars, it's a community of practitioners that want to learn and thrive together. It's the best place to connect with community and learn together. So if this podcast has helped you before, imagine what you will get from this podcast membership. So head on over to scrummastertoolbox.org membership and join the community that's shaping the future of Agile. We have so much for you, so check out all the details@scrummastertoolbox.org membership because listening is great, it's important. But doing it together, that's next level. I'll see you in the community Slack we really hope you liked our show.
- [14:48]
B
And if you did, why not rate.
- [14:50]
A
This podcast on Stitcher or itunes?
- [14:53]
B
Share this podcast and let people, other Scrum masters, know about this valuable resource for their work. Remember that sharing is caring.