I worked with many Product Owners. Dozens, to be more precise. Youngsters and oldies; aggressive and chilled-out; domain experts and newcomers. And yet, one thing is for sure – boy, do I think that role is cursed!
I will focus this article on the traits that I found useful in POs that we enjoyed working with.
Who exactly is a Product Owner?
Great question right? Who are they? What exactly is their job and what’s their stake in the project?
I googled for an answer and here’s what I found:
The Product Owner (PO) is a member of the Agile Team responsible for defining Stories and prioritizing the Team Backlog to streamline the execution of program priorities while maintaining the conceptual and technical integrity of the Features or components for the team.Source: Scaled Agile
Honestly, I think this piece of information is as useful as a description of anxiety – it generalizes the meaning but everyone experiences it differently.
Is Product Owner part of a team?
This is one of the shady areas as well. On one hand, the definition of a PO states that PO is a part of the Agile Team.
And yet, I’ve heard of teams that fight heavily to keep PO out, not letting them communicate during the daily for example. Because, you know – they are not part of the team.
So, is PO part of the team that makes the stuff or are they the representative of the “cold-hearted evil management”? I’ll give you my PERSONAL OPINION based on the experience and observations — if you want to do good as a PO, you should act more as a team member and less like a commanding officer.
It’s a hard balance to maintain, I’m aware of that. On one hand, you want to ensure the on-time delivery of project and probably secure a promotion, while on the other hand you want to be humble enough and remain on ground enough and make yourself on par with development team (note: by development team I refer to programmers, QA, UI/UX, etc.!).
So, how to get it right, right? I’ll give you my personal take on it.
How to become a Product Owner that will be loved by your dev team
I’ll put a focus here on the traits that I’ve found to be most useful in POs that we (development team) enjoyed working with.
Don’t act selfish; it’s not YOUR but OUR product
I’ve seen and heard of this many times. POs acting as if it’s THEIR product and dev team is hired to do it for them. No bueno, trust me.
Now, I can see where this is coming from. Especially if you’re new to software development. To an untrained eye, development team can sometimes appear as a bunch of lazy drunks who give zero crap about the product being built. Doubly so if you’re new to this game.
As usual, the truth is really somewhere in between. And this is where it’s really important how you position yourself. If you start acting bossy – you will get slaves for sure. If you position yourself as “one of us” with the vision – you will get humble followers!
Even though the former model is surely functional, I’d advise you to go for latter. Unless you want to spend most of your time babysitting your team.
You should have a vision
The best POs I’ve worked with had a vision of where this boat is sailing at.
They know the value of the product being built, they know WHY it’s being built and they know how to pass that vision to their teammates.
You don’t have to know everything upfront
I find this to be one of the most honoured and favoured traits in some of the POs I used to be (and still am) working with. Being humble enough to say “I don’t know” in front of your team.
You’d assume this would make you weak? And, you are right, if you set yourself to act as a boss, then it sure is a weak trait. But, if you took my advice from above – I hope you made yourself part of the team. The team never knows all the answers upfront, but is ready to embrace on a mission of discovering them.
Remain open and candid
Be open with your team. Share your concerns, deadlines and pressure that you are experiencing.
It’s ok to be a human and we’ll appreciate you for it.
Be clear and feel free to ask your teammates for help
As I stated above – you don’t need to know everything upfront. It’s okay to now know and to ask for help.
That’s what teams are all about anyway. Having people gather together to find answers to thing that they don’t know how to do.
Make yourself part of the daily meeting
I honestly have no idea if this is really against any Scrum guide or not. And frankly I don’t care, as this is really my opinion on this. And my opinion is – you should make yourself part of the daily meeting and share what you did yesterday and what you’re planning to do today.
This way you are showing your teammates that you are feeling as one of them, while, at the same time being able to first-hand experience how it is to share your daily status. Just do it!
Enjoy the ride!
Building products is hard. Doubly so when there’s a lot of people involved. And yet, if you opted for doing it, you probably have a passion for building stuff.
It will be bumpy, it will be stressful, but I’d say it’s the ride that matters and not the outcome 🙂
Being a good Product Owner is tough. Acting as a proxy between two forces that are constantly trying to pull and push is a no joke. And yet, someone has to do it all while ensuring that everybody’s needs are met. That’s what makes this role a cursed one.
Stay humble, have a vision, make yourself part of the team and, I can’t promise you the positive outcome but I sure can tell you that you’ll be way better than if you acted differently!
If you liked this article, you might also like:
- Oh no, daily again!
- Story Points that mistook themselves for Hours
- Scrum. From developer’s perspective.
- Here’s why I see programming as an art form
If you prefer, you may also subscribe to my mailing list: