Ways of working before features

Many platform decisions get stuck in discussions about features. But the capabilities they offer on paper tend to become irrelevant if the organisation’s own structure cannot make use of them.

The most common mistake is not choosing the wrong system, but choosing a system before the way of working has been defined.

The outcome is determined by how well the platform matches the organisation’s maturity. Three things need to be clear:

• how content is produced

• how decisions are made

• how responsibility is distributed

Only then can the platform become a support for the work, rather than something the work has to adapt to.

It is not technology that creates complexity

A digital platform is never just technology. Today, everything from traditional CMS platforms to headless solutions, DXPs, and low-code tools sits under the same umbrella.

The difference between them is not only technical, but rather about how content is handled, how much development is required, how many channels are supported, and how independent the organisation needs to be in its day-to-day work.

This also means that selecting a platform is, in practice, a choice of operating model. It is about defining a plan for:

• who is responsible for content and publishing

• how decisions are made regarding features and priorities

• how development and maintenance are organised

• how quality, accessibility, and security are ensured

Without this clarity, the platform risks becoming a tool for a few, rather than a shared resource for the entire organisation. If this is not defined from the start, governance tends to emerge afterwards, often with unintended consequences.

• Teams create their own publishing logics
• Content gets duplicated across systems
• Technical decisions are made locally without a shared direction
• And so on…

This rarely happens as one major misstep, but rather as many small local optimisations that together create fragmentation and inefficiency.

The cost that emerges after launch

When platforms are compared, the focus is often on the initial and visible costs: licensing, implementation, and project work. But in most cases, the real cost emerges after launch.

When the platform and the organisation are not aligned, friction tends to appear. This often leads to dependency on external resources to solve everyday challenges. When routine work requires technical involvement, costs tend to increase significantly over time.

Gradually, costs shift from technology to the organisation. What was once an editorial workflow becomes a development-dependent way of working, where even small changes require substantial effort.

This is where the difference between a “cheap” and an “expensive” platform emerges — not in licensing costs, but in what the organisation needs in order for the solution to actually work.

When the platform dictates the way of working

A clear sign that the alignment is off is when the system starts defining how work must be done.

When publishing is driven by technical dependencies rather than business needs. Or when content changes are pushed into development workflows, not because it is desirable, but because the system requires it.

This often leads to a shift within the organisation, where teams start finding alternative ways of working:

• content is managed in documents

• spreadsheets are used for structure

• parallel tools emerge alongside the system

This is not a rejection of the platform. Rather, it is an adaptation to make the platform work in practice.

Features are not the answer key

The most important shift in this type of decision is letting go of the idea that there is a “right CMS”. There are only systems that fit better or worse.

Evaluation and selection need to be put in relation to the organisation’s ways of working, technical landscape, level of maturity, and long-term needs. The same platform can therefore be both right and wrong.

A headless CMS can be powerful in a product organisation with strong development capabilities, but create friction in an organisation where fast publishing and autonomy are critical.

A traditional CMS can feel limiting in an advanced digital environment, but at the same time create stability and momentum where coordination is the main challenge.

The decision should be driven by the organisation’s ways of working and capability, not by which platform looks strongest in a feature checklist.

Final reflections

Choosing a CMS in a complex organisation is rarely about finding the most advanced platform. It is about selecting a solution the organisation can actually work with, evolve, and scale over time.

Platforms tend to reinforce the structure they are placed within. An organisation with clear ways of working and defined responsibilities will gain leverage even from simpler solutions. An organisation with unclear processes, on the other hand, risks increasing complexity regardless of how modern the technology is.

Successful platform decisions rarely start with functionality or requirements lists alone. They start with the organisation’s reality: how people work, how decisions are made, and what level of change the organisation is actually prepared to handle.

Two principles consistently appear in organisations that succeed:

• do not choose more system than the organisation can fully use

• never underestimate the gap between what is built and what can actually be maintained

In CMS evaluations, it is critical to understand how the organisation operates in practice. That means creating a clear picture of ways of working, responsibilities, processes, and technical dependencies before making a platform decision.