Over the years and across various projects and industries, I’ve witnessed countless mistakes that are glaringly obvious to those of us working on the front lines. We see the system’s guts, its weaknesses, and areas for improvement. Unfortunately, managers with a long-term vision often forget that reaching that long term requires a solid foundation. Those who truly understand the product’s current state are the ones who see its framework and foundation.

I once worked on an import system for a country with limited digital infrastructure. The system, programmed by the CEO in an obsolete language, quickly gained traction. However, the underlying technology was outdated and buggy. Despite the CEO’s resistance to a complete overhaul, the system eventually failed due to its technical limitations. A programmer who had secretly developed a superior system capitalized on the opportunity, taking over the market.

This shortsightedness is a recurring theme. I’ve seen countless CEOs and COOs ignore their product teams’ warnings about critical flaws and the need for a system overhaul. They prioritize growth and expansion over building a solid foundation. This often leads to a vicious cycle: the system becomes increasingly unstable, investors lose confidence, and the company is forced to cut costs.

Listen to your technical teams

My unsolicited advice to the C-level: Listen to your technical teams. They’re on the front lines and know what needs to be done. Don’t be blinded by numbers and projections. Sometimes, the best solution is to start over.

In my opinion, many of these startups would still be around if they had only focused on one thing: building a solid foundation. If you have an administrative system and its star module is invoicing, focus first on making invoicing work perfectly before adding other modules. Ensure that it can handle a significant increase in users, that it’s capable of multi-currency, and that it can be easily adapted to different languages and countries. It’s the lack of focus and excessive ambition that, in my experience, leads many startups to failure.

Stick to your core product and don’t let your team get bogged down in speculation and new ideas until the initial product is fully functional

Now, here’s the tricky part: how do we define when a module is “finished”? I think establishing clear criteria is crucial. First and foremost, it should work flawlessly. No bugs, no crashes, and minimal user complaints. It needs to deliver on its core promises. The transition from an MVP to a Minimum Acceptable Product (MAcP) should prioritize the perfect execution of the main module. This will serve as the bedrock for a scalable, widely accepted, and functionally robust system. The rest is up to sales and marketing.

Moving from an MVP (Minimum Viable Product) to a Minimum Acceptable Product (MAcP) where one of the main pillars is that this module or core functionality runs perfectly is essential

But what about innovation? What about growth? There’s no reason why we can’t work in parallel, at least conceptually, at the business analysis and product/UX level on new functionalities, whether they are user requests or market requirements. Companies can even have a specific team that advances proof of concepts and even MVPs of new features if they have enough resources. But if not, it’s preferable for developers to focus on finalizing the main module and fixing bugs, while stakeholders, BAs, POs, and UXers create prototypes and test new features or modules with users to validate if it’s worth bringing those ideas to reality.

Building a sustainable product requires a solid foundation. If you’re constantly firefighting, something is fundamentally wrong.

In short, building faster is not building better, nor for the long term. It’s understandable that due to the dynamics of investments, everything has a pace and that results are always expected, but if you have to invest more time in fixing bugs and serious system errors than in developing new things, it’s because there’s something fundamentally wrong. Something that sooner or later will undermine the project and when it’s time to change it will be too late and investors won’t want to keep losing money on a project that seemed to be moving very fast at first but is now losing more and more users.