The Conflict Nobody Talks About: When Business and Development Work Past Each Other
Article

The Conflict Nobody Talks About: When Business and Development Work Past Each Other

In many organizations there is a conflict that is rarely spoken out loud. It plays out between business units, product, and development. Not necessarily loudly and not necessarily aggressively. Often, in fact, very politely. Everyone sits in the same meetings. Everyone uses the same tools. Everyone says they are working toward a shared goal. And yet something else is happening.

Brigitte Pfeifer-Schmöller Brigitte Pfeifer-Schmöller Published Jul 6, 2026

The business side says: “We need this urgently.” Development says: “We can’t build it sensibly this way.” Product tries to translate. Management asks for the delivery date. And what emerges at the end is a backlog that reflects less a coherent product strategy than the sum of unresolved tensions.

When collaboration only works on paper

On paper, the collaboration is usually there. There are refinements, reviews, roadmaps, Jira tickets, status meetings, prioritization rounds, steering committees. Perhaps even OKRs, product visions, and regular alignment between business and IT.

But communication is not automatically clarification.

This is exactly what we keep observing in our work with product organizations: a great deal is being said, but not necessarily about the things that actually need to be resolved. The business side describes requirements because it feels pressure: from the market, from customers, from sales, operations, regulators, or executive leadership. Development asks questions, points to dependencies, talks about technical risk, quality, architecture, maintainability, and capacity.

Both sides are right. And that is precisely the problem. As long as these different perspectives are not deliberately brought together, no real shared ability to work emerges. What emerges is only a seemingly shared process.

This is not a soft observation. Research in requirements engineering has described communication between different stakeholder groups as a central challenge for decades. In their field study, Al-Rawas and Easterbrook identified three major communication barriers: ineffective communication channels, restrictions on expressiveness imposed by notations, and, notably, social and organizational barriers, which they found had the greatest influence on communication effectiveness. The largest global survey on requirements engineering practice, the NaPiRE study, found that incomplete requirements and communication flaws between project team and business side are the most frequently reported problems in practice, and among those most often experienced as leading to project failure. The causes it identifies are predominantly organizational, not technical.

In other words: this is not your organization having a bad year.

It is a structural pattern in the development of complex digital products.

The problem is rarely a lack of goodwill

In most organizations we work with, people want to do good work. The business side does not want to write bad requirements. Development does not want to block. Product does not want to be ground down between fronts. Leadership does not want to micromanage.

And still, patterns emerge that everyone eventually recognizes. Requirements arrive too late or already fully decided. Development is brought in only after the substantive questions have effectively been settled. Questions start to feel like resistance. Estimates become defensive. Prioritization becomes political. Reviews turn into status meetings. Product owners become pass-through heaters between expectation and feasibility.

And at some point, you hear the same sentence on both sides: “They just don’t understand us.” That is the moment a collaboration problem has become a cold conflict. Even organizations that have adopted agile ways of working are not immune. A systematic review of agile requirements engineering by Inayat and colleagues found that unclear requirements and communication deficits remain recurring challenges. Agile rituals change where the conversations happen, not whether the difficult ones happen at all.

Cold conflicts are more dangerous than they look

Not every conflict shows up as an argument.

Some conflicts show up as withdrawal, as politeness, as silence. You see them in the workaround nobody talks about, in the ironic comment after the meeting, in the ticket that keeps coming back because the requirement behind it was never really understood. You see them in technical decisions nobody on the business side can place, and in prioritizations that are officially accepted but practically not carried by anyone.

Conflict research has a name for this trajectory. Friedrich Glasl’s well-known escalation model describes how conflicts harden step by step: positions solidify, each side reduces the other to simplified images, direct exchange is replaced by actions and signals, and the parties gradually stop believing that talking will change anything. The critical insight is that this can happen without anyone ever raising their voice.

The dangerous thing about such conflicts is not that they exist. Different perspectives between business and development are normal. They are even necessary. It becomes dangerous when they are not worked on.

Because then they do not disappear. They migrate. Into tickets. Into architecture decisions. Into roadmaps. Into delays. Into quality issues. Into escalations. Into cynicism. Into mutual attributions.

And at some point the problem looks like a delivery problem, when it has long since become a clarification problem.

The cost is real, even if it rarely appears in any report. A frequently cited CPP study found that employees spend on average nearly three hours per week dealing with workplace conflict. Acas estimated the total cost of workplace conflict for UK employers at £28.5 billion per year, driven not primarily by open disputes but by resignations, absence, and quietly degraded collaboration.

Cold conflicts do not send an invoice. They collect interest.

Many product problems are conflicts in disguise

When releases keep slipping, the first response is usually to look at planning. When backlogs overflow, the conversation turns to prioritization. When requirements are unclear, a new template is introduced. When development seems slow, velocity gets discussed. When business units are dissatisfied, another alignment meeting is scheduled.

All of that can be useful. But it falls short when an unresolved conflict sits underneath.

Another meeting does not solve a problem when it is unclear what actually needs to be talked about, and another ticket does not create clarity when the underlying decision is still missing. The same goes for process: you can add as much of it as you like, but it will not produce collaboration between people who no longer trust each other to see the relevant reality in full.

A case study by Bjarnason, Wnuk, and Regnell at a large software company put it memorably: requirements were “slipping through the gaps.” The causes they identified were not tooling or talent, but scale, missing shared views, timing, and decision structures. The effects included quality problems, wasted effort, and software that failed to meet customer expectations. What looks downstream like a delivery failure often started upstream as a communication gap that nobody owned.

This is what we describe as upstream debt: the accumulated cost of ambiguity that was never resolved before work entered delivery. The organization pays once when unclear work starts moving, and then keeps paying interest in rework, late clarification, escalations, and meetings that feel necessary but change nothing.

Business and development see different risks

Part of the problem is that the two sides prioritize different risks.

The business side sees the risk of missing a market window. Of customers becoming dissatisfied. Of a process staying inefficient. Of a regulatory deadline being missed. Of sales or executive leadership having promised something that now has to be delivered.

Development sees other risks: technical debt, unstable architecture, security questions, integration problems, dependencies, missing testability, maintainability, performance, system complexity.

Both are real risks but if an organization has no space in which these risks can be weighed against each other properly, no good product emerges. What emerges is a power game over which risk sounds louder. Well, and then product work becomes politics.

Product Leadership begins where translation is no longer enough

Many product owners and product managers come under pressure in exactly this field of tension. They are expected to understand the business. To understand development. To prioritize, mediate, deliver, manage expectations, and create clarity, even when the decisions that would create clarity have not been made.

But product leadership does not mean shuttling translations back and forth between business and development, it means making the actual tensions visible and workable. Which assumptions sit behind a requirement? Which problem is really supposed to be solved? Which decision has not yet been made? Which risks are we carrying deliberately? Which dependencies are being underestimated? Which expectations remain unspoken? Which side does not feel heard? Where are we confusing urgency with importance? Where are we hiding conflicts behind scope, effort, or prioritization?

These are not purely methodological questions. They are leadership questions. Product leaders manage social complexity, not just tickets.

Organizations don’t just build software. They build their collaboration into it.

Software development is never only technical. How people talk to each other, decide, prioritize, and take responsibility shapes the product.

This is not a new observation. Conway’s Law has described for decades that organizations produce systems that mirror their communication structures. Martin Fowler summarizes it with Conway’s original formulation: any organization that designs a system will produce a design whose structure is a copy of the organization’s communication structure. Fowler adds that when architecture is designed at odds with how the organization actually communicates, tensions appear in the software itself: interactions that should be simple become complicated, and better design alternatives are never even considered because the necessary groups are not talking to each other.

Put differently: when business, product, and development work past each other, it does not stay on the relationship level. It lands in the product. In the architecture. In the interfaces. In the user experience. In the speed. In the quality. In the ability to respond to change.

That is why it is not enough to look only at processes, roles, or tools. You have to look at the working relationships those processes are supposed to carry.

What decision-makers should take seriously

If you keep seeing the same symptoms in your organization, it is worth looking more closely. Business units are dissatisfied because “IT is too slow.” Development is frustrated because “the business never knows what it actually wants.” Product is under permanent pressure. Prioritizations get reopened again and again. Strategic decisions arrive in teams as operational urgency. Meetings are full, but clarification never happens. Roadmaps look more stable than they are. Nobody argues openly, but trust keeps sinking.

Then you probably do not have a pure delivery problem. You have a collaboration problem. And very likely, underneath it sits a conflict that has never been properly worked on.

You don’t need more routines. You need clarification spaces.

Many organizations respond to these problems with additional meetings, new templates, or new role descriptions. Sometimes that helps. Often it is not enough.

What we observe in the majority of organizations is simpler and more uncomfortable: the conflict is not dealt with at all. People talk about each other instead of with each other. The business side complains about development in its own meetings, development complains about the business side in theirs. But the people at the center of the tension have never actually sat down together to work through it. Not because they are unwilling, but because such a conversation feels far outside the comfort zone. It is easier to escalate, to route around, or to add another alignment meeting than to face the person you have been complaining about for months.

This is why we work heavily with mediative elements in these conversations. The goal is not full harmony; that would be neither realistic nor necessary. The goal is that everyone becomes able to act again, and above all able to act for the good of the product and the organization, rather than for the defense of their own position.

Cold conflicts do not dissolve through more process. They dissolve when the relevant perspectives come back to the table, and when the organization is able to turn them into decisions that hold.

That requires spaces that work differently from status meetings. Spaces in which business, product, and development talk not only about features, but about expectations, risks, responsibility, decision rights, and real dependencies. Spaces in which blame is not distributed, but the ability to work together is restored. Spaces in which the question is not “Why aren’t you delivering faster?” but “What do we need to clarify together so that meaningful delivery becomes possible again?”

This is exactly where we start in our work with product organizations. In workshops and advisory formats, we look not only at backlogs, processes, or roles. We look at the tensions in the system that prevent business, product, and development from becoming genuinely able to work together.

Because the decisive step forward often does not begin with a new framework. It begins with a conversation that is long overdue.

Conclusion

The conflict between business and development is not the problem. The problem is when this conflict cannot become visible, discussable, and decidable. Because then it goes cold and cold conflicts cost speed, quality, trust, and focus.

Many organizations only notice this once the symptoms are visible everywhere: in overloaded backlogs, delayed releases, endless prioritization debates, and growing frustration on both sides.

Anyone who wants to improve product development should therefore not only ask how teams work, but also: Which conflicts are we currently carrying through our product organization without actually working on them?

And what would become possible if we started exactly there?

Sources