Agile Product Owner – New Name, Same Old Problem
July 29, 2009 5 Comments
This is a guest blog post by John Mansour, Founder and Managing Partner of ZIGZAG Marketing
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.
First, let’s cover the basics. There are two key roles in the software product delivery continuum that must precede the first line of code being written, regardless of development methodology.
- The “what & why” role – 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” role – responsible for determining “how” product features should work to support the things users do. 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 support the users. They spend most of their time with developers and they test functionality to make sure it works as designed, along with a host of other responsibilities. And yes, the best people for this role are former users or those who have worked intimately with a variety of users in multiple environments.
The “how” function is typically the responsibility of a functional product designer (for lack of a better title). For the fraction of 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 get much of the credit for things like iPhones and TiVo where the cool factor is the usability.
In my humble opinion, the confusion lies in two areas. First, software companies have been trying to combine responsibilities of the product manager and functional product designer for years and it’s a nightmare in every single case I’ve ever seen, and I’ve seen a lot. Plus it creates the same identity crisis as the product manager vs. the product owner in an agile world.
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 – your products will eventually fail. Second, “product owner” couldn’t possibly be a worse title, given the responsibilities of this role. Furthermore, product managers have always been affectionately referred to as product owners because they “own” the ultimate success of a product. Perhaps a dope-slap is in order for the person who coined the title “product owner.”
In summary, two distinct roles are necessary to feed requirements to software developers if you want usable products the market will buy, regardless of development methodology. The titles are less relevant as long as the responsibilities are clearly defined. For more on functional product designers read the article titled, Product Management & The Functional Designer – 3 Reasons it’s a “Must-Have” for Successful Products.
There is no better way for you to taint your team’s perspective of your market, your prospects, your customers, your buyers. They will now have ONE data point to rely on. Later when they question your market research based on your large number of customer data points, can you blame them? You will hear “That is not what I heard from the customer I talked to…..”
