Platform As Product

---
name: platform-as-product
description: Run an internal platform with users, feedback, and adoption metrics rather than as a mandated standard. Use when platform adoption is poor or teams complain about the tools they are required to use.
---

# Platform as product

Internal platforms have users who cannot choose a competitor, which
removes the feedback that keeps external products honest. Treating the
platform as a product supplies that discipline deliberately.

## Method

1. **Identify your users and their jobs.** Product engineers shipping
   features, not the platform team's idea of good practice (see
   customer-personas).
2. **Talk to them regularly.** Interviews and observation, since
   internal users complain informally and rarely file useful feedback
   (see customer-interviews).
3. **Measure adoption honestly.** Voluntary usage is the signal;
   mandated usage tells you nothing about whether the platform helps
   (see paved-road-adoption).
4. **Prioritise by friction removed.** The most painful step in the
   current workflow, not the most interesting engineering problem (see
   prioritization-frameworks).
5. **Publish a roadmap and honour it.** Internal users plan around the
   platform, and surprise changes break their commitments (see
   roadmap-communication).
6. **Support your users properly.** Documentation, examples, and
   responsive help, because a platform without support is a platform
   people avoid (see documentation-site).
7. **Retire what nobody uses.** Unused platform features cost
   maintenance and complicate the offering (see feature-sunsetting).

## Boundaries

Product thinking improves adoption; it cannot compensate for a platform
solving a problem teams do not have. Internal users cannot leave, which
means dissatisfaction shows as workarounds rather than churn.
Platform teams need enough staffing to support what they build.