Most software projects that go wrong don't fail because of the engineering. They fail because the team started building before the actual problem was clearly understood, and the misalignment doesn't surface until the wrong thing is already half-built.
Start with the problem, not the feature request
"We need a dashboard" is a solution someone has already jumped to, not a problem statement. The useful question is what decision the dashboard is meant to support, or what manual process it's meant to replace. Two teams asking for "a dashboard" might need completely different things once you understand what's actually driving the request.
A practical four-stage process
1. Understand
Before any design or architecture work, get specific about the business context: who's affected by this problem, how are they solving it today, what does success actually look like, and what constraints (existing systems, timeline, budget, compliance) shape the solution space. This stage should produce a written problem statement everyone agrees on — not assumptions carried silently into the next stage.
2. Design
With the problem clearly scoped, design the product experience and technical architecture together, not sequentially. A technically elegant architecture that doesn't match how users actually work is still a failure, and a great user experience built on an architecture that can't support it is a rebuild waiting to happen. This stage should produce a concrete implementation plan and a real estimate — not a guess made before the problem was understood.
3. Build
Development, integration, and testing against the real requirements gathered in stage one — not against an idealized version of the problem. Iterative delivery with visibility into progress matters here: stakeholders should see working software incrementally, not receive a single reveal at the end that may or may not match what they actually needed.
4. Launch and improve
Deployment is not the finish line. Monitoring, measuring actual usage against the success criteria defined in stage one, and iterating based on real behavior is what turns a shipped feature into one that actually solves the problem it was built for.
Why skipping stage one is the most common failure
Teams under time pressure often compress or skip the "understand" stage, treating it as a delay rather than the highest-leverage part of the process. The cost of this shows up later and is far more expensive: a build that technically works but doesn't solve the actual problem, discovered only after significant engineering investment.
Estimation: give a real number after understanding, not before
An estimate given before the problem is understood is a guess wearing a number. A useful estimate comes after enough discovery to identify where the real risk and complexity live — which is rarely where it looks like it will be from the initial feature request. This is why a real estimate should follow discovery, not precede it.
Common mistakes
- Jumping straight to architecture before the problem is fully scoped. This produces technically sound systems that solve the wrong problem.
- Treating discovery as a one-time phase. Understanding should continue throughout the project as new information surfaces, not stop once building begins.
- No defined success criteria. Without a clear definition of what "solved" looks like, launch becomes the de facto finish line, and nobody measures whether the problem actually got fixed.
- Treating "launch" as the end of the process. The improve stage is where a lot of real value gets captured, and it's the stage most often skipped once a deadline has passed.
Recommended approach
Resist the pressure to start building before the problem is genuinely understood — this is the highest-leverage place to spend extra time, not the place to cut it. Design product and architecture together. Give real estimates after discovery, not before. Treat launch as the start of the measurement and improvement phase, not the end of the project.
Conclusion
The technical skill required to build software well is necessary but not sufficient. What separates projects that solve the actual business problem from ones that ship a technically correct answer to the wrong question is almost always the discipline applied before any code was written.
This is how Kiaanlab approaches every engagement — understand the actual problem before proposing a solution. Tell us what you're building and we'll start there.