Let’s make a Product Owner

Transition from business analyst into Product Owner is not that simple, trust me.


Recently everybody talks Scrum, everybody does Scrum, everybody is Scrum! Almost like in some hoary, old joke – „I am afraid to open the fridge. I don’t want to see anything connected to Scrum in there”.

Have you ever wondered where your Product Owner is? Or maybe you use to be a business analyst, and now you are proudly called a „Product Owner”? Or you have a bunch of business analysts sitting somewhere covered in dust, and you’re wondering what to do with them because the Scrum days are coming?

If those two roles (business analyst and Product Owner) are spoken together, it most likely means that we’re in a huge software development corporation that was around forever. I am talking about the ones that were developing software long before I was born (and I was born in the early 80’s). And, most likely, there is a transition situation from so-called „traditional approach” (a.k.a. waterfall). The transition in most cases looks really simple to do:

– „Hey, Peter, here’s this Scrum thing, it’s great! Let’s do this.”

– „Sure John, when we do that we will be so Agile! And we’ll have a lot of money. Let’s figure out who does what now!”

– „Right, developers write code – simple! QAs – they test right? Let’s train them to write code – we will have automatic tests!”

– „Perfect, John – can I be Scrum Master – I always wanted to be a master of some sort?”

– „Of course, you can, you among all the developers have some social skills left. But we need to figure out who the Product Owner is, thoughts?”

– „Well, those business analysts… What do they do? They know business – otherwise, why would they be called business analysts?”

– „Yes! And I saw one of them TALK to someone the other day, I guess it was a CLIENT!”

– „Great, we have our Product Owner!”

I’ve been there; I saw that.I don’t want to talk about the transition itself, sometimes its done in a good way, sometimes its done in a terrible way. Now I want to focus on one particular transition – transforming a business analyst into a Product Owner. Camaro into Bumblebee, Pikachu into Raichu, Anakin Skywalker into … ok, that’s too far.

Have a look at what Scrum Guide says about the PO:

The Product Owner is the sole person responsible for managing the Product Backlog. Product Backlog management includes:

  • Clearly expressing Product Backlog items;
  • Ordering the items in the Product Backlog to best achieve goals and missions;
  • Optimizing the value of the work the Development Team performs;
  • Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what the Scrum Team will work on next; and,
  • Ensuring the Development Team understands items in the Product Backlog to the level needed

Well – a lot of BAs do all those things before they are called Product Owners. Moreover, if you are a BA and are not able to perform any one of those duties – you’re probably doing something wrong. So this looks like a natural transition, but to my mind, it is not so easy.

The most important thing that they say about the Product Owner on any Scrum training is that the PO needs to have a VISION OF THE PRODUCT.

And this is what most of the BAs that work in big corporations do not have. Here’s why:

  • A lot of business analysts are focusing on a part of the product. They are subject matter experts on one or couple of functionalities, but they do not see the full picture so well. Mostly the system is so complex, that it is impossible to know all the details. And BA work is all about the details!
  • BAs often do not work on the same team as developers. For the techie guys, they are those strange, mythical people that sometimes make coffee in the same coffee machines. I saw a project where these two groups did not talk to each other at all. It is really difficult to „Optimize the value of the work…” when this occurs
  • But most important of this all – BAs often do not even see or speak to the client! Yes, that’s true! Especially if you are working on a huge, off-the-shelf product – it is virtually impossible to have contact with the client. In between you as a BA and a client, there’s sometimes a proxy. Often the proxy is called „Marketing” and does not want to have anything to do with this „scrum thing of yours”. Sadly, those people often set your priorities … and have VISION OF THE PRODUCT.

So what really needs to happen to transition a business analyst into Product Owner properly? Business analyst really needs to have contact with the client. And she/he needs to own the VISION. She/he really needs to be able to make decisions on priorities! Otherwise, PO is just a label on one of your BAs. And you have PO somewhere else. Where? The same place where your vision is. Hint – look inside your marketing department.

5 thoughts on “Let’s make a Product Owner”

  1. I’m not sure why You consider Marketing as an owner of communication with customer such a drawback. As long as they talk with PO, share their vision of product and take feedback from POs I don’t see anything very bad in such situation. Take into consideration a situation when there’s a bunch of Scrum teams and POs working on a medium to large product/project – would You rather have POs available for Scrum teams or travelling between customers to gather their feedback and share the vision?


    1. What I am trying to say is that the “proxy” situation you have described is not a good thing. PO should have both – contact with the client and access to Scrum teams. If a PO is missing one piece of this equation, the PO is not really a PO. When the BA is suddenly a PO without access to client she/he is just a backlog manager without power to make decisions on priorities. These are given.

      Also, the large product/project situation requires to scale Scrum. In Nexus there is an Integration Team and PO is part of the team. Still, there is a single PO, according to the guide: “Product Backlog has a single Product Owner who has the final say on its contents”


    2. Also the following from Ben Horowitz’s “Good Product Manager, Bad Product Manager” could be quoted here: “Good teams have a compelling product vision that they pursue with a missionary-like person. Bad teams are mercenaries. Good teams get their inspiration and product ideas from their scorecard KPIs, from observing customers struggle, from analyzing the data customers generate from using their product (…) Bad teams gather requirements from sales and customers (…) “


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s