10 minute read
- Product Owner is a Scrum accountability that the existing Product Manager should take on rather than introducing a separate role. see why — jump to the section that argues this
- Evidence of real product-management capability and customer learning matters more than tools, certificates or job titles when hiring a Product Owner. see why — jump to the section that argues this
- An employer must grant clear decision authority, customer access and organisational respect for product decisions for the Product Owner accountability to function. see why — jump to the section that argues this
- Start by giving Product Owner accountability to the existing Product Manager, and only recruit externally if that product‑management capability is missing.
- When hiring a Product Owner, prioritise demonstrated product‑management capability and customer learning over tools, certificates, job titles or fixed years of experience.
- Before appointing a Product Owner, commit organisationally to clear product‑decision authority, access to customers and evidence, and genuine respect for those decisions.
Product Owner is an accountability within Scrum that an existing Product Manager should take on. The person carrying it sets the tone for product leadership and defines what product success means. Hiring for this work requires evidence that someone can make product decisions, learn from customers and use modern product management practices to maximise value.
One of my customers asked me to break down the Product Owner accountability into a job specification. I developed the specification with input from colleagues at Scrum.org, including Jim Sammons, following the earlier Hiring a Professional Scrum Master article. Below is a version an employer can adapt and use, with Jim’s contributions and the customer’s original interpretation.
Hiring a Professional Product Owner
Start with the person already responsible for managing the product. If they have the capability and authority to carry the Product Owner accountability, adopting Scrum is not a reason to introduce another person between them and the Scrum Team. Where that capability is missing, recruitment should address the product-management work that needs doing.
Business knowledge matters, alongside the ability to challenge existing assumptions. A candidate needs to understand customers, the market and the organisation’s constraints, and explain how evidence has changed their decisions. Familiarity with a backlog tool or possession of a certificate does not establish that capability.
The employer must also make the accountability possible. Product decisions need an identifiable owner, access to customers and usable evidence, and the organisation’s respect for those decisions. Someone expected to maximise value needs the authority to make choices about the product.
The specification below combines Scrum accountability with broader agile values and principles, lean practice and product management. The six Product Owner stances informed the original; this version groups responsibilities by the work an employer is hiring someone to do. For the short definition, see Product Owner.
Effective product ownership connects strategic goals to decisions about the Product Backlog and collaboration with the Scrum Team. Assess how candidates connect these responsibilities to customer understanding, learning and investment decisions.
Internal Appointment or External Recruitment
In the original article, I described seeing Product Owners appointed from within. Jim Sammons challenged that observation and argued for the value of an outside perspective. His response is reproduced unchanged below. The job counts belong to that original discussion, not to the current hiring market.
My take on the above…I am seeing the opposite. I’m seeing more companies valuing Product Ownership as a skill and going outside for it. I think this is a positive trend and will probably have the benefit of bringing an outside perspective to a company which may be exactly what a product needs.
Data: LinkedIn has 12,894 jobs for “Product Owner just in the US right now and 25,520 for “Product Manager”. Didn’t look at global numbers.
I added the following comparison to Jim’s figures in the original article.
| Country / Job Title | Product Owner | Product Manager |
|---|---|---|
| USA | 12,894 | 25,520 |
| UK | 9,256 | 23,241 |
| EU | 25,254 | 35,626 |
| Worldwide | 119,808 | 300,060 |
Historical LinkedIn job-count snapshot recorded in the original article. The figures are preserved as reported; they are not current totals, and a single snapshot does not establish a hiring trend.
Jim’s contribution raises a useful hiring question: what would an external candidate bring that the organisation currently lacks? Knowledge of the business and the ability to challenge its assumptions both matter. Recruiting externally does not require separating product management from Product Owner accountability; the appointment should bring the necessary capability and decision authority together.
Jim Sammons’ Five A’s of Product Ownership
Jim also supplied this graphic. Availability, agile mindset, accountability, authority and analytical thinking give an employer a concise way to examine whether both the candidate and the organisation are ready for product ownership.
The Five A’s of Product Ownership, supplied by Jim Sammons. Original graphic retained unchanged.
The availability point refers to designating a proxy. Someone can help answer questions and support delegated product work when the Product Owner is unavailable; that does not create a second Product Owner or remove the accountable person’s need to engage. The hiring discussion must establish how access and decisions will work in practice.
The authority point is an employer commitment as much as a candidate attribute. A job specification cannot provide authority that the organisation will withhold. The analytical point connects product decisions to customer feedback, risks and investment, rather than treating backlog administration as the whole job.
Certification and Evidence of Capability
Certification can provide evidence of assessed Scrum knowledge. It does not establish competence in product management, customer judgement or the ability to make difficult investment decisions. Ask candidates how they applied what they learned, including decisions they changed when the evidence changed.
Historical certification graphic retained from the original article. These are the counts displayed in that illustration, not current totals or evidence of hiring effectiveness.
Scrum.org’s Product Owner Open assessment provides a way to explore framework knowledge. Use it to inform a learning conversation, alongside evidence of actual product work.
A Scrum Product Owner Job Spec
Role Summary
The Product Manager takes on the Product Owner accountability within Scrum and is accountable for maximising the value of the product resulting from the Scrum Team’s work.
This person sets the tone for product leadership and defines what product success means. They use modern product management practices to understand customer needs, make investment decisions and learn from results.
The Product Owner may delegate product work while remaining accountable for product value and effective Product Backlog management.
Product Direction and Success
- Develop and communicate a product vision grounded in customer needs, business goals and market understanding.
- Develop and communicate a clear Product Goal, connecting near-term decisions to the product’s direction.
- Define success through customer and business outcomes, with evidence that makes progress visible.
- Develop and communicate budgets, investment options and an adaptable product roadmap.
- Change direction when evidence challenges the assumptions behind the strategy.
Customer Understanding and Experimentation
- Maintain direct contact with customers and use research, feedback and product usage to understand their needs.
- Distinguish stakeholder requests from evidence of customer problems.
- Work with Developers and relevant specialists to explore potential solutions.
- Form explicit hypotheses and use small experiments to test assumptions before making larger investments.
- Inspect the results of product changes and use what is learned to guide subsequent decisions.
Investment, Prioritisation and Release Decisions
- Order the Product Backlog to pursue the Product Goal and maximise value.
- Keep the Product Backlog transparent, visible and understood.
- Make investment trade-offs explicit, including decisions to stop work that no longer justifies its cost.
- Collaborate with the Scrum Team to limit concurrent work and finish useful increments.
- Make release decisions with relevant specialists, respecting quality, readiness and applicable constraints.
- Assess progress through outcomes and learning rather than the volume of features delivered.
Collaboration with Developers and Stakeholders
- Work closely with Developers, customers and stakeholders throughout discovery and delivery.
- Explain product decisions, negotiate competing demands and communicate what will not be pursued.
- Prepare for Sprint Planning by connecting proposed work to the Product Goal and the value sought.
- Provide product context and discuss trade-offs during refinement, while Developers retain responsibility for sizing and their plan.
- Remain available to clarify work and negotiate scope as learning requires, without endangering the Sprint Goal.
- Work with relevant specialists to make risks and constraints visible and support timely decisions.
- Develop and influence commercial agreements that support collaboration, usable outcomes and adaptation.
- Delegate product work where appropriate while retaining Product Owner accountability.
Candidate Requirements
The successful candidate must demonstrate:
- Product-management capability, including decisions about customer needs, value, investment and product direction.
- Understanding of the business domain and market, and the ability to challenge assumptions through evidence.
- Practical understanding of Scrum and the ability to fulfil Product Owner accountability while respecting team self-management.
- Experience using research and experiments to make decisions, including changing course when results challenge expectations.
- Clear communication of product vision, goals and trade-offs.
- The ability to collaborate across functions and make difficult choices within agreed authority.
Relevant experience may come from product management or from previously fulfilling Product Owner accountability. Evidence of capability matters more than a particular job title or a fixed number of years.
Scrum certification can support evidence of framework knowledge. It does not replace demonstrated product judgement.
Authority and Organisational Support
The organisation will:
- Establish clear authority for product and investment decisions and respect decisions made within that authority.
- Provide access to customers, product evidence and relevant specialists.
- Support collaboration across discovery and delivery.
- Make funding, regulatory, commercial and operational constraints explicit.
Developers retain responsibility for their plan and how they create a usable Increment. Other specialists retain their professional accountabilities.
A Customer’s Internal Interpretation
When I sent the original specification to my customer, they condensed it into a “What does this mean?” section for internal communication. Their response below shows how they translated the expectations into their own organisational context. The specification on this page has since been revised.
Their interpretation covers behaviours as well as accountabilities.
What Does This Mean?
Articulating the strategic vision of the product
Developing and explicitly communicating intermediate strategic goals
Propose how the product can tactically increase its value each Sprint
Understand and shape the impact of the product on our company
Collaborating closely with the Scrum Teams & Stakeholders on a daily basis
Developing and communicating budget, investments, and road-maps
Developing and influencing product governance and controls to enable professional Scrum
Understand the desired outcomes of stakeholders within the bounds of the business constraints
Defining our product(s) and services and how stakeholders will interact with them
Ensuring that the Product Backlog is transparent, visible and understood
Ordering Product Backlog items
Choosing what and when to release
Using evidence-based management techniques to optimise outcomes and value delivered
Create hypothesis and craft experiments to test that hypothesis quickly
Tracking product use and impact on end-users and drive consistent approaches across all Product Verticals
Actively manage stakeholders, their desires, expectations, and outcomes
Create an effective communication strategy
Influence the Developers during Planning and Refinement by helping them select and understand trade-offs
Work with Developers daily to clarify and renegotiate the Scope of the Sprint.
Each Sprint ensuring that the Scrum Team is prepared to discuss the most important Product Backlog items
The key point in the above is the delegation point; we are not thinking that a single Product Owner is able to conduct all of the above on a Programme of this size – and we obviously have other members of the Hiscox team, and Cognizant Business Analysts to share the load… but accountability remains with the Product Owner.
Reading the Customer’s Interpretation
The response above is the customer’s original interpretation of the earlier specification. Its repetition is useful: it shows which expectations they carried into their own communication.
They changed the references to customer outcomes and customer interaction into references to stakeholders. Those groups can overlap, but stakeholder requests do not by themselves establish what customers need or whether the product is useful. A specification should keep direct customer understanding visible.
They also moved the reference to influencing Developers from sizing to planning and refinement. They retained the word “Influence” while broadening the activities it referred to. The revised specification makes the boundary explicit: the Product Owner supplies product context and negotiates trade-offs; Developers retain responsibility for sizing and their plan.
The closing paragraph makes delegation concrete by naming people who can share the work. That supports a Product Owner who has help while remaining accountable. It does not transfer every specialist’s accountability to that person.
These differences show how the customer interpreted the text. They do not establish how the organisation subsequently worked.
Subscribe to Martin's articles
Writing since 2006
Articles, usually weekly on Mondays. One click to leave.
Sources
Enjoyed this? One click, no account.
Questions this answers
How do I write a Scrum Product Owner job description I can use for hiring?
Use a specification that makes the existing Product Manager also accountable as Product Owner, describes responsibilities around product vision, customer understanding, experimentation, investment and release decisions, collaboration with Developers and stakeholders, and sets out candidate requirements and the organisational authority they will receive. The page provides a structured example job spec with sections for role summary, detailed responsibility areas, required capabilities, and the support and authority the organisation must commit to.
Should I hire a Product Owner internally or recruit an external candidate, and what does each option bring?
If the existing Product Manager has the capability and authority to carry Product Owner accountability, Scrum adoption is not a reason to insert another person; where capability is missing, recruitment should address the product-management work that needs doing. An external hire can bring an outside perspective and needed capability and decision authority, but recruitment does not require splitting product management from Product Owner accountability; the appointment should combine them while ensuring knowledge of the business and the ability to challenge its assumptions.
Smart Classifications
Each classification [Concepts, Categories, & Tags] was assigned using AI-powered semantic analysis and scored across relevance, depth, and alignment. Final decisions? Still human. Always traceable. Hover to see how it applies.