This article is based on a piece originally published on devops.com in 2018. The concepts it raises around developer–product manager collaboration have continued to gain relevance.
The Premise: DevOps Solved Yesterday’s Problem
DevOps has been widely adopted and isn’t going away. It permanently changed how engineering and IT operations teams collaborate, deploy software, and respond to incidents. But as DevOps matures into standard practice, a new organisational challenge is emerging—one that sits at the boundary between engineering and product management rather than between development and operations.
Some are beginning to call this emerging discipline DevProd: a deliberate fusion of the developer and product manager roles, mirroring the way DevOps fused development and operations a decade ago.
DevOps Addressed a Huge Pain Point
To appreciate why DevProd matters, it helps to recall why DevOps mattered in the first place.
As software grew in complexity through the 2000s, teams of hundreds of engineers became common. Development teams wrote code; operations teams managed the infrastructure those applications ran on. The two groups had different toolchains, different priorities, and often adversarial incentives—developers wanted to ship fast, operations teams wanted stability.
DevOps, a term that gained traction following the 2008 Agile Toronto Conference, gave organisations a framework and a culture for breaking down that silo. Products and companies built around this collaboration—including AppDynamics (later acquired by Cisco), Splunk, Chef, and Puppet—demonstrated real commercial impact. Continuous integration and continuous delivery (CI/CD) pipelines became the standard rather than the exception.
Today, while DevOps practice is still maturing in many organisations, the core challenge it addressed—coordinating code releases with infrastructure operations—is broadly understood and increasingly well-tooled.
History Repeats Itself: The New Silo
A pattern that practitioners are now observing in engineering leadership conversations is telling: whenever the topic turns to deployment speed, feature rollouts, or experimentation, the product manager is either already in the room or is quickly mentioned as a key stakeholder.
This is not coincidental. Just as DevOps emerged when development and operations teams needed to move faster together, DevProd is emerging because product managers and engineers are increasingly blocked by the gap between them.
One widely-cited organisational model that demonstrates this principle in practice is Spotify’s squad model. Spotify structured its engineering organisation into small, autonomous squads—typically no more than eight people—each accountable for a discrete area of the product end-to-end. Rather than grouping people by discipline (all engineers together, all designers together), each squad contains the mix of skills needed to own its domain independently. Spotify published videos describing this engineering culture that became influential across the industry.
Feature-based team structures like this explicitly break the silo between product thinking and engineering execution. DevProd is, in essence, the cultural and tooling movement that supports exactly this kind of structure at scale.
Why DevProd? Why Now?
The timing of DevProd’s emergence is not arbitrary. Several converging trends explain why the developer–product manager relationship is under pressure now:
Software Versions Are No Longer the Unit of Delivery
For most of software’s history, the version was the primary unit of delivery. A release cycle would bundle a set of changes, QA would validate the bundle, and the bundle would ship. DevOps made those cycles shorter and more reliable.
But continuous delivery has effectively dissolved the version as a meaningful concept for many applications. Every change can now be deployed independently. The meaningful unit of delivery has shifted from the version to the feature. And features are owned, prioritised, and measured primarily by product managers—not engineers.
Different Priorities, Shared Goals
Developers and product managers approach software from fundamentally different frames of reference:
- Developers prioritise system integrity, performance, technical debt, and compliance with architectural requirements.
- Product managers prioritise business KPIs, user experience, market timing, and measurable feature impact.
When either group works in isolation, the other cannot fully achieve its goals. A product manager who can’t get engineering time can’t validate hypotheses. An engineer who doesn’t understand business context builds the wrong things efficiently. DevProd is the recognition that these two disciplines need a shared operating model—much as DevOps gave development and operations a shared operating model.
The Pattern That Signals a New Product Category
The argument that DevProd will follow the same trajectory as DevOps rests on a recognisable pattern that precedes new product categories:
- Companies identify a painful internal problem and build bespoke in-house solutions (similar to how IT teams built custom log management tools before products like Splunk existed).
- They invest ongoing resources in maintaining and evolving those solutions.
- The solutions demonstrably affect the company’s ability to meet business objectives.
- Executive buy-in follows, resources are formalised, and vendors emerge to productise what was previously custom-built.
This cycle is already visible in the feature management space. Large technology companies—including Facebook, Uber, and LinkedIn—have built sophisticated internal experimentation and feature flagging platforms. That these organisations chose to invest in building rather than buying is itself a signal that the commercial product category is still maturing.
It Won’t Be Easy—and Closer Collaboration May Not Be Enough
Bringing developers and product managers into closer working relationships is a necessary step, but not a complete solution. Several structural challenges remain:
Coordinating Parallel Experimentation
Both developers and product managers need to run experiments, but their experiments serve different purposes. A product manager might be running an A/B test on a pricing page while a developer is simultaneously testing a performance optimisation that affects the same component. Without a shared system for tracking and coordinating these experiments, they risk invalidating each other’s results or introducing compounding variables.
Feature Control in Production
Product managers increasingly need the ability to control feature visibility in production—enabling features for specific user segments, rolling back changes that hurt conversion, or gradually expanding a rollout. Historically, these actions required engineering time. In a DevProd model, product managers need tooling that allows them to act independently without creating engineering bottlenecks or risking application stability.
This is precisely the problem that feature management platforms—sometimes called feature flag or feature toggle systems—are designed to solve. They give product managers a control plane for features without requiring a new deployment for every change.
Speed Without Breakage
Developers need confidence that the changes product managers make through feature management tooling cannot break the application or degrade performance. This requires guardrails built into the tooling itself—something that well-designed feature flag platforms address through progressive rollout controls, kill switches, and integration with observability systems.
What This Means for Engineering and Product Teams
Whether or not “DevProd” becomes a widely adopted term, the underlying organisational shift it describes is real and actionable. Teams that want to stay competitive in a feature-centric delivery environment should consider the following steps:
- Form an explicit DevProd working group. Bring developers and product managers together not just for sprint planning, but for ongoing alignment on what features are live in production, what is being tested, and what the data is showing. This can be a virtual team rather than a structural reorg.
- Adopt a feature management platform. Choose a tool that gives both engineering and product management visibility into which features are active, for which users, and what their measured impact is. Evaluate platforms based on their ability to support both developer-controlled technical flags and product-controlled rollout flags from a single system.
- Define ownership boundaries clearly. The risk of closer collaboration without clear ownership is that neither party knows when to escalate. Document which decisions belong to engineering (application integrity, performance) and which belong to product (user targeting, rollout percentage, business KPIs) before you need to resolve a conflict under pressure.
- Build experimentation infrastructure deliberately. Treat your ability to run controlled experiments as a first-class engineering capability, not an afterthought. Whether you build or buy, invest in it before the absence of it becomes a bottleneck.
The Bigger Picture
DevOps demonstrated that organisational silos between technical disciplines are not inevitable—they are design choices that can be changed. The movement produced lasting cultural change, new tooling categories, and measurable improvements in how quickly organisations could respond to market demands.
DevProd applies the same logic to the boundary between engineering and product. It is not a prediction that a single term will go mainstream, but rather an observation that the pain point exists, organisations are already solving it ad hoc, and the conditions for a more systematic approach are in place. For engineering leaders and product leaders alike, the question is not whether this collaboration becomes more structured—it is whether your organisation will get ahead of it or catch up later.