The Product Owner’s Curse

This article is part of my Agile series, where I discuss various Agile-related practices from developer’s point of view.

Background

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 🙂

Conclusion

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!

Good luck!

If you liked this article, you might also like:

If you want to stay up to date about what’s happening on this blog, you may befriend me on LinkedIn, follow my posts on Instagram and Twitter, or subscribe to RSS feed.

If you prefer, you may also subscribe to my mailing list:

6 thoughts on “The Product Owner’s Curse

  1. Great observation. I have almost the same point of view when it comes to this. One thing I would add is basic technical knowledge. When PO doesn’t know what is subdomain, client side, server side, backend, SEO etc. it becomes much harder to communicate. And the requests can often be… fairy tales. What do you think about that?

    1. Very valid point man! In my opinion, PO with a technical knowledge (or even better – background) is as close to superhuman as it gets!

      Now, should the tech knowledge be REQUIRED? I guess not. I’d rather say it’s definitely preferable for the exact reasons you named.

      But I also feel obliged to point out that I worked with some POs who had 0 tech knowledge, but what they did – they FULLY relied on being pretty transparent with us. They’d focus on Product Side only (as in – this is what we need) but would have full trust in team to decide on HOWs, without any interference (e.g. “can it be done faster”, etc.). That really worked well honestly (and still does). But I’ve heard quite some horror stories as well though (luckily, I wasn’t the actor there), so I can totally understand where you comment might be coming from.

      All in all, thanks a lot for the comment man! Really appreciated!

  2. Great article! I would add another trait of POs that I find useful and generally engineers may find useful, and curious to get your opinion on this:
    The PO should do reality-checks, to make sure that what the team is building is actually in line with customer expectations. These “reality checks” can take various forms:
    – demo-ing prototypes to customers in order to get feedback, and then share feedback with the team.
    – find real-world examples of how customers use different systems or features, and communicate them to the team.
    – explain to developers and designers why a certain workflow will or will not work for a particular set of customers, and bring arguments (no, your personal opinion as PO should not matter)

    Basically, the PO should be the voice of the customer on the team. And yes, I agree it’s ok to say: “I don’t know, but I will try to find out” in front of the team.

    1. Man, amen to what you said. As in, literally.

      I think you nailed it with this one: “The PO should do reality-checks, to make sure that what the team is building is actually in line with customer expectations. These “reality checks” can take various forms”.

      I seriously can’t agree more. Because I myself have been witness of projects that just gain … not sure how to call it, probably some kind of inertia or whatever. But they just keep going even though nobody’s sure if we’re on the right course any more. They just keep happening because it seems to be the easiest thing to do.

      So, again, I agree with you 100%. Doing occasional reality checks both with the customer AND with the team is something that I’d consider incredibly valuable.

      >> Basically, the PO should be the voice of the customer on the team

      Amen to that!

Leave a Reply

Your email address will not be published.

Scroll to top