Help….I’m a Government Product Owner!

As described by Jeff Sutherland, the Product Owner (PO) is “the person responsible for managing the Product Backlog so as to maximize the value of the project. The Product Owner is responsible for representing the interests of everyone with a stake in the project.”

The Product Owner is a key role in the Scrum framework. It’s a tough role, and people often have difficulty embracing it. Today, I’ll discuss some of the common questions we get from POs in the government arena.

What’s my Role?
A Product Owner maximizes ROI by:

Identifying product features
Prioritizing features and other work
Ensuring a steady flow of value by choosing the most important work for the next sprint
Continually re-prioritizing, elaborating, and refining the list

A Product Owner guides and supports the team, keeping them from thrashing, by:

Continually painting a picture of the destination (the vision and context)
Ensuring a steady flow by “feeding” the team ready work
Being available and actively interacting with the team on a daily basis to answer questions and provide guidance
Making decisions to keep the team moving forward
Providing a link between business stakeholders and the team
Providing feedback as a sprint progresses
Signing off on work results
Providing a single voice to the team on product priorities and decisions

A Product Owner represents stakeholder interests by:

Actively interacting with stakeholders to identify needs, gather information, and solicit feedback
Ensuring the product creates value for stakeholders

What Skills do I need?
A Product Owner has, or develops, deep knowledge and competence in:

Business domain and subject matter expertise (SME)
Understanding and empathy with the customer, business, and market
Weighing risks and making timely decisions with available information
Conveying vision, setting context, and contributing to team and stakeholder understanding by “telling the story” of needs, behaviors, and success criteria
Understanding and incorporating appropriate techniques to communicate with the team and stakeholders
Understanding and use of conflict resolution techniques
Understanding of group dynamics and complex change
Negotiating priority and trade-off decisions
Facilitating discussions and decisions
Sensing and scanning inward, understanding and providing what the team needs to be effective
Challenging the team to improve
Sensing and scanning outward, understanding and delivering what stakeholders want/need
Managing stakeholder expectations

What’s my Title?
“That which we call a rose, by any other name would smell as sweet” – Shakespeare

Scrum does not specify who should play the Product Owner role. It only provides a general description of the role and responsibilities, and identifies a framework of ceremonies and artifacts that guide what to do.

So, the PO can be anybody (e.g., a Business Analyst, a Product Manager, or a Program Manager commonly play the PO role), as long as they have the necessary skills and time to dedicate to the role. How they fulfill the responsibilities of the role will vary from person-to-person based on experience, need, and organization culture, structure, and constraints.

For smaller projects/product lines, with fewer teams, the PO responsibilities can be handled by one person (e.g., a product manager, senior business analyst, or program manager).

In larger organizations, or larger programs/product lines, the PO responsibilities are often divided because one person won’t necessarily have the skills or sufficient time to fulfill the needs of the role.

A common division occurs at the intersection of the “inward”, team-facing, tactical responsibilities (handled by a business analyst) and the “outward”, customer-facing, strategic responsibilities (handled by a Product Manager or Program Manager). It’s important to remember that even if there is a division of labor and responsibilities, there will likely be some overlap and constant collaboration and “mind-melding” is required. This maximizes transparency, minimizes hand-offs, and ensures congruent decision-making. From the team’s point of view, there is still one PO, a “single voice” providing priority, information, and decisions.

Why is the PO role so hard to grasp?
Product Owner is a role, not a title. A “job role” is a function that’s performed, a description of the part a person plays. A “job title” is the name given to a position within a company, one that typically implies stature or hierarchy.

Traditional job titles have evolved over the years to align with specialized skills, collapsing roles, responsibilities, and skills into common titles (e.g., business analyst, project manager, and tester). These tried-and-true titles have a long history, and are recognized, hired, measured, compensated, and rewarded similarly across the industry. Many of us define ourselves by our job titles; they represent status and stability, identity and importance, achievement and acceptance.

Then along comes the Product Owner. A new role with skills and responsibilities that not only don’t map cleanly to a job title we’re familiar with, but actually overlap several (e.g., product manager, program manager, project manager, business analyst). Our axis shifts, our identity is challenged, and we sometimes find ourselves adrift in ambiguity. To compensate, we grasp for a detailed description and firm boundaries to help provide clarity.

This is a common “shu” response when acquiring new knowledge, especially true when that knowledge comes with a significant shift from what we’re used to. As we learn and become more comfortable, the need for boundaries lessens and our tolerance for ambiguity increases. Mentoring and coaching can help support individuals through this uncertainty.

How is a government PO different?
The Product Owner role itself is not really any different in the government….the responsibilities are essentially the same, as are the skills required.

What makes the government setting unique is the combination and degree of:

organization structure
funding strategies and acquisition constraints
compliance requirements
technical complexity
requirements complexity

I’ll talk briefly about how organization structure affects the PO role; the other factors are outside the scope of this blog.

Although the size and approach to government IT programs/projects is changing, at present they still tend to be on the large side. The number of different agencies and/or vendors involved, the number of teams, and where work is performed are all factors in determining complexity of the program structure.

It’s typical for government agencies to rely heavily on vendors to “design-build-test” their solutions, and keep the requirements definition and user acceptance (UAT) in-house. Subject matter expertise is split between government staff, who primarily have business domain knowledge and expertise, and vendor staff, who primarily have technical domain knowledge and expertise.

Since a key skill set for the PO is deep business domain expertise, it makes sense then for the PO to be from the government staff. And since the PO is responsible for making scope, schedule, and budget trade-off decisions, the ideal candidate would again be from the government staff. The government program manager is often a good choice as the PO, but care should be taken to adequately consider who is best positioned to handle challenges such as those identified below.

Typical, traditional government practices transfer risk and responsibility for failure to the vendor, but having the PO from the government staff means responsibility for successful delivery shifts to the government, as they can no longer claim to not be in the know.

PO Challenges in a Government setting
There are a number of common challenges that can impact establishing strong and effective Product Ownership of government projects and products. The considerations listed here are not all unique to a government environment, but often occur at a higher rate.

Key considerations include:

Time commitment – being a PO is a full-time commitment, not something that can be done “off the side of the desk”. Most of the considerations listed here affect the time commitment required by a PO. Environments where all of these factors occur will significantly impact a PO’s productivity and effectiveness.
Distance – remote teams increase a PO’s workload. This increase is often not considered when determining PO/team ratios. There are tools that can help, but it just takes more time and effort to establish a rapport and communicate with teams and stakeholders who are physically remote from the PO.
Hierarchical structures – power dynamics and hierarchical lines of authority can hamper a PO’s ability to make timely decisions.
Frequently changing vendor teams – increase a PO’s workload, requiring more support to build intellectual knowledge and onboard teams.
Multiple projects/products – one PO, one backlog, one team is a rule of thumb. That will vary somewhat depending on their maturity, the team’s maturity, and the type of work being done.
Customer availability – PO’s need timely access to end-users and other customers/stakeholders to be effective. Generally, the less customer availability, the more PO time is required for coordination.
Supportive environment – PO’s need support from leaders and sponsors to reinforce decision authority and help remove organization impediments.
Acquisition constraints – PO’s in the government are sometimes also the COR (Contracting Officer Representatives). Their SME knowledge makes them a good choice for this, but increases their workload, especially during pre-award activities.
Governance/Compliance – heavy compliance usually means a PO spends less time on CVA (customer value add) activities, and more time on BVA (business value add) activities.