Why so many technology products are marketed by attacking a problem they never properly define
By Hiran de Silva
For more than twenty years I’ve noticed an interesting pattern.
Whenever a new planning platform…
a collaboration tool…
an AI assistant…
or even a completely unrelated business product is promoted…
there is a very good chance that somewhere in the marketing material Excel will appear as the villain.
The examples are always familiar.
Version control.
Broken links.
Multiple copies of the same spreadsheet.
Manual consolidation.
Emailing files around.
Human error.
No audit trail.
Everyone who has worked in business has seen these problems.
The conclusion is then presented as though it were obvious.
“Excel is the problem.”
But is it?
Or has Excel become the most convenient strawman in enterprise software?
A strawman is easy to defeat
A strawman argument works by replacing the real thing with a much weaker version.
Instead of arguing against what something actually is…
you argue against an inferior substitute.
That’s exactly what I believe has happened to Excel.
The Excel shown in countless white papers and sales presentations is almost always the same.
A workbook sitting on somebody’s desktop.
Being emailed around an organisation.
Copied repeatedly.
Linked to other files.
Merged manually.
Nobody disputes that this creates problems.
But here’s the important question.
Is that actually Excel?
Or is it simply one particular way of using Excel?
Those are two completely different questions.
Notice what is missing
Read almost any piece of promotional literature from the Excel replacement industry.
You’ll find pages describing spreadsheet problems.
You’ll often find very little discussion of where those problems actually come from.
Even more surprisingly…
you’ll rarely find an explanation of how the new product removes the underlying cause.
Instead…
the assumption quietly becomes…
“If spreadsheets are involved…
the spreadsheet must be the problem.”
That assumption is rarely examined.
It is simply accepted.
Architecture matters more than software
Imagine two people both driving identical cars.
One is driving on a modern motorway.
The other is trying to drive through a muddy field.
When one journey is faster than the other…
would we conclude that one car is superior?
Of course not.
The infrastructure is different.
Yet this is remarkably similar to how Excel comparisons are often presented.
One side is a modern client-server application.
The other side is a collection of disconnected workbook files being emailed around an organisation.
Those are not two competing software products.
They are two completely different architectures.
The comparison is fundamentally unfair.
The missing chapter in Excel education
I believe another reason this misunderstanding persists is much simpler.
Almost every Excel course teaches Excel as though it were a document.
Open workbook.
Edit workbook.
Save workbook.
Email workbook.
Every formula…
every feature…
every tutorial…
takes place entirely inside the workbook.
Naturally, learners begin to think that the workbook is Excel.
It isn’t.
The workbook is only one possible container.
Very little mainstream Excel education discusses Excel as one component in an enterprise information system.
Very little discusses separation between presentation and data.
Very little discusses shared databases.
Very little discusses governed write-back.
Very little discusses multi-user business processes.
As a result…
millions of capable Excel users never discover that another way of thinking even exists.
They faithfully apply document-based techniques to enterprise business processes.
Then those techniques inevitably fail.
Excel receives the blame.
The self-reinforcing cycle
This creates an extraordinary feedback loop.
Training teaches document-based Excel.
Businesses adopt document-based Excel.
Document-based Excel creates document-based problems.
Marketing publishes those problems.
Replacement vendors cite those problems.
The next generation of learners studies the same document-based techniques.
The cycle begins again.
The narrative continually reinforces itself.
What if Excel was never the real problem?
Suppose the problem was never Excel.
Suppose the problem was treating enterprise information as disconnected documents instead of shared data.
That would change the conversation completely.
Suddenly…
version control isn’t an Excel problem.
It’s a file management problem.
Manual consolidation isn’t an Excel problem.
It’s an architecture problem.
Broken links aren’t an Excel problem.
They’re a consequence of distributing data across independent files.
Emailing spreadsheets isn’t an Excel feature.
It’s an organisational workflow.
These distinctions matter because they change where the solution should be applied.
Why this matters
If businesses misunderstand the source of their problems…
they risk replacing the wrong thing.
Instead of fixing architecture…
they replace software.
Instead of redesigning processes…
they purchase platforms.
Sometimes those platforms are entirely appropriate.
Sometimes they genuinely solve important business problems.
But organisations should reach that conclusion after correctly diagnosing the cause.
Not because Excel has become a convenient strawman.
The real question
Perhaps the most important question isn’t…
“Should we replace Excel?”
It’s this.
Are we replacing Excel…
…or are we replacing poor architecture?
Because those are not the same decision.
Add comment