How 6 User Interviews Changed a 10-Year Roadmap
When the board says something is impossible, do not argue. Show them the data.
Early in my tenure at a large EdTech company, I faced a challenge that would define my approach to design leadership for years to come.
We had a monster legacy system. Fourteen years of Delphi code. Complex legal requirements baked into every module. The market was demanding a modern web solution, and we were haemorrhaging competitive ground every quarter we delayed.
Leadership did the maths: migrating every feature to a new platform would take over a decade. The board's conclusion was simple: it was not happening.
But here is what I knew from three decades of leading design teams: users do not need every feature. They need the right features.
That insight, and the research to prove it, changed a 10-year timeline into an approved roadmap in under six months.
The legacy system trap
If you have worked in enterprise software, you have seen this pattern.
A platform accumulates features over years. Each feature exists because someone, at some point, needed it. Legal requirements get encoded. Edge cases get handled. The system becomes comprehensive, and comprehensively unmovable.
When modernisation conversations start, engineering does the responsible thing: they scope the full migration. Every feature. Every edge case. Every legal requirement.
The number comes back terrifying. Leadership looks at the timeline, looks at the budget, and shelves the project.
The research that changed everything
I proposed a different approach: before scoping what to build, let us understand what users actually do.
I ran a top task discovery initiative. Six user interviews. One expert validation group with power users and internal stakeholders.
The finding was striking, though not surprising to anyone who has done this research before: users spent 95% of their time on 6-10 core tasks. Everything else, the hundreds of features that made the migration estimate so daunting, was rarely touched.
This was not about cutting corners. It was about understanding where value actually lived.
Building the business case
Data alone does not change minds. You need to translate research into language the board understands.
I built a business case with three components:
1. The task priority matrix
A clear visualisation showing which tasks users performed daily, weekly, monthly, and rarely. The concentration at the top was impossible to ignore: a small number of workflows accounted for almost all user activity.
2. The phased migration proposal
Instead of "rebuild everything," I proposed a phased approach: launch with the core tasks that covered 95% of user needs. Handle edge cases through a legacy bridge initially. Migrate remaining functionality based on actual demand, not theoretical completeness.
3. The business value calculation
I showed what we could ship in year one versus year ten. I quantified the competitive risk of waiting. I demonstrated that a focused MVP would capture the market opportunity while the "complete" rebuild would miss it entirely.
The board did not need convincing that users mattered. They needed evidence that a smaller scope was not a compromise: it was the smarter strategy.
The outcome
Results
September 2021: The board approved the new product roadmap.
2022: The majority of development effort shifted to the modernisation initiative, an initiative that would not have existed without that research.
The platform that "could not be rebuilt" was being rebuilt. Not because the technical constraints changed, but because the scope was redefined by user reality rather than system completeness.
The lesson for design leaders
Now, as Head of Design, I see this pattern everywhere. Design leaders struggle to get traction on strategic initiatives because they are arguing on the wrong terms.
When executives say something is impossible, they are usually responding to a scope or a timeline. They are not saying the problem does not matter. They are saying the proposed solution does not fit their constraints.
Your job is not to argue. Your job is to reframe.
Here is the approach I now use for any initiative hitting executive resistance:
Start with user reality, not system capability. What do users actually need? Not what the current system does, not what competitors offer, not what stakeholders assume: what do users demonstrably spend their time on?
Quantify the gap between perception and reality. Executives often overestimate how much of a system users actually use. Show them the data. The concentration of usage on core tasks is almost always more extreme than people expect.
Propose a scope that fits their constraints. If ten years is impossible, what is possible in one year? What would deliver 80% of the value?
Make the risk of inaction concrete. Do not just show what you could build. Show what you lose by waiting. Competitive position, user satisfaction, technical debt accumulation: make the cost of the status quo tangible.
Why this matters more than ever
Legacy modernisation is accelerating across every industry. The pressure to move from outdated systems to modern platforms is intensifying, driven by user expectations, competitive dynamics, and the integration requirements of AI.
Design leaders who can navigate these conversations, who can translate user research into board-level business cases, will be invaluable.
This is not about being a better designer. It is about being a better strategic partner.
The companies that modernise successfully will not be the ones with the biggest budgets. They will be the ones who scope smartly, prioritise ruthlessly, and let user behaviour, not system architecture, define what "complete" actually means.
The question for your organisation
If you are sitting on a legacy system that feels immovable, ask yourself:
- Do you actually know which features users depend on daily?
- Have you validated assumptions about "must-have" functionality with real data?
- Could a focused, phased approach unlock a roadmap that currently seems impossible?
Six interviews changed a ten-year timeline for me. The research does not have to be elaborate. It has to be focused on the right question: what do users actually need?