Westerly Consulting

Homehome.html
Due DiligenceDue_Diligence.html
ProductProduct.html
Management AdvisoryManagement_Advisory.html
ResourcesBlog.html
AboutAbout.html
Contact UsContact_Us.html
 

Product Owner and Product Manager

Do you need both?


By Fred Engel

Westerly Consulting


Agile Scrum has added some confusion to the way products are built with its introduction of the Product Owner. The need for both a Product Manager (PM) and a Product Owner (PO) depends on how much responsibility is given to the PM.  If the PM is overloaded then he or she will not have the time to be the PO.  If not, then her or she can be the PO.  It is a design choice of the organization. This note discusses some guidelines for how decide on the role of the PO.


Let me start with a basic premise.  It is my belief that the person working with the solution creators (PO or PM) must know the customer and the market well. This person must have:


1.  Extensive discussions with and observations of customers. 

2.  Good data about usage patterns and needs. (In SaaS products it is now the norm.)

3.  Solid understanding of the competitive landscape in both features and market area.

4.  An ability to articulate how and why this new product or addition to the product is going to win.

5.  The skill and will to build consensus around the new capabilities.

6.  Be the Subject Matter Expert when it comes to all things having to do with the needed capabilities and the problem space (i.e. get people to use the product successfully). 

7.  Be the person in charge of determining if the solution meets the problem at hand (either directly or through a committee).


These duties can keep someone busy enough to be a full time job. The problem is that the job is often overloaded with other duties that cause a loss of focus.  The real benefit of defining products well is not universally valued.  In many companies the product itself is not the star of the show.  That is why the PM is so often overloaded.


For too many years the role of building the product has succumbed to the politics of the organization, often coming up short. Over the years so much has been added to the job of Product Manager that a rebellion has arisen in the form of Agile Scrum Product Owner.  I think this is a good thing because it has refocused everyone on the difficulty of building a good product and the need for undivided attention to that process. 


The politics of product responsibilities get in the way.


Here are some reasons that this job gets defocused:


1.  P&L responsibilities - There is a belief that only P&L responsibilities will cause true accountability. This causes the PM to focus on outbound marketing and sales which are very time consuming and does not leave much time for detailed product involvement.

2.  Added responsibilities to give the job teeth – Political muscle is usually something people seek in their jobs. It comes in many forms: promotions, new responsibilities, control over something important, influence after success, and friendships. The PM will seek additional responsibilities in the belief that these will help execute the job better. These additional duties (e.g. outbound marketing, sales support, trade shows, managing several products) will distract from the attention needed to do a superior job in defining a good product.

3.  The mistaken belief that the job of PM is instinct – An example will make this point best: a PM delivers a really great product because they did the job right. They get promoted for that success and continue to believe that they really understand that product best so they keep those responsibility without doing the homework they did in the past.  This works for a little while but falls off rapidly as the PM’s knowledge base gets stale.

4.  The role of Product Manager is not valued - The best people can see the value placed on the job and are not attracted to it.  If the role is low in prestige, power, political influence, or lacking good people to work with it will not attract the talent required to do the job well.

5.  Someone up high thinks they know best – This is a variant of #4 above in that the role can subservient to the dictator boss who comes in from time to time and turns the world upside down in the mistaken belief that they know best.  They can be well intentioned or not, but their belief that they know best can really hurt. Nobody good will stay in a job that gets this kind of interference.

6.  Marketing responsibilities are stacked on top of the PM role. A PM is not the marketer, if they are to spend the time building the right product.


The question really comes down to how valued the role of Product Manager is in an organization.  If the job is valued enough, then people will recognize the amount of time it takes to do the job well.  If they do not value it they will add other responsibilities to the job and it will be done badly.  The Agile revolution has refocused people on the fact that building good product is hard, takes time, and is uncertain.


Should the person defining the problem be part of the solution?


There is some belief that the people who define the problem should not be part of the solution process.  There are some good reasons for separating these roles:


1.  The problem definition will not be to biased by a proposed solution

2.  The skill set of dreaming up a solution is different than stating problems.

3.  If you are out collecting data can you be available to help in the highly interactive role of creating a solution.

4.  Good solution providers really understand the market and the product.


To me, the overriding counter point is that it makes the most sense to have the person who has done all the homework be part of the solution.  You cannot transfer that knowledge any other way. Theoretically, I could write a requirements document that is so detailed that everyone would have all they needed to know about the problem.  But people do not write things that well nor do people read all that completely.  The Waterfall methodology has been problematic partially because that process assumed you could write complete documents at each stage. You can’t, it does not happen. 


The rise of iterative interactive methodologies came about, in part, to help morph a problem statement into a solution in small steps that can be carefully monitored. You have to pay close attention to what you are doing and do it in small steps with everyone evaluating the results every step of the way.  Having the problem definer on the inner circle of this process brings the right balance to the forces involved in defining a product.


Microsoft calls this a “Forcing Function”, setting things up so that the natural forces involved drive things in the right direction. Having the discipline to look at the problem at hand carefully and design solutions to that problem is critical.  Having the person who really understands the problem and who has the connection with the customers and the market can stop the problem of forcing a solution to fit just because people fall in love with it.


So what do you call this person who figures out what the customers and the market require and then gets involved in making sure the solution addresses these things?  I am not sure it matters all that much.  The critical success factor is that the person has the time and the knowledge to do the whole job.  Do not overload this person.


Send comments to: fred@westerlyconsulting.com