Three lessons learned as a Product Owner

Three lessons learned as a Product Owner

Big Thoughts

10 February 2014 • Written by Jonathan Scher

Agile Consultant Jonathan Scher explains how his first experience as a Product Owner taught him three crucial lessons...

An explosive context

In France, everyone goes on summer leave in August. So my manager came to me and asked, “Hey Jonathan, how about being a Product Owner?” I said yes and became a Product Owner (PO) for four months.

This turned out to be an incredible opportunity as I uncovered three valuable lessons that can help you become a successful Product Owner.

Here’s the context. As the French government doesn’t like to see its data stored in foreign countries, it decided to finance two major telecom companies to build a French cloud offering and gave them 125 million euros each. SFR decided to use this money to create a separate company which it called Numergy, with help from a second security company called Bull. In 2012, telecom companies were on the spot. A new competitor had just risen up and proposed subscriptions 10 times cheaper than the average. Jobs weren’t guaranteed and many departments saw this programme as their salvation.

SFR decided to use the cloud infrastructure they’d been developing for three years. They assembled three teams sharing 10 developers, two web designers, two architects and three Product Owners on the different products needed to start the new company. Scrum was the way to ship the product before the competition.

As one of three Product Owners for the cloud product, I was responsible for building the Information System and was also the back-up Product Owner for the website. Before starting, I would have looked at functional knowledge as the most important requirement for a successful PO. But I quickly learned that soft skills are way more important.

Official definition of a Product Owner

Scrum.org publishes the Scrum Guide every year. In 2013, the detailed definition of a Product Owner on page five is that:

  • “The Product Owner is responsible for maximizing the value of the product and the work of the development team [...]

  • The Product Owner is the sole person responsible for managing the Product Backlog [...]

  • For the Product Owner to succeed, the entire organization must respect his or her decisions”

The reality is different. The value of the product is often difficult to assess. Is the value of being able to invoice your customers more or less valuable than being able to pay your employees? I was the sole person responsible for managing the Product Backlog. However, being a consultant, my decisions weren’t as respected as described above.

Even with all these restrictions, I was able to be a cornerstone for the management of this project and I learned some fundamental lessons along the way.

Lesson 1: You own nothing!

You may be a partner in your company, investing your own money into your product. Your experience may be different from mine. Being paid on a regular basis, the product was not mine, despite my status. The product was owned by a group of stakeholders. A Product Owner’s responsibility is to make them agree on the product development path.

Numergy’s website was going nowhere. The SFR Marketing department wanted it to sell B2B products. The SFR Strategy department wanted it to redirect to SFR products as much as possible. SFR operations wanted it to bring as little new functionality as possible, but SFR Brand wanted it to follow strict rules – implying the use of cutting-edge technology. An external agency was asked to design the website, but no one seemed to agree on anything.

As a back-up PO, I had to clear this up. It wasn’t possible to get all the stakeholders into a single meeting. So I sent an email to everyone asking what the top priority of the website was. No one could answer it. I explained that I had to clarify these points within a month or I would make choices for the stakeholders. I booked a one-hour discussion with every individual. Each person explained his purpose and the others then added to that purpose. A few discussions and some meetings later, the whole organisation was aligned on the number one goal of the website.

If it was the Product Owner’s product, he could come up with answers himself. But a product is really owned by its stakeholders. The Product Owner’s role is to align multiple stakeholders, not to make decisions independently. To align multiple people, you have to clarify and share the purpose of your project!

Lesson 2: Clear purpose and challenges: your top priority

Who will decide if your project is a success or a failure and based on what criteria? These two things will determine whether you are a good PO or not. For you to be aware of that is not enough: your entire team should know. I learned this the hard way.

Our information system was running smoothly. One of the characteristics of these kinds of projects is the secrecy that surrounds them. Nothing should leak to the competition so things are rarely even shared internally. One of the stakeholders then told me about the acceptance document. While the due date for the project wasn’t until December, it was early in November and we needed this document. I requested it and it arrived five days later, signed by the CEO, stating that once the testing was done, 37 million euros would be released. The document also listed precise acceptance tests… and most of the didn’t match at all with our development! The testing was due in 10 days. As you can imagine, the pressure was on.

My team had to work very hard to match the tests and we lost a good developer in the process. Finally, we were able to amend one criteria and pass all the others except for one minor one. The money was released.

This stress may have been avoided by checking the success criteria from the outset. And it was the Product Owner’s role to make it clear and to share it with the team and the stakeholders. One person said that it was a process problem – Scrum should include a ‘define success’ stage at the beginning. I would argue against this with my last lesson learned…

Lesson 3: It’s always a people problem

This is a quote from G. Weinberg in his book Secrets of Consulting: “No matter how it looks at first, it's always a people problem”. Any problem that arises can be tracked to and worked out with a person responsible for it.

On one hand, you have stakeholders that want the moon, right here and yesterday. On the other hand, you have a team that will do the best they can. The Product Owner’s job is to align all these people on a collaboratively agreed set of objectives. Taking the time to talk with each individual proved to be the best tool for that, helping me to avoid many crises like the following.

Once again, we were late on a delivery. One developer, to please the customer representative, was being very optimistic. He announced that he could finish his component in less than a week. He started working on it, including overtime – despite the fact that the component he was working on wasn’t critical. By having a one-on-one discussion with him at lunch, we figured out what was happening and were able to come up with a back-up plan and a much more reasonable estimate.

The PO role is much more people-oriented than product-oriented!

Not a product specialist!

Starting as a Product Owner in a cloud computing company, I was afraid that I didn’t know enough about the product. It turned out that my most valuable skills were my soft ones – getting people to talk to each other.

As a PO, you interact daily with lots of people. Your most important role is not as a product expert, technical specialist, business analyst or any other role needed to build a beautiful product. While soft skills are important for everybody in an Agile team, they are absolutely crucial for the PO. In a nutshell, the Product Owner is the glue that helps people with these skills transform ideas into working software.

Search the Assurity website (Hit ESC to cancel)