Internal Products

What Is An Internal Product?

An internal product is software that your organization does not offer for sale to others, but uses to support its various business activities. These products can be things your organization built in house or purchased to then customize and configure.

Internal products generally satisfy the needs of users internal to your organization or enables your organization to satisfy the needs of its customers.

Examples of Internal Products

Examples of internal products include:

• Business Intelligence
• Human Resources Information Systems (HRIS)
• Corporate Websites
• Customer Relationship Management (CRM)
• Enterprise Resource Planning (ERP)
• Internal Tools
• Claims Administration tools
• Event Registration Systems
• Membership Systems
• Accounting Systems

The specific internal products your organization has depends on the nature of your organization.

The thing that all of these examples have in common is that they are built or implemented in order to address specific needs that users inside your organization have and that require ongoing understanding and refinement.

Why distinguish Internal Products?

I’ve adopted the term internal product to emphasize the switch to a product approach of maintaining an organization’s IT assets like those listed in the examples above.

IT systems and applications are typically maintained through the use of projects as defined by the Project Management Institute:

a temporary endeavor undertaken to create a unique product, service or result.

Project management is generally based on a set of assumptions that while they hold true for many types of endeavors generally aren’t valid for systems and applications of the type that can be thought of as internal products.

The following compare/contrast of products and projects are based on a presentation from Allan Kelly and other work of the #noprojects crowd.

Software products (the successful ones at least) continue to change as your users needs change or you get a more refined understanding of those needs. Projects are temporary.

Products are maintained on an ongoing basis by the same team. Keeping a team together builds knowledge capability and performance. Projects are performed by temporary organizations which disband after the project is completed. That dissolution of the team destroys knowledge capability and performance.

Projects typically grow to be quite big in order to pass through the typical budget processes that most organizations have. This results in large deliveries with considerable lead time in between them. When a team is able to work on a continuous basis on a product, changes can be delivered in small batches which helps to reduce risk due to rapid feedback and increase return because users have access to new capabilities sooner.

I’ve also adopted the term internal product to encourage people working on them to have a greater focus on the user experience that is more prevalent in product management circles than in many IT organizations.

Even though it seems at first pass that people inside organizations do not have a choice as to what systems they use, that isn’t always the case. Business units can, and do, choose to go outside for their software tools.

Where an IT organization has successfully locked the rest of the organization into specific tools, those users may ineffectively use those those tools or create inefficient work arounds to a poorly conceived system.

Update October 21, 2018

Marty Cagan was a bit ahead of his time when he wrote Moving from an IT to a Product Organization in 2008.  The customer facing products he talks about in that post are the things that get produced when organizations do their “digital” transformation.

In the article above I’ve lumped both the internal-facing and customer-facing products that Marty talks about into the internal product category, which may or may not be the most accurate categorization based on the reasons that Marty stated, although I’d also argue that there are some aspects of the customer-facing products that we should apply to internal-facing products. After all, why should the software we build for people who work in organizations be hard to use.