Internal Products

What Is An Internal Product?

An internal product is software that your organization does not offer for sale to others, but is used 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)
• Customer Relationship Management (CRM)
• Enterprise Resource Planning (ERP)
• Internal Tools
• Claims Administration tools
• Event Registration Systems
• Membership Systems
• Accounting Systems
• Corporate Websites*
• Mobile apps*

* These items are used by both people inside and outside your organization and are typically created or enhanced as a result of an organization’s digital efforts. I include them as examples of internal products because your organization does not generally sell these products and therefore have many of the same considerations of the other products on the list.  They also have some of the additional demands of products for sale in that you have uncertainty around how they can best provide the desired outcome of your customers.

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 support your organization’s business activities and are not directly sold to customers.

Why distinguish Internal Products?

I’ve adopted the term internal product to emphasize the switch to a product approach for 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.

Additional Resources

From IT to a Product Organization

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?

Digital Transformation – An Example

One of the key forces that is causing organizations to think about using product management inside organizations is the increasing number of digital transformations. Melissa Perri shared this interview with Siamak Khorrami, Product Operations and Governance Lead at ATB Financial, as he reflected on their digital transformation. ATB Financial is a regional bank in Canada, owned by the government, so they understand the importance and complexity of moving into a digital environment in a world of constraints.

Bring Product Thinking to Non-Product Teams

Jeff Gothelf provides a clear explanation why you should apply product management ideas inside an organization in this HBR Article. His key argument is that when you work on a business process inside an organization, you can use product management approaches to determine whether or not you’re delivering value.

How to build better internal tools

The unsung heroes of the product world are the product managers and teams who work on internal tooling and non-customer facing parts of the product stack. Sure, internal tools aren’t necessarily the sexiest thing to be working on, but plenty of product teams do. And for good reason.

In some organizations, a single product team will be 100% dedicated to supporting internal admin tools and in others a significant proportion of time is spent on them. But it’s rare that any attention is given to those teams who build these types of products. So the folks at Department of Product thought, why not spend a bit of time collating some ideas and guidance on how to build better internal products?