Where is the beginning and the end of the Product Owner’s responsibilities?
The role of the Product Owner requires numerous activities during the cycle of a product or a service. The Product Owners are involved in…
The role of the Product Owner requires numerous activities during the cycle of a product or a service. The Product Owners are involved in many different moments during the implementation of a feature or a change in behavior. The big question is, where do PO responsibilities begin and end?
Beginning
The beginning is not a big secret; the PO is responsible for understanding the need, organizing and structuring it, for example, for a new product, it is necessary to understand:
Which problem do we want to solve? We must realize the underneath problem, what is causing pains to our customers.
Who is the target audience? We must create empathy to understand our customers. We need to be precise in a way that we are clear about who our target audience is.
What is the connection between the product and the problem? This connection must be crystal clear. If the product or service is not solving a real challenge, then it is doomed.
For new features or changes, there are no significant differences. The important thing is always to understand what the problem is, and not just focus on solutions, because a solution that doesn’t solve any problem will not have adherence in the market.
Wearing the shoes of Product Owners, we need to ensure that we know our customers, meaning that we understand what their pain points are and what is essential for them. We must be sure that we are solving real pains and not just building a solution that doesn’t solve anything. My favorite technique for this is Canvas Value Proposition; once it is done correctly, we are sure that we know which direction we should go.
A successful Product Owner is collaborative, meaning that we are not a hero instead of work together with UX, UI, and developers to discuss openly about the problems and identify the alternatives. Every team member will have a different perspective, given the chance of everyone sharing what they see, will allow us to find insights and breakthroughs.
Only after clarifying and understanding the problem, then the PO goes on writing Epics and User Stories, this sequence is essential for a successful approach. Otherwise, we may not reach our desired goals.
Successful Product Owners are highly skilled communicators; we must be able to listen more than we talk beyond being great observers.
Ending
Now the critical question is: where do the PO’s responsibilities end?
Unfortunately, there is a big misunderstanding nowadays. I often come across scenarios where POs and others involved think that when delivering a particular demand in the production environment, the work is done. This statement is hugely incorrect. The PO does not just lead the team to provide features, the PO’s obligation is to maximize the value of the business, so only after measuring the results our work is done, not before. A PO must always measure the results to understand whether the result maximizes the business value as expected.
But why does it happen? In my humble opinion that occurs because of the mindset, though many companies think they work with agile frameworks like Scrum, the mindset is still waterfall. We end up having a kind of Waterscrumfall. What I want to say is that Scrum is not only a set of ceremonies, roles, and artifacts. The most important is the mindset. Unfortunately, many leaders still follow traditional approaches, where after a project is delivered, we jump to the next, in Scrum, we MUST do it differently.
What should we fight for?
User Stories need to be measurable: we need to start with the end in mind, meaning that we know how to measure if the expected value was reached or not
Discuss the problems, not solutions: talk to the team about the issues we want to solve
Build solutions together: be humble, the best solutions are the result of a great team collaboration
Measure the results: understand whether the outcome of the User Story reached the goal or not
Take decisions based on the outcome: what should we do based on the result we got?
Improve: the result was not convincing, but we are on the way, understand better, iterate and measure again
Pivot: the achieved result is not what we expected, but there’s another alternative, then pivot and test the new alternative
Stop: our assumption is proved wrong, so it is better to accept the loss and keep moving forward
The whole story is: Product Owners must focus on the outcome and not in the output.