{"id":30116,"date":"2026-08-31T13:43:43","date_gmt":"2026-08-31T11:43:43","guid":{"rendered":"https:\/\/spiritinprojects.com\/?p=30116"},"modified":"2026-08-31T13:51:07","modified_gmt":"2026-08-31T11:51:07","slug":"confusing-features-with-benefits-often-leads-to-buying-the-wrong-software","status":"publish","type":"post","link":"https:\/\/spiritinprojects.com\/en\/confusing-features-with-benefits-often-leads-to-buying-the-wrong-software\/","title":{"rendered":"Confusing Features with Benefits Often Leads to Buying the Wrong Software"},"content":{"rendered":"\n

A few years ago, I found myself in a workshop preparing for a major IT procurement process. Within minutes, the flip chart was filling up with requirements:<\/p>\n\n\n\n

“The software must have an Excel export,”
“We need a dashboard,”
“The solution must work on mobile devices,”
“AI support would also be important,”
“We need a mobile app.”<\/p>\n\n\n\n

After about an hour, several flip chart pages were filled. Every department had contributed its wishes. Procurement added contract-relevant requirements, and IT was already discussing potential vendors and initial implementation considerations.<\/p>\n\n\n\n

I asked only one question:<\/p>\n\n\n\n


“Why do you actually need an Excel export?”<\/strong><\/p>\n\n\n\n

The room fell silent. After a moment of reflection, someone finally answered:
“Actually, we just want to share the evaluations easily with other departments.”<\/p>\n\n\n\n

At that moment, the discussion shifted. Suddenly, it wasn\u2019t about Excel exports anymore. It was about making information easier to share. For the first time, we weren\u2019t talking about features\u2014we were talking about the actual need.<\/p>\n\n\n\n

Whether this goal was later achieved through an Excel export, a dashboard, an automated report, or an interface no longer mattered.<\/p>\n\n\n\n

<\/p>\n\n\n\n

The Real Problem<\/strong><\/h2>\n\n\n\n

I encounter this situation surprisingly often. Many requirements describe a solution before the actual problem has been sufficiently understood.<\/p>\n\n\n\n

A dashboard is not a requirement. A mobile app is not a requirement. Even artificial intelligence is not a requirement\u2014at least not initially.<\/p>\n\n\n\n

They are all possible answers to a question that is often not even asked:<\/p>\n\n\n\n


What problem do we want to solve?<\/strong><\/p>\n\n\n\n

AI Is a Prime Example<\/strong><\/h3>\n\n\n\n

This phenomenon is especially clear in the context of artificial intelligence. In many projects, I hear statements like:<\/p>\n\n\n\n

“We need AI-powered search.”
“The new solution should have an intelligent chatbot.”
“The software must support generative AI.”
“The AI should analyze the data.”<\/p>\n\n\n\n

My usual response is: “What problem is the AI supposed to solve?”<\/p>\n\n\n\n

Desired Feature<\/strong><\/td>Actual Benefit<\/strong><\/td><\/tr>
AI-powered search<\/td>Find information within one minute<\/td><\/tr>
Chatbot <\/td>Automatically answer standard questions<\/td><\/tr>
Generative AI <\/td>Complete routine tasks faster<\/td><\/tr>
AI analyzes data<\/td>Make decisions faster and with better insights<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

Depending on the answer, the technical solution may look entirely different.<\/p>\n\n\n\n

AI is not a requirement.
AI is a possible solution.<\/strong><\/p>\n\n\n\n

Sometimes it\u2019s the best solution. Sometimes, however, simpler, cheaper, or more robust alternatives exist. That\u2019s why technology should not come first\u2014benefit should.<\/p>\n\n\n\n

<\/p>\n\n\n\n

Good Requirements Don\u2019t Start with Features<\/strong><\/h2>\n\n\n\n

<\/p>\n\n\n\n

The longer I work on projects, the more convinced I become:
A good requirement first describes the desired benefit. The feature comes later.<\/p>\n\n\n\n

Only when the benefit is clear can different solution paths be evaluated.<\/p>\n\n\n\n

Perhaps the Excel export or the intelligent chatbot is indeed the best solution. Perhaps not. What matters, however, is that we make this decision consciously\u2014not unconsciously by predetermining it in our requirements.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

<\/p>\n\n\n\n

<\/p>\n\n\n\n

Why This Mindset Is Well-Founded<\/strong><\/h3>\n\n\n\n

Interestingly, research has been addressing this question for decades.<\/p>\n\n\n\n

Barry Boehm\u2019s Value-Based Software Engineering<\/strong> places stakeholder value at the center of software projects.<\/p>\n\n\n\n

Goal-Oriented Requirements Engineering<\/strong> derives requirements from overarching goals\u2014not the other way around.<\/p>\n\n\n\n

As early as the late 1990s, Karlsson and Ryan demonstrated that requirements should be evaluated not only by effort but also by expected value.<\/p>\n\n\n\n

All these approaches share the same idea:<\/p>\n\n\n\n


Not every feature automatically creates value.<\/strong>
<\/p>\n\n\n\n

Every additional feature incurs effort and cost: development, testing, documentation, training, and later maintenance. A feature is only meaningful if it contributes to project success.<\/p>\n\n\n\n

Therefore, every requirement should answer a simple question:
What specific benefit does it create?<\/p>\n\n\n\n

If no convincing answer can be given, it\u2019s worth taking a second look at that requirement.<\/p>\n\n\n\n

What Does This Mean for Tenders?<\/strong><\/h2>\n\n\n\n

A tender process should describe what goal is to be achieved as precisely as possible. It should only specify a concrete solution where absolutely necessary.<\/p>\n\n\n\n

The earlier we commit to a particular feature, the smaller the solution space becomes. And sometimes, we rule out the very innovation we were seeking.<\/p>\n\n\n\n

<\/p>\n\n\n\n

My Experience<\/strong><\/h2>\n\n\n\n

In many projects, I now ask a simple question:<\/p>\n\n\n\n


“What actually happens if we don\u2019t have this feature?”<\/strong><\/p>\n\n\n\n

Only when a convincing answer is given does a desired feature become a truly justified requirement.<\/p>\n\n\n\n

Often, it turns out that a feature hides a completely different goal.<\/p>\n\n\n\n

And that\u2019s where good business analysis and structured requirements engineering begin.<\/p>\n\n\n\n

<\/p>\n\n\n\n

Conclusion<\/h2>\n\n\n\n

Software doesn\u2019t succeed because it has many features.<\/p>\n\n\n\n


That\u2019s why, in future workshops, I\u2019ll likely ask less:<\/p>\n\n\n\n


“What features do we need?”<\/strong><\/p>\n\n\n\n

And more:
“What problem do we actually want to solve?”<\/strong><\/p>\n\n\n\n


And then:
“What benefit do we want to achieve?”<\/strong><\/p>\n\n\n\n

Because those who confuse features with benefits often buy the wrong software.
<\/p>\n\n\n\n

Further Reading<\/strong><\/p>\n\n\n\n