By Hiran de Silva
Every so often, a debate flares up online about Microsoft Copilot, or some new Excel feature, or some shiny new technology that does not quite behave as people feel it should.
The complaint is familiar.
“It’s not finished.”
“They shouldn’t release it until it works properly.”
“Users should not be expected to put up with this.”
At one level, I agree.
For a great many users, that is absolutely right.
But I think that reaction also reveals something deeper, and far more important, about Microsoft, Excel, innovation, and the changing demography of technology itself.
Because Microsoft has never really served just one kind of user.
It has always served at least two.
One is the mass consumer: the person who wants to buy a product and have it work like a domestic appliance. Press the button. Get the result. No mystery. No experimentation. No unexpected gaps. No need to “figure it out.”
The other is the innovator: the person who does not need the whole thing to be complete, polished, and idiot-proof. The innovator wants a foothold. A direction. A capability. A hint of what might be possible. Give that person enough to get moving, and they will build things the product team did not even imagine.
That second class of user is central to Microsoft’s history.
And I would go further.
Without that second class of user, much of what Microsoft eventually turned into “finished products” might never have existed at all.
Microsoft did not begin by selling finished appliances
This is the first thing people forget.
Microsoft’s great significance was never simply that it made software you could buy and use out of the box. Its significance was that it enabled other people to create.
That is a very different proposition.
A vacuum cleaner is meant to be finished.
A kettle is meant to be finished.
A photocopier is meant to be finished.
But a programming language, a spreadsheet, a development environment, a programmable office suite, a platform, or a data tool is not quite the same kind of thing. Its value often lies precisely in the fact that it opens possibilities rather than closing them down.
Microsoft’s first great wave came from that enabling spirit.
The entire personal computer movement, in its formative commercial years, was not about handing ordinary people perfect, self-contained digital appliances. It was about opening up new capability to people who were willing to explore, adapt, tinker, invent, and build.
That mattered enormously.
And it still does.
BASIC was an enabler, not a household appliance
Take Microsoft BASIC.
The BASIC language itself had already been created in the 1960s as a way of making programming more accessible. It was meant to be something that non-specialists could learn far more easily than the heavier, more formal languages of the time.
That spirit is important.
This was not a product for someone who wanted to “consume” a finished experience. It was a tool for someone who wanted to make something.
It empowered schoolboys, hobbyists, enthusiasts, tinkerers, and business-minded pragmatists to create software that solved real-world problems. It let people build useful things before an industry of packaged software had fully matured around them.
That is the DNA.
Microsoft’s roots were not merely in selling finished software. They were in equipping people to create capability.
And that, to me, is the key lens through which modern complaints about “unfinished products” should be viewed.
I came from the innovator side of the divide
This is not just theory for me. It is personal history.
Before my first commercial spreadsheet software in business work, I was already fascinated by the possibility of making computers do useful things. I was not sitting around waiting for a perfect consumer package to arrive in a glossy box and solve my life.
I wanted to build.
In the early 1980s, when personal computers were still expensive, awkward, and far from turnkey, I was already in that world. My first commercial business software was Microsoft Multiplan and dBase II in 1983. But even before that, I was trying to create spreadsheet capability because there was a business problem to solve and no easy off-the-shelf answer that fit our circumstances.
That point is worth dwelling on.
Today, many people think of software as something you simply subscribe to, install, and use. But back then, the machine itself was only part of the story. Hardware was expensive. Software was separate. Formats were incompatible. Distribution was awkward. Documentation could be scant. Support was patchy. There was often no “finished product” in the modern consumer sense.
And yet that was not a reason to walk away.
For some of us, that was the attraction.
We did not need perfection. We needed enough.
Enough to get going.
Enough to improvise.
Enough to create an advantage.
Enough to solve a problem that mattered.
That was the spirit in which I worked then, and in many ways it is still the spirit in which I work now.
The Tiger computers taught the lesson perfectly
One of the most formative experiences for me was with the Tiger computers that Richard Desmond (a billionaire since) effectively commandeered when a company that developed it could not settle the bill for our ad campaign. He ended up with six of these machines and passed them on to me for use in the business.
Now, here is the point.
Those machines were not a finished consumer experience.
They were not the kind of thing you would hand to an ordinary user and expect instant delight. They required adaptation. They required software. They required disk format conversion. They required patience. They required someone willing to get their hands dirty and make the thing useful.
One machine went to New York. One went to Munich. One was broken in a move. Others were used in the office. I had one at home. They each became part of an unfolding practical story rather than a neat retail experience.
And that is exactly the point.
To some people, such a setup would have looked absurdly unfinished. A disappointment. An inconvenience. Something not ready for prime time.
To me, it looked like opportunity.
It looked like raw capability waiting to be turned into something of value.
That distinction runs all the way through my thinking on today’s arguments.
There are two kinds of user, and they want different things
When people talk about “users,” they often speak as though all users form one great undifferentiated mass.
They do not.
There are people at the broad, popular, consumer end of the pyramid who quite reasonably expect software to work smoothly and predictably. They are not trying to push boundaries. They are trying to get work done. They want reliability, clarity, and ease.
But there is another class of user higher up the pyramid in terms of technical appetite, business responsibility, or creative ambition. This person is not merely using the product as provided. They are leveraging it, extending it, combining it, weaponising it, and often building capability for others.
This is the difference between the consumer and the innovator.
I do not even like to reduce that second class simply to the word “developer,” because “developer” can sound reactive, as though someone is merely implementing a spec handed down by someone else.
“Innovator” is better.
The innovator is proactive. The innovator sees possibility where others see inconvenience. The innovator is willing to endure roughness because roughness often marks the frontier.
And Microsoft, historically, has depended on that kind of person.
The demography changed
What changed over the years was not that the innovator disappeared.
What changed was the ratio.
In the 1980s and even much of the 1990s, personal computing was still heavily populated by enthusiasts, serious business users, power users, experimenters, and technical people. Even ordinary office workers had to be more adaptable than many people today realise.
But in the 2000s and beyond, computing became fully democratised.
Laptops became normal.
Software became ubiquitous.
Office tools became everyday commodities.
The internet expanded reach and visibility.
Social media amplified the most accessible and most consumer-friendly narratives.
The result was a huge demographic shift.
The consumer audience did not merely grow a bit. It exploded.
So when people now complain that a Microsoft feature is “unfinished,” that complaint reflects a world in which the dominant visible audience is no longer the frontier innovator but the mass-market consumer.
That is why publishers changed.
That is why training content changed.
That is why book titles changed.
That is why social media rewards surface-level usability and immediate gratification.
That is why “advanced” often now means “advanced within the box,” rather than “advanced in solving enterprise problems.”
The demography changed, and with it the tone of the conversation.
Excel has always had this tension built into it
Excel is perhaps one of the clearest examples of this split.
For many people, Excel is a tool to calculate, format, chart, and organise. They want useful features that work cleanly and obviously. That is fair enough.
But Excel also grew powerful because it could be pushed far beyond that role. It became a programmable environment. A modelling environment. A front end to other systems. A prototyping environment. A problem-solving environment. In the right hands, it became a platform.
And once a tool becomes a platform, the question “is it finished?” becomes more complicated.
Finished for whom?
Finished for what?
Finished at what level?
Finished for a novice?
Finished for a finance manager?
Finished for an innovator building enterprise capability?
Finished for a social media demo?
Finished for live operational pressure?
These are not the same thing.
Shared Workbooks was “finished” for some and useless for others
Take Shared Workbooks.
When this arrived in Excel 97, it addressed a real and growing problem. In the DOS era, one person sat at one machine. There was no serious issue of multiple people trying to work the same file at once across a network in the way that later became normal.
But by the Windows and network era, this was a pressing business problem. One user had a file open. Another wanted to update it. Saving conflicts became real. So Microsoft introduced Shared Workbooks as a big step forward.
Now, was it a finished product?
For some people, yes.
For teams with narrow enough requirements, Shared Workbooks may well have been perfectly acceptable. It solved enough of the problem to count as a solution.
But for serious work of the sort I was doing, it did not solve the problem in a meaningful way. Why? Because the underlying spreadsheet paradigm had not truly been designed for that mode of collaboration, and because certain important capabilities had to be limited or excluded in order to make the feature function at all. Once you moved into areas involving macros, automation, or more sophisticated architecture, the feature quickly showed its limits.
So was it finished?
That depends entirely on which class of user you belonged to.
And that, again, is my point.
The word “finished” hides a demographic argument.
OLE, Binders, XML file formats, Excel Services — Microsoft kept pushing outward
The same pattern appeared elsewhere.
Object Linking and Embedding, or OLE, was another grand idea. You could embed an Excel object inside Word or PowerPoint in a far more live and interactive way than a mere screenshot. It was clunky, yes. Heavy, yes. Sometimes overkill, yes. But it pointed in a direction: Office applications as a more connected working environment.
Then there were binders, another attempt to gather multiple Office components into a more unified package.
Then later came shifts such as the XML-based file formats, driven partly by the idea that spreadsheet content had become too important to remain trapped inside opaque files on personal machines. There was an ambition to make spreadsheet data more reachable, more inspectable, more available to wider systems and workflows.
Then there were ideas like Excel Services.
Some of these stuck partially. Some disappeared quietly. Some were stepping stones. Some were dead ends. Some were ahead of their time. Some solved only a narrow problem.
But look at the pattern.
Microsoft kept releasing capability in advance of maturity.
Not because it was incompetent, but because part of its historical role was to explore, provoke, and enable.
The real breakthrough was not polish, but possibility
The point I keep returning to is this: many of the most important things Microsoft released first appeared as possibility, not polish.
A perfect example is Excel’s journey toward working with external data.
I have often referred to Microsoft’s DevCast in December 1993, where Excel 5 was demonstrated (by a young Satya Nadella. Who then had hair. Whatever happened to him?) connecting to a backend enterprise database – an IBM AS/400 – to retrieve information for practical business use. Looking back now, the connectivity was clunky. It involved moving parts. It was not consumer-smooth. It was not tidy. It was not what today’s audience would regard as “finished.”
But it was there.
That matters.
Because once something is there, a certain class of person can run with it.
The innovator does not sit there moaning that the railway has not yet been built. The innovator sees a frontier route and starts moving.
What happened next? Over time, this capability became smoother, more standardised, more integrated. By Office 97 and ADO, a more coherent and practical consumer-facing layer had arrived. The “finished product,” such as it was, came later.
But would it have come later if the early version had not been released first?
That is the question.
Innovators are not waiting for perfection
People like me were never looking at these things and saying, “I refuse to touch this until Microsoft has made it fit for the broadest consumer market.”
That is not how value gets created at the edge.
If there is enough there to solve a difficult business problem, that is enough.
If there is enough there to gain an advantage, that is enough.
If there is enough there to build something other people cannot yet build, that is enough.
That is how much of real commercial innovation happens.
It is not the consumer who pushes boundaries.
It is not the person demanding a polished appliance who discovers a new architecture.
It is not the casual user who opens up a new commercial path.
It is the person willing to work with raw capability.
That was true for early spreadsheets.
It was true for databases.
It was true for web development.
It was true for data connectivity.
And it is true for AI.
The same thing happened in web development
I saw exactly the same pattern in the early web application world.
When Macromedia released Dreamweaver UltraDev, there was enormous excitement — and enormous frustration. Many of the developers coming from earlier visual tools suddenly found themselves with a product they did not fully understand. There was no smooth, complete, foolproof path for the kind of work they wanted to do. They were effectively being pushed toward a deeper level of understanding than many had yet acquired.
Some complained. Some stalled. Some demanded more hand-holding.
Others, myself included, saw the opening.
I worked it out quickly, published tutorials, and ended up becoming recognised in that field precisely because the product was not yet a finished appliance. There was room for pioneers. There was room for interpretation. There was room to discover superior methods. There was room to shape the practice.
That is how frontier value appears.
If everything is already finished for everybody, the early advantage is gone.
So what about Copilot?
This brings us back to Copilot.
Is Copilot a finished product?
That depends entirely on who is asking.
If you ask the broad consumer audience — the dominant audience now visible on social media — then the complaint is understandable. Most users do not want a frontier tool. They do not want to debug the future. They do not want to feel like unpaid participants in an evolving experiment. They want something dependable, clear, and complete.
That is a reasonable demand.
But if you ask the innovator audience, the question is different.
That person is not asking, “Is this finished?”
They are asking, “Is there enough here to do something valuable?”
“Can I build on this?”
“Can I exploit this?”
“Can I create an advantage from this while others are still complaining?”
That is a completely different mindset.
And that mindset has always been central to Microsoft’s ecosystem, whether the mass market remembers it or not.
I am not waiting for someone else’s finished product
In my own case, I do not use Copilot as my central AI relationship.
What I have found immensely powerful is my engagement with ChatGPT and related tools. That relationship is already helping me do things at speed and scale that would once have taken vastly longer. It is helping me think, write, structure, test, extend, challenge, and refine. It is giving me not just answers but prompts, angles, warnings, and better directions.
For my purposes, that is real value.
Not because it is a perfect finished consumer appliance, but because it gives me enough leverage to move.
That is exactly the distinction I am making in this article.
The frontier user does not wait passively for a perfect machine to descend from heaven. The frontier user works with the opening.
That is how advantage is made.
The consumer is not wrong — but neither is the innovator
I am not saying the consumer is foolish. Far from it.
The consumer perspective is legitimate.
If Microsoft sells increasingly to a vast mainstream audience, then naturally that audience will judge products by mainstream standards. If a feature is confusing, unreliable, restricted, or over-promoted relative to what it can actually do, people have every right to complain.
But it is a mistake to assume that this is the only valid standard.
There is another standard.
The innovator standard asks whether a capability opens a door. Whether it points to a future. Whether it enables a small but highly capable group of people to do something commercially significant before the broader market catches up.
That standard is quieter. It is less visible on social media. It tends not to dominate the online conversation. But historically it has often been the more important one.
Microsoft’s history is the story of that tension
When you step back, the history of Microsoft can be read as the ongoing tension between these two audiences.
The consumer wants certainty.
The innovator wants possibility.
The consumer wants completion.
The innovator wants leverage.
The consumer sees roughness as failure.
The innovator often sees roughness as frontier territory.
And many of the products people later remember as mature, reliable, mainstream tools began life in that rougher state, serving the second audience long before they satisfied the first.
That is why I resist the shallow complaint that Microsoft should simply never release anything until it is perfectly finished.
If it had always operated that way, much of the innovation that later became normal might never have emerged.
The polished road often exists only because someone first went down the muddy track.
The real question
So the real question is not whether users like unfinished products.
Of course most do not.
The real question is this:
Would many of the “finished products” people later came to depend on ever have existed if earlier, rougher, more experimental capability had not first been released to those willing to use it?
Would Excel’s deeper data connectivity have evolved without that earlier, clunkier opening?
Would web development tools have matured without early adopters wrestling with half-finished possibilities?
Would AI tools become practically useful if nobody serious worked with them until every wrinkle had been ironed out?
I do not think so.
That is why the current argument around Copilot is, in the end, not really about Copilot at all.
It is about what kind of user you are.
And it is about whether we still remember that a great deal of business progress has always come not from people demanding a finished appliance, but from people willing to roll up their sleeves and build with what is there.
For some, unfinished means not ready.
For others, unfinished means opportunity.
And Microsoft’s history has always belonged to both.
This article was dictated to video recording live by Hiran de Silva on 6 March 2026 while reading the post referred to, and the comments. Subsequently directly turned into this article through Open AI ChatGPT. This article is a condensed version. The original can be found here [TBA].
Add comment