Product Owners must know their customers to succeed in today’s competitive markets. There is a common agreement among experts involved in product management about it. A lot has been said about this topic. In this blog post, I discuss the different ways to know your customers. To make it more practical, I share some tools to ease application in the work environment.
Organizations have been taking their efforts toward Agility for many years. Some of them seem to be successful in this field, and some of them are not.
So, how to measure the results and benefits of this effort?
Interestingly, so many organizations have revenue or profit as their Product Goals as well as Strategic
Goals. Some organizations do not consider using Product Goals at all. Or they are not aware of this
How often have you thought: "This Sprint Review is useless and boring!" or "We are just reviewing
internally what we already have seen before as a Scrum Team. We have no new feedback. Let's skip
this event. Waste of time."
How often have you been exposed to the conflict or different objectives between departments? If
never, congratulations! You have probably seen and experienced healthy environments, meaningful
shared goals, and true leaders. Keep on!
Previously, I have described some challenges with the Evidence-Based Management implementation. There are plenty of challenges regarding the process of applying Evidence-Based Management, there are also great results.
People in organizations are often afraid of running experiments. I have observed that approximately 70% of people responsible and accountable for products are reluctant to validate their assumptions by experimenting. There are several reasons for this hesitancy. The most common is misunderstanding what exactly the Agile experiment means. The second one is the negative result of the experiment. I always answer that this is fine that we have such a result! It means that there is no need to develop a solution that no one wants or does not fulfill users' expectations.
Based on my experience working in agile environments since 2010, I did some research and had general observations on the topic. Regardless of the business domains or product area, there are some common rules that may devastate your efforts toward agility.
Large numbers of Product Owners begin their work by creating requirements. In some situations, these scopes are dictated by others. Their work mainly consists of describing demands, thus apparently appearing as a scribe in their role.
In this blog, Professional Scrum Trainer Magdalena Firlit talks about some of the differences in words between English and the Slavic languages with helpful tips for translations when it comes to Professional Scrum certification assessments.
While working with plenty of Scrum Teams and teaching Professional Scrum Product Owner classes, I observed a similar anti-pattern regarding Product Owners, which resembles anti-patterns of Scrum Masters who are not empowered.
Through my professional experience, while serving my customers, working with Scrum Teams and training people in Professional Scrum, I have observed that some Scrum Masters only work to serve the Development Team and the Product Owner.