Building software is rarely a solo effort. Even the simplest product is the result of multiple perspectives coming together, often with very different incentives and ways of thinking. For people new to software engineering, this can feel confusing at first. Who actually decides what gets built? Who figures out how to build it? And where does design fit into all of this?

This post is meant to answer those questions from the perspective of an engineering manager. My goal is to explain not just the roles involved, but how the collaboration actually works in practice, including the negotiation and tradeoffs that happen along the way.

The Core Stakeholders in Software Development

At the heart of most software teams are three core functions: product, engineering, and design. There is often a business function as well, sometimes embedded within product and sometimes operating alongside it, but the day to day execution usually revolves around these three.

Product teams are responsible for deciding what should be built and why. They are closest to customers, stakeholders, and the market. They translate customer needs and business goals into problems that the team should solve. Product managers tend to think in terms of outcomes, value, and prioritization.

Engineering teams are responsible for figuring out how those problems get solved. This includes system design, implementation, scalability, reliability, and long term maintainability. Engineering brings feasibility into the conversation. Something might be a great idea, but if it cannot be built reliably or within reasonable constraints, it needs to be rethought.

Design teams focus on how things look and feel to the user. When there is a user interface involved, design plays a critical role in usability, clarity, and overall experience. They translate abstract requirements into concrete visual and interaction models that users can actually engage with.

Not every piece of software involves all three equally. Backend heavy systems, internal tools, and infrastructure work may involve little to no design. This is why, in most cases, the two mandatory functions are product and engineering, with design coming in when there is a meaningful user facing component.

Why Product and Engineering Form the Core Partnership

In most organizations, product and engineering are the foundational partnership. Product defines what success looks like. Engineering figures out how to achieve it.

This relationship is not transactional. It is deeply collaborative. Product does not simply hand engineering a list of requirements, and engineering does not blindly execute them. Instead, both sides shape the solution together.

As an engineering manager, this is where much of my role lives. I spend a lot of time translating between product intent and engineering reality. That translation work is rarely clean or linear, and it almost always involves negotiation.

How Work Typically Starts With Epics

In many teams, especially startups and fast moving organizations, product work begins with high level groupings called epics. An epic represents a large body of work that delivers a meaningful outcome.

For example, an epic might be enabling customers to place and return orders on an ecommerce platform. Another might be launching a new onboarding experience. These are not tasks. They are goals.

At this stage, the epic is intentionally broad. It defines what needs to exist, not how it will be implemented.

Breaking Epics Into Executable Work

Once an epic exists, the next step is breaking it down into smaller pieces that engineers can actually work on. Giving a single engineer an entire epic rarely makes sense. The work needs to be divided into stories or tasks that can be owned, estimated, and delivered incrementally.

When an epic is straightforward and easily understood from a product perspective, product managers often take the first pass at breaking it down. For example, an ecommerce epic might naturally divide into ordering, payments, returns, and notifications.

However, not all epics are product oriented. Some are deeply technical, such as performance improvements, platform migrations, or reliability work. In those cases, product managers may not have the technical context needed to break the work down meaningfully.

This is where engineering managers step in. I often take ownership of breaking down technical epics into smaller, logical units of work, while collaborating closely with product to ensure alignment with broader goals.

There is no hard line here. It is a spectrum. Some product managers are highly technical. Some engineering managers take on significant product ownership. The right split depends on the people involved, the problem being solved, and what is happening in the organization at that moment.

Collaboration Without Clear Reporting Lines

In many companies, product and engineering do not report to the same immediate leadership. This means collaboration cannot rely on hierarchy. It relies on relationships.

I have worked in environments where I effectively acted as a product owner for periods of time because product bandwidth was limited. I have also worked with product managers who were technical enough to break down complex systems while I focused on people and delivery challenges elsewhere.

What matters is not who owns which task, but whether the team is moving toward a shared outcome. Feature delivery is a team sport. You succeed together or you fail together.

Negotiation Is Not Conflict

One of the most misunderstood parts of product and engineering collaboration is negotiation. Negotiation is often framed as conflict, but in healthy teams, it is simply joint problem solving.

Product managers are supposed to bring ambitious goals. They represent customer needs and business opportunity. If they do not push for more, they are not doing their job.

Engineering’s role is to evaluate feasibility. Some ideas are impossible. Some are possible but expensive. Others are possible within a constrained scope or timeline.

When product brings a set of features to engineering, the engineering manager works with the team to provide rough estimates and feasibility assessments. This translates into capacity conversations. How many engineers do we have? How much time do we realistically have? What tradeoffs are required?

This is where negotiation happens. Maybe the original request included ten features, but the team can realistically deliver seven. At that point, product prioritizes. What matters most? What can be deferred? What smaller version still delivers value?

This back and forth continues until the team reaches a shared understanding of what will be built and why. Not everyone is always happy, but everyone should be aligned on the decision.

Where Design Fits Into the Picture

Design typically enters when there is a user interface involved. Product works closely with design to translate requirements into wireframes and visual flows. Design then becomes the bridge between abstract intent and concrete experience.

Engineering reviews designs with a feasibility lens. Some designs are technically complex. Others may impact performance or require significant additional effort. This leads to another round of negotiation.

For example, a design might include rich animations or complex interactions that look great in a prototype but are costly to implement or difficult to support across devices. In those cases, engineering and design collaborate to find alternatives that preserve the user experience while reducing complexity.

I have worked in environments without dedicated design teams, usually for internal tools. In those cases, engineers often make design decisions themselves. But for serious, customer facing products, having dedicated design expertise is invaluable.

Design Negotiation in Practice

Design negotiation often feels similar to product negotiation, but with a different focus. Product is the primary customer of design. Engineering becomes a secondary stakeholder.

Design proposes solutions. Engineering evaluates feasibility. Product balances user value and delivery timelines.

When this collaboration works well, the final result is not exactly what any one group originally proposed. It is better. It reflects user needs, technical reality, and business constraints all at once.

Final Thoughts

Engineering managers live at the intersection of product, engineering, and design. The role is not about enforcing boundaries. It is about navigating them.

Successful collaboration depends far more on trust and communication than on org charts or role definitions. The best teams are flexible, pragmatic, and aligned around outcomes rather than ownership.

If you are new to software engineering, understanding this dynamic early will help you see why decisions are rarely as simple as they appear from the outside. And if you are already in the field, reflecting on how these collaborations actually work can make you a more effective partner across the board.

If any part of this resonates with your own experience, I would love to hear your perspective and how collaboration works in your teams.