On Collapsing Product and Engineering

Caveat

What follows are my thoughts on the merging or overlapping of roles that is occurring during a time of great disruption in our industry. It is by no means applicable to all companies or all teams. However, it has been a not-infrequent topic in my conversations with several tech leaders, and I thought it was well worth writing about.

Thesis

There's a growing push in our industry, accelerated by AI-assisted workflows, to collapse the boundary between Product and Engineering. The promise is a business with fewer handoffs, faster iteration, and smaller teams. For some, this challenge can quickly turn into: "Do we still need Product?", which is probably not the right question. While teams are experimenting with removing the seams which historically separated these functions, the underlying responsibilities are still not going to go away.

The pressure leading to all of this is real. AI-assisted workflows are compressing development cycles almost unimaginably, and questioning these legacy handoffs between functions. And in smaller, high-leverage teams, the traditional divide between Product and Engineering can feel unnecessary. But that's not the same as eliminating the work that boundary once managed.

What I'm seeing instead, in my own work and in conversations with others, is an attempt to collapse four things into a single function:

• Ownership: defining what should be built and why it matters.
• Discovery: validating ideas through user understanding and iteration.
• Execution: building, shipping, and stewarding systems.
• Accountability: being responsible for outcomes.

Historically, these have been distributed across roles, with Product holding ownership and discovery, and Engineers focused on execution. Accountability was often shared or ambiguous. However, holding all these responsibilities simultaneously introduces a challenge not of simplification, but of compression and coherence.

The Shift

Collapsing Product and Engineering does not remove responsibilities. Instead it concentrates them into a heavier role that requires broader and more integrated skills that either role demanded. At a minimum, this model depends on:

Holistic systems thinking  

Engineers must think beyond features, and instead understand how systems evolve over time, including data models, APIs, dependencies, and operational behavior. Otherwise, all decisions are made locally and may not withstand global pressure.

Business model awareness  

Decisions cannot be made in isolation from revenue models, cost structures, and strategic goals. Engineers must understand not just what users want, but what sustains the business.

Robust delivery infrastructure  

Frequent iteration without strong CI/CD, observability, and rollback mechanisms introduces risk, sacrificing safety for speed.

Tradeoff judgment  

Every decision becomes a tradeoff which cannot be deferred: speed vs durability, UX vs complexity, cost vs performance.

Direct stakeholder trust  

If an isolated Product layer acting as intermediary is removed, stakeholders must trust Engineers directly. This requires clear communication, shared context, and credibility.

The Risk

If the responsibilities of this collapsed role do not hold, there is real risk of failure. This is not a failure of engineering execution, but of continuity, coherence, and stewardship:

No long-term roadmap  

Work becomes reactive. Teams respond to immediate needs without shaping the system over time. Data models may drift and architecture may become harder to reason about.

Fragmented UX 

Each feature may be implemented correctly in isolation, but the overall product experience becomes inconsistent and the system may lack a unifying perspective.

Implicit decisions  

Decisions are able to be made continuously but may lack articulation. Stakeholders may lose visibility because no one is synthesizing and communicating the broader direction.

In Practice

To make this more concrete, it's helpful to frame what this looks like in practice by mapping it to typical Product responsibilities. These phases do not disappear, but they can be seen as overlapping with Engineering responsibilities in many ways.

• Conceive: frame the problem and system intent.
• Plan: architect and plan for delivery.
• Develop: code and implement the infrastructure with product judgement.
• Qualify: test, validate, and observe the system prior to deployment.
• Launch: deploy using CI/CD methodology.
• Deliver: iterate and maintain reliability, leveraging observability in production.
  • Introduction: the most rapid iteration phase.
  • Growth: scaling and standardization of the system.
  • Maturity: optimize further and make the system more efficient.
• Retire: evolve the system past maturity.
  • Decline: simplify or deprecate the system.

The Reframe

So the question isn’t whether Product and Engineering can be collapsed, but whether teams are prepared to replace those functions with something stronger. It forces Product thinking to move into Engineering, which might better be seen as raising the bar for this role, not diluting traditional functions.

It requires practitioners who can operate across system design, user understanding, and business context, while still delivering reliably in production.