Most product management advice assumes you sell software

When you read an article on product management, do you think, “That’s great for that kind of company, but it’ll never work where I’m at?”

If so, you’re probably reading an article that doesn’t specify the context where it applies, and/or you don’t work on a B2C or B2B software product.

Most product management writing implicitly assumes a B2C or B2B tech company setting. That makes sense because that’s where most of the growth in product management has come from over the last decade or so.

But plenty of companies that build software and don’t sell it are adopting product management too. Companies in insurance, financial services, retail, healthcare started down this road when they found that agile was necessary, but not sufficient, to see real results from their technology spend.

But you can’t lift practices from a tech company, drop them into an insurance company with no changes, and expect them to work. The frameworks and techniques have to account for the context in which you’re using them.

It’s rather cumbersome to repeatedly say software non-tech companies buy or build but don’t sell to refer to this context, so I wanted to come up with a meaningful name. I’ve landed on internal product.

That context drives how you sort what you’re building, why the usual playbook doesn’t quite fit, and how you organize teams around it, before landing on who actually ends up owning these systems.

What is an internal product?

An internal product is software that your organization doesn’t offer for sale to others, but uses to support its various business activities. These products can be things your organization built in-house, or things it purchased and then customized and configured.

Internal products enable your organization’s internal processes and its interactions with your customers.

Three types of software you depend on but don’t sell

That’s a fairly broad definition, so I find it helpful to note three different types of internal products.

Internal tool

Something built for employees or internal stakeholders to use directly. Nobody outside the organization ever touches it. Business intelligence, general internal tools, and claims administration systems usually land here: employees use them to do their jobs, even if there’s a purchased platform underneath.

Digital product

A customer- or member-facing digital experience that isn’t the organization’s primary commercial product. Corporate websites, mobile apps, event registration systems, and membership systems fit this type. People outside your organization use them directly, even though you don’t sell them.

Business system

Purchased software, such as CRM, ERP, HRIS, or accounting, that enables a business process for an organization. You configure and customize these rather than build them from scratch, and the people using them are almost always internal.

Why distinguish internal products?

I adopted the term internal product to emphasize a switch to a product approach for maintaining an organization’s IT assets, like the ones listed above.

Organizations typically maintain IT systems and applications through projects, defined by the Project Management Institute as “a temporary endeavor undertaken to create a unique product, service or result.” That definition assumes an endpoint. Internal products don’t have one. The claims system doesn’t stop needing a team just because the project budget ran out.

I’ve also adopted the term to encourage an increased focus on user experience, something that’s more prevalent in product management circles than in most IT organizations.

It might seem like people inside organizations don’t have a choice in what systems they use, but that isn’t always true. 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 use them ineffectively or build inefficient workarounds to a poorly conceived system.

Marty Cagan made this same case back in 2008, and organizations outside tech are catching up.

How you identify and organize around internal products

For a product you sell, defining it is usually straightforward. It gets complicated once you need multiple teams working on it, or once you’re dealing with an internal product where the boundaries aren’t as clean.

I’ve seen organizations handle that a few different ways:

• aligning a product team to a business process, like claims administration,

• aligning a team to a specific system

• splitting teams by technology while pulling in product people from the business unit that needs the work done.

There isn’t a universally right answer, and each comes with tradeoffs between ownership and flexibility. I go through all three in more detail, along with how to decide which one fits your situation, in How do you identify your internal product?

Who actually manages internal products

The people who own the vision and long-term value for an internal product are rarely called product managers. They’re usually a Director or VP who leads the business area the product supports, and product management isn’t how they think about their job. That’s often fine, but don’t expect them to give up their day job to spend half their time in the product team room playing with Sharpies and sticky notes.

I lived through this exact situation when I worked on a pricing app a while back. The director of finance held the official product owner title because he owned the process, but I ended up doing most of the actual product ownership work as delivery lead, while he made the calls that needed his authority. I get into that example, and where this whole dynamic comes from, in Who really does internal product management?

Some will say this is just swapping project for product, and it doesn’t free up the Director’s calendar. That’s fair as far as it goes. But I’ve seen what happens when you treat changes to a system as a set of projects. You ship the system, disband the team, and six months later nobody’s sure who’s supposed to fix it when something breaks. Treating it as a product means someone stays accountable for it after go-live. That’s the actual difference.

Bringing it together

That’s why I write about internal products in the first place. A lot of people spend their careers managing them, but most product management advice is written for people who sell software, not for the Director who owns a claims system or the analyst stuck maintaining a corporate website. The context is different enough that the advice doesn’t always transfer.

I’d love to hear what this looks like where you work. What’s the biggest challenge you’re running into with an internal product right now? Reply and let me know.