In the world of agile software development, the product manager vs product owner confusion is hardly new. This problem has existed as long as software and product managers have been around. It merely has a new name. If you define their responsibilities in a way that mirrors the business of the customer, the confusion is all but gone.
Basics on the Product Owner and Product Manager Roles
There are two key roles in the software product delivery continuum that must precede the first line of written code, regardless of development methodology.
- The “what & why” role is responsible for determining “what” the target customer is trying to accomplish (business goals) and “why” those goals are important from a market perspective. The “what and why” role serves as the conduit for all inputs both internal and external. The end game of this role is to grow revenue by aligning product direction with the business goals of the customer. The “what & why” function is typically the responsibility of the product manager. Traditional or agile, it’s necessary regardless of who does it, their title or how it gets done.
- The “how” role is responsible for determining “how” the product should work to make users better at their job in a way that helps the customer meet their business goals. In its most basic form, this role is a surrogate user responsible for explaining in verbal, written and illustrated forms and in excruciating detail, what users do, how they do it and how software must work “functionally” to make users better at their job. The best people for this role are former users or those who have worked intimately with a variety of users in multiple environments, i.e. implementation consultants.
The “how” function is typically the responsibility of the surrogate user (for lack of a better title). In the waterfall days, they were called Business Analysts and SMEs (subject matter expert). In an agile environment they’re called Product Owners.
Call them what you want, every company with high user interaction products needs them.
For as long as the product management profession has been around, software companies have tried to combine the “what & why” role and the “how” role. It’s a nightmare in every case because most people have a comfort zone that’s either more “what & why” or “how.” Very few people have both skill sets, and even if they did, they don’t have the capacity to do them well on a consistent basis.
Regardless of development methodology, combining these roles is a recipe for failure because the skill sets and personality types required are distinctly different for each, not to mention the time commitment. When combined, the end result is either the right functionality with poor usability or highly usable features no one cares about. The bottom line — combining these roles will never consistently produce solutions that have both high market value and great usability.
In summary, two distinct roles are necessary to feed requirements to software developers if you want marketable products with great usability, regardless of development methodology. The titles are immaterial as long as the responsibilities for the what & why role and the how role are assigned to two distinct roles.
For more detail on the product owner, read The Functional Product Designer Role: It Makes Everything Click.
If the switch to agile development is stressing your organization, sign up for our Agile Product Management Training where you’ll learn how to create successful products using the best of both agile and traditional methodologies.