However, I would like to take this opportunity to respectfully disagree with some of your article’s implied rhetoric to be entertained and conclusions, and challenge others.

In my view, the two are completely different perspectives — and they sometimes conflict. That is not to say that the two cannot possibly be the same person. It’d be wrong, but these two can become one. If you will, please consider the difference between long-term commitments, and those that are short-term.

In some regards, a Product Manager may have to entertain a customer-base that are under long-term support contracts, in that a certain release of the product needs to be supported for up to 10 years, while providing updates to the product to fix bugs, security issues and provide enhancements, but all without any pleasant or unpleasant surprises. Backwards compatibility for updates provided are key. These are, if you will, the platforms that large banks deploy software on that is developed at pace — otherwise they would be developing the platform at pace in addition to developing the software at pace.

In contrast, a Product Owner may pursue a vision for the product — in a professional capacity, it is any degree of fulfillment of that vision that creates the business value, but in doing so the Product Owner may be completely oblivious to that rather completely unintentional side-effect — the role’s interest is in the satisfaction for stakeholders, not business value directly.

A level of nuance is in whether or not the product is deployed in a self-contained, self-managed sphere, or requires distribution and management by third parties (consumers). To illustrate what I mean by that exactly;

The consumer gets it and then the consumer runs it, or

The provider runs it and then the consumer gets it.

So, let us further explore the argumentative fallacy in putting stakeholders on the same footing as customers; A Product Owner, I propose to you, represents all stakeholders, and is committed to pursue a vision. A Product Manager in contrast solely represents the business’ interests, most commonly the same as customer interests. Product Management is therefore one of the stakeholders, and perhaps a major-major one, and all too often the sole stakeholder — that doesn’t mean the two positions can therefore be confused.

To illustrate with an example where the discrepancy comes in play though;

Facebook product development is likely to entertain a vision that isn’t too far off the corporate vision;

People use Facebook to stay connected with friends and family, to discover what’s going on in the world, and to share and express what matters to them.

You would think that it’s the people that make up the pool of “friends and family” that are the products customers, but they are not. They are consumers, and it requires you yourself too become a consumer. As a consumer of the service though, you become a stakeholder.

But “friends and family” isn’t paying for the platform to be provided. Who pays?

Under the clause that customers pay and consumers do not, advertisement agencies are Facebook’s customers, and “friends and family”, and thus you yourself, are the consumers. For some, it is therefore argued that the consumers are the product, sold to customers, because without the consumers there would be very little left to sell.

However “friends and family” are whatever, they are very clearly stakeholders, even though acting in solely their best interest might violate business value, as the actual customers are something completely different (and in recent times, perhaps not even advertising agencies).

Thus, from certain perspectives, the interests of customers and stakeholders can conflict.

Easier examples can be found in areas of product development where the product is distributed among consumers, whom then run it themselves. Exemplary situations can be found in the world’s most popular web servers (Apache httpd, NGINX) and site development platform (WordPress).

As far as I’m aware, neither of these projects use Scrum, but all of them facilitate a distinction between what they want for the next generation of their product, versus what they might also need to do to sustain an adoption rate for the then current, and past, versions of their product.

Furthermore, a differentiation could be drawn from whether or not the product is proprietary, or non-proprietary. It comes more natural to me to speak of the part of the ecosystem that is Free Software aka. Open Source (ie. non-proprietary). In the issue at hand, it is far more easier to converge more and more, in one’s mind, the positions that a Product Manager and Product Owner may hold with regards to the future of the product, if the product is self-contained, self-operated, or proprietary.

Another argument is in the very nature of Scrum, and certainly one more reason I feel the methodology bears merit;

If, in a Scrum managed development process, the development team finds resolving bugs from past releases to inhibit the moving forward to future versions (i.e. clear product backlog, pursuant vision), then it is the responsibility of the Scrum master to address the inhibitors. I shall provide some options to illustrate how this isn’t necessarily the development team’s problem (albeit I have to admit that it probably is);

Better development methodologies could be entertained, to prevent bugs; Test-Driven Development comes to mind.

Continuous Integration, Continuous Delivery and Continuous Deployment (to a non-production environment) become key to success more and more,

Release Management may need to be taught a lesson or two,

Targets may need to be defined more clearly,

…

…, and there’s many more reasons inhibitors for a development team do not need to be addressed within the development team.

I think I’ve done enough for now, to illustrate how presenting a point of view as if it were the truth deserves a challenge. I look forward to discussing in more detail 😉