The power of perspectives

I have spent much of my career working somewhere between disciplines. Strategy, design, technology, product, sales, marketing and business development all have their own ways of understanding a problem, their own language and their own assumptions about what matters. Over time, I have come to think that this difference is not something we should try to eliminate. It is something we should deliberately use.

Put the same business challenge in front of people with different experience and they will rarely see exactly the same problem. A designer may notice something in the customer experience that everybody else has accepted as normal. An engineer may understand that a technical constraint is not really a constraint anymore. Someone with a commercial background may question an assumption about what customers will actually pay for, while a person from operations may recognise immediately why an apparently elegant concept will be extraordinarily difficult to deliver.

Then there are the people who live with the problem every day. They often know things that will never appear in the presentation: why a process that looks irrational developed the way it did, which exceptions occur in reality, where customers behave differently from the model and which informal workarounds quietly keep the business functioning.

None of these perspectives necessarily contains the answer. Each of them may contain a part of it.

That distinction has become increasingly important to me, because many of the business challenges we are trying to solve today simply don’t fit neatly inside the organisational disciplines we have created to solve them.

Imagine developing a new AI-enabled service. It requires an understanding of customers and the proposition, but also technology, data, operations, people, economics and perhaps regulation. The service needs to be useful, possible to build, possible to operate and capable of creating business value. Decisions in one area will inevitably affect decisions somewhere else.

Which discipline owns that problem?

I don’t think any of them really does. The problem belongs to the business.

That creates an interesting tension because most organisations are still structured around functions and capabilities, while many of their most important problems cut straight across them. Research on cross-functional collaboration has been pointing to this for years: complex transformation becomes difficult when functions optimise their individual contribution rather than organising around a shared outcome.

For me, this is part of what makes Business Design interesting. Not because Business Design should become yet another discipline claiming ownership of the answer, but because it can provide a way of connecting different disciplines around the same business challenge.

Let the challenge define the team

Professional services organisations understandably tend to see the world through the capabilities they have built. A design company will naturally recognise design problems. A technology company will see technological possibilities. A strategy consultancy will approach the challenge strategically. None of that is necessarily wrong, but it does create a risk that we begin with the people and capabilities available to us and then shape the problem around them.

I increasingly think we should reverse that logic.

Start with the business challenge, understand what needs to change, and then ask which perspectives are actually necessary to solve it.

Sometimes the answer may be surprisingly small. A challenge around a new market may need deep domain knowledge, customer research and commercial thinking. Redesigning an operational workflow with AI may require people who understand the existing work intimately alongside AI engineering and process expertise. Developing a proposition may require customer insight and commercial thinking early on, with technology or operations becoming much more important as the idea develops.

The point is not to surround every problem with as many specialists as possible. That would simply create another kind of complexity. The point is to recognise that the composition of the team should follow the shape of the challenge and that the composition may need to change as the work progresses.

The principle is simple: bring the right perspective into the work when it can still change the outcome.

That last part matters.

Too often, specialist knowledge enters the process after the important decisions have already been made. Operations is asked how to implement something that has already been designed. Technology is asked to build a proposition it had no role in shaping. Customers are asked to validate something the organisation has already decided to launch.

That isn’t really multidisciplinary problem solving. It is sequential handover.

The people closest to the problem often see something we don’t

This becomes particularly important when we think about domain knowledge.

There is a natural tendency in consulting and innovation to place a high value on the external perspective. There are good reasons for that. Someone coming from outside the organisation can challenge assumptions that have become invisible internally and bring experience from other companies, industries and disciplines.

But distance also has a cost.

The people working inside a business often possess knowledge that is extremely difficult to capture in process maps, datasets or interviews. They understand exceptions and dependencies because they experience them. They know where the formal process differs from the real process and where customers behave differently from what everybody believes they do.

This became particularly obvious to me when thinking about how businesses should identify opportunities for AI.

An AI engineer can understand what the technology makes possible, but that doesn’t necessarily tell us where it will create value. Someone who understands the business and the work being performed can recognise where quality matters, which decisions are difficult, where knowledge is missing and what a meaningful improvement would actually look like.

Neither perspective is sufficient on its own.

The value emerges when technological possibility meets an intimate understanding of how value is created today.

I think the same principle applies much more broadly. External expertise is valuable partly because it can challenge the way things are. Internal expertise is valuable because it understands why things are the way they are. Put those perspectives into a productive relationship and something becomes possible that neither side could easily achieve alone.

That is very different from simply “involving stakeholders”.

It means treating their knowledge as part of the design material.

Good collaboration needs disagreement

There is, however, a slightly romantic idea of multidisciplinary collaboration that I don’t recognise from reality.

Putting smart people with different backgrounds into the same room does not automatically produce better answers. Sometimes it produces more meetings, more language problems, competing priorities and a solution that represents the least objectionable compromise between everyone involved.

Different perspectives become valuable only when they are allowed to affect the work.

Google’s Project Aristotle research famously identified psychological safety as an important characteristic of effective teams: people need to feel able to question assumptions, raise concerns and acknowledge uncertainty. I think there is a related challenge when people from different disciplines work together. It is not enough that they are able to speak. Their perspective has to be able to change the direction of the solution.

If the technical implications cannot change the proposition, there is little point involving technology early. If customer research cannot challenge the commercial assumptions, research becomes decoration. If operational reality cannot alter the experience we are designing, we are simply postponing the problem until implementation.

That inevitably creates tension.

I don’t think that is something we should design out of the process.

A proposition can be extremely attractive to customers and economically unattractive to the company. A business model can look fantastic in a spreadsheet and fail when it meets customer behaviour. A digital experience can be compelling and technically fragile. Something can be technically feasible but almost impossible for the organisation to operate consistently.

Those tensions are useful because they expose the reality of the business we are trying to create.

The first three concepts are familiar from design and innovation thinking. I think adding workable is useful because technical feasibility and operational reality are not the same thing.

A service may be technically possible to create while requiring an operating model that makes little sense. An AI solution may perform beautifully in a controlled environment while demanding data, governance or human oversight the organisation cannot realistically provide. A proposition may make perfect sense to the customer but create complexity elsewhere in the value chain that destroys the economics.

Those are not implementation details to solve later. They are part of the design.

Making gives perspectives somewhere to meet

One of the difficulties with multidisciplinary work is that different professions don’t just think differently. They also produce different things. Research creates insight, strategy creates choices and direction, design creates concepts and experiences, technology creates architectures and systems, and finance creates economic models.

All of those outputs can be excellent individually and still fail to become a coherent business.

This is one reason I place so much emphasis on making.

When an idea becomes tangible, the nature of the conversation changes. A prototype forces the proposition to become specific enough to react to. A service walkthrough exposes operational implications. An AI workflow makes assumptions about human and machine responsibilities visible. A simple commercial model reveals where the economics depend on behaviour we haven’t tested.

Suddenly, different disciplines are no longer discussing different abstractions. They are looking at the same thing.

And that shared object gives the team somewhere to disagree productively.

A prototype, in this sense, is not merely a design deliverable. It is a way of bringing different forms of knowledge together and exposing where they do not yet fit.

The question changes from What do you think about the idea? to something much more useful:

Does this actually work?

The idea is cyclical rather than sequential: different perspectives shape what we make. What we make gives us evidence. The evidence changes our perspective.

That feels much closer to how good multidisciplinary work actually happens.

Perspective as a design material

There is also a larger organisational question hiding underneath all of this.

Companies have traditionally built capabilities primarily by employing people, while consulting firms have built relatively permanent capability structures and sold those capabilities to clients. Both models will continue to exist because many capabilities need continuity, accumulated knowledge and a stable organisational home.

But increasingly, not every business challenge needs the same combination of expertise.

That creates room for a different model in which organisations maintain a strong core while becoming better at assembling additional capabilities around the problems they need to solve. Those capabilities may come from employees, external specialists, partners and increasingly AI systems.

The team itself becomes something we can design.

That flexibility does not reduce the need for ownership. In many ways it increases it. Someone still needs to understand the whole challenge, maintain the connection to the business outcome and ensure that excellent individual contributions become one coherent solution.

I think orchestration therefore becomes more important as access to specialist capability becomes easier.

But orchestration is not simply project management. It is not just coordinating tasks between specialists. It is maintaining a shared understanding of the problem while allowing different perspectives to reshape the answer.

This has gradually changed the way I think about expertise.

I used to think primarily about multidisciplinary teams as a way of gaining access to different skills. I now think their more interesting value is that different expertise allows us to see different realities.

And what we see determines what we eventually design.

A customer researcher can reveal a problem nobody had recognised. Someone from operations can expose an assumption that makes a concept unrealistic. An engineer can make something possible that fundamentally changes the proposition. A commercial perspective can force the team to confront whether anybody will pay. Someone who has spent ten years inside the business may say one sentence that makes everyone realise they have been solving the wrong problem.

That is why I have come to think of perspective itself as a design material.

We can deliberately ask which perspectives a particular challenge needs, when they need to enter the work and how they should interact. We can design teams around problems rather than forcing problems through predetermined teams.

And perhaps one of the most useful questions at the beginning of difficult work is not: Who do we need to execute this?

It is:

Who might see something here that the rest of us don’t?

Followed by an even more important one:

Whose perspective are we missing?

The hardest business problems rarely belong to one discipline.

The answer probably doesn’t either.