
Anuj Ojha: Helping PO’s Move Beyond User Story Templates to True Customer Understanding 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: . The...
Loading summary
Vasco
Have you ever wondered what it really takes to make Agile work well? At the Global Agile Summit, we're bringing you real life first person stories of Agile succeeding out there in the real world that will inspire you to take action. Whether you're a leader, a product innovator, a developer, you'll hear practical insights from those who've done it. They'll be telling their own stories from the stage. I'll tell you more about this at the end of this episode. So stay back and listen to the full detailed description of what we have in store for you at the Global Agile Summit. But if you can't wait, you can go right now to globalagilesummit.com and check out our full schedule for now onto the episode. But I'll see you at the end of this episode with more details on the Global Agile Summit. Talk to you soon. Hello everybody. Welcome to our Friday, excuse me, our Friday episode, the product owner episode. And of course we are going to talk about amazing product owners and not so amazing product owners this week with Anush Osha. Hey Anush, welcome back.
Anush Osha
Hey Vasco, thank you so much. We are finding your Friday episode. Go ahead.
Vasco
Absolutely. And to start the day, let's start with and let's say maybe an anti pattern example of things product owners do that don't really work so well. So let's start there. Anush.
Anush Osha
Thank you Vasco. It's a very interesting role, product owner. I will say that if you do not have the right product owner in place, oh my goodness, what wrong can happen? Everything wrong can happen. So first thing first I would like to say that they need to know what is the role of the product owner and why you might have been hired so far. It might happen for filling your need. You might have been earlier before playing the role of a project manager or a business analyst or maybe qa. And now you're stepping into this role and you might have had different experience with the other product owners, but you should know first of all what your role is. So my first thing is whenever you know you become a product owner, you need to know why and the what of it instead of just jumping and to the backlog, writing the stories and coming to it. So one thing which I have experienced with the product owner is they think yes, of course we need to build a backlog and how to do it. Okay. Then comes a discovery mindset. Do you as a product understand how to do a discovery, whose problem it is? Do you know who are the Personas? Have you empathized with the Persona and made an empathy map for the Persona altogether. Then comes a point again to know that, okay, we know the Persona, but what is their current journey so far? How's it going? And then you're trying to identify what is a to be journey. Let's say a name called User Journey mapping. Have you done that or not? And then comes another part, that story mapping, where it's about going to the breadth and the depth of the to be flow and then collecting all the ideas in the world possible to address the problem that we're trying to solve. Without all this, why are you jumping directly to create a user story? And firstly, who told you that the user story is a part of a scrum, though it's not. It's not a part of the scrum. It is a practice in extreme programming where they talk about all these aspects, but suddenly in which school do we learn when it happens to us that we feel that it's all about just writing user stories and adhering to the template. And even without that, we are rushing to solve it and not even knowing the problem well. So my request to the product owner first would be a first anti pattern. What they could break is don't focus more onto writing documents where the whole point was not to have just enough documentation, but we see that we are focusing more on to writing the documents instead of understanding the problem and spending more time over it. So that's one thing which I want to say.
Vasco
So before, before we go any further though, Anush, I think it's really important for us to address this. So. So you described the proctor anti pat wanting to focus on the story writing, perhaps even writing all of the stories themselves and instead of understanding the customer, understanding what they are looking for, understanding their journey and so on. But how do you help a product owner get out of that mindset? Like how do you help them to focus on those steps that you were talking about? Right?
Anush Osha
Yeah, it's important first of all to ask the right questions to them. Many times we feel that they are trapped and reason why they are trapped because they are part of a bigger game in which they have to continuously produce certain things. And I see that they are more acting like a translator. Translator? Why? Because they have been asked to do certain job. Now again, understand product owners should be asked to do a job. No, no, no. Product owner should be the person who should go everywhere possible to identify what all things I need to do to get my goal achieved. So first thing is we have to stop them into doing what they are doing and Ask them or train them about certain fundamentals which because of which we have missed the outcome in a possible way. Example, I have worked with the product owner and I figured out that that person was so much engrossed into his role that didn't even know that what should be the next increment we should create. This person was purely busy into just writing, translating what customer has told into the call, adding those items from the call into the tickets and asking the team now you go do whatever you want and give me the solution for it when you are acting like a pseudo client. This is the point where we need to train product owner to probe and understand why customer wants it and do not take the solution from the customer the way how it is. So what it takes took we we let the senior product owners who have had a capability along with that I also have gone with the product owner and face the customer together. We we realize that why why the customer is behaving the way they are behaving, why they are getting dominant. Possibly they have problems with the solution. Okay. Possibly they the work what we might have given them in the past have not met their expectation and that's why they are babysitting us. That's why they are holding our hand and asking us to do exactly what it is. So we now need to build up a relationship. We now need to let them know that we will work on better experience of them. But you don't dictate us, okay? Don't tell us what should be the solution. We want to explore the problem and that's when we have scheduled certain customer interviews. That's when we have sent our product owner to the customer's place first and stay some time with them and just observe how they are doing what they are doing. And then based on that we should bring the problem back on the table for the entire team. You should not just be telling the problem through Jira ticket. You should be in the moment. So what we have understood even in the Sprint planning meeting, Vasco, the experience has been product owner starts with okay, these are the eight tickets that we need to finish in the Sprint. Stop it. Talk about why we started this project. Talk about where have we reached in the journey of the project. Talk about what we will achieve at the end of the Sprint will help us into taking the next three steps. Okay? Talk about what have we shown to the customer in our past experience and worked well and not worked well for them. And then tell the team that we have to find together how we can make the better experience so this change itself, I believe can onboard everyone around the product owner and bring data about it, do market research, identify the market rhythms and go proactively to the customer. Ask you, you know what happened. I just want to add like 30 seconds more every requirement at one of the client that we are working with. First thing what we did, we asked the product owner to put three indicators in front of all the requirements. Indicator 1 reactive, then responsive and then proactive. What has been the source of the requirement? 70% of the requirements were reactive. Okay. Proactive just 5%. Okay. And remaining were just responsive, just handling around and things. And that was when we realized that hey, we don't have the steering in the hand. Steering is in the customer or staring is the hand of the sales guy who is selling the requirement. You don't have steering, you are just sitting there. So that's what I want to say.
Vasco
Yeah. And that's very important what you just referred to. Right. We need to help the POs understand that they need to get the steering. It's not necessarily offered to them either. Right. Like they need to show that they can be trusted. They need to take initiative and great POs do. And that's what we're going to talk about next. Great pos. So share with us potentially the best product owner you've ever worked with. How did they work?
Anush Osha
The best product owner that I worked with have included everybody possible who are directly, indirectly affecting the product. Come together in the same room and talk. The product owner just has talked about the vision, the goal and the key problem that we are solving and then gave the entire house to the people to come together and solve it. Product owner was mindful to talk about the first MVP. Of course MVP's first and the other future releases. But let the team come in together and identify how are we going to address it. This person has made a point very clear that I am not going to go into the solution space. I will stay in the problem space and I will. You can ask me question when I am in the problem space, but I will ask you a question when you are in the solution space. But you are the owner of the solution space and I'm the owner of the problem space. And even I feel that at times I may miss the problem. Do you help me out? So that person that I know has been the darling of all the stakeholders, had a great relationship with the analytics team to fetch the right data was having, I would say absolute pain following up the customers and knowing that how are they doing what they are doing. How's the experience so far? And the customers, I don't know how but they used to end up loving him because that's the way how he has brought that kind of synergy. So it's about building relationship. It's also not about digressing. So many times it happens so that so many requirements comes to us for and we end up building a Frankenstein. And we have experienced that in that person which which we were coaching that this guy was always trying to keep things aside. You know, Eisenhower's metrics also where you need to know what's urgent and important and what's not that urgent important what to do to the T this person was following it and in the end was very careful that we all may be wrong and in the strategy ensure to fail faster continuously. So the customers were also working like a trusted partners and vice versa. It was more not more like a transactional relationship. When you move on from a transactional relationship towards trusting partner relationship, I believe Vasco the game changes the very moment it happens.
Vasco
That's a very good point also because of course software is developed by people and delivered to people in the end, right? Like software is a tool and I think that it's very important to realize that in the end we're not delivering software, we're delivering something that the customer wants through software. Software is the tool, it's not the goal. The goal is something else like reduce costs, increase customer acquisition, lower bugs, whatever the outcome is. So that's a really good point. Anush, this is a great story and of course we're getting close to the end. But before we go Anu share with us, where can people find out more about you and the work that you're doing?
Anush Osha
Vasco, I'm a co founder of a consulting firm called benzene.com and we pronounce it wrong. It is called B E N Z ne because the domain name with the right spelling was too expensive for a bootstrap like our to start. So please, I request everyone that there are a lot of blogs that we have on our website. Great learning material and we are open to share more with the community. In our truest sense we believe in driving I will say turnkey transformation and why I say the word framework agnostic because I do not want with my team ending up again as I used the word earlier, lipstick on the face of the organization. It should be meaningful engagement and helping them to grow. So we are benzene.com we are team of consultants and we look forward to make a mark into this world. With our small firm and if we could make some relevant change, we'll be very helpful. So this is me and that's it.
Vasco
Absolutely. And we'll put the link to benzin.com in the show notes so that people can easily find it. And and why not get in touch with Anuj? His LinkedIn profile is also in the show notes. So why not ask a few follow up questions, strike up a conversation? Anuj, it's been a pleasure. Thank you very much for your generosity with your time and your knowledge.
Anush Osha
Thank you so much Bosco for having me here and we look forward to talk more. Thanks again.
Vasco
Foreign thank you for staying here is all you need to know about the Global Agile Summit if you've ever suffered or know people who are suffering from agile fatigue, this event is for you. Agile fatigue is that feeling that settles in when we can't really see a light at the end of the tunnel. We get discouraged, especially when conversations revolve around the same old frameworks, the same old buzzwords and theories. We don't feel that energy anymore. Well, the Global Agile Summit is a different kind of event. We're bringing you real life first person stories of agile succeeding out there in the real world that will inspire you to take action and transform the way you work. The Global Agile Summit will happen in Tallinn, Estonia May 18th. That's the workshop day, and then 19th and 20th, the conference day. And Talinestone is one of the most innovative tech hubs in Europe. The Global Agile Summit is hosted together with Latitude 59, which is kind of a citywide celebration of software startups and groundbreaking ideas. And we'll have a shared ticket for you to attend attend those events as well. So who will be speaking? Well, we've got an incredible lineup of thought leaders in software and agile. For example, Clinton Keith, the person who wrote literally wrote the book on game development with Scrum and is busy bringing Agile to the world of game development. You must check his session. The very famous and well known Jurgen Apello, author of Management 3.0, will be talking and exploring about AI's impact on leadership. We also have Goiko Adsic, who's taking an unconventional look at product growth with his Lizard Optimization keynote. Other speakers include, for example, Sven Dietz, who's challenging everything we know about software development by ditching, literally ditching contracts and estimates. Can you imagine his teams deliver software before their competitors are even done with the contract negotiation? How agile is that? But there's more. We'll cover engineering practices in our developer track with talks on e.g. aI assisted test driven development, developing products in minutes with a different approach to how we develop, configure, deploy platforms and much more. We also have a product track where we cover cutting edge ideas around product discovery, delighting customers with product delight frameworks. We'll have a talk about that. And we also have an Agile Business track where we will talk about, for example Open strategy, a very agile approach to managing organizations and delivering software faster to clients faster than you can even write a contract. Literally. I mean, I already told you about Svendit's story is amazing. It definitely is a must see. I'm sure you'll be inspired and get a lot of ideas for your own software projects and software delivery. Now whether you're a business leader, product innovator or a developer, you'll definitely find value in our three focused tracks. That's Agile Business for those working with businesses and organizations, Agile Product for product managers, product owners and innovators and Agile Developer for the builders making Agile work in practice. The coders, the testers, the designers, the producers, the scrum masters, you name it. If you join, you will meet over 200 agile professionals from all over the world. People who just like you, want to grow, want to share and want to learn by challenging the ideas that don't work anymore at the Global Agile Summit, you'll get new connections, fresh ideas and the energy to take your own Agile to the next level level. And who knows, maybe even find your next career opportunity. So don't miss out. Check out the full program and grab your ticket now@globalagile summit.com I'm really looking forward to seeing you all in Tallinn, Estonia in May. I'll see you there.
Scrum Master Toolbox Podcast: Agile Storytelling from the Trenches
Episode: Helping PO’s Move Beyond User Story Templates to True Customer Understanding | Anuj Ojha
Host: Vasco Duarte
Guest: Anuj Ojha
Release Date: March 7, 2025
In this insightful episode of the Scrum Master Toolbox Podcast, host Vasco Duarte engages in a profound conversation with Anuj Ojha, an experienced Agile Coach and Certified Scrum Master. The discussion centers around empowering Product Owners (POs) to transcend the conventional confines of user story templates and cultivate a deeper, more empathetic understanding of their customers.
Anuj Ojha begins by highlighting prevalent anti-patterns that hinder Product Owners from effectively fulfilling their roles:
Overemphasis on Documentation: Anuj observes that some POs prioritize writing extensive user stories over comprehensively understanding customer needs.
"Don't focus more on writing documents where the whole point was not to have just enough documentation, but we see that we are focusing more on writing the documents instead of understanding the problem and spending more time over it."
[04:24]
Lack of Discovery Mindset: POs often jump directly into backlog creation without engaging in essential discovery activities, such as identifying personas, mapping user journeys, and conducting empathy exercises.
"Without all this, why are you jumping directly to create a user story? And firstly, who told you that the user story is a part of a scrum, though it's not."
[03:30]
Acting as Translators: Some POs become mere translators of customer demands into tickets, neglecting to probe deeper into the underlying problems and customer motivations.
"They have been asked to do a certain job. Now again, understand product owners should be asked to do a job. No, no, no. Product owner should be the person who should go everywhere possible to identify what all things I need to do to get my goal achieved."
[05:30]
Vasco Duarte inquires about actionable strategies to help POs overcome these anti-patterns. Anuj offers several approaches:
Asking the Right Questions: Encouraging POs to delve deeper by questioning the 'why' behind customer requests can foster a more analytical and empathetic approach.
"Ask them or train them about certain fundamentals which because of which we have missed the outcome in a possible way."
[05:35]
Engaging Directly with Customers: Anuj emphasizes the importance of POs spending time with customers to observe their behaviors and gather firsthand insights.
"We have sent our product owner to the customer's place first and stay some time with them and just observe how they are doing, what they are doing."
[06:45]
Collaborative Sprint Planning: Instead of merely listing tickets, POs should initiate discussions about the project's vision, past achievements, and future goals to align the team towards meaningful outcomes.
"Stop it. Talk about why we started this project. Talk about where have we reached in the journey of the project. Talk about what we will achieve at the end of the Sprint will help us into taking the next three steps."
[07:30]
Categorizing Requirements: Introducing indicators such as reactive, responsive, and proactive for each requirement helps in understanding their origins and steering the product development accordingly.
"We asked the product owner to put three indicators in front of all the requirements. Indicator 1 reactive, then responsive and then proactive."
[08:00]
Anuj shares qualities that distinguish exemplary Product Owners:
Visionary Leadership: Effective POs articulate a clear vision and set attainable goals without micromanaging the solution space.
"The product owner was mindful to talk about the first MVP... but let the team come in together and identify how are we going to address it."
[09:30]
Ownership of Problem Space: By owning the problem space and allowing the team to own the solution space, POs foster innovation and collective problem-solving.
"I am not going to go into the solution space. I will stay in the problem space... you are the owner of the solution space and I'm the owner of the problem space."
[10:10]
Relationship Building: Establishing trust-based partnerships with stakeholders and customers shifts interactions from transactional to collaborative, enhancing overall product quality and customer satisfaction.
"When you move on from a transactional relationship towards trusting partner relationship, I believe the game changes the very moment it happens."
[11:30]
Prioritization Skills: Utilizing frameworks like Eisenhower’s Matrix helps POs discern between urgent and important tasks, ensuring that the team focuses on what truly matters.
"Eisenhower's metrics... what to do to the T this person was following it and in the end was very careful that we all may be wrong and in the strategy ensure to fail faster continuously."
[10:50]
Anuj underscores that software development is fundamentally about people and their interactions. By fostering strong relationships with customers, analytics teams, and internal stakeholders, POs can better align product outcomes with customer needs.
Trusted Partnerships Over Transactions: Building deeper connections means POs can anticipate and adapt to customer needs more effectively, leading to products that genuinely solve customer problems.
"This is about building relationship. It's also not about digressing... trusted partners and vice versa."
[11:00]
Customer-Centric Approach: Understanding that software is merely a tool to achieve broader business goals helps POs and teams focus on delivering real value rather than just functional features.
"Software is not the goal. The goal is something else like reduce costs, increase customer acquisition, lower bugs, whatever the outcome is."
[12:00]
As the episode wraps up, Vasco invites listeners to connect with Anuj Ojha and explore further resources:
Connect with Anuj: Listeners can find more about Anuj’s work at benzene.com and connect with him on LinkedIn as provided in the show notes.
Global Agile Summit Promotion: Anuj briefly mentions the upcoming Global Agile Summit in Tallinn, Estonia, encouraging listeners to attend for deeper insights and networking opportunities.
"We're benzene.com, we are a team of consultants and we look forward to making a mark in this world. With our small firm, if we could make some relevant change, we'll be very helpful."
[12:37]
Vasco concludes by emphasizing the value of attending the Global Agile Summit for those experiencing Agile fatigue, promising real-life success stories and transformative insights.
Key Takeaways:
Resources:
Stay tuned for more episodes of the Scrum Master Toolbox Podcast for actionable advice and inspiring conversations to elevate your Agile practices.