Platform Strategy and User Segments

In this fictional company, the platform team’s backlog held a hundred and forty requests, and once a quarter the team put them to a vote. Any engineer could vote, and about forty web product teams did, so the winners were reliably things that made the web teams’ lives a little easier: a faster preview build, a nicer template, a dashboard widget. The company’s eight data science teams voted too, and lost every time. Their problem was not on the list as a feature; it was in the support queue as a complaint. Getting an environment with a GPU took three weeks, through a ticket that crossed the platform team, the cloud team, and finance, and while they waited they trained on laptops or on a cloud account one of them had opened with a corporate card. Those eight teams built the recommendation system that produced about a third of the company’s revenue. Nothing on the platform roadmap was for them, and a vote-only policy gave the team no way to correct that imbalance.

Three separate mistakes were compounding. The team had never decided which capabilities should be common to everyone and which should be left to teams, so the roadmap was whatever got requested. It had never divided its users into segments with different needs, so a majority of one kind of user set priorities for all. And it prioritized requests rather than problems, so a three-week wait that nobody had phrased as a feature could not compete with a widget that someone had. A platform strategy connects decisions about what to make common with whom to serve and whom to decline. Standards and exceptions define the permitted paths; evidence about the problems behind requests then guides investment priorities.

What making something common is worth

The CNCF platforms white paper describes several reasons to share capabilities: reducing the cognitive load on product teams, concentrating operational expertise, reusing delivery mechanisms, governing security and other risks, and using providers for undifferentiated foundations. Those are potential gains, not a promise that every shared service will deliver them. Evan Bottcher describes the corresponding costs of independent stacks: duplicated maintenance, repeated technology evaluation, and friction when people move between teams. Platform strategy weighs those costs against the loss of useful local choices. A common capability earns its place when the organization can explain who benefits and who will carry its operating burden.

Four questions help assess each capability. How many users need it? Does it differentiate their work, or is it plumbing they would rather not maintain? Who pays when teams do it differently? And can the platform operate it reliably within its skills, funding, and support capacity? The CNCF white paper recommends frequently needed, undifferentiated capabilities as a starting point. Its maturity model also distinguishes capabilities worth developing internally from those available through industry standards; its examples are not a mandatory destination for every organization. The three levels in A Standard Nobody Could Deviate From—strong standardization, a baseline with choice, and team choice—help frame this decision. Applying them to a platform still requires an explicit scope and authority for each control.

Candidate capability	Teams that need it	Differentiating?	Who pays for divergence	Platform can operate it?	Decision
Identity, secrets, audit logging	All	No	Security, every team	Assumed available in this example	Required control outcomes; specify which implementations are mandated or approved
Deployment pipeline for web services	Forty web teams	No	Operations, on-call, anyone who moves teams	Yes	Common by default; leaving carries the operating cost
GPU training environments	Eight data teams	No, but their product depends on it	The teams waiting and finance reviewing substitute cloud spend	Not established: ownership, skills, support, and capacity need testing	Candidate shared capability for this segment; investigate a provider or a supported path with users
Feature store and model serving	Eight data teams	Partly: the features are the product	The data teams	Serving yes; features no	Serving common; feature logic stays with teams
Front-end component library	Forty web teams	Yes: it is the product’s look	The web teams	Not the platform team’s expertise	Left to a web guild; platform hosts and builds it
Preview build speed	Forty web teams	No	The web teams; frequency and blocked work determine the burden	Build support exists; improvement effort needs estimation	Assess aggregate benefit across users; minutes per run may accumulate substantially

Two rows deserve comment. The GPU environment is common in the sense that matters, a capability many teams need and none wants to build, even though the teams are a minority; commonality is about the shape of the need, not the size of the majority. And the component library is a case where the platform declines: it is differentiating, the platform team lacks the skill, and the right owner is the people who use it, with the platform providing the hosting and build. That refusal is a strategic decision and belongs on the refusal list that The Load Has to Land Somewhere argues every platform should publish. A platform that commonizes everything anyone asks for is not thin, in the sense of a thinnest viable platform, and it will eventually operate things it does not understand.

Segments: a platform has more than one user

A vote can obscure differences in work. DORA warns that one platform design can exclude needs such as data science and mobile development. The CNCF maturity model describes situations in which typical use cases are served while users with unusual requirements cannot extend the available path. Spotify’s account illustrates one response: golden-path tutorials organized around engineering disciplines, including backend, client, data, and machine-learning work. That is a useful segmentation example, not a universal rule about how every platform must divide its users.

A useful platform segment groups users with similar tasks, constraints, and support needs. Work-based segmentation can cross departmental boundaries, although regulatory context, geography, organizational responsibility, or experience may also matter. The following is a provisional map for the fictional company; it includes users the platform has chosen not to serve yet.

Segment	Size	What they build	What they need from a platform	What they do without it	Platform’s stance
Web and API service teams	About forty teams	Customer-facing services	Service scaffolding, pipeline, runtime, observability, secrets	Copy another team’s setup, with drift	Fully served; the main golden path
Data science and ML teams	Eight teams	Models and the pipelines around them	GPU environments, data access, experiment tracking, model serving	Laptops, a card-funded cloud account, three-week tickets	Served: a second path, built with them, starting from the wait
Data engineering	Three teams	Pipelines and datasets	Orchestration, warehouse access, lineage	Their own orchestrator	Served through the data platform; the developer platform provides identity and delivery
Mobile	Two teams	The apps	Build machines, signing, store release	A build machine under a desk	Partly served: build and secrets; release tooling declined, with the reason written down
Internal tools and analysts	Many, occasional	Scripts, dashboards, small apps	A place to run something small without a service’s ceremony	Spreadsheets and a shared VM	Recognized but not currently served; review scope in a year or sooner if evidence changes

Each segment needs its own account of problems and evidence, but the shared budget still requires decisions across segments. The platform and its sponsors must allocate capacity against organizational objectives, obligations, expected benefit, dependencies, and operating cost. Record both absolute reach and the proportion of a segment affected: eight of eight teams is a coverage measure, not a substitute for counting users or estimating impact. The CNCF white paper supports starting with a limited group of engaged teams. Stream-aligned teams are important customers, but analysts, data scientists, and individual information workers can also be users. The recommendation system’s share of revenue makes its needs worth investigating; it does not establish the marginal value of a platform improvement.

Standards and exceptions, when the standard is a platform

A golden path is a supported way to do a kind of work. Spotify and the Netflix example reported by Bottcher describe arrangements in which teams could use alternatives while accepting different support or maintenance responsibilities. Those historical arrangements do not make every platform standard optional. Security or regulatory controls may be mandatory even when the implementation path is a choice. An enabling constraint should make acceptable choices clear and useful. An Offer, Not a Standard explains the support contract, versions, and responsibilities that make the offer usable.

Define where departure is allowed and who can authorize it. A temporary exception may need an owner, compensating measures, an expiry, and a resolution plan; a continuing approved alternative instead needs durable ownership and periodic review. If the governing requirement allows no departure, the choices may be redesign, refusal, or stopping the activity. A Standard Nobody Could Deviate From explains these governance decisions, and a technology standard should state the applicable scope and authority. CNCF’s composability principle supports using parts of a platform and supplying other capabilities where permitted. Bottcher’s argument for competition adds a useful feedback mechanism, but a sole internal provider can still learn from task outcomes, support records, and user research.

Read exception records alongside those other signals. Eight similar departures warrant investigation, but they may reflect a missing capability, migration difficulty, poor documentation, training needs, or a capacity shortage. The log is selective: people who cannot obtain approval or who silently work around the platform may never appear in it. In the fictional case, card-funded accounts are workarounds to investigate, not proof of eight approved, identical exceptions. The response could be better support or migration, a new capability, an approved external alternative, or a documented decision to preserve the current scope. Reviewing the reasons by segment tests both the supported paths and the refusal list without turning every departure into a feature commitment.

Feature requests, and the problems behind them

A feature request often proposes a solution before its underlying problem has been evaluated. Some requests already include useful measurements, incidents, or user evidence; others need follow-up. Neither a request nor a vote proves value, but both can help identify where to investigate. Bottcher describes shared-service backlogs driven by competing priorities and loud voices, and recommends starting with demonstrated needs, reusing proven solutions, and testing capabilities jointly with the teams that will use them.

For each request, identify who experiences the problem, the task in which it occurs, its frequency, the consequences of waiting, and what users do instead. Record the evidence and the unknowns separately. In the fictional investigation, 140 requests are grouped into eleven problems, including the GPU wait found through support records and interviews. Four Hours on the Dashboard, Nine Days for the User explains how journeys and support evidence help. An incomplete problem statement is a reason to scope investigation, not evidence of zero delay cost. The CNCF maturity model’s Measurement Level 2 example includes allocating 20% of time to user-defined features and accepting feedback through surveys, interviews, voting, and comments. That is an example scenario, not a universal quota: choose an allocation alongside maintenance, support, obligations, and available capacity.

Product discovery gathers evidence about value, usability, feasibility, and organizational viability in proportion to the proposed investment. A trial with one team can answer a narrow early question without establishing success for all users or the ability to operate at scale. Discovery continues during delivery and operation; it may lead to a limited release, another experiment, a process change, a pause, or stopping work. The platform product manager coordinates product decisions with users, engineering, operations, and those authorized to accept risk and allocate resources. A problem may be urgent enough to investigate before there is enough evidence to rank a full implementation.

Choosing what to build next

Intercom’s RICE method multiplies reach within a defined period, impact, and confidence, then divides by effort in person-months. It estimates impact per unit of work; dependencies and essential capabilities can still affect the decision. SAFe’s weighted shortest job first divides relative cost of delay by relative job duration. Its numerator combines relative user and business value, time criticality, and risk reduction or opportunity enablement. Those relative scores are not automatically currency amounts. Duration and effort are different: parallel staffing can change elapsed time without proportionately changing person-months. Job size can proxy duration only when the capacity and delivery assumptions make that reasonable. Do not silently substitute effort for duration or treat RICE and WSJF as interchangeable formulas.

Before using either method, choose comparable units and an observation period. Eight teams each waiting three weeks for one request contribute 24 team-weeks of aggregate elapsed waiting for that cohort. That is neither a monthly rate nor 24 team-weeks of idle labor: users may do other work. Estimate avoidable active work, blocked outcomes, and incremental workaround spending separately, without counting the same loss twice. For lifecycle economics, three person-months to build plus half a person-month per month to operate needs a stated horizon—six operating months would total six person-months before other costs. Keep that calculation separate from a WSJF duration denominator. Conditions that cannot be traded belong in a mandatory gate, because a weighted score allows compensation between criteria. A gate can require an authorized response by a deadline without selecting a particular platform build. Finally, a value hypothesis needs a test that distinguishes the proposed effect from other causes: a later measurement alone does not prove attribution.

Problem and reach	Evidence available	Still unknown	Provisional next action
GPU environments take three weeks; 8 data teams	Ticket records and interviews support the problem and its reach	Request frequency, avoidable work, incremental spend, solution effect, and operating capacity	Investigate with two teams; compare a supported provider route and platform changes before committing to a build
Deployment fails without a usable reason; about 30 web teams	A third of support tickets concern this problem	Time lost per failure, recurrence, proposed fix effect, and delivery duration	Measure representative failures and test a diagnostic improvement
Preview builds take eleven minutes; 40 web teams	Build duration is observed	Run frequency, blocked work versus parallel work, attainable reduction, and capacity cost	Estimate aggregate benefit and compare improvement options; do not dismiss it as convenience
Mobile signing on a desk machine; 2 teams	An incident history and a security finding require assessment	Exact control obligation, deadline, acceptable remedies, and closure evidence	Security owner specifies the response; compare existing controls, provider, build, or stopping the unsafe activity
Pipeline-status widget; some web users	A request signals interest	Underlying task, frequency, impact, and delay cost; unknown is not zero	Run a bounded inquiry if its expected information and urgency justify the effort

The product and engineering leads propose limited investigation of GPU access because repeated waits and alternative spending are visible, while the sponsors retain capacity decisions across segments. The preview problem remains a candidate for substantial aggregate benefit. Mandatory responses have their own authority and deadlines; acceptable remedies can be compared within those constraints.

The available evidence supports targeted investigation and required control responses. Unknown frequency, solution effect, operating capacity, and delivery duration still prevent a comparable implementation ranking; resolve the gaps that could change the next investment decision.

When enough evidence exists for scoring, record the formula, scales, weights if any, common horizon, capacity assumptions, and sensitivity to uncertainty. Revisit the decision as estimates, obligations, or dependencies change.

What a reviewer should ask

• For each capability the platform operates, which of the four questions supported making it common, and is the answer still true?
• What has the platform explicitly declined to make common, and is the reason written where users can find it?
• Who are the segments, by kind of work, and what is the platform’s stated stance toward each?
• Which segment set the last three roadmap decisions, and was that on purpose?
• How many teams are off the golden path, for which reasons, and which reasons cluster?
• What is the largest cost the organization is paying today for a capability the platform does not have?
• Of the top ten requests, how many have a problem statement with a count, a cost, and a source?
• Which obligations require a response, who sets its deadline, and what evidence will establish that the selected remedy satisfies the gate?
• When did the ranking last change because a cost changed?

In one possible continuation of this fictional case, the team keeps voting as an input and publishes its segments, scope decisions, evidence gaps, and capacity allocation. A limited GPU trial with two teams precedes an operating-capacity review and a broader release. The company observes shorter environment waits and the closure of some substitute accounts; comparable tasks, observation periods, user populations, and concurrent changes still need examination before attributing the improvement or estimating savings. Preview builds improve in a later quarter, with no claim about how quickly an alternative voting process would have delivered them. Mobile teams receive a managed build machine, but the signing finding remains open until the security owner verifies the required controls. Quarterly review combines exceptions with support and task evidence and revisits the already identified, unserved analyst segment after forty analysts report running scheduled scripts on a shared virtual machine. Strategy changes the decisions the team can explain; it does not turn preliminary evidence into proven value.

References:

• CNCF TAG App Delivery, Platforms White Paper (Creative Commons Attribution 4.0).
• CNCF TAG App Delivery, Platform Engineering Maturity Model (Creative Commons Attribution 4.0).
• Evan Bottcher, What I Talk About When I Talk About Platforms, martinfowler.com, 5 March 2018.
• Gary Niemen, How We Use Golden Paths to Solve Fragmentation in Our Software Ecosystem, Spotify Engineering, 17 August 2020.
• DORA, Capabilities: Platform engineering (Creative Commons Attribution 4.0).
• Sean McBride, RICE: Simple prioritization for product managers, Intercom.
• Scaled Agile, Weighted Shortest Job First, SAFe Knowledge Base, publicly visible definition.