Home > Articles

Introducing the Product Owner Stances

📄 Contents

  1. The Misunderstood Stances of a Product Owner
  2. 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

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

InformIT Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from InformIT and its family of brands. I can unsubscribe at any time.


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information

To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.


Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.


If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information

Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.


This site is not directed to children under the age of 13.


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information

If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.


Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.

Sale of Personal Information

Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents

California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure

Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact

Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice

We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020