Skip to content

Running an internal service as a product

Help Finance, HR, Legal, technology platforms and other shared services work as Internal Product Teams. Understand the teams you serve, make the common case self-service, and review adoption and reliability.

Who it is for

Internal Product Teams

Leaders and practitioners responsible for Finance, HR, Legal, technology platforms, and other internal services.

Product leaders and representatives of the teams using those services, who can help define needs, boundaries, and measures of usefulness.

Inside the module

What the module covers

When a Stream Team can ship in days, an internal service that takes weeks to respond becomes the longest step in its work.

This module helps Finance, HR, Legal, platform, and other shared services operate as Internal Product Teams: teams that treat Stream Teams as customers, make the common requests self-service, and measure themselves on voluntary adoption.

By the end, participants have practiced how to

  • Identify the recurring queues between Stream Teams and an internal service and rank them for productization
  • Apply the rule of three and the three productization signals to decide what warrants an Internal Product Team
  • Research internal customers with the interviews and observation that Stream Teams use with external customers
  • Design a self-service interface for the common case with a clear route for novel or ambiguous requests
  • Select measures to publish, such as voluntary adoption rate, time to onboard, and service level objectives
  • Evaluate internal pricing against the design principles of low friction, real choice, and published prices

Module outline

How the time is spent

Each part ends with a short exercise, on your own work where you have it and on a prepared case where you do not. We adapt the examples and emphasis to the people in the room.

  1. Find the interfaces worth productizing

    Locate where Stream Teams repeatedly wait on your service and separate real candidates for productization from premature ones.

    Search, Booking, and Stay Management each maintain authentication. The repeated capability becomes one shared authentication product owned by an Internal Product Team. All three Stream Teams use it through self-service interfaces.

    Put it into practice

    List the requests Stream Teams send your service, from the data you brought or from the team’s own estimates, rank them by volume and waiting time, and choose the top two or three candidates.

    Topics covered

    • Traditional departments and Platform Teams as Internal Product Teams
    • Three signals that work warrants an Internal Product
    • The rule of three for shared capabilities
    • What does not warrant an Internal Product
    • Teams routing around a slow department

  2. Treat Stream Teams as customers

    Apply product discovery to an internal service by studying how teams use it before deciding what to build.

    Put it into practice

    Map one internal customer journey through your service from request to result, marking where teams wait or work around you.

    Topics covered

    • Continuous research with internal customers: interviews and observation
    • Pain points and unmet needs of the Stream Teams served
    • Confirming demand across three or more teams
    • The smallest useful product for the common case
    • A Product Manager and roadmap for the service

  3. Design the self-service interface

    Turn repeating patterns of work into interfaces teams can use without raising a ticket, while novel work still reaches an expert.

    Put it into practice

    Draft the self-service option for one common request, the route for exceptions, and the legal, security, or financial obligations it still has to meet.

    Topics covered

    • X-as-a-Service as the cheapest interaction mode
    • Templates, automated checks, decision trees, runbooks, and dashboards
    • Covering the common 80 percent and escalating the rest
    • Small core with extension points
    • Outside examples: AWS, Stripe Atlas, and Deel

  4. Run it as a product

    Agree how the service will be owned, measured, and given a reason to keep improving.

    Put it into practice

    Choose the measures of usefulness and reliability you will publish, and decide how the service will respond when teams route around it.

    Topics covered

    • Voluntary adoption as the success metric
    • Published measures: SLOs, time to onboard, adoption rate
    • Onboarding, documentation, and migration support
    • Internal pricing design principles and the Haier trading platform
    • Regulated services where teams have no alternative supplier

Practical results

What the cohort leaves with

  • A ranked list of recurring requests, with the top two or three chosen for productization
  • An internal customer journey map for one service, showing waits and workarounds
  • A draft self-service option and exception route for one common request
  • A short set of measures to publish, covering adoption, reliability, and time to onboard
  • A position on internal pricing: whether to introduce it and what alternatives teams would have

Before the module

Bring data on the requests your service receives: types, volumes, and how long teams wait. Invite two or three people from the Stream Teams that use the service, and confirm beforehand which regulatory, security, or financial obligations cannot change.

The company learning plan

Where this module fits

Part of the Internal Product Teams courses, taken at the Scaling support stage of the implementation.

See all company courses →

Internal Product Teams

  • Running an internal service as a productThis course
Explore the supporting documentation