Most of the topics I cover I directly related to the role of the Scrum Master. However, as a business owner, I have also been playing the role of the Product Owner for ScrumMastered.
As a Scrum Master you should support your Product Owner (PO), same as you support Developers. So knowing a bit more about the challenges your PO might be facing can really help you.. help them.
In this video, I’m sharing the five key lessons I learned as a Product Owner of ScrumMastered.
Let’s summarize what I talked about in the video:
Busy work ≠ great product.
This is an important lesson that can help your team get some of their valuable time back. Believe me, it’s better to spend some extra time on planning, than work on someone no one needs.
Usage = value delivered.
There are many value metrics that you can implement for your product. Some of them can be extremely helpful. However, sometimes they are difficult to set up and collect. So in the meantime you can focus on a very easy metric that you don’t even need to collect, you can just observe it: the usage rates. Do your customers actually use your product? If your customers are loving it, they will show it by using it.
Focus on the need, not solutions.
To help you create a product that is actually used by customers, you need to really understand their needs. The focus here is on the need. Many teams and POs fall into the trap of “knowing” the exact solution to customers’ problem, without realizing that they made too many assumptions and built a product customers don’t want.
A good example of this would be a thirsty customer. Let’s imagine you know that your customer wants to drink something because they are thirsty. If you are not careful you might jump to and assumption. For example, that they want to drink water, and start working on delivering just that. You focused on YOUR solution – water – instead of figuring out what customer’s ideal solution is. Maybe they want to drink tea! ☕
“Yes” also means “No”, and vice-versa.
This is my absolute favorite and the one that, for whatever reason, many people do not take into account.
Prioritizing your work, ordering your Product Backlog, is all about finding that balance between what you work on, and what you drop.
If you say “Yes” to one feature, you need to have a very clear understanding of what you are saying “No” to. That might be a good conversation to have with the stakeholders that have a tendency to interrupt your team’s Sprint 😉
Know when to pull the plug.
The hardest lesson of them all.
Sometimes your product is just not right. Customers don’t want it. Developers hate working with it. And generally, it seems that you’ve wasted time and money. It’s just not your best work.
You have to pull the plug and stop wasting more time and money in it.
I’ve worked with a company that built a platform for internal teams to use to build their websites. However, everybody hated it. It was clunky. It was too slow. And it was costly to maintain. Unfortunately, instead of pulling the plug, the company decided to continue building more products that no one wanted on top of that platform. What’s the reasoning? “We’ve already spent millions on it, we can’t stop now”.
Believe me, the better solution is to stop. Because remember, when you say “Yes” to work on unsuccessful products, you are saying “No” to other (potentially more profitable) opportunities.
Now it’s back to you.
What are some of the important insights and advice you would give to a Product Owner to help them be more successful?
Share your thoughts in the comments 👇
