How do you identify your internal product?

When I meet folks who work on internal products, I often ask “What product do you work on?”

I’ve also used that question in workshops to get a feel for the backgrounds and experience of the participants.

I frequently get puzzled looks in response to that question and thanks to some feedback from Adrian Reed, I figured out why.

There are some significant assumptions built into that question:

The person sees themselves as actually working on a product (vs a system, or an app, or…)
The person knows how to define the boundaries of that product.

I’ve been comfortable with the idea of internal products for a while. But it’s distinctly possible that a lot of business analysts and product owners don’t look at things that way.

So I thought it’d be worthwhile to look at a few different ways to define your product.

For small products that you sell, this question is straightforward. It gets complicated when you have a large product that you need multiple teams to create, or internal product situations where the definition is not as easy.

There is no right answer.

That said, here are some things to think about as you try to decide how to identify your product(s) and organize your product teams and product people.

Products for sale

When your organization’s primary activity is developing and selling software, your product is your software. Melissa Perri in her Product Institute class on product management defines a product as “A distinct vertical functionality that solves a problem or performs a utility function for a customer for which our business purpose is furthered, either through monetary remuneration or advancement of organization objectives.”

If you develop android or iOS apps that serve one purpose it is pretty clear cut. Your product is your app.

If you’re Microsoft, your product might be Office 365. Or, your products might be Word, Excel, PowerPoint, Outlook and Notes.

If you’re a SaaS like Slack, your product is the service of helping teams communicate where the software is a big part.

So when you sell software, your initial definition of your product is pretty clear cut. What do you need to solve a customer problem and earn money?

But when your product becomes complicated enough that you want multiple teams to keep improving it, defining your product becomes a little more complicated. You’re no longer defining your product to slap a price on it, you now need to figure out how to organize the team that works on it, and the product people that work on it.

And that’s exactly the challenge that you face with internal products.

Here are three different ways you may go about defining products in an internal product setting based on what I’ve observed in different organizations. I’m sure there are other ways, and I’d love to hear your thoughts.

Organize by Business Process

You can identify a product by aligning based on business processes. This approach translates to a strong outcome orientation—business processes are often centered on delivering a specific outcome.

One example of this is where you have a product team that supports everything needed to run a specific business process, let’s say claims administration. It should be fairly straightforward to identify the right product person, at least in terms of business knowledge and decision authority in this setting. It’s someone that owns or has a great deal of responsibility for claims administration.

One big downside? Defining business processes can sometimes be as tricky as defining products. And you’re also likely to decompose business processes into smaller processes.

Depending on how much work you need to do to support the overall business process, you may need to do the same thing with your product team and product people.

Organize by System

You could always organize your product team by system so that a specific team owns one or more systems. You’ll align the product person in this case with the product team more so than the stakeholders that use the system.

The benefit to this approach is the team becomes very familiar with the system and you’ll always know who to turn to when you need changes done to a specific system.

The big downside is that the team will inevitably focus on outputs. Because of their area of responsibility, they will always view success as delivering specific changes. You can sometimes get around this if you only need a single system to deliver a specific outcome.

This is the way we organized the team that works on the Agile Alliance website. To get specific outcomes, we often need to change the website and other things, but the team that works on the website only sees changes they need to make there.

Organize teams by technology; product people by business unit

A third approach I’ve seen is when you have a central IT organization that wants to adopt an agency model for staffing work on systems.

They create teams that have an expertise in a specific technology (mainframe, data warehouse, web applications, mobile apps). Those teams then effectively “bid out” for work to various business units that need work done.

These teams often have product people on each team but then also get product people involved from the business unit that is having work done. In this situation, a business analyst stays with the team from one effort to the next and the product owner comes from the business unit.

The advantage to this approach is that you have a great deal of flexibility when attacking a specific initiative.

The big downside is this structure reinforces an output focus, and a project-based way of thinking.

How to decide which approach works well for you?

So when you try to decide how to organize your product teams, how do you go about doing that? Here are some questions that you may find helpful.

Are you serious about working in an outcome-based manner? If so, you may find organizing your teams around those outcomes, or business processes to be a good route.
Are you just starting down the journey of having stable product teams? If so, the first step may be to organize around systems. Chances are when you operated in a project-based approach you had specific people who frequently worked on the same systems. That may give you some idea of initial teams to form.
Does your organization need a lot of flexibility and looks outside for help just as much as inside your organization? You may find organizing by technology to be a good first step.

Like I said before, there is no right answer, so it’s important to be aware of the options and your current context and consider what might work best for you.

Once you think you know what that might be, try it. Also, be willing to inspect and adapt. Sometimes your first instinct will be spot on, other times not so much.

What approaches have you seen?

I’ve suggested three models I’ve seen in the wild, but I fully expect that there are other approaches. If you’ve organized product teams successfully, please share your experiences in the comments. Even if you’ve been involved in an approach to organize teams that didn’t work, share that as well, along with what you’ve learned.