Walking through software: a physical approach to platform modernization
Mapping a decade of software evolution into a modern platform.
Every feature in legacy software tells a story. To uncover them all, I transformed our office into a walkable user story map, retracing a decade of platform evolution one sticky note at a time.
Context
A service and operations management platform had been the backbone of the company’s offer for nearly a decade, digitising hospitality operations to reduce paperwork, minimise calls, and keep staff focused on guests rather than administration.
When the COO began planning a full modernisation of the platform, the challenge wasn’t technical. A decade of organic growth had left the system’s full scope partially undocumented, spread across institutional memory rather than any single source of truth. He came to me knowing we needed a structured way to surface it all before a single line of new code was written.
I recognised user story mapping as the right approach: a way to make the invisible visible, one feature at a time.
Challenges
The platform had evolved organically over nearly ten years, growing to accommodate new clients, new workflows, and new integrations without ever being fully documented. No single person held the complete picture, and even the COO — who as co-founder knew it best — would rediscover forgotten features during our mapping sessions.
The complexity wasn’t just technical. Multiple user types, each with distinct workflows, had to collaborate seamlessly to deliver the best guest experience possible. Understanding those interdependencies was as important as cataloguing individual features.
The goal was clear: before committing to a modernisation plan, we needed a complete and honest inventory of what existed, what mattered, and what could be left behind.
Approach
We started small, deliberately: a housekeeping manager logging in to assign rooms for the day. A routine action that takes seconds in practice. But following that single action backwards and forwards immediately revealed layers of dependency: user configuration, room types, occupancy data pulled from reservations, reservations fed by third-party integrations, … One login, one morning routine, and already the walls were filling up.
From there we continued role by role, following each user type through their working day. A housekeeper moving through rooms with a checklist, reporting faults, registering minibar consumptions. A technician taking charge of repairing a fault. Each role brought its own setup requirements, its own dependencies, its own forgotten corners of the system. We didn’t impose a structure. The structure emerged from following the work.
Throughout the process, prioritization happened naturally. Not every feature needed to make it into the first release, and some were immediately set aside as post-MVP. Others were reconsidered as the full picture emerged, their importance becoming clearer once we could see how they connected to other workflows. The map didn't just document what existed. It helped us decide what mattered first.
By the end of the week, the walls told a complete story. A story I invited colleagues, board members, and other stakeholders to walk through. Moving chronologically through each persona’s day, we could verify what we had mapped, surface anything missing, and show everyone involved in the project the true scope of what the platform had become over a decade.
Key insights
The mapping confirmed much of what the team already knew intuitively. Real-time information flow was critical across every role. Every department’s work directly affected every other’s. But seeing it all laid out explicitly, at scale, on four walls, made the volume and frequency of those dependencies impossible to ignore in a way that no document or conversation could ever do.
One finding genuinely surprised us: the platform’s configuration and setup requirements were far more extensive than anyone had consciously acknowledged. Nearly a decade of client onboarding had layered complexity that nobody had fully mapped before. That insight directly shaped the new platform: client-side setup became a design priority, not an afterthought.
Outcomes
The physical map didn’t stay on the walls. Transferred into Miro, it became the foundation for everything that followed: MVP scope decisions, release cycle planning, and eventually the primary reference document for the external design and development team brought in to build the new platform.
For the first time, the full scope of a decade of software was visible, shareable, and actionable. Board members and stakeholders who had never had a complete picture of the platform’s complexity could now walk through it. The investor’s team could see not just what existed, but what had been prioritised, deferred, and why.
What started as a week of sticky notes on four walls became the single source of truth for a modernisation project.
Reflections
The method was right. Looking back, I can’t imagine a more effective way to surface a decade of accumulated complexity in a week. A written document or structured interview process would have taken longer and revealed less.
If I ran it again, I’d pay more attention to the physical execution. The post-its on the walls were quick and functional, but a more considered setup would have made the map easier to photograph, share, and hand over to the external team. The thinking was solid; the presentation could have been better.