Your Competitor Is a Spreadsheet

Sell software to small companies for any length of time and you notice that the deals you lose are rarely lost to a competitor. They are lost to a spreadsheet — one that already exists, that the person who built it understands completely, and that has never sent an invoice.

Most product teams treat this as an education problem. It is not. The spreadsheet is winning on merits that are real, and until you can name them you cannot beat it.

What the spreadsheet is actually better at

1. It fits the process exactly. It was not designed; it accreted, one column at a time, in response to real events. Every quirk in it corresponds to something that actually happened. No software product built for a market can match that fit, because it was built for the average of a thousand companies and this business is not the average.
2. It changes in seconds. A new requirement is a new column. In your product it is a feature request, a roadmap position and a release. That gap is not a detail — it is the difference between a tool that follows the business and a tool the business has to follow.
3. Nobody has to be trained. The skill already exists in the building. Your onboarding, however good, is a cost paid in the currency small companies have least of.
4. It cannot be taken away. The file is theirs, it opens without a login, and it works if your company disappears. Customers rarely articulate this, and it weighs on the decision anyway.

Where it genuinely fails

The spreadsheet has three structural weaknesses, and every product that succeeds against it wins on at least one:

• Concurrency. One person editing works. Three people editing produces divergent copies, and the reconciliation cost grows faster than the team does.
• History. A cell that changed leaves no record of who changed it, when, or what it was before. The moment a disagreement becomes expensive — a client dispute, an audit, a payroll error — that absence becomes the whole problem.
• Anything time-triggered. A spreadsheet cannot notice that something is late. Every deadline it manages is actually managed by a person remembering to look, which means the process fails exactly when that person is busy.

If your product does not win decisively on concurrency, history or automatic action, the spreadsheet is the rational choice and the customer is right to keep it.

What this implies for the product

Three consequences we have applied to our own software, at some cost to features we liked:

Import is not a feature, it is the front door. If the first hour requires retyping what already exists, the comparison the customer runs is "everything I have" against "an empty screen", and the empty screen loses. Accepting their existing file, with its inconsistent naming and its blank rows, is the highest-leverage work in the product.

Export has to be real and obvious. Counter-intuitively, making it easy to leave makes people more willing to arrive. A product that can be exited in one click competes with a file that can be copied in one click. Hiding the export is a tell, and customers read it as one.

Do one job completely rather than five partially. The spreadsheet does everything badly and that is acceptable because it is free. Charging money buys you the obligation to do one thing so well that a spreadsheet cannot approach it — usually the one that involves several people, a timeline, or a record that has to survive scrutiny.

The uncomfortable conclusion

For a meaningful share of prospects, the correct advice is to keep the spreadsheet. One person, no deadlines, no dispute risk — the software is worse for them, and telling them so is not a lost sale so much as a shorter path to the ones you can actually help.

It is also the fastest way to find out where your product genuinely wins. If you cannot say out loud which of the three weaknesses you beat, you have not found the product yet; you have found a feature list.