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?
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.
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.