Can You Answer the Following Question: What Is Your Product?
Why are some elements of Scrum purposefully vague and how does it impact your Scrum Team?
Scrum is very popular in the software industry. There are logical reasons for this. First and foremost, it started out as a new way of creating software. On top of that, Scrum is an Agile framework. Agile also has its roots in software development:
“We are uncovering better ways of developing software by doing it and helping others do it.” — Manifesto for Agile Software Development
But how often is a product software only? Many Product Owner and teams do themselves and their product short by limiting their focus on software. Or even worse: a software feature.
In this article, I will discuss this anti-pattern and suggest ways to solve it.
A framework for complex product environments
With its roots in Software Development, Scrum is NOT a framework to deliver software features. It is something else:
“Scrum is a lightweight framework that helps people, teams and organizations generate value through adaptive solutions for complex problems.” — Scrum Guide 2020
Scrum exists to deal with complexity. In a fast-changing environment, detailed long term planning doesn’t work. Scrum uses empiricism: Transparency, Inspection and Adaptation. With Scrum, you take small steps towards your goal. Between these steps, you reflect on what you did and on other factors that may be of influence. Only then, you decide what to do next towards that goal.
Scrum Teams create value by building and releasing products. As a result, Scrum has Product Owners, Product Goals and Product Backlogs.
What is a Product?
Scrum is all about building products. But what is a product? Here is the definition in the Scrum Guide:
“A product is a vehicle to deliver value. It has a clear boundary, known stakeholders, well-defined users or customers. A product could be a service, a physical product, or something more abstract.” — Scrum Guide 2020
This is a broad description, perhaps intentionally. Scrum is deliberately non-descriptive on many aspects because they are context-sensitive. The new Scrum Guide is even less descriptive than the previous version. Every environment is different. By being (too) descriptive about a topic like the definition of a product, the Scrum Guide would potentially rule out environments that would be perfectly suitable for the framework.
This doesn’t make the life of a Product Owner any easier. The Scrum Guide doesn’t help much to determine the product.
Many Product Owners have the responsibility for features like search functionality, reporting or payment clearing. According to the Scrum Guide, these would qualify as products. They are all vehicles to deliver value. But they don’t bring value in itself, as Roman Pichler points out nicely:
“I don’t go to Amazon to search or checkout. I want to buy the right product at the right price with minimum hassle.” — Roman Pichler
Pichler has the following definition of a product, which I like a lot:
“Something that creates specific value for a group of people, the customers and users, and to the organisation that develops and provides it.” — Roman Pichler
Features are pieces of a product. Scrum Teams may be focusing on features. That is fine. Product Owners who do this, miss the complete picture. The Product Owner should eye the whole product.
There’s more to the product
So a product can have supporting features, expanding the scope of the product. But there’s more. For example:
- How do people know about the product?
- How do people understand how the product can help meet their needs?
- How can people get help in using the product?
- How does the company apply their policies to the product?
All of these topics are important. Every Product Owner has had marketing, sales, support and/or security come into play. Many of them haven’t considered these to be part of their product. But, what if they are? How does this impact the work of a Product Owner?
Here is a great visualisation of the different aspects of a product:
All of these aspects help create value for your customers and users. Hence you can argue they all are part of the product.
Product Owner anti-patterns
With what I just discussed, let’s now look at a Product Owner who is responsible for creating value for a software feature. Often the following anti-patterns happen:
- The Product Owner, responsible for the feature alone, will not consider if working on other features may bring more value than the feature she is owning. This leads to suboptimal choices.
- The complete product will not be inspected on a regular basis (every Sprint). The respective teams and their stakeholders will only consider their individual features in isolation.
- When the software is ready for the world, other aspects get their focus. Only then do other teams like sales and operational support start their work on supporting the product. Software development works in an agile way, but the rest of the product is being executed sequentially. A product isn’t done when the software is done.
- Even when software creation, sales initiatives and support topics are all done at the same time, there is no inspection and adaptation together. There is no one Sprint Review to discuss the complete product. With that, there is no true alignment and no true learning. It’s like a team playing a football match and each sub-team (defense, offence, midfield) has their separate meeting to evaluate how the match went.
A Product Owner who only has a final say about a part of the product isn’t effective. As a result, the product isn’t as valuable as it can be.
How to address these issues with Scrum?
The most logical way to start dealing with these issues is to identify what is your product, taking into account everything I discussed in this article.
The next step is to identify the Product Owner. In Scrum, there’s only one Product Owner for a product. This Product Owner works with one Product Backlog. All things that are needed to create value with the product are on this Product Backlog.
The one Product Owner can work with multiple Scrum Teams:
“If Scrum Teams become too large, they should consider reorganizing into multiple cohesive Scrum Teams, each focused on the same product. Therefore, they should share the same Product Goal, Product Backlog, and Product Owner.” — Scrum Guide 2020
Here are some examples of cohesive Scrum Teams for a product:
- several Scrum Teams can work on their specific product feature;
- a Scrum Team could work on marketing aspects of the product;
- a Scrum Team could work on expanding support to the product.
There are many more options. These are just examples.
All the Scrum Teams have their own objectives every Sprint, as a Sprint Goal. But they all work towards the same Product Goal and work from the same Product Backlog. At the Sprint Review, the Product Owner, all Scrum Teams and the stakeholders reflect on what was done in the Sprint and discuss what to do next. In a complex environment, it is key to have these regular moments of inspection and adaptation to deal with the changes that are bound to come.
Every Sprint, the Product Owner can determine what would be the most important things to work on next. If empiricism works full-throttle, teams will never work on topics that are deemed unimportant or irrelevant at that point in time.
The power of the Product Goal
When it is clear what the product is, the Product Goal can do amazing things. It brings focus, also to the teams and individuals that don’t work on the core product directly.
A powerful example of an inspiring goal is the Landing a man on the Moon goal from John F. Kennedy, as Sjoerd Nijland also explains in this excellent article:
“”I believe that this Nation should commit itself to achieving the goal, before this decade is out, of landing a man on the Moon and returning him safely to Earth.” — John F. Kennedy, May 1961
This inspirational goal did wonders to the people involved. As the legend goes, when Kennedy visited NASA headquarters, he introduced himself to a janitor who was mopping the floor. Then he asked what he did at NASA. The janitor answered:
“I’m helping put a man on the moon!”
Everything the janitor did, helped to put the man on the Moon.
A good Product Goal can do wonders to your teams too. It doesn’t matter if they build the software, do the marketing, arrange support. They’ll know they are part of a whole: a group of people building a wonderful product.
If you are a Product Owner for a part of the puzzle only, you will miss this opportunity. With that, you miss out on a core part of Scrum. Scrum has always been about setting a broad, ambitious goal and then working towards this goal. It has never been about building a part of the puzzle only.
Conclusion
Many Product Owners don’t realise what their true product is. They work on the software that is the core of the product. Often they even work on a feature of the product alone.
A product often is so much more. It is also about telling the story, supporting your users, incorporating policies and other things.
Realising this and understanding the impact of the complete product experience changes the perspective. It helps to take the steps to brings focus and improves your chances to deliver the highest possible value to your users and customers.
