Nasza strona używa cookies. Dowiedz się więcej o celu ich używania i zmianie ustawień w przeglądarce. Korzystając ze strony, wyrażasz zgodę na używanie cookies, zgodnie z aktualnymi ustawieniami przeglądarki. Rozumiem

Who can become a Product Owner

Check which skills you should have to become a great Product Owner.

Being a scrum product owner (PO) is tricky. You are like a king without an army, having a degree of power without direct ways of enforcing your will. It’s a managerial position like no other and requires slightly different skills when compared to a traditional leadership role.

Are you a developer that would like to try something different or business analyst ready to step up? Or a project manager that is witnessing an agile transformation and you want to see if you have what it takes to embrace your new role?

In this article, I want to present you the skills and character trades you will need to be an excellent product owner. Not surprisingly, they often match the agile values!


Modesty

Being a product owner is not really about the experience you have, the education or the upper management support. It’s all about research, numbers and later results. The basic scrum loop of inspection and adaptation applies to your PO actions even more than to the product itself. An excellent product owner will hardly ever make decisions based on his guts or because he was told to. Any backlog change must come because of good research and stellar numbers that can be easily explained to stakeholders and developers. A modest PO will allow his work to speak for himself, with no ego in the way of his success.


Diplomacy

While the numbers must speak for themselves, often enough politics are also a consideration. An excellent product owner must be able to navigate through a difficult web of mutual relations while still owning his backlog. Don’t get me wrong, it’s not like PO must seclude himself in an ivory tower and protect himself from external dependencies. Quite the opposite really! You must put yourself in the spotlight and be able to say “no”. Your confidence and arguments for refusing should, however, be fully transparent. Like in the modesty section, you should have all the right tools to protect your backlog whenever a stakeholder makes an unjust demand. However, please do not there is a deeper layer in refusing – you can’t make enemies. The numbers may speak for themselves, but they might not have the right bedside manner. You need to be a great PR person for those numbers too!


Always question oneself

Excellent product owner never trusts his success and never surrenders immediately. Let’s start with the less positive scenario. You have released a new feature – all the testing, preparation and research proven it will be a massive hit. However, the KPIs plummet and the feature must be hastily disabled. Now, of course, the scrum method does impose the need for understanding the reasons for the failure.  But those are often hard to understand or may not make a lot of sense. However, an excellent PO will not rest until the reasons for failure are understood. Perhaps there is one small detail, string or a weird bug that killed otherwise great increment? If you lack tools to understand why the feature failed, get those tools, improve the tracking or spend time in your analytics tools until you have a definite answer. Similar, in situations the new change was a massive hit – don’t settle on it. Look for weaker elements of the increment, be the harshest critic of your own work.


Empathy

We must remember that one of the lessons that scrum teaches is “People over processes”. The fact that PO can see the development team on the planning session alone, doesn’t mean he should. You need to make sure that people you work with like their job and sometimes factor in their personal ambitions and concerns into your sprints. Paying the technical debt isn’t a made up problem that developers come up with to prevent you from releasing your ground-breaking achievement quicker. Make sure your teammates’ (You are after all a scrum team’s member, not its leader) voices are heard and their efforts are appreciated. Trust in your team’s recommendations, even if you used to be a developer yourself. Understanding tech is great, shaping it directly as a product owner will often be counter-productive and might jeopardize your team’s morale and initiative. You’re all in this together and it’s up to you to make sure everyone enjoys their work!


Being ahead of the game!

Don’t ever forget your primary goal – to optimize the increments’ value, whatever that would mean for your product. In the middle of the struggle between development, reporting and stakeholder management, it’s easy to forget we are in times, where technology changes every day! Remember that PO is not a project manager – you are to make the best possible product choices and for that, you must have the widest possible product knowledge. Thus, make sure to find time to be an inventor and an explorer. Take time to read relevant books, magazines and websites. Stay on top of every competitors' moves and sometimes look into your “crystal ball” to try to predict the future.

Remember, nothing lasts forever and apart from assuring product’s success here and now, you also need to future-proof it. Dare to go even a step further! Imagine a world, where your product becomes obsolete, try to predict how could this happen and how to prevent it. If that is not possible, what other product can you start to develop to get your company ready and people employed?  


I hope I helped you answer whether a product owner career path is right for you. If you have any questions or wish to discuss this article be sure to email me at bartosz.jaworski@stepstone.com or LinkedIn.


Good luck with your products!