Becoming a Product Owner, Part 1

I am programmer and Scrum Master but has been offered to become Product Owner for the same part of the product I am currently working on. I decided to accept the offer and this is my live story, written as I go. Perhaps this will be of interest to you.

First of all, to me, this was not a decision I took lighthearted. However, I do have the fortune of peer coaching at Crisp and the offer came the same morning we had our last coaching. That was a timing like there was a meaning behind.

It is not supposed to be full-time either, so I need to choose what I shall do the rest of my day. It turned out that initially there was no choice. It was not possibly to find a Scrum Master to fill in my gap. The next sprint I will be both PO and SM. Hua!

During the coaching I learned that some of us have full time as SM. I consider myself lucky not having that amount of impediments.

Can one be both SM and PO? Well we will see about that, but it is not a conflict as if they where representing two parties in a business deal. They are on the same agenda with a common goal, deliver business value and stay focused on that moving target called market.

So what do I do first? I attended Hans Brattberg‘s course “Scrum for PO” a year ago just out of curiosity, so I got the slides out and tried to get a grip of it again.

To no surprise for me, a PO is supposed to know the market, customers and users. I consider that a weak spot of mine. Since I have been working with the system for quite a while, I do have an understanding, but it is somewhat distorted as always when you learn a domain from the coding perspective. I know about lots of weird details and the current approach to supporting the business with IT but I do not know if there are anyone out there who has completely different idea.

My responsibility will be focused around replacing a legacy system. I can say a lot about that in particular but while refraining from comments, I can say that it has a classical problem with lots of external interfaces built on file exchange. I could get technical here, know what I mean?

With my PO goggles on, though, lots of external interfaces means lots of external stakeholders. I think that one of my first tasks will be to nail those. Who are they? What are their interest in my system?

Then there are the users in our (my client) organization. The legacy system has a horrible user experience which they have gotten used to. We need to step back a take new look so we do not end up in something that is pretty much the same but slightly better. Already we have done so but there is a lot more to do. Shall I as a PO, innovate? Well, I guess I should at least make the workshops happen where innovation takes place.

Balancing the urge for something better, is the fast replacement of the legacy system. It is labour-intense and support is a high risk so it costs every day. That balance is a true challenge.

I have also noticed that there is room for improvement on the transparency. Goals, vision and current progress of the teams has to come clearer to the rest of the organization. I think I need a wall some place where everyone can see it.

Come to think of it, all users that sit at the same location, what if I put up something for them to write on? A board where they can post immediately as they come to think of something. With headlines like “I wished that the system” and “This ruined my day”.

And then there is the product back log. As we are using Trac today, Jan Grape’s suggestions seems interesting.

Will there be a part 2? 😉

One response on “Becoming a Product Owner, Part 1

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.