“What system do we need?". The question every transformation needs to ask. But not until it's ready to.

When a process breaks down, when a merger creates operational chaos, when a sales team underperforms or operations fall short of capacity - the instinct is to reach for technology. A new CRM. A better ERP. An automation platform. A data warehouse. That’s because the assumption is that the right tool will fix the underlying problem.

As a result, teams fall into risk of moving quickly into features, platforms and implementation paths before they have fully understood what value needs to change - for the customer, the business, or the people doing the work. But technology does not fix broken processes. It facilitates, scales and accelerates them - including the broken parts. But it does not fix their wrong design, fragmented structure and any other conceptual mistakes that a process can witness. Organisations that invest in platforms before defining what value they are supposed to deliver routinely find themselves in the same position twelve or eighteen months later: the system is live, the costs are sunk, and the business problem remains. Sometimes it is even worse, because now it is embedded in software. When this happens, the natural response is to question the implementation, the vendor, the configuration or the level of adoption.

Those factors matter. But they are often symptoms of a deeper issue: the transformation started before the value logic was clear enough.

"What system do we need?" is a truly valid question in course of planning your transformation. But much further in the process than the beginning. A much better first question is: "What value needs to move differently through our organisation - and how do we know when it does?"

And this is not a philosophical distinction. It has direct, practical and - very often – financial consequences for how a transformation project is scoped, resourced, and measured.

When you start with value, you are forced to define:

• What outcome you are actually trying to achieve, and how it will be measured - not in technology terms, but in business terms. Faster decisions? Lower cost-to-serve? Higher conversion? Reduced operational risk?
• Where value is currently being lost - the handoffs, delays, rework loops, and misalignments that sit between your current state and the outcome you want?
• What success looks like before a single line of code is written - so that when the technology is eventually selected, it is evaluated against a clear standard.

This is the foundation of value-first transformation. And it is still, in 2026, observed as the exception rather than the rule.

The value-first gap appears in recognisable patterns across industries.

In financial services, a flagship example is when it surfaces during merger integrations - where the assumption is that harmonising two organisations means integrating their systems, when the real work is aligning their processes and redefining how value flows to the customer. Organisations that start with process clarity before touching technology consistently achieve faster results at lower cost.

In operations, the gap appears when capacity is the stated problem and capital investment is the proposed solution - when in reality, the constraint is invisible waste embedded in how work is sequenced and handed off. Addressing the process first routinely unlocks meaningful output gains without additional infrastructure spend.

In many cases, the real constraint is not capacity, but waste embedded in the process - unnecessary steps, handovers, and rework that do not create value for the customer.

In sales and commercial functions, it shows up when conversion rates are low and the response is to invest in a new CRM or a larger lead database - when the actual bottleneck is in how the sales process is designed, how leads are qualified, and how the handoff between marketing and sales is managed.

In each case, the technology question is not wrong. It is simply premature.

To show how process methodologies sit at the heart of value-first transformation work, let’s take a closer look at the benefit of a sample combo: Value Stream Mapping and BPMN 2.0.

Value Stream Mapping makes the flow of value through an organisation visible, identifying where it moves efficiently, where it stalls, and where it disappears entirely. It is a diagnostic tool that shifts the conversation from "what do we need to build?" to "what is actually happening, and what should happen instead?"

While BPMN 2.0 (Business Process Model and Notation) provides a shared language for business and IT teams to describe that future state with precision. It eliminates the translation loss that typically occurs between a business requirement and a technical specification. And it ensures that when technology is eventually introduced, it is built around a process that has already been validated against business outcomes.

Together, these tools make the value logic of a business explicit, testable, and improvable. How does that influence the next steps? In short, before a single system is selected or a line of code is written, the business already knows what it is building - and why it will work.

One of the most powerful shifts in value-first thinking is the application of MVP (Minimum Viable Process) logic to transformation design. Rather than designing the complete future state and then building toward it over a multi-year programme, value-first transformation identifies the smallest process change that will deliver a measurable business outcome - and delivers that first.

This approach reduces risk, accelerates time-to-value, and builds organisational confidence in the transformation itself. It also creates a feedback loop: each iteration generates real data about what is working, which informs the next design decision.

It is, in essence, the same logic that has made agile software development the standard in product teams - applied to the business processes that sit beneath the technology.

Before your next transformation conversation turns toward systems, platforms or vendors, ask one simple question:

If the technology decision had to be delayed by three months, would the team still know what needs to change?

If the answer is yes, the initiative is likely grounded in clear business logic.

If the answer is no, the organisation may be using technology selection to create a sense of progress before the real transformation work has been done.

To test this, leaders can ask:

• What value are we trying to create, protect or improve?
• Where is that value currently delayed, diluted or lost?
• Which process steps directly contribute to the outcome?
• Which steps exist mainly because of legacy structures or organisational habits?
• How will we measure success in business terms?

These questions do not replace technology decisions. They make those decisions better.

For COOs, CIOs or Heads of Transformation the practical implication is straightforward: the governance of transformation needs to change before the technology does.

That means creating space - at the start of every significant initiative - to answer the value question before the vendor question. It means building the capability to map processes and define success metrics as a precondition for technology selection, not as an afterthought. And it means being willing to challenge the assumption that speed-to-implementation is the same thing as speed-to-value.

The organisations that are getting transformation right in 2026 are not necessarily the ones with the most advanced technology stacks. They are the ones that have learned to ask a better first question.

See how it works in the real world. Five scenarios. Five measurable outcomes. Mixed business environments, but the same pattern.

Get inspired. Download the free guide.