Hi there! For the past 18 months I have had the great opportunity of being Product Owner in a distributed development team. Head-count: 20 people, split up into two Scrum Teams. I would like to share the experience I’ve gained in this post – from Product Ownership in theory to how I applied things in practice. Disclaimer: Please be aware that I’ll only scratch the surface of that huge topic.
With great power comes great responsibility
I was a software developer and architect when our management approached me in 2014 asking if I wanted to take over the PO role for a JEE based web application. What I had heard so far about Product Owners were statements like “A Product Owner must be like Superman”. And of course I knew the role definition from some basic Scrum trainings. Being Superman? That somehow attracted me and I thought it would make a nice addition to my CV. Challenge accepted!
With great power comes great responsibility (this is valid for all kind of superheroes), so I said to myself it might make sense to elaborate in more detail what the role is intended to cover. In Munich, there was a training course on offer, held by a certain Jeff Patton, with the tempting title “Passionate Product Ownership (PPO)” and it included a free PO certificate without requiring me to pass one of those troublesome multiple choice exams. So I made my way to Munich. Hey: If you ever have the chance to enjoy a training course held by Jeff Patton, go for it. It was really inspiring to benefit from Jeff’s experience, and to learn about his views on Product Ownership.
The Product Team
Let’s start with some of my key learnings from the PPO training. The Product Owner is not the one person who takes all the decisions. Ideally, he leads a small Product Team covering the three major aspects of a successful product: Value, Feasibility and User Experience. These aspects need to be covered by true experts: Product Manager(s) who knows the target market, a Lead Developer or Architect who is able to roughly estimate if something is technically feasible and an Interaction Designer or Usability Engineer who understands the usability aspects of the product to be built. This team drives the process of transforming opportunities into actual product backlog items and takes decisions cooperatively. The obvious advantage of this approach: the product backlog will not contain items that are either not feasible, not usable or not valuable. Furthermore, there is always someone available who can take a decision.
My Superman vision started crumbling away with what I’d learned. I won’t be “the one and only” taking all the ultimate decisions concerning the product on my own? The PPO training turned out to be the kryptonite for my dreams of supremacy…
Being serious again: it is absolutely crucial (and it makes a lot of sense) that one does not take major decisions in areas where they are not fully competent. I realized more and more that my role would be to act as a facilitator for the key stakeholders of the web application we were developing.
Your job is to change the world
Product Ownership is about changing the world. What does that mean? In your Product Team, you have to identify opportunities in today’s world that can be turned into value. The key to success is not the amount of output your Scrum team produces. It is rather to reduce output, but to increase outcome and impact. The essence of business strategy is to decide what not to do. The smallest feature could have a very high impact. By just creating a lot of output you can quickly end up with a bungled product. As a Product Owner, you need to take care that you build the right product with your team. The following video illustrates nicely what might happen if you don’t have a clear vision:
Your stakeholders will constantly come up with feature requests and new ideas. Act like a doctor, not like a waiter in dealing with those. Imagine yourself sitting in a restaurant. You can demand whatever you want from the menu and the waiter will always serve it to you. Have you ever been told by a waiter “You shouldn’t eat the Schnitzel. This will have a bad effect on your body shape.”? Me neither. But when you visit your doctor, you can’t just ask for Valium. Well, if you can, the guy is called a dealer, not a doctor. He will rather investigate the cause of your current symptoms and find an adequate and sustainable treatment. You, as PO, always need to understand the root of the problem. Then decide what to do with your stakeholder’s request. Avoid asking “Why?”, but conjure up the magic question: “If you had that feature, what would you then do?” Or to formulate that a bit more straight-lined: don’t be a junk funnel, be a junk umbrella!
In my product context, the business projects impacting our web application had a very strong influence. I took on the doctor’s hat and consulted the projects. So in my Product Team were primarily people from these business projects, and we took reasonable decisions together.
The two-dimensional backlog
One of my key takeaways from the PPO training was the Story Mapping technique. In brief, Story Mapping is a technique for structuring a backlog and separating the essentials of a product from the nice-to-have features. You start with a high-level narrative story backbone and build more detailed items around that. A two-dimensional backlog emerges, serving as a nice overview of the product you are building. It enables good conversations and prioritisation. I highly recommend reading the book written by Jeff Patton for an introduction to this topic (Jeff Patton, User Story Mapping, O’Reilly Media). We adopted Story Mapping in a particular way, so evangelists please lay your bible aside or skip this section.
Prior to when we started using Story Mapping, we had a one-dimensional list of unprioritized user stories buried in our backlog tool. This caused some pain. Getting an overview of what was actually in the backlog was scarcely possible. As a result, dependencies between stories were almost invisible and identifying what to do next was a cumbersome task. Do you also suffer from meetings where a high number of people fall asleep or play around with their smartphones? In our team, this unfortunately was the backlog refinement meeting. We went through the immense list of backlog items again and again and again…
Story Mapping inspired me to do an experimental workshop with my team. I couldn’t go for the narrative flow approach with the usual activities backbone. We were more in a mode of serving five to ten business projects with various enhancements in our software. But I really liked the idea of having a two dimensional backlog and slicing the map into portions. Still being in Munich, I created a draft for that workshop in my Moleskine and sent out an invitation for a release kick-off workshop.
I really can’t stand those guys who get back from a training course with an “I’m now able to save the world” attitude. Can you? The bad thing was, when I returned from Munich a few days later, I was just such a guy. But the stage was set, with 20 people attending. There would be a lot of burned money, if this wasn’t successful. I initiated the workshop by explaining the major business goals of the business projects impacting our web application. These goals were the backbone of our Story Map. Immediately after that, I pinned the stories below their related project goals. Then I asked the team to split into groups of 4. This is dinner table size: 4 people will most likely have only one conversation going on. Their task: bring the stories of your business project into a reasonable order, taking into account business priority, technical risk, readiness, and dependencies. If you lack the knowledge to assess these aspects, get help from another team or from the PO.
Next, I revealed a ball of wool. I pulled the yarn along the wall to slice it at some random point. The next task for the groups: move everything we need to do in Sprint 1 above the line, the rest below. Then quickly present your results to the team. As expected, we had too much to build for Sprint 1. So the last task of the team was to select the most important stories and commit them to Sprint 1.
The Meeting was over. I took a deep breath. Wow. The meeting took less than 2 hours and I was impressed how well that worked. I set time boxes for each part and had a big timer on the screen so that the team had to work in a really focused manner. After the workshop, we had:
- a common understanding of what the entire release would be about, based on the business goals of our projects
- a reasonable choice of stories and a team commitment for Sprint 1
- happy team members because everybody could individually contribute
I asked the team for feedback immediately after the workshop. On a scale from “This was total crap, please don’t do it again.” to “Amazing! Would love to do it again.” Most of the crosses were close to “Amazing!”. I transferred the Story Map we’d built from the meeting room into our office space, so that it was visible all the time and we could do further backlog refinements and prioritisation directly in front of that wall.
I knew that my predecessor had accumulated a lot of overtime during the past 2 years. Is being Product Owner a stressful job? Yes, it is. If you’re the “9 to 5” guy, forget it. You won’t be happy. And neither will your stakeholders. Nevertheless, self-management is essential to protect you from losing the overview and from burning out. Scrum protects the Scrum Team from being overloaded in a nice way by promoting that the team commits itself for the sprint scope. Does it do the same for the Product Owner? Nah. I quickly realized that I need good self-management including the readiness to delegate work. I basically applied a personalized Zero-Inbox policy and a weekly based calendar refinement. Furthermore I had an amazing Scrum Team and so didn’t hesitate to delegate tasks. These measures led to an acceptable workload for most of the time. Some guidelines/thoughts from my experience that can make your life easier (this is not only recommended for product owners):
- For each e-mail you receive, ask yourself: Why are you the receiver? Could/Should it be addressed to someone else?
- For each meeting invitation you get, ask yourself: What will be my contribution to that topic? Do I really have to attend?
- In the bigger context, things are often not as urgent as they seem to the requester. Their topic is naturally the most pressing for them, but this is not necessarily true for you and the project as a whole. Relax and prioritise.
- There is always too much to build. Prioritise and don’t feel bad about it (that was a hard process for me because I am a very service-oriented guy working for an IT consulting company).
What’s left of Superman?
There is obviously so much more to say about product ownership. I have attempted to give you some basic insight into this huge topic and to share my personal experience. Looking back to my initial “Being Superman” vision, I conclude the following. There are a lot of people out there relying on you, and requesting the (formal) power you own and the services you offer. You need to keep track, prioritise and really take the responsibility that is attached to the PO role. In a way you really are Superman because you subordinate your ego for the benefit of the outcome.
Don’t hesitate to contact me to chat about product ownership. Take care and build great products!