Product strategy has a certain air of glamour to it. Roadmaps, user stories, innovation sprints. There’s nothing sexy about re-purposed spreadsheets, however. Or systems that were designed before anyone had a smartphone.
The truth of legacy products and platforms.
It’s a reality many of us face when we build digital products inside global enterprises, enterprise systems, or in heavily regulated spaces. It’s the truth of working in large organizations where “agile” is still an upstart scrum team fighting for breathing room.
In 2022, I found myself completely embedded in the above: leading product efforts on an entire portfolio of enterprise systems defined by old technology, siloed teams, and high-stakes user operations. It was nothing like the glossy, air-tight world of unicorn SaaS startups. But it taught me as much about building a product as any contemporary setup ever could.
Here are 7 lessons from the trenches.
1. Stop Fighting the Constraints — Start Designing with Them
Legacy products and systems always have constraints. Old tech stacks, hardcoded logic, processes, and compliance requirements that slow everything down. The temptation is to treat all those constraints as blockers to be removed or bypassed.
But I’ve learned that the opposite is true. You have to lean into those constraints: design with them, not against them. And not just design with them, but start with them. List them all out. Hypothesize their impact. Design a solution with those constraints already in place.
We started the above with reporting tools we needed to design for internal users in our enterprise system. Half of our internal users don’t have constant internet access. That meant we had to make offline data sync our number one priority, even before thinking about features or roadmap milestones. It wasn’t sexy. But it was the right move.
Constraints aren’t the enemy. They’re guardrails for focus.
2. You Can’t Ship What You Don’t Understand
One of the most humbling lessons of legacy environments: you just can’t understand what you don’t know.
There’s a drive in modern product teams to skip straight to prototyping/testing. But working with enterprise stakeholders and operations users, I’ve seen the consequences of skipping the homework.
We once spent weeks observing how investigations were being processed manually, before we were allowed to write our first user story for a digital investigation management module. But that discovery work saved us months of rework and miscommunication.
Discovery is just table stakes in legacy systems. But more than that, it’s respectful. Observing the current process, being nosy, asking questions, and carefully testing assumptions are the differences between building for your users and building with them. People know the difference when you take the time to understand their world.
3. You’re Not Just Driving Innovation — You’re Building Bridges
Legacy systems, by their very nature, have been battle-tested over years, if not decades, of real-world use. This means innovation in that environment often takes a more subtle form. Not the flashy disruption of disruption for its own sake. Your value and product leadership are actually found in alignment: working to make teams see the same picture from their unique vantage points.
Can you help someone in security policy see the value in cross-team process alignment? Can you bridge between a business partner and an IT operations group by carefully translating both their needs and pain points? Can you take a 20-year-old workflow and turn it into a meaningful digital experience without imposing completely new patterns on the user?
This is the work that truly unlocks transformation. Not by force, but by building bridges of shared understanding one meeting at a time.
The best product leaders I’ve ever worked with have been those who can take strategic goals and translate them into user needs, then listen and reflect back what users are actually asking for in technical solutions.
4. Stakeholder Management Is the Product
When I say stakeholder management is the product, I’m not being glib. In legacy systems, stakeholders aren’t just the audience — they are the product. One director or stakeholder with decades of institutional knowledge and political clout can make or break your adoption overnight.
We no longer treated “stakeholder reviews” as checkpoints on a timeline. We began inviting them to design sessions. We started showing them half-finished mockups. We let them veto features and argue with our technical architects.
Guess what? More alignment. Less project resistance. And a final product that everyone who mattered got.
Because people want to be heard and feel seen. When you do that, they become the strongest possible advocates.
5. MVP Looks Very Different Here
The classic MVP definition needs rethinking in a legacy environment: the smallest version of the product you can ship to start getting feedback and iterating.
This doesn’t work in a legacy system for the following reasons:
- Many of your users are not digital natives. Have never known a world where work was done in Excel vs. in a native digital tool. So “quick” iterations can take a long time.
- Testing in production systems can’t be done like flipping a feature flag. You usually need sign-offs and dedicated integration slots.
- Adoption can’t be measured in pageviews and opens. It’s measured in behavior change over time.
The MVP we built for a case management tool wasn’t a clickable prototype. It was a hybrid manual+digital process that we had users track with Excel spreadsheets. We knew it validated our overall flow, but also let us build trust with both stakeholders and the people doing the work before we even started building the actual digital product.
The “minimum” in MVP is different here. Because you’re not just de-risking the code. You’re de-risking the change.
6. UX is a Business Differentiator — Even for Legacy
This is one of those widespread myths I had to unlearn: that “legacy” system users don’t care about UX. That they will use whatever you give them.
Not true.
We built one module that had tons of legacy system data and workflows. But added contextual help documentation for our operational users. It was nothing special. But it reduced onboarding time by 40%. In country after country, the feature users praised above all else.
UX is more important than ever when your system is one of no choice. And when people can spend 6+ hours/day inside your interface, every extra click or clunky label is friction they have to climb over.
Friction isn’t just annoying; over time, it causes serious user burnout. Good UX is a true business differentiator even inside legacy systems because it shows people you care about their time and cognitive load.
7. Progress is Measured in Trust
If I had to boil this list down to one lesson, it would be this: success is measured in trust.
Legacy systems have one hard truth: you can put the most comprehensive product out there, and if your internal experts don’t believe it will help them, it will not get adopted. Period.
When working in legacy systems, the real metric for success is not features delivered. It is an adoption over time. It is the internal SME calling you back when they have questions. It is stakeholders asking you to attend planning meetings. It is team members who believe the product will actually make their lives better.
Trust is the runway any long-term product evolution needs. Without it, you are stuck in a game of one-off tactical wins. With it, you can lay down one modernization layer on top of another with support, not resistance.
You don’t earn trust by promising people transformation. You earn trust by consistently delivering relevance to their unique world.
Final Thoughts
There’s a lot of talk about digital transformation in tech. But most of it doesn’t happen in shiny deck presentations or in the sleek world of modern product development. The real transformation happens in the hard friction world of legacy platforms and systems.
Systems that have been around for years, maybe decades, that are thick with processes and politics and people who are just as smart, capable, and hungry for change as you are. Hungry for tools that just actually work.
If you are lucky enough to find yourself building a product in that space, don’t resist it. Lean into it. The friction of those constraints will make you a better product leader than any agile manifesto or innovation framework ever could.
