“Who should be the Product Owner (PO) for this project?”
“Do we even need a PO here?”
“Should the PO come from IT or the business?”
“Should we split the PO role?”
“What does a PO even do?”
If you’re asking (or trying to answer) questions like this, this guide is for you.
In this guide, we’ll dig into the key responsibilities and activities of a strong Product Owner. What do they do day-to-day?
Then, we’ll look at the capabilities someone needs to be a strong PO, what we refer to as a Full STAK PO: someone with the skills, time, authority, and knowledge to do all the responsibilities well.
Finally, informed by those responsibilities and capabilities, we’ll help you think through who the PO ought to be for a particular team or initiative.
Our Definition of Product Ownership
Great Product Ownership involves learning and communicating what to build, including who it’s for and why it matters, in collaboration with the team and stakeholders, in order to maximize the flow of value through that team.
What Product Ownership Isn’t
The Product Owner is not a rebranded requirements writer, a backlog tool clerk, or a proxy project manager.
The role exists to ensure that a team is consistently focused on the most valuable work, at the right level of detail, given what is currently known. To ensure the work of that team is adds real value to customers and provides economic benefit to the business.
A team represents a large, ongoing investment. A 7-person Scrum team can easily have a loaded cost of $2 million per year. The PO is responsible for the return on that investment. And we say “flow of value” because it ought to be continuous, now and in the future. Every sprint, every quarter, every year of investing in that team should create a positive ROI.
The Responsibilities of a Product Owner
The Product Owner has responsibilities across several areas, from high-level and strategic to low-level and tactical. A great PO…
- Learns What Matters (Continuous Discovery)
- Holds the “Big Idea” (Purpose, Vision, and Context)
- Decomposes the Big Idea Into a Backlog (Backlog Refinement)
- Makes Work Visible and Ready
- Makes Value-Based Tradeoffs Explicit
- Aligns Stakeholders (Especially in Internal Contexts)
- Collaborates With the Team
- Focuses on Outcomes and Learning Over Quantitative Output
Let’s look at each one in detail…
Learns What Matters (Continuous Discovery)
While POs need domain knowledge to do their job well, it’s a myth that the PO knows everything and just needs to get it out of their head and into documents or a tool. Rather, for any reasonably complex initiative, we think of the PO as the “chief learner” in the problem domain.
A good PO:
- identifies assumptions to test
- conducts customer interviews, observation, and other customer research tests to understand customer needs and behaviors
- decides which customer segment(s) to focus on and in what order
- gets feedback on work-in-progress
- monitors how completed work is received and used
- updates the backlog based on evidence
Good POs don’t “gather requirements” as if they’re just out there in the world waiting to be picked up. They discover which customers to serve and which problems are worth solving, often experimentally and iteratively.
In our Complexity-Aware Planning, Estimation, and Delivery (CAPED) approach, this is a big focus in phases 1 and 2, Strategic Planning and Active Planning. For initiatives using CAPED, the PO often takes the lead in facilitating Assumption Brainstorming, Complexity Mapping, and Feature Mining.
Holds the “Big Idea” (Purpose, Vision, and Context)
The Product Owner is responsible for ensuring that the team’s work is grounded in a clear strategic outcome, what we often refer to as the “Big Idea.” This outcome should deliver a clear economic benefit through some combination of revenue and savings. (Or a clear impact benefit in the case of government or non-profit work, where revenue isn’t a meaningful metric.)
Product Owners are responsible for communicating to the team and stakeholders about:
- The purpose of the work (why it matters)
- Who it’s for
- What better future the team is trying to create
- The business context and constraints
- Relevant customer research and learning
The PO does not need to invent all of this themselves, but they do need to understand it deeply, keep it visible, and use it to guide prioritization and tradeoffs.
This Big Idea is intentionally high-level and stable. It provides direction without prematurely locking in solutions. Without it, teams default to reactive, request-driven, order-taking work.
Decomposes the Big Idea Into a Backlog (Refinement)
A Big Idea is too large and nebulous to land on a development team’s backlog. It needs to be broken down into smaller chunks to enable focus and incremental delivery. The best POs do that at two levels:
Meaningful but Focused Increments of Value
We teach organizations to organize work into meaningful increments of value. We use the idea of Minimum Marketable Features (MMFs) in software, or analogous increments in other domains. These represent chunks of value that make sense to deliver, validate, or evaluate together. The smallest thing we could deliver that their intended beneficiary would be excited to learn about. Ideally, “marketable” means “enough value to be worth shipping,” but in some contexts, that’s still too large, so we go with “worth demoing to real users” or similar.
Small Slices of Value
MMFs are smaller and more tangible than the Big Idea, but they’re still too large for day-to-day work. Even as we break work down further, we still want teams to focus on value and make incremental progress every day. So, we find it useful to express day-to-day work as small slices of value (user stories in software, or similar small increments elsewhere).
These slices:
- Are small enough to complete quickly, typically in 1-3 days
- Represent real progress toward an MMF
- Enable fast feedback and learning
The PO’s responsibility is not to over-specify these slices, but to ensure they are the right size and ordered by value.
Decomposition is Collaborative and Complexity-Aware
This decomposition is typically a collaborative activity between POs and their team. When POs try to do it solo, work is often structured in ways that don’t make sense for delivery. When POs try to just let the teams do it, work is often structured in ways that don’t incrementally create value or resolve business complexity. The best POs do it collaboratively.
In CAPED, decomposition happens just at the top of the backlog during Active Planning, when work is highly complex. The goal is to identify the next MMF or two and the next handful of user stories. Just enough to probe the core complexity of the initiative. Once that core complexity is resolved and work moves into Phase 3, Analytical Planning, decomposition becomes more analytical and comprehensive. Good POs maintain awareness of complexity and plan appropriately.
Makes Work Visible and Ready
Good POs continuously visualize and refine the work at the 3 levels (big idea, meaningful increments, small slices) so the team and stakeholders can always see what’s next and what context it fits into. Our PO Board model is a Kanban system for this. [tk link to PO Board]
The PO is responsible for:
- Keeping the right amount of detail at the right time
- Preventing over-elaboration of future work
- Maintaining a sustainable pace for themselves and the team
Treating the backlog as a pull system, where detail emerges as and when needed, allows the PO to be both strategic and responsive without burning out or drowning in detail.
Makes Value-Based Tradeoffs Explicit
A central Product Owner responsibility is making tradeoffs visible and intentional.
The PO:
- Helps articulate why one option is more valuable than another
- Brings cost-of-delay and opportunity cost into conversations
- Prevents the team from being driven by the loudest voice or most recent request
Depending on context, the PO may make prioritization decisions directly or facilitate decision-making among multiple stakeholders.
In all cases, the PO ensures decisions are grounded in value, not habit, politics, or false urgency.
Aligns Stakeholders (Especially in Internal Contexts)
Every Product Owner thinks about their end users and their team. Great Product Owners are aware of and proactively manage all their other stakeholders as well.
A good PO:
- Identifies relevant stakeholders
- Understands their needs and incentives
- Schedules the right conversations at the right times with the right stakeholders
- Helps stakeholders see tradeoffs
- Prevents uncoordinated demand from overwhelming the team
In product organizations, the PO is often a visionary who sets direction while coordinating with and informing stakeholders.
For internal teams, Product Ownership is sometimes a more facilitative role. Their team serves multiple stakeholders, each with their own goals, incentives, and unique domain expertise. POs in this situation facilitate negotiations between stakeholders who directly influence the direction of the team. This is a valid and common form of Product Ownership when done deliberately and skillfully.
Collaborates With the Team
Great Product Owners collaborate with their teams every day.
They:
- Are available for frequent conversation
- Clarify intent and constraints
- Learn alongside the team
- Adjust direction as new information emerges
They do not:
- Assign tasks
- Manage individuals
- Act as gatekeepers or approvers
- Substitute process for judgment
The PO’s presence enables flow, learning, and shared understanding.
In Scrum, the Daily Scrum meeting is a good place to coordinate daily collaboration. Team members can share where they need the PO’s help on current work. The PO can share where they need help on backlog refinement. Together, everyone can plan their day for maximum impact.
Focuses on Outcomes and Learning Over Quantitative Output
Finally, the Product Owner is responsible for keeping attention on:
- Whether work is creating meaningful outcomes
- What the team is learning
- Whether priorities should change
Success is not “everything we planned got built.” Success is not “our velocity increased by 20%.” 20% more of the wrong thing is worse than no increase.
Instead, successful Product Ownership is learning our way toward valuable outcomes, one meaningful increment at a time.
Full STAK Capabilities To Be a Great PO
Product Ownership is a big job. Those eight areas of responsibility require capabilities from a PO that we refer to as “Full STAK.” That’s not a spelling error, it’s an acronym, a deliberate pun on full stack developers.
Full STAK Product Owners have the Skills, Time, Authority, and Knowledge to do the role. When choosing a PO, you’re not looking for someone who is the deepest expert in everything. You are looking for someone who can span the whole role without dropping critical responsibilities.
S — Skills
An extensive set of skills is required to fulfill all the above responsibilities well. Great POs have skills in customer research, casting vision, decomposing and organizing work, facilitating stakeholder conversations, and communicating the state of large, complex work, among many others. When domain experts become POs, this is often the capability that needs the most attention.
But skills alone aren’t sufficient. A skilled PO without enough time, authority, or domain knowledge will fail in the role.
T — Time
The PO role simply takes a lot of time to do well. Part-time POs tend to fall into one of the following unhealthy patterns:
- They neglect strategic work and end up with a team that’s reactive and unfocused.
- They neglect collaboration with their team, preferring to focus on the big picture, and often end up with the right idea implemented wrong in the details.
- They neglect customer research and validation and build something that doesn’t actually meet customer needs.
A — Authority
Pretty much everyone has limited delivery capacity. No one ever tells us, “If only we had something valuable to work on with all this capacity!” Thus, POs have to say “yes” to some things and “no” to others. A great PO needs the authority to make priority and scope decisions and have them stick. Sometimes a PO has this authority based on their position. Often, people with positional authority need to explicitly delegate authority to the PO for them to be effective.
K — Knowledge
The PO needs enough domain and customer knowledge to make good judgments. In product-focused teams, this is an expected and logical part of the role. In other teams that provide shared services or internal capabilities, the domain knowledge can be distributed across multiple experts. For example: sales, marketing, operations, compliance, finance, and leadership. The PO needs to collect, curate, share, and use that knowledge.
Responsibilities Outside the PO Role
There are some responsibilities a PO may have that aren’t, strictly speaking, part of the PO role. Product Ownership is focused on collaborating with a team to build the right thing. POs sometimes take off their PO hat and put on another one.
For example, a Product Manager who fills the PO might also have market-facing responsibilities like pricing strategy or product marketing. A business leader who acts as a PO for a business automation initiative might have people management responsibilities. Those examples and many others may be part of a person’s overall job description, but they are not part of the Product Owner role. If someone has many responsibilities outside of their Product Owner role, they are likely to struggle with having enough time to be a strong PO.
Who Should Do the PO Role, Then?
Who should do the PO role? Whoever can. It’s not primarily about job titles or reporting structure. It’s about who’s sufficiently Full STAK to do the PO responsibilities in your context. Or, who’s closest to Full STAK, and what do we need to do to close the gaps?
Business or IT?
Should that PO come from the business or tech side of the org? We’ve seen good and bad POs from either side. They tend to have different strengths and gaps.
Business-side POs often start stronger on domain context and stakeholder access, but may struggle with time or product skills. IT-side POs often start stronger on collaboration and delivery mechanics, but may struggle with customer knowledge or authority.
Why Splitting It Doesn’t Work
Sometimes, orgs try to make up for gaps in the PO role by splitting it between two or more people.
We have never seen a case where splitting the PO role resulted in a high-velocity, fast-learning agile team. Common splits like Product Manager/Product Owner, Product Owner/Business Analyst, Business Product Owner/Technical Product Owner, and other permutations all result in impediments to real productive delivery. Great Product Owners are great because of their ability to zoom out to the strategic level and zoom in to specific details of the team’s day-to-day work.
But a PO Team Might Work
The only multi-person approach to Product Ownership that we’ve seen work is a small team that collectively fulfills the role, one that speaks with a single voice about prioritization decisions, but collaboratively covers the full STAK capabilities.
One of our favorite examples of this was in a medical technology company. They struggled to find anyone with enough PO skills and domain knowledge. So, they decided to make the PO a pair. An experienced product manager paired with a physician’s assistant or nurse practitioner. They worked together on everything, not splitting the role but doing it collaboratively as a small team. Talk about Full STAK!
As AI improves, it’s going to shape the PO team in ways we don’t fully grasp yet. If AI accelerates development, for example, a PO team may be necessary to keep up because even a full-time PO can’t feed the team enough high-value work. And AI may become effectively part of the PO team, increasing PO capacity, ideally supporting rather than replacing human creativity and decision-making. We’re watching and experimenting in this space as it emerges.
How to Become Full STAK with Humanizing Work
We work with our clients to help POs level up to become Full STAK.
We help executives create systems and structures to choose the right POs, form the right teams, distribute authority, and make time for what matters.
And we teach POs the skills they need to handle that long list of responsibilities with fluency and ease.
Contact us to discuss how to grow Full STAK Product Ownership in your organization. Or just join an upcoming public Product Owner course to level up your PO skills.