What vs. How: the first trap in transformation projects
by Nicolas Henckes, Founder & CEO
There is a mistake I see regularly in product or digital transformation projects in SMEs as much as in larger organisations: confusing functional requirements with technical solutions.
It is not a competence problem. It is a framing problem.
"Faster horses"
Henry Ford is often credited with a line that has become almost a management cliche: "If I had asked my customers what they wanted, they would have said faster horses." The attribution is disputed (no verified primary source has ever surfaced) but the idea has endured because it captures something real.
What customers articulate is constrained by what they already know. They describe the world as it is, not as it could be. They ask for improvements to the familiar rather than alternatives to it.
The important thing is that this does not only apply to customers.
It applies equally to the people inside your organisation.
When you ask a team what they need, they will describe what they are missing in the tools they already use. They will ask for more features in the current system. More automation of the current workflow. A better version of what they have.
This is not wrong. It is natural. But it is not the same as understanding what they actually need to accomplish.
Why this happens - and why it is structural
Teams do not describe their needs in a vacuum. They describe them in relation to the reality they operate in every day: the system they log into every morning, the workarounds they have built over the years, the features that frustrated them last week.
This framing is almost impossible to escape from the inside. It is not a failure of imagination - it is the normal result of being embedded in an operational context. The closer someone is to the day-to-day, the harder it is to separate what they are trying to accomplish from the way they currently accomplish it.
There is also an organisational dimension to this. In many companies, feature requests are not just technical preferences - they are political positions. A team asks for a specific functionality because it reflects their view of how the organisation should work, which data should be central, which workflow should be the default. The request encodes assumptions about power and priority that are rarely made explicit.
This is why collecting requirements in a workshop and calling it "needs analysis" often produces a sophisticated inventory of the status quo rather than a genuine picture of what needs to change.
The distinction that changes everything
The What vs. How framework is not a methodology. It is a discipline of thought.
What: the functional objective of the user, what they are trying to accomplish, independent of any tool or process.
How: the way they imagine achieving it, the interface, the workflow, the technical logic.
A simple example from the public sector: when governments rolled out digital services in the early 2010s, citizen feedback consistently asked for "a simpler version of the paper form." What people actually needed was to accomplish a task, renew a permit, claim a benefit, without unnecessary friction. The form was the How. Eliminating the form entirely was often the right What.
Another example from enterprise software: teams migrating off legacy ERP systems routinely ask to "replicate the old screens." The How they know. The What - access the right data at the right moment to make a decision - can often be served in radically different ways.
When the two get conflated in specifications, you build complex tools that satisfy requests without solving problems.
The distinction matters most at the moment when it is hardest to apply: at the start of a project, when everyone is aligned and enthusiastic and the last thing anyone wants to do is slow down to question whether the shared understanding is actually shared.
What this looks like in practice
In the projects I work on, I push to separate the two levels from the start.
It comes down to a few questions asked directly to the teams:
"If the current system did not exist, how would you describe what you need?"
"What is actually slowing you down today, not in the tool, but in your work?"
"If this feature disappeared tomorrow, what would you no longer be able to do?"
The last question is particularly useful. It cuts through accumulated requests and gets to the real dependency.
But the questioning is only part of the work. The harder part is creating the conditions in which people can answer honestly. In many organisations, the requirement-gathering process is also a visibility exercise - teams use it to demonstrate relevance, to protect budget, to signal priorities upward. A question like "what do you actually need?" can feel like a trap if the culture has not created space for that kind of candour (see our article on Servant Leadership).
This means that effective What vs. How work is not just analytical. It requires trust, and trust takes time to build. In a long engagement, this is something you can develop progressively. In a short mandate, you have to earn it fast - and that often means starting with the people who are furthest from the politics and closest to the real work.
This is not a theoretical exercise. It is what distinguishes genuine needs from organisational artefacts - features that exist because "we have always done it this way," preserved through successive system migrations without anyone questioning their purpose.
The cost of getting this wrong
When the What vs. How distinction is not made at the start of a project, you typically see one of two outcomes.
The first is over-engineering: a solution that is technically complete but operationally unusable. Every requirement has been met. The system does what was asked. But the people who were supposed to use it find it too complex, too rigid, or simply not aligned with how they actually work. Adoption is low. The investment fails silently.
The second is scope creep with no clear resolution principle. Without a grounded understanding of the What, there is no way to evaluate competing feature requests. Every new ask is potentially valid. The project grows indefinitely, or it gets cut arbitrarily when budget runs out - leaving a partial solution that satisfies no one.
Both outcomes are expensive. Both are avoidable. And both typically trace back to the same failure at the beginning: not taking the time to ask what the work is actually for.
The management dimension
In transition situations - whether a digital overhaul, a reorganisation, or a system change - this framing work is rarely done from the inside. Teams are too close to the subject, too loaded with operational demands, too exposed to internal political pressures to maintain the necessary distance.
This is one of the concrete values of an external perspective in these phases: not just to "facilitate," but to ask the right questions at the right moment, before technical choices become irreversible.
An experienced external lead brings something that is underrated in transformation contexts: permission to ask naive questions. Not because they do not understand the business, but because they are not bound by its history. They can say "I understand that this is how it has always worked - but why?" without threatening anyone's position or reopening old organisational wounds.
This does not mean the answers come from the outside. The people who understand the work are always inside the organisation. The role of the external perspective is not to replace that knowledge but to surface it - to ask questions that internal stakeholders cannot easily ask each other, and to create enough distance from the existing How for the real What to become visible.
Where to start
If you are heading into a transformation project and you want to apply this discipline, the single most useful thing you can do before the first requirement-gathering session is to agree on one principle with your team: every request will be documented in two columns. What the user needs to accomplish. How they currently imagine doing it.
The gap between those two columns is where the real design work happens.
What the team wants and what the organisation actually needs are often two different things. Taking the time to distinguish between them at the start of a project is what separates a delivery from a transformation.
---
By Nicolas Henckes, Founder & CEO of Kitsune Advisory. Kitsune Advisory provides interim and fractional CEO services to companies in Luxembourg, France, Belgium, Germany, and Switzerland.
