OMG They made me Product Owner!!

The face of guy in the hallway expressed a mixture of euphoria and terror when I passed him in the hallway. We had met at the coffee machine before and we discussed how the company was moving to a more Scrum based way of developing their products.

Between euphoria and terror

“You sort of know how this PO thing works right?” was his first question. When I nodded, he confided in me that they had made him Product Owner of a new team, without prior training. In general, not the best start, but I can see why the guys were anxious to start: their Product would address a pain experienced by many of their clients, promising start! Over coffee and a whiteboard, we produced four steps you can take to kickstart a team that is new to Scrum and the Product Owner role.

Product | Which problem do you solve? 

There is so much you should do, but to get started: understand. If you inherit a product, make sure you get behind the business driver. Are we filling a gap in the portfolio? is it a stepping-stone product? what is our impact on brand and turnover? What problem does our product solve for the customer and why? can you spend some time with actual users of the product? and observe how they use the product? Go over the rolling wave plan. Create an overview of what the strategic themes are, the upcoming features and what is planned in the next sprints?

If you are still puzzled about the problem you are going to solve, don’t start solving it. It’s better to delay the start than to start without a goal. Note that this is not the same as not knowing how to solve the problem. You can start if you know what to solve and why, without knowing the how. If you picked your team right, they will know better than you how to solve the problem.

Personal | check in with the team

If want to work together as a team, you better know each other as a team. So here is what you can do:

• Who is on the team? and who is in supporting roles?
• For your team members: explain your strong feats. Why should they be happy to have you on the team, what are your strengths, passion if you like?
• Where can I use help? what takes you effort to do and where can you be supported so you have more time and energy for your awesomeness
• Crazy hobbies. Share something personal with the team, learn the person behind the coder, tester, designer etc. what makes us tick? We may have more in common than we think.
• What kind of person am I? I typically use the DISC model to describe who I am and why I behave as I behave. It’s not that I can’t switch between modes, it’s just that my natural stance is yellow for example. If you want to convince me, this is how you can say things I like and this is what most likely won’t work. Knowing what type of person you have on team is unbelievably valuable.
• What makes me happy?

Team | a good start

Next is to kickoff the new team. Who are we? what are our values? Of course, your Scrum master should help you with that, but you run the Product, which means you make sure it gets done. Once everyone has his or her avatar that resonates with the team’s name, work on the Definition of Done and stick it on the wall for everyone to see. This is a bit of interplay between the team and the Product Owner but it is very valuable not to have second-guess every single delivery. Next: move your desk and sit with the team. Seriously I don’t care about your corner office, sit with the team. Their non-verbal communication won’t propagate through Jira, and you need to hear their sighs if stuff turns out more difficult than expected. Or would you rather hear it after the Sprint Review, from the stakeholders?

Process | Align on your interpretation of Scrum

Make sure that what you call Scrum and they call Scrum is the same thing. The guide may be clear enough, but I have never seen two implementations that are the same, so check, check and double check. How does the release process work? In the end it is only value if people can use it. Do we release multiple times per day? once per sprint? slower?
It’s good practice to allocate “swimming lanes” for things like incident handling, helping other teams, improvements, and functional user stories. What are the investment ratio’s for these lanes? and what does improvements mean? Developers typically want to start refactoring the moment they press “save”. The problem is sometimes they are absolutely right to do so. Come up with a balanced way of allocating work so there is no confusion and expectations are managed.
This usually takes at least a day, but you will be in a better position by knowing why we are building our product, knowing each other and how we work together. Don’t forget to play a game together like Boris Glogger’s ball game and have some drinks.
Next day: Sprint 1, go and be awesome!

Want to learn more about agility, martial arts and product management? Go order the book from bol.com or managementbook.nl if you are in the Netherlands or Belgium or sign up to get the international edition.