A difficult product can provoke an expensive reaction: replace the team, rebuild everything or keep shipping in the hope that the problem disappears. In this closing lesson, Carlos Sanabria proposes a more deliberate decision process.
The first step is visibility. Determine whether the problem comes from the customer experience, the technical foundation or the process and ownership around delivery.
What you'll learn.
- Identify the problem before choosing a large intervention.
- Separate process restructuring, refactoring and rebuilding.
- Review UX, technical readiness and team practices together.
Avoid a reaction without a diagnosis.
A slow release or unhappy customer does not, by itself, establish that the entire system needs replacing. Rebuilding can consume significant effort while leaving a problem in priorities, workflow or ownership unresolved.
The opposite reaction also carries a cost: continuing to add features without understanding the underlying issue can increase complexity. Describe the specific inconvenience first, such as poor usability, churn, unsafe changes or repeated delivery delays.
Check the way the team works.
The decision tree asks whether a change in methodology can address the problem. That might involve priorities, ownership, release discipline or a clearer development process.
A process change is a different intervention from replacing the people doing the work. Examine whether the team has the information, responsibilities and safeguards needed to deliver before concluding that different personnel will solve the issue.
Compare refactoring with rebuilding.
If process changes are insufficient, investigate the technical structure. A fundamentally workable system may need refactoring: improvements to organization and internal design that make it easier to change safely.
A rebuild is a larger replacement effort and needs a clear technical and business justification. Carlos presents it as an option when the foundation cannot support the product’s needs, rather than a default response to frustration. The audit should make the trade-offs visible.
Use the closing checklist.
Review the product and UX: can users understand the experience, complete their tasks and trust the outcome? Review the technical foundation: are security, architecture and engineering practices adequate for the intended use?
Then review the process and team: are priorities clear, ownership explicit and releases controlled? These three areas influence one another. A documented diagnosis helps you choose an intervention that addresses the cause and gives you a way to evaluate whether the situation improves.
Refactor, rebuild or restructure based on what the audit reveals. A clear understanding of the problem makes the scope, cost and purpose of the next step easier to judge.
