The Right Position for Product Organizations

What is the purpose of a product organization? Thinking generally, it is to increase the value of a product “in the eyes” of the customers, consumers, or users of the product. It doesn’t matter whether the product is toilet paper or software.

The product manager has decision rights over what the product will become.

The product organization manages a portfolio of products, and the purpose of portfolio management is usually maximize the value of the portfolio. How they do this job depends largely on the products and the organization that sponsors them.

This isn’t a post about how product management is done, but where the product organization “fits” in the larger organization. In a product “company” – one who produces a product to sell to its customers whether that product is a consumable, a service, an asset, or something else – the product organization is positioned between sales/marketing, R&D and delivery. Its purpose is to organize and maintain the development plan (strategy) for each product in the portfolio. It controls the sequence and to some degree the schedule of product improvements. The product group represents the customer point of view in the “provider” organization. It would be silly to think that the product management function should exist in the customer organization. The customer organization has a “procurement” organization – that decides which product it wants to buy, and what terms it is willing to accept to procure the product.

So what if any is the role of “product management” in a non-product context? Certainly, within a larger enterprise, there are products that are completely internal. One division provides services solely to other divisions within the company. One might immediately think of human resources or accounting as organizations that provide services to the rest of a company. Information Technology often occupies this spot, providing both services and assets (software and hardware) to the larger organization.

So if IT is the provider, is it providing product or service? Is the internally developed software an asset? Is IT the holder of the portfolio? Is the business unit that commissions the software the holder of the portfolio? What if the software is purchased from an external vendor, but IT “implements” – is that product or service?  It is this “worldview” that IT holds that defines how IT sees its position in the organization.

Seth Godin posted a distinction between client and customer which adds an interesting twist. If you have consumers who can choose your product or an alternative, then they are customers. If you have a consumer that tells you what product to produce, they are a client.

So we have two distinctions:

The consumer can either be a customer or a client. If they are a customer, then the provider holds the product portfolio. If they are a client, then it is less clear.

Does the client run “procurement”, and are the procuring “product development services” from IT?

In this case, then part of product development services could include product management, or a separate product management function could be evolved. Like many companies outsource their treasury portfolios to investment management firms, the entirety of product development could be outsourced – but who implements and supports the product.
If this is the case, IT owns product development, and may have several clients (business units or divisions) that share product development cost by funding these activities. IT must run the product organization, and manage the product portfolio, whereas if all products are bespoke to a specific client, then they may run several product organizations (per client).

or does the client run “Product” and IT is their delivery organization?

 This makes IT application development, a purely service organization, like a consulting firm. It requires IT to think differently about its resources and organization structure. IT may also run “implementation services” – which take the finished applications and “roll them out” and a separate support services organization dealing with operational challenges stemming from technology.

If the client runs product, they take a much greater responsibility for the design and success of the product, basically just outsourcing development to IT. This actually positions them well, to have multiple app dev “vendors”, outsourcing to other consultancies is possible if they have a well established product organization.

 This multi-vendor model would require a separate procurement function to negotiate delivery contract terms. The idea of competitive bidding starts to become attractive.

Obviously, there are some complexities not discussed. Political considerations, personal ambition, the talent pool. It talking with colleagues in different non-product organizations, the relationship of IT application development with its customers is often poorly defined, the source of contention, and drama. I think that in my experience it is because both client and provider act like they own the product development function, but they are not good at negotiating decision rights around the portfolio.

Regardless of whether business or IT owns the product organization, both sides need to evolve their organization to make the relationship work. Decision rights need to be clearly articulated, and each organization needs to structure themselves to execute their responsibilities effectively. When the relationship is between two companies, there are established contracts which define these responsibilities and “real” money changes hands. Internally, the contracts are soft, and the money is transferred between two pockets – often making the relationship less formal. Less formal is good when everyone has a common goal and common worldview. Less formal is bad when the goals and worldview are different – it makes the trust required to make progress difficult to develop.

No Comments

Post a Comment