From 2010–2015 I worked as a Scrum Master for a web agency. We developed software solutions for external clients. When I started, Scrum wasn’t used at all. It was something we figured out along the way. I changed my role from Project Manager to Scrum Master, the developers slowly moved from programmers to product developers, and we tried many experiments with the Product Owner role because that proved to be a returning challenge. In the context of Scrum, the Product Owner plays an essential role. But who should become the Product Owner?
This question recently emerged again in a conversation on LinkedIn. Answering it in a bunch of short comments proved quite challenging, so I promised to share my thoughts in more detail in a blog post. In this article, I’ll share how we addressed this challenge, what experiments we tried, and what insights I gained from the period after 2015.
Word of warning, this isn’t going to be a “Scrum Guide post”. I’ll simply share the things we tried, please don’t be shocked if it isn’t fully according to the letter of Scrum. That’s what I recommend anyhow, figure out what works for your context.
When I started with Scrum, I changed my role from Project Manager to Scrum Master, the developers slowly moved from ‘programmers to product developers’, yet the Product Owner role remained challenging to fulfill.
A bit of background
Stop writing proposals ✍️, start selling Sprints 💰
That’s in a nutshell the approach we used within our Scrum team. Long story short; we had many bad experiences with spending months writing detailed proposals only to discover things always worked out differently. 🤷 So, we stopped writing proposals. Instead, we started selling Sprints.
Whenever a customer approached us, we would…
- Create the product vision & backlog together. Remember, no contract was signed at this point. The customer shared their ideas, and we would create a product vision, roadmap, and Product Backlog together.
- Estimate the Product Backlog together. Our first version of the Product Backlog mostly contained large chunks of work. At the end of the session, we would make a rough estimation: “With the knowledge, we have at this point in time, we think it will take us somewhere between 5–7 Sprints”.
- Start small. As a start, the customer would only buy 1 Sprint. Even if they were already willing to pay for more, we only signed a contract for 1 Sprint. This would result in a Done increment. If they were satisfied, they could buy more Sprints.
- Invite customers to the Scrum events. In particular, the Sprint Review, and optionally as an observer to the other Scrum events. The customer would pay for a total package, this includes the hours we spent in the Scrum events. Some customers were curious to learn what these events were about. So, to build trust, we invited them to the Daily Scrum (as an exception), and they also actively joined refinement sessions.
- Sell the entire team as a ‘package’. The customers got the entire team, including the tester, analyst, designer, Scrum master, developers, etc. No discussion about hours and roles. This saved us a lot of discussions. Because many customers didn’t see the value of e.g. a Scrum Master or a tester. Selling it as a package allowed us to sidestep this painful and time-consuming debate.
- Sell Sprints. Because the team was fixed the customer also knew what the costs per Sprint were, for example, 40.000,-. This means the necessary budget for this project would be between 200.000,- and 280.000,- (given the estimate of 5–7 Sprints). Although the customer only bought 1 Sprint at the start, they did have the option to buy multiple Sprints afterward. This gave us some security and continuity as well.
- Give customers the option to stop at any moment. By selling Sprints, an advantage for the customer is the possibility of early termination of the contract. An important requirement was that each Sprint should result in a Done increment. When the cost of continuing the project was higher than the additional value received, they had the possibility to simply stop buying Sprints. This decision was always taken in close collaboration, and most customers gave us enough time to prepare ourselves for a new engagement.
Some customers were curious to learn what the Scrum events were about. So, to build trust, we invited them to the Daily Scrum (as an exception), and they also actively joined refinement sessions.
In the end, it was all about trust. Creating the product vision & backlog together, estimating the backlog together, starting small, and inviting the customer to the Scrum sessions are all practices to build this necessary foundation of trust. When there’s a foundation of trust it also becomes easier to sell the entire Scrum team and sell sprints. And of course, quickly delivering valuable, working software is the ultimate way to gain trust.
For us, this proved to be a great way of working. Not every customer liked it. But we build some awesome products with the ones that did!
Our struggle with the Product Owner role
Although this way of working proved to be successful, the Product Owner role remained challenging to fulfill effectively. When we started selling Sprints, the Product Owner was someone from our own organization. However, the customer really owned the product budget. As a result, the Product Owner was limited in their role. Because they weren’t managing the product budget, they also couldn’t make quick decisions on how to maximize the return on the investment. Whenever they wanted to reorder, change, or update the Product Backlog, permission from the customer was required first. And the decision to release was also something the customer would decide.
Another negative side effect was the mindset of the customer itself. Instead of playing an active role with the team, they shifted into a passive role: “Here’s our list of requirements, good luck building it!”. This resulted in frustration on our side and started to damage the relationship between the Scrum team and the customer.
It didn’t take long before we were convinced the Product Owner role should be fulfilled in a completely different way. Because of the limited product mandate, the Product Owner couldn’t live up to its purpose of “maximizing the value of the product resulting from the work of the Scrum team”. All of this made our Product Owner completely powerless. Instead of ‘order makers’, they became ‘order takers’.
Because of the limited product mandate, the Product Owner couldn’t live up to its purpose of “maximizing the value of the product resulting from the work of the Scrum team”. Instead of an order maker, the Product Owner became an order taker.
Our solution
We decided to make our customer the Product Owner! In addition, the former Product Owner (someone from our web agency) changed into a supporter, coach, and mentor for the new Product Owner. Although this might sound like an easy fix, it definitely wasn’t. It took quite some time to convince our customers to give it a try. It was a totally new approach for them and a role they never fulfilled before. But eventually, it worked out really well!
Some things that happened were:
- Because the customer turned into the Product Owner, they also needed a desk near the Scrum team. In some cases, we moved our entire team to the customer’s locations, and sometimes the customer would sit in our office;
- The customer joined all the Scrum events. They initiated the Sprint Planning, joined the Daily Scrums (when necessary), organized the Sprint Review, and participated in the Sprint Retrospectives;
- Our former Product Owner coached & mentored the customer on a daily basis with their new role. He would advise them on how to order the Product Backlog, create a roadmap, determine when to release, etc.
- The customer became responsible for setting the Product Goal (although we didn’t use the term yet), and for crafting potential Sprint Goals;
- It was also the customer who took the lead during the Sprint Review and share an update with the stakeholders from his own organization;
Because the customer turned into the Product Owner, they also needed a desk near the Scrum team. In some cases, we moved our entire team to the customer’s locations, and sometimes the customer would sit in our office.
In a way, we gave the steering wheel to the customer, and immediately they understood that driving like a maniac was only going to derail the development of the product. The impact of radical and contradictory decisions became more clear when the customer actually joined the Scrum team. And the benefits of a sustainable pace were beneficial for everyone. Most importantly, the feeling of shared product ownership grew strongly. Not only with the customer but also with the developers. Because the developers worked so closely with the customer, they really understood the value of the product and what it made possible.
I also noticed that the mindset of “us” (web agency) versus “them” (customer) slowly disappeared. Instead, a feeling of “we’re all in this together” started to emerge and this gave collaboration and morale a strong boost!
Over time, quite a bunch of customers acquired their (product) driving license :)
Closing
I’m fully aware that the solution I describe is highly contextual, and it might not be perfectly suitable for your organization. My intention was to share what I’ve tried and to offer you inspiration for your product development efforts. Within Scrum, the Product Owner role is truly essential, so it’s definitely worth figuring out the optimal way of fulfilling the role.
As always, I’m eager to learn from your experiences. So feel free to share them. Let’s learn and grow, together!
Footnote: this article, and the solution I describe, isn’t based on one case. It’s a mixture of different customers in different periods of time. I’ve also included ideas I tried when I didn’t work for the web agency anymore. For the sake of readability, I merged things a bit.