Benefits of Formalism between Internal Digital Product Teams

Some Digital Products are expected to be shared and used broadly as components or dependencies in more complex Digital Products. Microservices architectures are a common example. For a Digital Product that is an “internal” sub-component or dependency of another Digital Product, some formalism in understanding pricing and contracts helps in three ways:

  1. It may create an objective basis for understanding financial outcomes and value for the sub-component products. Increased formalism and consequential measurement practices provide continuous visibility of the operational and financial data needed to support full lifecycle Product Management, providing the same level of insight and routine control provided by Enterprise Resource Planning (ERP) systems or by cloud platform providers.

  2. It may provide the data collection processes needed to understand internal products by the same standards used for externally sourced products. This can result in a more objective comparison of options. In some cases, an internally sourced product may be a candidate external product in its own right. Alternatively, an apples-to-apples comparison of well-defined internal and external products could provide the case for replacing internal products with more viable external options.

  3. It may support long-term planning of the product lifecycle and the management of technology risks. Roadmapping and investment planning can become more proactive and long-term (as opposed to reactive and ad hoc). The use of automated reports can reveal concerns about the full stack of components such as end-of-life, security vulnerabilities, and compliance.