Strong functions can still build a weak product organisation

A product organisation can have strong Engineering, strong Product and strong Design, and still produce a weak product.

That happens when each function is good at its own job, but the system between them is poorly designed. Product protects commitments and priorities. Engineering protects capacity, feasibility and technical integrity. Design protects experience quality and customer needs. None of those positions are wrong. In fact, they are exactly what you would expect from strong functions.

A better model is not one where Product, Engineering and Design stop advocating for their perspective. It is one where leaders agree in advance on the principles that govern the trade-offs between them.

The problem is what happens when every meaningful decision has to be resolved through negotiation between them.

You see this most clearly when pressure arrives. The date is fixed, the budget is fixed, the commitment has already been made, and something still has to move. Usually, the thing that moves is the product. Scope gets cut, validation gets deferred, system work becomes phase two, and experience debt accumulates quietly in the background.

That is one of the patterns I explored in the first two series. What’s broken? looked at the symptoms. Shipping becomes the measure of progress, ownership fragments across teams, and quality becomes harder to hold as the organisation scales. Why organisations stay broken looked underneath those symptoms at authority, incentives, decision-making and the systems that keep producing the same behaviour even when everyone can see the cost.

Series 3 is the pivot. This one is about what I think we should build instead.

For me, that starts with a simple idea. Strong functions matter, but they are not enough. Better product organisations are built when Engineering, Product and Design leaders jointly design the system between their functions, rather than relying on negotiation to resolve it every time pressure appears.

The better model starts before the trade-off

Most EPD organisations are still designed around functional expertise. Product brings customer and business context. Engineering brings technical judgement, feasibility and sustainability. Design brings customer understanding, experience quality and interaction design. That division is useful because it creates depth and accountability.

Where it becomes fragile is when those responsibilities also become the boundaries of leadership.

A better model is not one where Product, Engineering and Design stop advocating for their perspective. It is one where leaders agree in advance on the principles that govern the trade-offs between them. The leadership team should already have a shared view of what can move when a project comes under pressure, what constitutes acceptable quality, what debt is worth taking on, what decisions teams can make for themselves, and when commercial urgency is important enough to change the normal standard.

Without that, every difficult decision starts from first principles. Product argues for the date, Engineering argues for what is feasible, and Design argues for the experience. The organisation becomes dependent on negotiation strength rather than a shared operating model.

The better version is different. Leaders still disagree, but the disagreement happens inside a set of principles they already own together. That matters because it changes both the speed and quality of the decision. Teams are no longer waiting for three functions to defend three different things before they can move.

Before a major initiative starts, the leadership team should be able to agree what is fixed and what can change. A regulatory deadline and intended customer outcome might be non-negotiable, while scope, sequencing and implementation approach remain flexible. The team should also agree what evidence would justify moving the date. The value is not in creating another planning artefact. It is in giving the team a decision frame they can use later without reopening the same debate from scratch.

What this looks like:A team starts a compliance initiative knowing the regulatory deadline and customer outcome are fixed, while scope, sequencing and implementation approach can move. When pressure arrives later, they are applying an agreed decision frame rather than renegotiating the project from scratch.

Scope should be a lever, not the only lever

One of the clearest signs of a weak operating model is when scope is the only thing the organisation is prepared to move.

A deadline is fixed. A commercial commitment has already been made. Engineering capacity is constrained. Cost is constrained. Something still has to give, so the product absorbs the constraint.

That creates a familiar pattern. An interaction is simplified, an edge case is removed, validation is deferred, a dependency is moved out, or a system-level improvement is pushed into the future. Sometimes that is absolutely the right choice. Strong teams should know how to reduce scope, and good product judgement is often about identifying what does not need to exist.

The problem is when scope reduction becomes the organisation’s default strategy for speed.

A faster organisation is not simply one that does less. It gets better at making decisions, reduces unnecessary dependencies, improves the foundations teams build on, creates reusable patterns, learns earlier, and gives people enough context and authority to resolve more problems without escalation. A cheaper organisation simply cuts more.

The two can look very similar on a roadmap, but they are not the same thing.

A better product organisation treats scope as one of several movable constraints. Time can move. Sequencing can move. Ambition can move. Technical approach can change. A commercial commitment can be revisited when the evidence changes. Sometimes quality can move too, but it should be an explicit trade-off rather than the quiet casualty of every delivery conversation.

When a team says it cannot deliver the full outcome by the target date, the first question should not automatically be what can be cut. The team should be able to put the main constraints on the table together and ask which one is cheapest to move. A payroll initiative might keep a compliance deadline fixed while moving lower-value countries into a later release, changing the technical approach or narrowing the commercial promise. The point is not to avoid reducing scope. It is to stop making scope carry the entire negotiation by default.

What this looks like:A payroll release is running late. Instead of immediately stripping back the experience, the team keeps the regulatory deadline fixed, moves lower-value markets into a later release and narrows the first commercial promise. Scope still changes, but it is one trade-off among several rather than the automatic casualty.

If scope is the only thing that is allowed to move, then it is not really one lever among many. It has become the organisation’s pressure-release valve.

Senior leaders should optimise the whole, not just the function

Functional leadership still matters deeply. Design leaders should build strong craft, research capability, systems and judgement. Engineering leaders should build strong technical practices and sustainable foundations. Product leaders should build commercial judgement, customer understanding and the ability to frame the right problems. The organisation is weaker if any of those functions are weak.

But seniority should change the scope of the job.

At some point, being a strong leader has to mean more than being the strongest advocate for your discipline. You still need to build the function, raise the bar, hire well, develop people and create the conditions for strong practice. You also need to recognise when protecting your function is making the wider system worse.

Sometimes Design should be the function saying that the experience is already good enough and more design would not materially improve it. Sometimes Engineering should accept that the cleaner technical answer is not worth the investment. Product should be willing to walk away from a commitment when the evidence no longer supports it.

The reverse matters too. Engineering should be willing to protect an experience standard when another cut would materially damage the product. Product should sometimes argue for technical investment because the organisation is paying the cost of avoiding it repeatedly. Design should understand when genuine commercial urgency changes the appropriate quality bar.

That is not about becoming less opinionated. It is about becoming more accountable for the whole.

The better leadership teams I have seen are still full of disagreement. The difference is that their position is not predetermined by their title. They can move between perspectives because the thing they are trying to optimise is bigger than the function they happen to lead.

One simple way to reinforce that behaviour is to change the nature of product reviews. Rather than asking each leader only for their functional view, ask them to identify the most important risk they see outside their own discipline as well. A Design leader might identify unnecessary technical complexity, while an Engineering leader might call out an experience compromise that should not be accepted. Over time, that starts to make cross-functional judgement an expectation of seniority rather than something that depends on individual personalities.

What this looks like:In a product review, the Engineering leader is the person arguing that another experience compromise is unacceptable, while Design questions whether the technically ambitious option is worth the customer value it creates. Their point of view comes from the problem, not the title.

Shared outcomes need shared incentives

Most leadership teams already say they share outcomes. Everyone wants the product to succeed, everyone cares about customers, and everyone wants the company to grow.

The problem is that broad outcomes do not automatically override the incentives people experience every day.

If Product is measured on roadmap delivery, Engineering on velocity and reliability, Design on quality, and leadership celebrates shipping above everything else, then those signals will shape behaviour.

The small polls I ran alongside the earlier series were not research, but the pattern was useful. When I asked what organisations really reward, nobody selected customer outcomes. When I asked what most turns a team into a feature factory, delivery-based metrics came out strongest.

That makes sense. Teams generally respond to the strongest signal in the system, not the most aspirational language in the strategy deck.

A better product organisation makes the measures around teams reinforce the behaviour it wants. Delivery still matters, but it cannot be the only visible expression of progress. Customer outcomes, product quality, learning, sustainability and the reduction of experience or technology debt all need to have a place in the conversation.

This can be made tangible in the way initiatives are reviewed. A team launching onboarding should not only report whether the release shipped. They should also be able to show what happened to activation, SEQ, support contacts and any known experience debt that was deliberately deferred. That changes the conversation from whether work completed to whether the product improved.

What this looks like:An onboarding launch review does not stop at “shipped on time”. The team looks at activation, SEQ, support contacts and the experience debt intentionally carried into the release. Delivery is still visible, but it sits alongside evidence that the product actually improved.

Telling teams to think in outcomes is not enough. I’ve always felt leaders sharing ‘focus on outcomes’ was bullshit without ‘how’. A leaders job is to make outcome-based behaviour viable.

Decision rights have to be designed, not assumed

Another part of the system that needs to be explicit is authority.

Teams often appear slow because too many decisions still travel upwards. A designer needs approval from a Design leader, a Product Manager needs approval from a senior Product leader, Engineering wants architectural sign-off, and eventually one decision becomes a chain of dependencies across the organisation.

That is not just a process problem. It is a design problem.

A better organisation is clearer about what teams can decide, what needs alignment, and what genuinely requires escalation. That clarity matters because authority changes behaviour. When teams know the boundaries, they can make faster decisions with more confidence. When those boundaries are vague, people protect themselves by escalating.

This should be designed deliberately at the start of important work. A team might be free to change flows and interaction patterns, require EPD alignment to materially change the committed customer outcome, and only escalate when there is a significant compliance, commercial or financial implication. The aim is not to create another approval framework. It is to remove the ambiguity that causes people to seek approval unnecessarily.

The leadership job is not to stay close enough to make every important decision. It is to create enough context, principles and trust that fewer of those decisions need to come back up.

What this looks like:A team can change interactions, content and flows without leadership approval. Changing the intended customer outcome requires EPD alignment, while a material compliance or commercial risk gets escalated. The boundaries are explicit enough that the team knows when it owns the decision and when it does not.

That is where leadership starts to scale.

The seams need explicit ownership

One of the more interesting poll results from the first series was around experience ownership. Product came out highest, but Design and “everyone” were not far behind. The exact percentages matter less than the ambiguity.

Inside a team, ownership is usually relatively clear. Across a journey, it often becomes much less obvious.

Customers do not experience the organisation the way we draw it. They move from onboarding into setup, from a notification into a task, from payroll into billing, or from product into support. They experience terminology changing, patterns drifting, assumptions breaking and duplicated actions appearing between team boundaries.

The seams are where organisational fragmentation becomes customer experience.

A better product organisation does not rely on “everyone owns the experience” as a substitute for accountability. Shared ownership is useful, but it still needs enough authority behind it to change the whole.

That does not mean one function owns the entire experience. It means the leadership system has a way to protect things that cross functional and team boundaries.

One practical way to do that is to choose an important end-to-end journey and assign a senior owner for its health rather than for every feature inside it. Their job is not to take delivery away from the teams. Their job is to identify broken seams, bring the right teams together and make sure inconsistencies are actually resolved rather than added to a backlog that nobody owns.

What this looks like:Three teams own onboarding, payroll setup and billing, but one senior leader is accountable for the health of the journey across them. They do not take delivery away from the teams. They make sure terminology, patterns and broken hand-offs do not disappear into the gaps between roadmaps.

The same principle applies to technology, data, content, research and other horizontal concerns. If the value crosses the org chart, the accountability often has to as well.

The system between the functions needs to be designed

This is the part I think organisations underinvest in.

We spend a lot of time building strong functions. We define role expectations, career ladders, craft standards, rituals, review mechanisms and functional strategies. All of that matters.

We spend much less time designing the system between those functions.

That system is where decisions get made, where evidence is weighed, where quality gets traded, where customer insight enters planning, and where teams learn what the organisation really values.

If that system is weak, strong functions will still struggle.

A strong Design organisation inside a weak product system will still have difficulty creating a coherent experience. A strong Engineering organisation will still spend its time absorbing poorly resolved decisions. A strong Product organisation will still drift towards output if delivery is the clearest route to success.

The organisation only becomes stronger when the connective tissue becomes stronger too.

One useful way to expose the quality of that connective tissue is to map how a single important decision currently moves through the organisation. Take something like changing a core onboarding pattern and trace who initiates it, who reviews it, what evidence is required, when Engineering constraints enter the discussion and who can ultimately decide. Anywhere the path depends on informal influence, repeated escalation or unclear ownership is a part of the operating system worth redesigning.

What this looks like:Take one contentious product decision and trace how it really gets made. If it passes through four leaders, two reviews and an executive escalation before anyone feels able to decide, the problem is not that the team needs to move faster. The decision system itself needs redesigning.

That is what I mean by building a better product organisation. It is not about flattening disciplines or making everyone responsible for everything. It is about being much more deliberate about the shared system that sits around them.

A different test of leadership

There are two questions I think are useful for senior EPD leaders. The first is whether they can argue against the apparent interests of their own function when it is the better decision for the product. The second is whether they are willing to protect something that does not traditionally belong to them.

If Design only ever protects Design, Engineering only Engineering and Product only Product, then we may have strong functional representation without having a strong EPD leadership team.

The better test is whether leaders have created enough shared context that the right decision no longer depends on which function is speaking.

You can see this in the decisions that created the most debate over a quarter. If Design always argued for quality, Product always for commitments and Engineering always for reduction, then the leadership system has probably not evolved very far. What you want to see instead is evidence that leaders are responding to the situation rather than simply representing the interests of their function.

What this looks like:Review the decisions your leadership team debated most over the last quarter. If each function consistently took the same side, you may have strong functional representation without yet having a shared product leadership model.

That is a harder standard, but it is also a more useful one. It asks leaders to take responsibility not only for the health of their function, but for the quality of the system the functions create together.

Building something better

Series 1 looked at what happens when shipping becomes the product. Series 2 explored why organisations continue reproducing those behaviours even when many of the people inside them can see the cost. Series 3 is about what we build instead.

For me, that starts with strong functions, but it does not stop there. Better product organisations make trade-offs explicit rather than hiding them inside scope. They align measures with the outcomes they say they care about. They give teams clear decision rights. They create ownership across seams. They expect senior leaders to optimise the whole rather than only the discipline they represent.

None of that removes tension. It gives tension somewhere more useful to go.

A useful place to start is with one current initiative and look at how the organisation around it actually behaves.
Are multiple constraints allowed to move, or does the product absorb everything? Is success measured beyond delivery? Do teams know what they can decide? Is someone accountable for the experience across the seams? Are the EPD leaders around the work optimising for the whole, or are they still primarily defending their own function?

Start with one initiative:Look at what is genuinely allowed to move, how success will be measured, which decisions the team can make, who owns the seams, and whether the leaders around it are optimising for the whole. One initiative will often tell you more about the organisation than a maturity assessment will.

Those questions reveal more about the strength of a product organisation than the maturity of any single discipline in isolation. Strong functions are still essential. But the quality of the organisation is determined just as much by the system between them.

That is the part we need to get much better at building.

Strong functions can still build a weak product organisation was originally published in Bootcamp on Medium, where people are continuing the conversation by highlighting and responding to this story.