Introducing the Product Owner Stances
- The Misunderstood Stances of a Product Owner
- The Preferred Stances of a Product Owner
Stances are attitudes and behaviors that Product Owners display at times, but not all the time. Here the authors explore the six most frequently displayed misunderstood stances and how you can recognize them and become more productive with Scrum.
This chapter is from the book
This chapter is from the book
This chapter is from the book
The Misunderstood Stances of a Product Owner
The accountabilities of a Product Owner are often misunderstood, leading to interesting implementations of Scrum, and of Product Ownership in particular. The misunderstanding occurs in part because organizations try to map the Scrum framework and Product Owner accountabilities to existing processes, roles, artifacts, and events. Such implementations of Product Owner accountability often result in attitudes and behaviors that are not very productive in practice. These ineffective behaviors and attitudes are referred to as the misunderstood stances of the Product Owner.
What are stances? You can think of them as patterns. They are attitudes and behaviors that Product Owners display at times. Because most people do not display these stances continuously and consistently over time, but rather only in moments, stances is a more fitting term than patterns. Let’s explore the six most frequently displayed misunderstood stances and how you can recognize them.
The Clerk
The Clerk is also referred to as the admin, secretary, waiter, yes man, or order taker.
Clerks are the waiters who gather the wishes and needs of stakeholders and serve them up in the form of user stories to the Developers. They aren’t focused on achieving the product vision or on crafting clear goals and objectives. Clerks never say no to stakeholders but instead try to please everyone by delivering on their wishes and needs. There’s nothing wrong with servant-leading customers and stakeholders, but Product Owners whose main purpose each day is to get new “orders” from stakeholders are missing the point of being a great Product Owner.
The following patterns are associated with the misunderstood stance of the Clerk:
Clerks tend to have an endless (or at least extensive) Product Backlog, primarily because they rarely if ever say no to the stakeholders. When a stakeholder poses an idea, requests a new feature, or tells them what to do, Clerks typically respond, “Sure, let me add that to the Backlog.”
Clerks typically have an internal focus. Internal stakeholders tell them what to do and what to build. Clerks don’t (often) interact with external stakeholders, rarely with external users, and (almost) never with real, paying customers who buy the product. They seldom talk (or allowed to talk) to external influencers or governance stakeholders, such as legal authorities and/or regulators.
Clerks act as a go-between (carrier pigeon) between the Developers and the stakeholders. They need to put people on hold frequently to get more information from others. They can’t make any decisions because they need approvals and permission before acting. This reactive, permission-seeking stance often demotivates everyone. Clerk Product Owners struggle to say no because they try to please everybody. They tend to micromanage, distributing tasks among team members, managing via spreadsheets, utilizing people, reducing effort estimates by the Developers, maximizing output, and being a team coordinator.
The Story Writer
The Story Writer is also referred to as the analyst, technical writer, legacy system copycat, scribe, and note taker.
It’s often in the language that you can detect a Story Writer. Many conversations they have are about the details in the Product Backlog items. The Developers in the Scrum Teams push back when work is not compliant with the Definition of Ready (DoR). They push the Product Owner to make items ready for Sprint in accordance with the DoR. A DoR is a practice (not required in Scrum) that Story Writers and Scrum Teams sometimes use.
Although helpful to some teams, a DoR can also result in counterproductive behavior if it starts to feel more like a contract in the hands of a Story Writer than a simple, handy checklist.
The point, however, is not really about the DoR. The point is that a Story Writer is focused on all the details, such as requirements descriptions, acceptance criteria, nonfunctional requirements, and other details in tickets. When a product increment does not produce the value or outcomes the Scrum Team hoped to achieve, the Developers often point to a lack of clarity and specifications. This often reinforces the Story Writer stance, and the Product Owner focuses even more on documenting all the details, keeping this misunderstood pattern intact.
The following patterns are associated with the misunderstood stance of the Story Writer:
Story Writers typically have a very well-organized Product Backlog. The Product Backlog items (usually user stories) on the top are small, specified, designed, detailed, estimated, and refined to be clear. They focus on specifying the work to a great level of detail, making sure that the Developers have no further questions because all the details are in the tickets.
Story Writers have a keen eye for details, and they love to dig into all the nitty-gritty stuff. They are great at specifying user stories. They tend to write user stories, acceptance criteria, and functional descriptions all day long.
Other associated behaviors are acting as a business analyst, acting as a technical writer, copycatting legacy systems, scribing, and note taking.
The Project Manager
The Project Manager is also referred to as the velocity maximizer, resource utilization maximizer, wish list administrator, sidekick to management, and progress reporter.
Project Managers are typically concerned with the day-to-day progress of the Developers. They rarely if ever miss a Daily Scrum, even if only to ask individual team members what they’ve done, what they’re going to do, and whether anything is blocking them. They measure the success of the team in the form of increased velocity and tend to “report” on story points, burndown charts, and velocity to the stakeholders during the Sprint Review. All in all, many of these Project Manager stance takers are focused on progress, resource utilization, dependency management, and the basic application of the Scrum framework (e.g., doing the Events and ensuring clear roles and accountabilities). All of these activities are useful; however, they should not be of primary concern to Product Owners. Also, they distract Product Owners from their core accountability: maximizing the value of the product.
The following patterns are associated with the misunderstood stance of the Project Manager:
Project Managers are used to managing projects, not managing products. Projects have a clear start and end, are temporary, and are executed by a temporary team/organization. The project manager role is designed to deliver output, which is then delivered to the line organization for further implementation and the actual realization of the expected outcomes. However, being a Product Owner is not a temporary endeavor! Product Owners are in it for the long run (not just for delivering some outputs) and are (or should be) accountable for the total cost of ownership and profit and loss of the product.
Project Managers are typically concerned with the day-to-day progress of the Developers. Now just to be clear, it is not necessarily bad to know what is going on with the Developers. However, a Product Owner’s job is not to manage the progress that the Developers are making. Your job is to maximize the value delivered by the Developers by making sure the (potentially) most valuable (or most risky) work is done first.
When a Sprint produces more story points than were delivered in a previous Sprint, Project Managers usually get excited.
Project Managers are often used to reporting on (traditional) measures of progress, such as scope, time, and budget, as well as on deliverables, progress percentages, risks, milestones, and deviations from the original plan. Although it is not a bad practice for Product Owners to keep an eye on the budget and potential risks, the way to deal with them in Scrum framework is quite different.
Project Managers are used to getting projects/assignments with a clear scope, timeline, and budget. They are also accustomed to asking a steering committee for permission or approval to guide their actions and decisions. Product Owners do not answer to a steering committee. They don’t go out to get new projects and assignments. They create a product vision and strategy and start maximizing value. Product Owners are accountable and responsible for the outcomes.
Other associated behaviors of Project Managers are micromanaging, managing the metrics, setting deadlines, distributing tasks among team members, managing via spreadsheets, utilizing people, reducing effort estimates by the Developers, maximizing output, and being a team coordinator.
The Subject Matter Expert
The Subject Matter Expert (SME) is also referred to as the senior user, key user, process manager, domain expert, or business expert.
SMEs are expert at explaining how things work. Product Owners who favor this stance are a blessing and a curse. When they bring relevant domain knowledge to the Scrum Team, the team can make more informed decisions and create a better plan to achieve Sprint Goals and other goals. The SME stance can also lead to a single point of knowledge, and rather than forgoing discussion, as in the Story Writer stance, its stance manifests as micromanagement and spoon-feeding the Developers. Another manifestation is that the domain expertise can lead to biased judgments because SMEs often assume that they know what is right for the customer, even when direct feedback from customers indicates otherwise.
Many organizations seem to expect Product Owners also to be SMEs with detailed knowledge about business processes. Although there’s nothing wrong with understanding the business processes well, Product Owners don’t have to be the experts.
The following patterns are associated with the misunderstood stance of the SME:
SMEs can specify work up to a great level of detail. They are, as the term says, experts in their business, domain, or technical field, and some don’t hesitate to share their knowledge with everyone else. Consequently, one of the traps of having SME Product Owners is that they can talk about their area of expertise for hours. It’s not uncommon that meetings take much longer than expected and that, despite the SME’s lengthy discourse, nobody understands the goals that they’re working toward.
Other SMEs, by contrast, frequently make comments such as “You don’t need to know that” or “I’ll let you know about the next steps when we get there.” The information they have may be valuable, yet they guard it closely—sometimes by design, sometimes unconsciously. Knowledge is power, and some SMEs perceive their knowledge as job security. Some SMEs, therefore, aren’t necessarily in favor of knowledge sharing; they instead spoon-feed the Developers tiny pieces of the total picture, keeping themselves constantly involved throughout the development effort.
Another risky behavior that SMEs frequently display is to be both Product Owners and Developers. For example, a SME Product Owner might simultaneously serve as a software/enterprise architect, a business developer, or maybe a customer journey expert There is a risk in having multiple jobs and roles in the team. Being the senior or expert on the team often reveals the pitfall of stepping in and doing it yourself. It is not unheard of that the senior Developer or architect rearranged the codebase overnight or that a Marketing Product Owner redesigned the whole marketing campaign plan over the weekend.
Other associated behaviors are being the architect, being the technical (development) expert, being the test manager, being the senior (technical) person on the team who decides on all the details, being the UX designer, being a micromanager, distributing tasks among team members, and reducing effort estimates by the Developers.
The Gatekeeper
The Gatekeeper is also referred to as the protector, guard, shield, gateway, or single point of contact.
Gatekeepers are the single point of contact between the Scrum Team and the outside world. They tend to block all connections between the Developers and its stakeholders; all communication goes through the Gatekeeper. Product Owners with a Gatekeeper stance must answer all of the Developers’ questions, but they do not have much time for the team. Also, Gatekeepers typically want to sign off on all requirements.
There’s nothing wrong with “protecting” the Developers from the outside world. There is also nothing wrong with explaining to stakeholders that they should not approach individual team members directly because they work as a team, not as individuals. Product Owners can help the Developers to stay focused by collaborating with the Scrum Master in coaching stakeholders about how the Developers do teamwork. However, Product Owners who make themselves the single point of contact between the Developers and the outside world are missing the point of being a great Product Owner. Also, being overprotective of the Developers—shielding them from stakeholders and preventing them from getting direct customer, user, and stakeholder feedback—often results in missed opportunities for maximizing value.
The following patterns are associated with the misunderstood stance of the Gatekeeper:
The Gatekeeper is great at keeping stakeholders away from the Developers and blocking all communications. The agreement made between the Gatekeeper and the Developers is that all questions are asked and answered through the Gatekeeper, who will consult with stakeholders if necessary. The Developers do not pose questions directly to users or stakeholders, let alone customers.
Another typical Gatekeeper pattern is that all the ideas, wishes, demands, and work should be communicated directly to the Product Owner. In this way, Gatekeepers ensure that not even the smallest stakeholder request reaches the Developers without the Gatekeeper’s knowledge.
Gatekeepers also block feedback from the stakeholders to the Developers. They tend to see 2- to 4-hour Sprint Reviews as a waste of the Developers’ time—time that could be better spent writing code. They therefore host the Sprint Reviews alone; gather feedback from the stakeholders, users, and customers; then share that feedback with the Developers.
Gatekeepers insist on signing off on all the requirements and deliverables that the Developers produce.
The Manager
The Manager is also referred to as the team boss, team lead, technical lead, Product Owner & Scrum Master, and HR-responsible person.
The Manager is concerned with the well-being of the Scrum Team. The Manager loves to see happy, engaged, and motivated people. They love it when people are developing themselves, learning new skills, obtaining new knowledge, and making mistakes. The Manager is a real people person, focused on people’s growth. Another goal of the Manager is to evaluate individual team member performance.
Product Owners as Managers typically are responsible for performance management and evaluating the team. They have many one-on-one conversations with individual team members to learn more about their personal goals and performance. There’s nothing wrong with caring for the Developers or with stimulating the Developers to try, learn, experiment, and fail. However, Product Owners who make performance management a big part of their job are missing the point of being a great Product Owner.
The misunderstood stances of the Product Owner are typically driven by confusion about what product ownership is (really) about. Fortunately, there are many things you can do to correct these misunderstandings of the Product Ownership accountabilities. By exhibiting the preferred stances, attitudes, and behaviors, for example, and by explaining why the system is misinterpreting Product Ownership, you can help to change the system. If you are not a Product Owner yourself, you can help your Product Owner by influencing the system toward a positive outcome.
Don’t change the people, change the system and the people will follow.
—Serge Beaumont