Robbin Schuurman

The Clerk is your personal waiter for all your user story serving. Gathering all the wishes, user stories and demands is what The Clerk does.

Some of the most famous and influential leaders of all times include people like Mohandas K. Gandhi, Nelson Mandela, Martin Luther King Jr. and Abraham Lincoln.

The Project Manager is typically concerned with day-to-day progress of the Development Team.

The Customer Representative Product Owner is the go-to person for people in the organization who want to gain a understanding of what customers (and/or users) are looking for in the product or service which the Product Owner is responsible for.

The Subject Matter Expert or SME is the expert in telling you how stuff works. Product Owners that favor this stance are a blessing and a curse.

Visionary Product Owners are people like Steve Jobs, Elon Musk, Thomas Edison and Winston Churchill.

With the launch of a brand-new Product Owner-Advanced class (including certification) coming up, we want to introduce you to some new and unpublished content: The Stances of the Product Owner. In this article, we’ll share an overview of both the preferred and the misunderstood Stances of the Product Owner. In upcoming articles, we’ll do a deep dive into each of the Stances individually.

Finally, it’s here! An advanced and certified Professional Scrum Product Owner-Advanced class, with PSPO-II certification! After months working in secret, we can now share the journey that Chris Lukassen and I had in creating this advanced Product Owner class.

The Product Owner role is implemented in organizations in various different ways. The responsibilities and authorities of Product Owners vary across organizations, departments, teams and Product Owners. This can be explained to some extend, because it is a role that people need to grow into. The role requires some specific competences and a specific mindset. In addition, for many organizations it is a new and unknown role in which people (typically management) are trying to find the right balance of responsibilities and mandate. Preferably, a Product Owner has a lot of mandate and he or she is the final decision maker for the product. In many organizations this is not (yet) the case however. In order to create clarity about the level of Product Ownership in your organization, we distinguish five types of Product Owners: The Scribe The Proxy The Business Representative The Sponsor The Entrepreneur The figure shows these different types of Product Owners visually. In this figure you'll see the expected benefits that can be achieved, based on the authorities (or maturity) of the Product Owner. A 'Scribe' therefore has few responsibilities and authorities, an 'Entrepreneur' has many responsibilities and authorities. The image shows the growth path of the Product Owner as we often see it at organizations. Product Owners grow in their authorities and herewith, the added value of their role increases for the product, organization and customers. Having more mature Product Owners will enable organizations to experience more benefits of applying Scrum and value delivery will typically increase for the better. In the following paragraphs the different types of Product Owners are explained in more detail, and we will discuss how you as a Product Owner can take a step in the authorities that you have. The Scribe We often find the Scribe Product Owner role in organizations that are just starting out with Scrum, and/or in organizations that have not completely embraced the Agile mindset (and therefore do not apply Scrum properly). These organizations see the Product Owner primarily as someone who administers the Product Backlog, collects the wishes from the stakeholders and translates them into User Stories for the Development Team. This type of Product Owner often has none to very limited authorities. This Product Owner mainly ensures that the wishes of the stakeholders are written out in understandable language for the Development Team. In organizations where this type of Product Owner is very common, Business Analists or Requirements Engineers are often appointed as Product Owner. In such situations, the mandate often lies with someone else, such as a steering committee or a Project Management Office (PMO). The Proxy Just like the Scribe Product Owner, we often see the Proxy Product Owner (in short: Proxy) in organizations that are in a starting phase with an Agile way-of-working and in adopting the Scrum Framework. The Proxy has some more authorities than the Scribe has. The Proxy, for example, also often gets the authority to make (limited) choices in the ordering of the Product Backlog. However, the vision, the business goals, the desired outcomes/results and the scope is still being determined by other people, such as a steering committee, project sponsor or business owner. In many organizations we encounter Proxy Product Owners who used to be in the position of project manager or teamlead. These roles or positions typically already have the responsibility of bringing a project to a successful end. Therefore, it seems logical to many organizations to change these peoples' roles to 'Product Owner'. However, these Proxy Product Owners are not the final decision-makers. They typically have to ask for approval when changes happen. They have to ask for approval to change priorities. And they have to ask for approval when they want to change the planning, roadmap and Product Backlog. The Business Representative The next type of Product Owner is the Business Representative. The Business Representative is typically a representative from the business side of the organization, who knows the business context, market, customers and users well. Therefore, this person typically knows from experience what customers and users would need and/or what they would like to have. This person is typically one of the 'seniors' or 'experts' in the organization, who has connections to customers and/or users. This type of Product Owner could also be people like process owners or system owners. Although the term Business Representative suggests that this type of Product Owner comes from 'the business', this is not necessarily the case. It could also be that someone from the IT department is in the Product Owner role, with the maturity level 'Business Representative'. Examples of IT-people in this role could be information managers, architects or security experts. These people may have gained a lot of knowledge about the (technical) product, and therefore be suitable Product Owners. To strengthen this concept of having IT Product Owners... remember that Bill Gates and Steve Jobs were excellent Product Owners too, and these guys really were 'IT-people'. So, the Business Representative has more authorities than the Proxy. The Business Representative is typically responsible for a part of the product, a system or a (set of) process(ess). Within this system or process, this Product Owner may determine for him- or herself which work will be carried out by the Development Team. The Business Representative is therefore responsible for the Product Backlog and he or she has the authority to manage the Product Backlog by themselves. This is however, only as long as the desired changes can be done within the budget that was allocated by other people, such as management or a steering committee. The Business Representative does not have an own budget to spend as desired. He or she needs to get approval for budget changes and therefore often still has to deal with a steering committee or manager. The Business Representative also typically has a list of work to be done, projects to perform or goals to achieve, which were defined by someone else. The Sponsor In contrast to the Business Representative, the Sponsor has his or her own budget. This is the biggest difference between the 'Business Representative' and the 'Sponsor'. In addition to budget responsibility, the authorities for both types of Product Owners are fairly similar. The Product Owner type 'Sponsor' is initially often filled in by business managers, IT managers and customers (in a business-to-business setting) for example. Since Sponsor Product Owners have their own budget, they typically also have more opportunities for up- and downscaling the Development Team. This doesn't mean that you should add or subtract people per Sprint! It could be however, that due to enormous success of the product, the Product Owner would like to scale up to a second or a third team. By having this flexibility and authority these 'Sponsors' can therefore accelerate and delay developments much more, and therefore they have a greater impact on the return on investment and total cost of ownership of the product. Besides the budget authority, Sponsor Product Owners also have a bigger say in 'what' needs to be done. He or she is allowed to define the work to be done, the projects to perform or business goals to achieve. The Entrepreneur The last type of Product Owner is called the 'Entrepreneur'. In practice, we also refer to this role as the 'mini-CEO'. This level of Product Ownership is what we ultimately want to achieve in organizations. This type of Product Owner can achieve the most impact for customers, users and the organization by far. The Entrepreneur Product Owner takes full responsibility for the product and also has full authority over the product. The Entrepreneur Product Owner is someone with a strong vision on the market, customers and the product. It is someone with passion for the product and is someone with strong leadership and communication skills. Entrepreneur Product Owners are ultimately responsible for the product and are therefore profit & loss responsible. Besides product development, they are also responsible for maintenance, operations, marketing, legal aspects and sales. That is why we typically refer to this level as 'mini-CEO'. It is a Product Owner who has his or her own 'mini-company' (which could be a mini-company within a large enterprise). Growing responsibilities and authorities So there are five types of Product Owners, each having their own focus, key responsibilities and authorities. With this growth model you can make an estimation for yourself which type of Product Owner you are, or which types of Product Owners you find in your organization. Remember that the (hierarchical) function within the organization only partially determines which type of Product Owner a person is. If a Product Owner used to be in a management function, he or she probably has some more authorities already. This may help Product Owners to grow faster through the maturity model, but it is not a prerequisite to be or to have been a manager! The authorities a Product Owner has are not only determined by their (previous) function. The authorities are mainly determined by the way you act. By the way the person behaves. In our experience, authorities aren't given away 'for free'. Getting more authorities needs to be earned. And the way you earn more authorities is by taking more responsibility and showing ownership. But how do you take on more responsibilities as a Product Owner? Well, actually that is quite simple... You increase your responsibilities by taking more ownership and responsibility for the success of the product, step by step. For example, develop the product vision and actively promote it amongst your team, stakeholders and management. Actively collaborate with your key stakeholders. Show how you and your team are adding value for customers and users. Make value measurable. And also have a clear view on the costs. Create transparency on these topics and show that you are taking responsibility for the product. Be proactive and do not wait until someone does it for you. So, take initiative. With this you will create more room for yourself to decide things, and thus get more authorities. Successful Product Owners that we have met take responsibility. In many cases, these Product Owners started out as Scribes or Proxy's. Many of them have developed into Sponsors or Entrepreneurs. The term 'Product Owner' isn't just made up, because the creators of Scrum 'needed a name'. The name of this role actually contains the word 'owner'. So the role is about 'owning' the product and it's about taking the responsibilities that come with owning a product. Therefore, ownership is exactly what you have to display to your stakeholders. This is not just about things like the product vision, Product Backlog and financial aspects. It's about your attitude, about your mindset and behaviors. So it may help to regularly reflect. Look yourself in the eye. Have you really done everything you could to improve the product? Are any setbacks caused by others, or could youhave done something in a different way? Take ownership! I hope this blog helps you to gain some insights into the growth path for Product Owners and some steps you could take to increase your responsibilities and authorities as a Product Owner. There is of course much more you could do, but I'm also curious about your own experiences! What type of Product Owner are you? Which steps did you take to grow? What are the next steps for you as a Product Owner? Thank you for reading!

As a Product Owner, you are responsible for Product Backlog management, stakeholder management and forecasting. Therefore, you will probably use a variety of tools and techniques to track progress, manage expectations and keep people informed. One of the tools that may come in handy for you is a product roadmap. Applying product roadmaps effectively can be challenging however. The concept of a product roadmap however, is that it is a high-level, strategic plan, that describes the likely development of the product over the next period of time. The roadmap should support the products' purpose and vision and it helps the Product Owners to keep their stakeholders aligned. The roadmap also makes it easier to coordinate the development of different products and it fosters transparency in order to manage customer expectations. In a lot of organizations, I see that Product Owners are focused mostly on developing features and therefore, a lot of roadmaps are also dominated by features and functionalities to be delivered. The disadvantage of focusing on features too much, is that there are always too much features that would add value, therefore creating a lack of focus on the vision and goals. By focusing on the features too much, the roadmap will turn into an overloaded product backlog, instead of a high-level, strategic plan for the products' future development. In my everyday practice, I've seen a variety of product roadmaps that were used. Although these three different roadmaps all have different pros and cons, I've seen all of them add value for Product Owners in their daily work. Personally, I always use a combination of these three roadmap practices. I mostly use the Storymap in the beginning of a products' development, because I want to create insight for the stakeholders in the products' features. Goal Oriented product roadmap (GO product roadmap) What I personally like a lot about the GO product roadmap is that it facilitates a lot of focus on the goals you wan't to achieve as a Product Owner, much more than the actual work to be done (the features). Although the GO product roadmap offers the possibility of adding features, I like to start with the end goals in mind, and I believe every Product Owner should do so. The GO product roadmap and focus on goals enables value steering (steering on outcome) instead of steering on work packages (steering on output). Since you are responsible for the product vision, strategy and roadmap as a Product Owner, I believe this is a valuable asset of the GO product roadmap. Another aspect of the GO product roadmap I like a lot is that it supports you in thinking about the most valuable features that enable the achievement of your goals. Since Agile is also about "Simplicity - maximizing the work not done" (Agile principle #10), I like the concept that there is only a small amount of space in the model, to force you to think about the top three most important features for a release. What I also like a lot, is that in one glance, you can get an overview of you products' development over the next upcoming releases, which comes in very handy to manage your stakeholders! Depending on the organizations' context, I sometimes leave out the dates and release name sections of the GO product roadmap. I do this since I've seen quite a lot of stakeholders in the past, who saw the dates in the roadmap (which were forecasts from my perspective) and they concluded that they would certainly receive the functionality on the date that was in the roadmap. Since we're working in complex environments which change and since people change their minds overtime, this didn't always work out very well. Therefore, depending on the context, I sometimes use and sometimes don't use the date and release sections, to stimulate interactions and to prevent the wrong interpretations of the items on the roadmap. In these cases, I often combine the GO product roadmap with the Now-Next-Later product roadmap. Now-Next-Later product roadmap The now-next-later product roadmap is a visualization I like a lot, because it's really easy to understand for everyone. All stakeholders understand the concept of this model, since it's easy to understand that you are working on the stuff in the "now" part, the "next" part is what is coming up soon and the work to be done in the "later" part is further away in time and still has to be prioritized. The negative aspect of this roadmap from my perspective, is that it is focussed more on the features, rather than the goals/objectives you would like to achieve as a Product Owner. Besides that, the model doesn't offer much room for including KPI's, releases or dates. Since dates and timelines are important information to stakeholders (in most of the situations I have been in) this may be something you need to consider when applying this type of roadmap. On the other hand, it may just as well be an advantage that the now-next-later product roadmap doesn't include dates, since this offers you the opportunity to interact with your stakeholders, instead of them reading the data from your roadmap.As mentioned earlier, I often like to combine the now-next-later product roadmap with the GO product roadmap, which adds more value for yourself and your stakeholders. Story map The story map is a really nice type of roadmap that I often use in the beginning of new projects or products. The story map is an excellent way to create a nice overview of all the features you and your stakeholders can think of, which will be important to your product. Although the idea is not to create an unlimited list of all the features and functionalities that will likely be developed somewhere in the future, it does provide a nice starting point to facilitate creative ideas for your product. What I like most about the story map is that it provides an overview of all the user activities that need to be covered by the system, which in turn enables you to create small and valuable user stories, which can be developed and delivered incrementally and iteratively. Another aspect I like a lot about the story map is that it starts with the user activities, and thus taking a users' perspective on the product. I really like this concept, since it helps you with brainstorming about the product from a users' perspective, after all, we develop our products for our users and customers right? The main downside of the story map that I've seen in practice is that it creates the illusion that all the features for the product will be developed. Since we're being Agile, it is not our goal to create a complete plan or breakdown for the product, so my advice is to use the story map at the start of your new product development project, but also make it very explicit to stakeholders that you will not neccesarily develop all of the stuff in your story map. So manage these expectations well! 11 Tips for Agile Product Roadmaps I hope these different roadmap types are useful for you, but remember: "Being Agile is not about processes and tools but about individuals and interactions". Therefore, and thanks a to Roman Pichler for offering some inspiration, I would like to share the following 11 tips with you about creating Agile product roadmaps: Start with your product vision (tip: use Roman's Product Vision board); Describe and validate your product strategy; Focus on goals and benefits, by creating a goal oriented product roadmap (or one of the other types I've explained before); Tell a coherent story about the likely growth of your product and don't oversell it; Keep it simple! Resist the temptation to add too much details to your roadmap; Actively collaborate with stakeholders to ensure buy-in; Have the courage to say no, to prevent an overload of features in your roadmap; Think twice about adding timelines, dates or deadlines to your roadmap; Make sure your roadmap is measurable, by adding measurable goals and KPI's; Create a rough estimate for each feature (#people + required skills) to determine the viability of a feature; Review and adapt your product roadmap on a regular basis. Thanks for reading, if you have any feedback to share please do, and good luck with creating your product roadmaps!