Product management is everywhere today, but its history and relationship with Agile is often misunderstood.
Agile
Before we go deeper into product management, let’s talk about Agile. If you go to Google and ask for Agile explanation, it will give you millions of links, including an alliance of people that decided that this is the way Agile suppose to work. Some of the 17 original Agile Manifesto authors joined the alliance and that supposed to give them credibility and the power to act as an arbiter, I guess.
But, let’s go back to the source – the Agile manifesto. It states:
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
Essentially, it’s a prioritization principle: agile encourages teams to focus on human communication, real results, collaboration, and flexibility — but without completely ignoring processes, plans, or documentation. And it has nothing with about Product Managers and Product Owners. While Agile principles guide development, they don’t directly define product roles — that’s where Product Management comes in.
Product Manager
There are dozens of sources about product management available online. Product School posted a 7 minute read about product management that deserves your attention.
Brand Man could have been the memo that founded product management, but it was 1930 and I have more reasons to believe it’s related to Marketing than IT. It’s clear that some features of the “brand man” were taken into the foundation of the product role, that’s why products should know their customers’ pains and aim to solve them. Over the years, the product role evolved from marketing-focused to encompassing customer problems, strategy, and feature delivery.
Product Owner
Scrum, as one of the frameworks built on top of Agile, introduced some interesting roles, including a role of a product owner. As mentioned in the scrum guide, Product Owners are accountable for maximizing the value of the product resulting from the work of the Scrum Team. How this is done may vary widely across organizations, scrum teams and individuals.
Product Owner’s responsibilities, according to the Scrum Framework:
- Define the product vision: Communicate the long-term goal and purpose of the product to the team and stakeholders.
- Manage the product backlog: Create, maintain, and prioritize backlog items (features, bugs, improvements) based on business value and stakeholder input.
- Prioritize work: Decide what the team should focus on next, balancing business priorities, customer needs, and technical feasibility.
- Clarify requirements: Ensure backlog items are well-understood by the development team, with clear acceptance criteria.
- Stakeholder liaison: Act as the main point of contact for stakeholders, customers, and end-users to gather feedback and align expectations.
- Validate delivered work: Review completed features during sprint reviews to ensure they meet requirements and deliver value.
- Accept or reject work: Officially accept backlog items as done, ensuring quality and alignment with the product vision.
- Maximize ROI: Continuously make decisions that optimize the return on investment of the product.
- Support the development team: Answer questions, provide guidance, and help unblock the team regarding product-related issues.
In my opinion, Product Owner is just a role of a Product Manager inside Scrum, if your team chooses to work with Scrum. Yet, there are hundreds of links scattered around the internet to tell you otherwise.
Bottom line
Product Manager is still one of the most popular jobs in the modern world. Products are the “bridge” between the development teams and the business, that works in the shadows and solves a problem someone’s facing.
Whether you’re a developer, a business leader, or aspiring PM, understanding these distinctions will help you work more effectively with your product teams. Which approach works best in your organization?