Developer Experience: Run the Internal Product Portfolio

An internal platform can have excellent documentation, high availability, and little voluntary use.

Engineers may copy an older service template, wait for a specialist, or maintain a private deployment path because the official route makes one critical task harder.

The platform dashboard reports health. The developer journey reports abandonment.

Developer experience is the product discipline of reducing avoidable friction and risk across the work of understanding, changing, verifying, releasing, and operating software.

That makes it an internal product portfolio, not a tooling clean-up project. Its users are engineers, but its consequences reach product flow, reliability, security, and the organisation’s ability to change.

Define the outcome without claiming productivity

“Make developers more productive” is too broad to govern.

Developer output depends on product clarity, architecture, team design, skills, work mix, technical debt, interruptions, and the delivery environment. A platform team controls only part of that system.

Use a bounded outcome:

Engineers can complete a named recurring journey with less avoidable delay and cognitive burden, while preserving or improving the required safety and operating evidence.

The journey might be creating a service, changing an API, testing a data migration, diagnosing production behaviour, rotating a secret, or responding to an incident.

Name the unit of change, population, risk boundary, current alternative, and evidence that would show the journey became better.

Platform Strategy covers whether shared capability creates enough interdependence and economic value to justify platform investment.

Developer experience begins after that strategic claim, with the actual work developers must perform.

Observe the journey before designing the platform

Do not start with a satisfaction survey or a backlog of requested tools.

Select a journey that matters to several teams and observe it across different levels of familiarity.

Capture:

• the trigger and intended result;
• systems, documents, people, and credentials involved;
• active time and waiting;
• decisions requiring specialist knowledge;
• failures and recovery paths;
• private scripts or workarounds;
• steps developers repeat without understanding why;
• evidence needed before the result can be trusted.

Interview the people who abandoned the official path as well as frequent users. Their workarounds may reveal missing capability, a legitimate exception, or incentives the platform team failed to see.

A senior engineer’s success can conceal cognitive load carried through memory. A new joiner’s failure can reflect missing context rather than a universally bad tool.

Keep those explanations separate until more evidence is available.

Diagnose three experience dimensions

The DevEx framework by Noda, Storey, Forsgren, and Greiler organises developer experience around feedback loops, cognitive load, and flow state.

It synthesises prior research and practitioner work. It is not a controlled test showing that improving one dimension causes organisational performance.

Use the dimensions to diagnose a journey.

Feedback loops

How long does it take for an engineer to learn whether an action was accepted, correct, safe, and effective?

Inspect local build and test feedback, review, environment creation, deployment, policy checks, logs, alerts, and the path from production behaviour back to the change.

Delay is only part of the problem. Fast ambiguous feedback can be worse than a slower answer that identifies the failed condition and recovery route.

Cognitive load

Which concepts, systems, policies, commands, and exceptions must the engineer hold in mind to complete the journey?

Distinguish essential domain complexity from avoidable organisational and tooling complexity.

A payment engineer may need to understand settlement. They should not need to discover undocumented network policy through failed deployments.

Moving complexity into a platform does not remove it. The platform team accepts responsibility for maintaining the abstraction and exposing when it no longer holds.

Flow

Can the engineer make meaningful progress without avoidable interruption, hand-off, rework, or task switching?

Flow is not uninterrupted coding time. It includes access to decisions, environments, expertise, and reliable system state.

Record where the journey stops and what restarts it. A ticket queue, flaky check, missing owner, and unclear error can produce similar delay with different causes.

Use SPACE to prevent a one-metric story

The SPACE framework covers satisfaction and wellbeing, performance, activity, communication and collaboration, and efficiency and flow.

Its authors argue that developer productivity cannot be represented by one metric or dimension. SPACE is a conceptual framework grounded in literature and industry experience, not a standard scorecard.

Select evidence at individual, team, and system levels.

Question	Evidence that may help	Misleading shortcut
Can developers complete the journey?	observed task success, failure route, recovery	login or page-view count
Is feedback usable?	wait, failed step, error comprehension, next action	average pipeline duration alone
Is cognitive burden changing?	journey interview, support theme, exception count	one satisfaction score
Does the team coordinate differently?	hand-offs, ownership waits, contribution path	message or meeting volume
Is the product effect visible?	delivery delay, instability, customer repair	lines of code or tickets closed

Use Building a Product Metrics Practice to define ownership, provenance, interpretation, and review for measures that enter the operating system.

Do not use developer metrics for individual ranking. Once a measure controls evaluation, people have reason to optimise the representation rather than the journey.

Design a paved road as a product claim

A paved road is an intentionally supported route through a recurring engineering task.

It may combine templates, automation, infrastructure, policy controls, documentation, observability, and support. It should make the common responsible path easier without pretending every workload is identical.

Write the claim:

Target user and journey
Supported product and technical conditions
Result the road delivers
Complexity it accepts on the user's behalf
Safety and compliance controls
Feedback and recovery behaviour
Known exclusions
Contribution and exception route
Migration promise
Deprecation condition

DORA’s platform-engineering guidance describes internal platforms as products for developers and recommends journey-based, user-centred development.

DORA combines multi-organisation research with practitioner guidance. Its aggregate findings do not prove that a particular paved road will improve a local team.

Start with one frequent, costly journey. Test whether eligible teams can complete it with less assistance and whether the required controls remain effective.

Do not build a complete platform before one road earns adoption.

Treat adoption as a decision, not compliance

Mandating use can increase apparent adoption while hiding poor fit.

Separate:

• eligible teams: the road fits their stated conditions;
• aware teams: they know the route exists;
• evaluating teams: they have tried it on real work;
• adopting teams: they use it for a suitable journey;
• retained teams: they continue when another suitable need appears;
• departing teams: they return to another path or build an exception.

Investigate departure. The platform may lack a capability, impose migration cost, obscure failure, or conflict with a team’s operating model.

The alternative may also export risk or duplicate expensive capability. Product discovery does not require the platform team to accept every preference.

Publish supported boundaries and the evidence behind them. Make the default easy, then govern exceptions honestly.

Startup Velocity examines the related delivery trade-offs. Here, adoption remains evidence about fit, not a target for platform compliance.

Price migration and exceptions

Migration is product work. Existing teams carry data, automation, alerts, permissions, deployment assumptions, and incident habits that the new road may change.

For each team, record:

• current journey and dependency;
• promised benefit and evidence;
• compatibility or data change;
• retraining and documentation burden;
• parallel operation period;
• rollback or exit route;
• specialist support required;
• owner and completion condition.

An exception should state why the paved road is unsuitable, which controls remain mandatory, who owns the alternative, and when the exception will be reviewed.

Do not turn exceptions into shame. Repeated exceptions around one condition may be evidence that the product boundary is wrong.

At the same time, an unsupported route cannot quietly inherit the platform team’s service promise.

Release Management helps separate migration readiness, exposure, stop conditions, and recovery from the mechanics of the paved road itself.

System Design for Product Managers helps expose authoritative state, contracts, failure, and migration consequences behind these internal product decisions.

Govern contribution, incentives, and power

The platform team controls defaults that can affect every engineering team. That is product power even when no reporting line exists.

Its incentives can distort the portfolio.

Adoption targets may encourage forced migration. Ticket targets may preserve manual support. Standardisation goals may reject valuable variation. Infrastructure cost goals may move cognitive and operating cost onto application teams.

Balance the decision rights:

• platform team owns the supported product and service boundary;
• application teams contribute journey evidence and product constraints;
• specialist authorities define mandatory risk conditions;
• a named owner decides shared investment and unresolved exceptions;
• contribution rules let domain teams improve the road without fragmenting it.

Track costs on both sides. A platform that saves central effort by making every application team perform the same manual work has not removed the cost.

Kaizen is relevant when platform and application teams can test one recurring friction without turning continuous improvement into unbounded platform scope.

Cross-Functional Collaboration provides the wider model for letting expertise change a shared decision without making responsibility a committee.

Deprecate roads that no longer deserve support

Internal products accumulate promises. Templates, APIs, actions, images, libraries, and documentation remain in use long after a better route exists.

Define deprecation when the road is introduced:

• evidence that a successor covers the required journey;
• known consumers and compatibility needs;
• migration assistance and deadline;
• security or reliability reason for urgency;
• exception authority;
• behaviour after support ends;
• archive and ownership of historical records.

Do not call a road deprecated while critical teams cannot leave it responsibly. Do not support it indefinitely because no owner will choose the migration cost.

Portfolio management includes stopping investment, not only adding capability.

When adoption conceals a broken journey

Consider a fictional internal platform that offers a paved road for creating web services. Its adoption data says nothing yet about whether developer work improved.

The platform team reports successful service creation and high availability. Several data teams still use a private template.

Journey observation shows why. The official road creates a service quickly, but its logging contract cannot represent the data lineage those teams must expose during incidents.

The private route is slower and duplicates security work, yet it produces the required operating evidence.

The platform team does not mandate migration or copy the entire private stack.

It narrows the paved-road claim to eligible web services, adds lineage evidence as a product discovery track, and creates a reviewed exception for data workloads.

The next test follows one real data service through creation, deployment, diagnosis, and recovery. Adoption will count only if the team can complete the journey within the declared control boundary.

Faster delivery remains an open question. What changed is the diagnosis: conflicting signals have exposed a product-boundary decision.

Review the portfolio through journeys

A quarterly platform roadmap can hide whether any developer journey improved.

Review a small set of critical journeys:

• What task and population did the capability serve?
• Which DevEx dimension constrained it?
• What qualitative and system evidence changed?
• Which risk or cost moved elsewhere?
• Who adopted, departed, or required an exception?
• Which migration remains unfinished?
• Which road should expand, change, or be deprecated?

CI/CD performance may explain one part of the feedback loop. It should remain one dependency among documentation, architecture, environments, permissions, observability, support, and decision rights.

Developer experience becomes a product capability when the organisation can choose which internal journeys deserve investment, prove whether they improved, and withdraw promises that no longer earn their cost.

Sources

• Noda, Storey, Zimmermann, Bird, and Forsgren: DevEx, What Actually Drives Productivity (primary framework publication synthesising research and practitioner experience around feedback loops, cognitive load, and flow; not a controlled causal study)
• Forsgren et al.: The SPACE of Developer Productivity (primary conceptual framework spanning five dimensions and several levels; it does not prescribe a universal score or metric set)
• DORA: Platform engineering (official current research and practitioner guidance treating platforms as internal products; aggregate associations and recommendations require local validation)

Read next

• Platform Strategy: Fund Shared Capability Deliberately
• System Design for Product Managers
• Building a Product Metrics Practice