The moment a decision is made to start a software project, the atmosphere in the meeting room or inside one’s mind shifts abruptly. There is an idea on the table, but uncertainty hangs in the air. The human mind, especially those close to engineering disciplines, dislikes uncertainty. To relieve this discomfort, we resort to the fastest, most familiar, and most dangerous method: Making things concrete.
At this exact point, the classic question that determines the fate of the project is asked:
“So, what are we going to build?”
Relief washes over the room the moment this question is asked. Because it is the easiest question to answer. Whiteboards are immediately filled, lists are drawn up, screens are imagined. “The user will log in here,” “There will be a reporting button there,” “The admin panel will show these metrics.”
Everyone is happy because they are defining things. It feels like the project has started, the wheels are turning, and the fog of uncertainty has lifted. On paper, everything looks perfect. Feature lists entered into spreadsheets create the sensation that the project has a plan.
Yet, the reason the vast majority of software projects fail is not technical incompetence during the coding phase. The real reason is often organizational habits and the illusion of early clarity created by asking this very question at the start.
The question “What should we build?” is a trap that forces a focus on solutions before the problem itself, its boundaries, and its risks are clear. It is akin to writing a prescription for a patient who has not yet been diagnosed. The medicine may be real, the dosage calculated to the millimeter; but if it is not the right disease, the perfection of the treatment saves nothing.
The Trap of Concreteness and the Illusion of Progress
The biggest misconception in software development is thinking that defining the scope of work solves uncertainty. In reality, what is often done is not solving uncertainty, but ignoring it.
Uncertainty naturally creates anxiety. Questions like “Does the customer really need this?”, “Is the market ready?”, or “Could this be technically harder than we expect?” cannot be answered immediately. They require research, time, and most importantly, the answer might be “No.”
However, the following sentences are clear, concrete, and reassuring:
- User login screen will be built. (2 days)
- Reporting module will be coded. (5 days)
- Payment integration will be provided. (3 days)
When you make this list, executives think they are managing the budget, project managers think they are managing time, and developers think they are managing the workload. This is a dangerous illusion of progress. Because this list consists of "nice-to-have" assumptions, not validated requirements.
When an item is added to this list, the brain marks it as "to be done" and shuts down the inquiry of "is it necessary?". The goal is now to code that feature in the best possible way. The possibility that the feature should not be written at all has been removed from the table.
Falling in Love with the Solution
This fallacy produces distinct and costly behavioral patterns in project processes. When a team starts designing the solution immediately instead of understanding the problem, a blindness sets in.
When this blindness begins, the axis of conversation in meetings shifts:
1. Tools Overshadow Purpose
Technical debates begin before it is clear what is being done, why it is being done, or which data is critical. “Which language should we use?”, “Should we use NoSQL or Relational?”, “Which Cloud provider is cheaper?”. These questions are important, but not at this stage of the project. Discussing which cement to use in the foundation without knowing what the building will be used for is not engineering; it is a waste of resources.
2. Micro-Decisions Hide Macro-Problems
While the core value proposition remains unclear, the team tries to feel safe in the details. Micro-decisions like “Should the button be blue or orange?” or “Should the logo be on the right or left?” sit at the center of the project. While critical and risky decisions are postponed, insignificant details are discussed for hours.
3. The Perfect Scenario Software
The “What should we build?” list usually contains scenarios where everything goes right. However, real life is full of errors. Teams focused on the list do not think about edge cases and potential failures. As a result, the software works perfectly in the demo presentation but crashes in the hands of the first real user.
The Same Mistake Regardless of Scale
It is not just inexperienced teams that fall into this trap. The reflex to ask “What should we build?” takes on different guises depending on the scale or owner of the project, but the result is always the same: Wasted resources and technical debt.
In the Startup World: Vision Intoxication
The entrepreneur is in love with their idea. For them, the question “What should we build?” is a session to transfer the vision in their head to the developers. Sentences usually start with “It will be like Uber, but for industry X.”
The fundamental error here is thinking that the biggest risk for a startup is the inability to build the software. In reality, the biggest risk is building a software perfectly that no one wants. By dictating what needs to be done, the entrepreneur turns the software team into mere executors. Even if the team sees gaps or illogical flows in the business model, they do not warn anyone because their job description is defined as coding the given list. The result? A ghost town launched six months later, working without errors but used by no one.
In the Corporate World: Budget Protection Reflex
In the corporate world, the situation is more political. Here, the question “What should we build?” is usually asked during annual budget periods. A department keeps the list of things to do as crowded as possible to secure a budget. The logic is: the larger the scope, the larger the budget.
The motivation here is not to solve the problem, but to avoid burning the budget. The analysis and design phase is often seen as a waste of time, and immediate coding is requested. Consequently, the resulting products turn into clumsy structures that have hundreds of features, do everything, but do nothing practically. Bloated software is born exactly this way.
In Service Procurement: The Contract Trap
When a company outsources software services, it wants to measure the value of its money with countable outputs. “5 modules, 20 screens, 3 integrations.” Therefore, it builds the contract on the list of things to be done.
However, the software development process is not linear; it is an iterative learning process. Information learned in the third month may render a module planned in the first month unnecessary. But because the contract is based on deliverables, that unnecessary module is built. The client wastes money, and the agency wastes time. Both parties have complied with the contract, but the value produced is low.
The Myth of "The Developers Didn't Understand Us"
When the project reaches its inevitable conclusion, the budget is exceeded, and the resulting product does not meet expectations, the culprit is usually sought on the technical side.
- “The developers took too long.”
- “The technology they used was wrong.”
- “Their analysis skills were weak, they didn't understand what we said.”
These accusations serve no purpose other than masking the real problem. The problem is not whether the developer used React instead of Vue, or wrote in Go instead of Java, or the database schema. The problem is that the accuracy of the list placed in front of the developer was never questioned.
The software team may have implemented the list given to them to the letter. They may have written technically perfect, high-performance, bug-free code. But if that code brings a wrong assumption to life, technical perfection means nothing.
In management science, this is called doing the wrong thing right. When you do the wrong thing right, it takes much longer to realize the mistake. Because the system is working, it gives no errors, it just does not produce the expected business outcome. This is the most insidious type of failure.
Tear Up the List: The Right Starting Questions
So, how should a software project start? What should we put in place of the question “What should we build?”
For a healthy, sustainable project that truly creates value, the set of questions to be asked is as follows:
1. “What problem are we solving?”
This question focuses on the pain, not the solution. Saying “We will build a CRM” is a solution. Saying “We cannot track our customer data because it sits in 3 different excel files and we are losing sales” is a problem. When you clarify the problem, you may see that the solution is not always writing software from scratch; sometimes a ready-made tool or a simple integration might be enough.
2. “What happens if we don't solve this?”
This question determines the value and priority of the project. If the answer is “Nothing much happens, we just slow down a bit,” then making a large custom software investment in that project is a mistake. Software should be built to unlock critical bottlenecks for the business or the user.
3. “What is our biggest risk?”
Is it technical risk, market risk, or operational risk? Lists usually hide risks, showing everything as equally important. The right approach is to build the smallest structure that will test the riskiest assumption first.
These questions are uncomfortable. They do not promise immediate concrete screens or colorful buttons. They create a deep silence at the meeting table. But that silence is the moment the project is saved.
Software development is not about coding, it is about decision making. Code is merely the result of decisions made. If decisions are taken with the depth of “Why are we doing this?” rather than the haste of “What should we build?”, the resulting software becomes not just a working program, but a working solution.
Many teams at this stage do not seek this clarity alone. Questioning one’s own assumptions is difficult because humans are easily convinced by their own ideas. Discussing assumptions with an outside perspective and being exposed to the question “Why?” often speeds up the process incredibly. The real loss of time comes not from pausing to think, but from moving in the wrong order.
