When Every Decision Was Right, and Everything Still Goes Wrong
Legacy systems without a product strategy end up in workarounds, manual processes, and structural opacity. Tina Bandalo-Emruli, Project Manager and Senior Backend Engineer and Team Lead of the Digital Consultants at mimacom, explains why technical quick fixes fall short, and what actually works.
Key takeaways
- Systems without an overarching product vision grow reactively and become unmanageable over time, even though each individual decision made sense.
- Technical quick fixes solve symptoms, not root causes. Without strategic clarity, the same problems reappear, even on a new platform.
- Roles, permissions, and organizational structures cannot permanently compensate for organizational ambiguity.
- A step-by-step approach, covering security, structure, and strategy, delivers more sustainable results than a radical restart.
- Product strategy is not an optional future initiative. It is the precondition for any scalable development.
What do a Swiss Army knife and a legacy enterprise system have in common? Both can theoretically do everything, and that is exactly what makes them increasingly unusable. What seems like a useful tool in theory becomes a bulky pocket knife without a blade long enough to cut anything. Legacy systems are much the same; there's a host of functions, but none are quite right for the job.
A recent assessment of one such system revealed a pattern that will feel familiar to many organizations. The uncomfortable part: no one made a mistake. It started with a good idea, which became a proof of concept built to win over a customer. Instead of replacing it, the team turned the POC directly into the production system. Every new customer brought new requirements. Each decision made sense on its own.
And yet, anyone looking at the system today can barely recognize the original idea.
This is the paradox of many legacy systems. Negligence did not cause this state. The opposite did: a sense of responsibility, customer focus, and pragmatism. Yet at some point, teams end up with a system they can barely explain themselves. That is not a technical failure. It is a strategic signal.
I have seen this pattern across many projects, in different industries and different company sizes, but always with the same underlying structure. The problem is rarely technical. It is a product problem.
Symptoms of a missing product vision
"The system kept getting more complex, even though the business processes themselves did not."
Tina Bandalo-Emruli, Project Manager and Senior Backend Engineer, mimacom
What followed was predictable. The system could barely scale to new user groups. Instead, the team introduced workarounds, integrated hardcoded fixes, and closed security gaps with temporary patches, each time adding manual effort and reducing transparency.
The concrete consequences:
- Roles were used for purposes they were never designed for.
- Permissions compensated for organizational ambiguity instead of reflecting how the business actually worked.
- Exceptions became permanent solutions.
- The organizational structure lost its functional meaning.
- Users ended up with too many or too few rights for their actual work.
- An extensive editor manual replaced what should have been an intuitive user flow.
The core of the problem was the absence of a shared product vision. New requirements were implemented reactively. Roles, permissions, and organizational structures kept evolving, but without an overarching model to guide that evolution.
Why technical quick fixes fall short
The obvious response is to identify pain points and close them as fast as possible. But technical quick fixes remove symptoms, not root causes.
Even a completely new platform would develop the same problems over time if the underlying organizational questions remain unresolved:
- Who is responsible for which decisions?
- How should the organization be modeled from a functional standpoint?
- Which roles are actually needed?
- What product goals apply for the next few years?
- What governance rules secure the target model in the long term?
A proven approach: Incremental improvement over a big bang
The team deliberately chose a structured improvement approach over a radical restart. This is the path we follow at mimacom.
| Phase | What it achieves |
|---|---|
| Eliminate security risks | Immediate stabilization, no more emergency patches, no uncontrolled access |
| Clean up the organizational model | Functional realities are accurately reflected again |
| Simplify the role model | Users get exactly the rights they need for their work, no more, no less |
| Establish governance | Clear rules prevent new requirements from undermining the model again |
| Sharpen product strategy | Only then does a larger structural redesign truly make sense |
This is where we come in
This kind of work is not purely a technology problem. It requires people who combine product thinking, organizational understanding, and technical expertise. At mimacom, we call them Digital Consultants, and this is exactly what they do every day. They help companies clarify what their product is, who it serves, and how it should evolve strategically.
We recognized early that our clients need more than development capacity. They need advisory work that connects technology and product strategy, and that has the confidence to say when a technical fix is not enough.
It's not about whether, but how
After many years working on digitalization and transformation projects, I am convinced that a missing product strategy is one of the most common and most expensive problems in legacy systems. It is also a problem that can be solved, if you start in the right place.
The good news: it does not take a big bang.
A pragmatic starting point, cleaning up structure, defining clear responsibilities, and building a shared product vision, delivers measurable results quickly and creates the foundation for sustainable development.
If this pattern sounds familiar, talk to us.
