Identifying Internal Products

Most Internal Product Teams don't get created from scratch. They emerge from work that started somewhere else: a duplicated capability across Stream Teams, a slow internal department that became a bottleneck, an Enabling Team practice that grew into something users needed continuously. The skill is recognising when something has crossed the threshold from "still part of the Stream Teams' work" to "warrants its own product team."

Goal

To recognise candidate Internal Products early enough that they can be productised before duplication and friction calcify, while avoiding the temptation to productise prematurely.

When does work warrant an Internal Product?

Three signals usually indicate that something has crossed the line:

1. The same work is being done in three or more Stream Teams

The "rule of three" applies here. The first time a Stream Team builds its own auth, that's the cost of doing business. The second time another team builds something similar, you might still be looking at two different problems. By the third Stream Team, the cost of duplication is starting to pay for the cost of building a shared product.

The reason to wait until the third instance, rather than productising on the first or second, is that the first two cases rarely tell you the right shape of the abstraction. Each team built theirs to fit their specific need. Looking across three independent implementations shows what is actually common versus what each team thought was common.

2. A slow internal department is becoming a critical-path bottleneck

When a traditional internal department (Finance, Legal, HR, Marketing Operations) is slowing down Stream Teams enough that the teams are routing around it (asking forgiveness later, hiring shadow specialists, working on lower-value problems they can deliver without the bottleneck), the right response is usually to convert the department to an Internal Product Team. Productising the department's outputs (self-service approval flows, templated contracts, automated compliance checks) restores both speed and quality control.

3. An Enabling Team practice has grown beyond enablement

Enabling Teams are designed to coach, not deliver. Sometimes a practice the Enabling Team developed becomes valuable enough that Stream Teams want it as a continuous service rather than a one-off coaching engagement. A research practice that needs continuous recruitment infrastructure. A design system that needs maintenance and a public component library. A QA practice that needs a shared test infrastructure.

When this happens, the right move is to spin out the productised side as an Internal Product Team and keep the Enabling Team focused on coaching. Trying to do both inside one team blurs the enable-don't-deliver line and makes the team less effective at either job.

What doesn't warrant an Internal Product

The mirror set of signals, when something looks like a candidate but isn't:

• One team has built something cool and wants it to be used. Wait for two more teams to ask for it before investing.
• A leader thinks teams should use a shared service. Mandates produce malicious compliance, not adoption. Wait until the demand is genuine.
• The Stream Teams are using the same vendor. That vendor is the Internal Product. There's no need to wrap it in another team unless the wrapping itself adds enough value to justify a team.
• The work is genuinely once per product. Not everything that two Stream Teams have done needs to become shared. If the work was a one-off integration that won't recur, leave it where it is.

The decision

When a candidate is identified, the Ecosystem Team makes the call on whether to create the Internal Product Team and how to fund it. The Stream Teams that need the product are the first customers. The transition is usually:

1. Confirm the demand. Talk to the three (or more) Stream Teams that have done the work. Are they all solving the same problem, or different problems that look similar?
2. Identify the smallest useful product. The first version doesn't need to handle every edge case the existing implementations cover. It needs to handle the common case well enough that two of the three teams would migrate to it.
3. Fund a small initial team. Internal Product Teams start small (sometimes just one or two people) and grow with adoption.
4. Make adoption voluntary. Voluntary adoption is the success metric for Internal Products. If teams don't choose to use it, the product isn't ready.

Anti-patterns

• Premature productisation. Spinning up an Internal Product Team after one Stream Team builds something cool. The team is now responsible for a product that may turn out not to be needed.
• Mandated migration. Forcing Stream Teams to switch to the Internal Product before it's actually better than what they had. Produces resentment and usually a worse product, because the Internal Product Team doesn't have to compete on quality.
• Too broad a remit. Setting up the Internal Product Team to "own all platform-y things" instead of one specific product. Becomes overloaded, never delivers anything well.
• Productising the bottleneck without changing the team's incentives. Renaming the Legal Department "Legal Internal Product Team" without giving them ownership of customer outcomes (Stream Team satisfaction, time-to-resolution) doesn't change anything.