In the world of agile software development, the confusion over product owner versus product manager is hardly new. This problem has existed as long as software and product managers have been around. It merely has a new name – a big reason for much of the confusion.
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” functionality should go into a product and “why” from a market and business 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 market dynamics and customer needs. 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” function is typically the responsibility of a functional product designer or surrogate user (for lack of a better title). For the software companies that have them, they go by such titles as Business Analyst, SME (subject matter expert) and Technical Product Manager. In an agile environment they’re called Product Owners.
Call them what you want, every company with high user interaction products needs them. They generally get the credit for the “cool usability” factor.
The confusion lies in two areas:
- First, “product owner” is a very confusing title. Product managers have always been affectionately referred to as product owners since they “own” the ultimate success of a product. But OK, the name was created by software developers based on the need for a dedicated product requirements feeder role, something products managers have typically done as part of their role.
- Second, software companies have tried to combine the responsibilities of the product manager and the functional product designer (product owner) for years and 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. A dilemma on par with, “would you like to lose an arm or a leg today?” 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. The titles are immaterial as long as the responsibilities for the what & why role and the how role are clearly defined.
For more detail on the functional product designer, read Product Management & The Functional Designer – 3 Reasons it’s a “Must-Have” for Successful Products.
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.