Is your SaaS product really competing with a spreadsheet?

Yes, if the work your product is meant to run still runs in a spreadsheet, a chat thread or on paper. Then the alternative a buyer is really weighing you against is not another SaaS product but the way the work runs now, and that is why users keep going back to the spreadsheet.

The spreadsheet wins on things a feature comparison ignores: anyone can start in a minute, the columns bend to fit the work, everyone already knows how to use it, and it can be shared and exported freely. A product beats it by owning what a spreadsheet handles badly (state and history, who may change what, approvals and exceptions, validation at scale, one version of the truth) while keeping the spreadsheet's strengths where they matter.

The status quo can be a spreadsheet, a chat thread or paper

On Beyond the Interface by Tcules, our co-founder Jatin Leuva asked the conversion copywriter Alex Napier Holland whether his research had ever found something a product team's research had missed. He pointed to the evaluation stage: teams ask customers what they like and dislike about the product, and less about what they compared it with. Then he went further:

"You're competing against two things a lot of the time. Spreadsheets and WhatsApp. Most of the world is based on spreadsheets and WhatsApp." (27:19)

His point was about marketing: for a prospect who has not yet accepted paying for software at all, the useful conversation is why a spreadsheet does not scale and why running a serious business process on WhatsApp is limited and not secure, not how you compare with other SaaS products. This article takes the product design half of that idea.

The size of that alternative is easy to underrate. Microsoft researchers Andy Gordon and Simon Peyton Jones wrote in January 2021 that Excel formulas are written by an order of magnitude more users than all the C, C++, C#, Java and Python programmers in the world combined (Microsoft Research).

Our own record shows the status quo is not always digital. In the Scissors staffing software case, recruiters kept timesheets and other records on paper, and candidates' shifts were recorded on paper first, at the job location. In the Auxentios CPQ case, users relied on separate tools to retrieve sales opportunities, talk to customers and colleagues, build repair and maintenance contracts and iterate quotations. In neither case was the work running on one rival product alone: in one it ran on paper, in the other across a set of disconnected tools.

What the spreadsheet does well

If the status quo is a spreadsheet, the product is judged against what spreadsheets do well:

• Anyone can start in a minute. There is no procurement, set-up or training before the first row.
• Columns bend to fit the work. A new exception gets a new column the same afternoon, without asking anyone.
• Everyone already knows how to use it, including the client, the supplier and the person who joined last week.
• It can be shared and exported freely, in a format almost every other tool reads.

Feature parity with another SaaS product misses that comparison. A team running the work in a sheet is not choosing between two products; it is choosing between change and no change.

Research on decisions explains why "no change" starts ahead. William Samuelson and Richard Zeckhauser described status quo bias in 1988: in a series of decision experiments, people disproportionately stuck with the option they already had, and data on faculty members' choices of health plans and retirement programmes showed the bias was substantial in real decisions (Journal of Risk and Uncertainty). In information systems research, Greta Polites and Elena Karahanna reported results that largely supported their model: habitual use of an incumbent system, perceived transition costs and perceived sunk costs build inertia, and inertia lowers how easy to use and how advantageous people judge a new system to be, as well as their intention to use it (MIS Quarterly, 2012).

The practical reading is that the spreadsheet is not a weak competitor that loses on features. Its users judge a new product through it. Every extra set-up step, every field they cannot rename and every export that is harder than "save as" counts against the product before its benefits register.

Where a spreadsheet stops scaling

The spreadsheet's strengths come from having no model of the work: no states, no roles, no rules. That is also where it fails as the work grows.

• Errors have long been found to be common. Raymond Panko, in a 2000 paper for the European Spreadsheet Risks Interest Group, reported that fifteen years of research studies had concluded unanimously that spreadsheet errors are "both common and non-trivial" (Panko, 2000).
• Manual handling becomes a control risk. JPMorgan Chase's management task force on its 2012 trading losses found that a new risk model ran on a series of Excel spreadsheets completed by hand, by copying and pasting data from one to another. The bank's Model Review Group had called the manual spreadsheet process "error prone" and "not easily scalable", and a formula divided by a sum where the modeller had intended an average (task force report, 16 January 2013). The report lists these among several failures; the spreadsheet was not the sole cause.
• One formula range can change a conclusion. Thomas Herndon, Michael Ash and Robert Pollin, replicating Carmen Reinhart and Kenneth Rogoff's 2010 study of public debt and growth, found a spreadsheet error that left five countries (Australia, Austria, Belgium, Canada and Denmark) out of an average. It was one of three problems they reported, alongside the selective exclusion of data and unconventional weighting (PERI working paper 322, April 2013).

None of this makes spreadsheets bad tools. It means a spreadsheet does not know what the work is supposed to be, so nothing stops anyone from breaking it. That gap is where a product earns its place:

The last row matters as much as the others. A product that wins on control but loses import, bulk edit and export asks people to give up the strengths they chose the spreadsheet for.

Read the export button as evidence

An "Export to spreadsheet" button inside a product is a signal, not a feature to ship and forget. Two of the six signs we look for when B2B SaaS and workflow software has started to fight the work are about exactly this: people export data to make the real decision, because the product stores the record but does not provide the comparison, context or action the work requires; and automation hands exceptions back to chat and spreadsheets as soon as the rule does not fit. Our UX debt glossary entry gives the same example of how that debt accumulates: teams may keep duplicate approval states and export work to a spreadsheet, and each new change becomes slower until the underlying model is resolved.

Information systems research makes a similar case. Steven Alter presents his theory of workarounds as useful, among other things, for bringing possible workarounds into systems analysis and design (Communications of the AIS, 2014).

So when you look at exports, ask which screen the data leaves from, which role takes it and what happens to the file next. Each answer points somewhere different:

• An export that ends up in a report or board pack can point to a reporting gap.
• An export that comes back as an edited import can point to a missing bulk-editing model.
• An export that ends in a chat thread can point to an approval or exception the product does not represent.

Research the switch, not only the product

Our UX research can look at the work around the screen as well as the screen: artefacts, support records, workarounds and handoffs. We keep observation apart from interpretation. "Recruiters leave the system to coordinate availability" stays an observation until the study separates missing capability, policy, habit and integration constraints.

Napier Holland made the research point plainly. Teams that only ask current customers about the product are, in effect, talking to people already sold on it, and they miss the earlier stages: not knowing a product was needed, then evaluating, then trying. In his words: "where are our customers actually at? What are they actually doing?", as opposed to what the team assumes they are doing (28:00).

Add these questions to interviews with people who switched to the product, people who left it and people who looked and never started:

1. What did you use for this before, and what made you change?
2. What did you compare it with, including carrying on as you were?
3. What still lives outside the product: which sheet, thread or paper form, and who keeps it?
4. When did you last export something, and what did you do with the file?
5. What would make you go back?

The answers describe the product you are really competing with. Design against that one.