Skip to main content

Platform Engineering

Build Platforms Like Products

Internal platforms are products. The teams that treat them that way — with product strategy, user research, and experience design — build platforms that developers actually choose to use.

Explore the Framework

The Shift

Why Apply Product Thinking to Technical Products?

Technical products and platforms are often built with engineering rigour but without the discipline of product thinking. The result: capable systems that engineers avoid, workarounds that proliferate, and platform teams that can't explain why adoption is low.

User-Centred Investment

Product thinking starts with users — in this case, developers. Understanding what they actually need, rather than what the platform team thinks they need, is what separates platforms that earn adoption from platforms that mandate it.

Measurable Outcomes

Product thinking introduces accountability. Teams define what success looks like before they build, measure it after they ship, and adjust based on evidence. This discipline prevents investment without impact.

Strategic Alignment

Platforms built with product thinking have roadmaps. They can explain their current state, their direction, and their trade-offs to stakeholders. This alignment is essential for sustained investment and organisational trust.

Definition

What is a Technical Product?

Before you can apply product thinking to a platform, you need a clear definition of what a technical product is — and what makes one worth building.

"A technical product is any platform, tool, service, or API that developers interact with to do their work — whether it is built for internal engineers or external consumers. It has users. It solves a problem. It can be designed, iterated, and measured."
— Platform Thinking by Bo

Types

Types of Technical Products & Platforms

Technical products exist across the full engineering stack. Each type serves a different user need and demands a different product approach.

Internal Developer Platforms

Self-service platforms that abstract infrastructure complexity and provide golden paths for internal engineering teams.

  • Deployment platforms
  • Secret management
  • Developer portals
  • Scaffolding tools

Data Platforms

Systems that enable engineers and analysts to work with data at scale — from ingestion and storage to processing and serving.

  • Data warehouses
  • Streaming platforms
  • Feature stores
  • ML platforms

Observability Platforms

Tools and systems that give engineers visibility into how their services behave in production.

  • Logging systems
  • Metrics platforms
  • Tracing infrastructure
  • On-call tooling

Security & Compliance Platforms

Systems that help engineers write secure code and meet compliance requirements without becoming security experts.

  • SAST/DAST tooling
  • Policy-as-code systems
  • Access management
  • Audit platforms

External APIs & SDKs

Developer-facing products that enable external engineers to build on top of your platform or services.

  • REST/GraphQL APIs
  • Client SDKs
  • Webhooks
  • Developer portals

Developer Tooling

Tools that improve engineering workflows directly — from coding to reviewing to testing.

  • CLI tools
  • IDE extensions
  • Test frameworks
  • Code generation tools

Characteristics

Characteristics of Great Technical Products

These nine characteristics define the difference between a technical product that earns trust and one that developers work around. Hover over each to reveal the detail.

Clear Ownership

A named team with a mandate

Great platforms have a team that owns them, is accountable for their quality, and has the mandate to make decisions. No ownership means no roadmap, no quality bar, and no one to call when things break.

Developer-First Design

Designed for the user, not the builder

The interface, documentation, and behaviour of the platform are designed around developer mental models — not the internal architecture of the system producing it.

Self-Service Capability

Developers can onboard without hand-holding

The best platforms enable developers to get started, build, and ship without needing to contact the platform team. Self-service is not just a feature — it is a design philosophy.

Stable Contracts

APIs and interfaces don't break unexpectedly

Platform teams earn trust by maintaining stable interfaces, communicating breaking changes early, and providing migration paths. Unpredictable changes erode developer confidence.

Opinionated Defaults

Good decisions are made by default

Strong platforms have opinions. They guide developers toward secure, scalable, and maintainable paths by making good defaults obvious and easy.

Observable by Design

Platforms expose signals about their own health

A platform that doesn't expose its own metrics, logs, and traces makes debugging and trust-building impossible. Observability is a first-class feature.

Measured Adoption

Usage and satisfaction are tracked

Platform teams that treat adoption and developer satisfaction as primary metrics make better prioritisation decisions. If no one is measuring adoption, no one is accountable for it.

Versioned & Documented

Changes are communicated; behaviour is explained

Comprehensive, maintained documentation and a clear versioning strategy are not optional. They are the interface between the platform team and the developer user base.

Golden Paths Exist

The right way is obvious

Golden paths are pre-paved routes through a platform that represent the recommended way to accomplish common tasks. They reduce cognitive load and improve consistency across the organisation.

Scope

Internal vs External Technical Products

Not all technical products are the same. Whether your platform serves internal engineers or external developers shapes every design and strategy decision you make.

Internal Technical Products

  • Users are internal engineers with organisational context
  • Closer feedback loops: direct access to users
  • Mandate can support adoption initially, but value sustains it
  • Some rough edges tolerated if value is clear
  • Focus on productivity, compliance, and standardisation
  • Cost centre framing: value is measured in engineer efficiency

External Technical Products

  • Users are external developers with no insider knowledge
  • Feedback is indirect: support tickets, community forums, churn
  • Adoption is entirely voluntary — DX is the product
  • Rough edges cause immediate abandonment
  • Focus on discoverability, onboarding, and stability
  • Revenue or growth centre: value is measured commercially

Why It Matters

Business Value of Technical Products & Platforms

Technical platforms are investments. When built with product thinking, they return compounding value across the engineering organisation. Here is the case, made concretely.

Engineering Velocity

Well-designed platforms reduce the time engineers spend on undifferentiated work — infrastructure, tooling, compliance — freeing capacity for product development.

Risk Reduction

Platforms encode best practices. When security, compliance, and reliability standards are platform defaults, they are applied consistently rather than depending on individual engineers.

Organisational Scalability

As engineering teams grow, handcrafted approaches to infrastructure and tooling don't scale. Platforms are how organisations scale engineering capability without scaling the cost linearly.

Standardisation & Observability

Platforms create consistency across the engineering estate — making it possible to instrument, monitor, and reason about systems at scale.

Developer Retention

Engineers stay where they can do their best work. Investing in internal platforms and DX is a direct investment in the quality of the engineering environment — a key hiring and retention lever.

Cost Efficiency

Platforms create economies of scale for infrastructure and tooling. One well-built deployment platform serving 50 teams costs far less than 50 teams maintaining their own.

Core Concepts

Foundational Ideas

Developer Experience

Developer Experience is the quality of every interaction a developer has with a platform, tool, or API. It is the bridge between what your platform does and whether developers choose to use it. Platform as a Product and DX are inseparable disciplines.

Why Developer Experience matters?

Learn more

Developer Journeys

A developer journey maps every stage of a developer's relationship with a platform — from first awareness through daily use to becoming an advocate. Understanding the full journey reveals where experience breaks down and where the platform earns trust.

01

Discover

Developer becomes aware the platform exists

02

Evaluate

Assess whether the platform fits their need

03

Onboard

Get from zero to first working implementation

04

Build

Use the platform for real work

05

Scale

Expand usage, bring in teammates

06

Advocate

Recommend the platform to others

From Theory to Practice

Start with Discovery, Not Roadmaps

The most common mistake platform teams make is planning a roadmap before understanding developer needs. DX Discovery is the structured research methodology that gives you the evidence to build the right things.

Explore DX Discovery

A Personal Note

The platform-as-a-product mindset changed how I think about my work. Before I internalised it, I thought about technical excellence: uptime, performance, feature coverage. After, I started asking different questions — who are our users, what do they actually need, and how would we know if we were succeeding? Those questions are harder, but they lead to better outcomes. A technically excellent platform that developers don't use has failed. A simpler platform that earns adoption has succeeded.

Jacob Lueg Tiedemann

Jacob Lueg Tiedemann

Product Builder

Where to Go Next

FAQ

Frequently Asked Questions

Technical Products

Treating a platform as a product means applying product management discipline to internal platforms. This means defining users (developers), understanding their needs through research, defining a product strategy, measuring adoption and satisfaction, maintaining a roadmap, and iterating based on feedback. It's the difference between 'we built a thing' and 'we're continuously improving a thing that developers choose to use'.

A technical product is any internally or externally facing platform, service, or tool that developers interact with to do their work. This includes internal developer platforms, CI/CD systems, data platforms, API gateways, SDKs, and developer portals. The defining characteristic is that the primary user is a developer or technical practitioner, not an end consumer.

A traditional infrastructure team provides capacity and services, often reactively. A platform team with product thinking proactively understands developer needs, defines a product vision, and invests in experience alongside capability. The key shift is from 'we operate systems' to 'we build products that enable developers'. This requires a different skillset and mindset — closer to product management than pure operations.

Adoption is earned through trust, discoverability, and a smooth getting-started experience. Developers adopt platforms that solve real problems, have clear documentation, behave predictably, and don't require heroic effort to get started. Mandate doesn't drive adoption — value does. The most effective platform teams combine great capability with intentional experience design, and measure adoption as a primary success metric.

Internal technical products serve developers within the same organisation. They often benefit from closer collaboration, more tolerance for rough edges, and can leverage organisational context. External technical products (public APIs, SDKs, developer tools) must be entirely self-explanatory because users have no internal knowledge, no access to the team, and will leave if the experience is poor. External products demand more investment in documentation, onboarding, and stability guarantees.

Success indicators include adoption rates (what percentage of eligible teams use the platform), developer satisfaction scores (NPS or CSAT), time-to-onboard new users, frequency of unsolicited positive feedback, reduction in support tickets over time, and DORA metrics improvement among platform users versus non-users. No single metric tells the full story — a balanced scorecard approach works best.