Platform as a Product: Delivering Value While Balancing Competing Priorities
#Regulation

Platform as a Product: Delivering Value While Balancing Competing Priorities

•
Infrastructure Reporter
•6 min read

Software platforms must be treated as products, not just code, requiring a balanced multi-disciplinary approach that considers engineering, design, usability, security, and value for internal customers.

Software platforms must be treated as products, not just code. Success requires balancing engineering, design, usability, security, and value for internal customers and the organisation, Abby Bangser mentioned in her talk Platform as a Product at GOTO Copenhagen.

A product mindset, clear ownership, and continuous investment prevent bottlenecks, platform decay, and wasted effort, enabling scalable, sustainable value over time.

Software products don't exist in a vacuum; they require a balanced multi-disciplinary approach. People don't interact with systems because they enjoy interfaces or APIs, Bangser said. They use them to achieve outcomes, so for a product to succeed, it must deliver value to both its users and the organisation behind it, she argued.

Software development success is more than just engineering excellence, Bangser said. It needs design to ensure usability, product thinking to balance prioritisation around value, and attention to concerns like security, scale, and cost. When teams focus too narrowly on writing code, they often miss the broader needs of users and stakeholders.

Platforms are software; a platform is just a software product with internal consumers, which means stricter return-on-investment expectations. It has to earn adoption and investment by being useful, usable, and reliable, Bangser explained: Teams that treat platforms purely as technical infrastructure tend to struggle, whereas teams that adopt a product mindset can create coherent, valuable experiences by treating capability, usability, and outcomes as first-class concerns.

A common challenge with platform engineering is that organisations unintentionally recreate the centralised IT models they were trying to move away from when they adopted DevOps. They introduce platform teams, but still end up with bottlenecks, slow processes, and unclear ownership, Bangser said. Instead of speeding things up, the platform becomes another layer of friction:

One reason for this is an imbalance in focus. Platform teams often architect for the consumer experience but overlook the producer experience. Platforms are two-sided markets, and for a platform to scale, it needs to decentralise extension. By actively enabling multiple teams to contribute capabilities, they remove the single group blocker. When a platform has clear contribution models and well-defined boundaries, it can evolve independently of any one team, Bangser said. Capabilities exposed through stable APIs can be composed and extended by others, much like microservices scale delivery through clear contracts. This allows platforms to grow without creating new silos or dependencies.

In theory, technical debt is a conscious trade-off. In practice, it often accumulates quietly until it becomes a serious problem, Bangser explained: In platforms, this typically appears as what I call platform decay: a gradual buildup of ad-hoc or unsupported tools, undocumented processes, manual steps, and inconsistent or hard-to-maintain patterns that require investment to maintain long-term value. As decay sets in, maintenance costs rise, and adoption slows because the platform no longer has the capacity to align with user needs alongside maintenance. Teams start working around the platform rather than with it, Bangser argued.

One reason internal platforms are particularly vulnerable is that they lack the immediate revenue signals of customer-facing products, allowing debt to grow unpaid for long periods. Applying a platform-as-a-product mindset makes a significant difference here, Bangser argued: When internal platforms have clear roadmaps, active developer feedback loops, and sustained investment in quality and usability, they often become less expensive over time rather than more, despite the initial perception.

Platforms are inherently dynamic; capabilities that once seemed essential can become redundant as cloud services evolve, while features that initially appeared niche can grow into critical foundations, Bangser explained: Platforms need to be treated as a living product rather than a set of static projects. Like a garden requires ongoing care, platforms need to plant new capabilities while also pruning or refactoring features that no longer provide value. This mindset enables organisations to adapt continuously and deliver sustainable value over time, rather than relying on one large, expensive transformation after another, Bangser concluded.

Walking Skeleton Approach

InfoQ interviewed Abby Bangser about delivering platforms.

InfoQ: How do you apply the walking skeleton approach in delivering platforms?

Abby Bangser: A walking skeleton is a minimal end-to-end slice of functionality that exercises the full system, from development through to production deployment. Its value is in validating assumptions early, exposing gaps before they become expensive, and creating a fast feedback loop. For platforms, this means identifying the smallest viable path that covers core workflows, including contributor onboarding, consuming capabilities via APIs, CI/CD integration, and deploying into a real environment. Building this early reveals where developer experience breaks down and where operational tooling is lacking. Once the approach is validated, they can iterate from a working foundation and expand with confidence.

AI Impact on Platforms

InfoQ: What impact does artificial intelligence have on platforms?

Bangser: AI is changing both how platforms are built and what users expect from them. Developers increasingly expect intelligent, context-aware tooling that provides recommendations, troubleshooting assistance, and help optimising configurations. To support this, platforms need to be API-first and event-driven, exposing data and controls in standardised ways. From a platform-building perspective, AI also enables richer product feedback by analysing usage patterns, surfacing friction points, and automating routine tasks. Ideally, AI works on both sides of this feedback loop and helps platforms reduce cognitive load for developers based on real usage monitoring rather than assumptions.

About the Author

Ben Linders runs a one-person business in Agile, Lean, Quality and Continuous Improvement. Author of Getting Value out of Agile Retrospectives, Waardevolle Agile Retrospectives, What Drives Quality, The Agile Self-assessment Game, Problem? What Problem?, and Continuous Improvement. Creator of many Agile Coaching Tools, for example, the Agile Self-assessment Game. As an adviser, coach, and trainer, he helps organizations by deploying effective software development and management practices. He focuses on continuous improvement, collaboration and communication, and professional development. Ben is an active member of networks on Agile, Lean and Quality, and a frequent speaker and writer. He shares his experience in a bilingual blog (Dutch and English) and as an editor for Agile at InfoQ. Follow him on twitter: @BenLinders.

Related Content

Comments

Loading comments...
Back to Home