Customer discovery for spreadsheet replacement software starts with one row

Customer discovery for spreadsheet replacement software should start by following one real piece of work through the file. "We use spreadsheets" tells you very little. The file may be a calculator, an approval queue, a shared memory, an informal database or a report someone exports and never edits.

What you need to learn is what people get done with that arrangement, where it causes trouble and what a replacement must keep. A spreadsheet that looks untidy to an outsider may hold years of useful local knowledge. (Somewhere there is a tab called FINAL_v3, and someone depends on it.) Understand the job before you claim to improve it.

1. Follow one recent item from arrival to decision

Ask the participant to pick a completed example they are allowed to discuss. Follow one row, request, case or reporting period through the process. A tour of every tab produces a feature list. A single case shows how the parts connect.

Useful opening questions:

• "What caused this item to enter the file?"
• "Who added it, and where did the information come from?"
• "What happened next?"
• "When did someone make a decision using it?"
• "How can you tell that the work is finished?"

GOV.UK's contextual research guidance describes learning from people's normal environment, equipment, documents and work. It also distinguishes observation from approaches that interrupt with questions or ask people to narrate. Choose on purpose: a narrated walkthrough is useful, but it is different from watching undisturbed work.

If the live file holds information the participant can't share, work from a redacted example or a made-up case with the same structure. Note the limit. A cleaned example may hide the messy exception you most need to understand.

2. Map the workflow around the file, not the complaints about it

This canvas is our own. Fill it with one concrete case before generalizing to the usual process.

Add a side column for things outside the workbook: messages, emails, meeting notes, other systems and someone's memory. A replacement that ignores those may simply move the visible table while the difficult work stays where it was.

Keep observed steps separate from the participant's account of what usually happens; they carry different weight. Mark anything you inferred so you can check it later.

3. A made-up example: the agency staffing workbook

An agency plans staff assignments across projects. A coordinator maintains a workbook, team leads send changes in chat, and a director uses a weekly summary to decide which projects can take on more work.

The team follows one assignment change. A designer's availability drops. The coordinator finds the row, adjusts the allocation, checks a formula, colors a cell and messages the team lead. The director sees only the summary tab, in a later meeting.

At first the opportunity looks like "replace manual data entry." The case shows something more specific: the director may read the summary before the team lead has confirmed the new allocation. The colored cell carries that pending state. The summary doesn't show it.

That changes the next interview. Ask the director about a recent staffing decision. Ask the coordinator how pending changes become final. A prettier dashboard wouldn't answer either question yet.

The product might eventually need an explicit confirmation state. It might only need a small check before the summary is exported. So far the research has found a boundary to investigate. It hasn't proved anyone needs a whole new staffing system.

4. Find out what the spreadsheet does well

Ask why the current arrangement survives. What can the coordinator change without waiting for an administrator? Which calculations are trusted? What happens when a new project needs an extra field? Can people export a version for a client, or keep working when another service is down?

These answers name what a replacement could accidentally remove. Don't write off flexibility as technical debt, and don't assume every hand-colored cell should become an automated rule. The color may stand for a judgment the team hasn't fully defined.

GOV.UK's user-needs guidance stresses understanding the problem and desired outcome without turning a preferred solution into the need itself. Here, "needs a spreadsheet replacement" is a proposal. "Needs to tell confirmed assignments apart before accepting work" is an outcome you can research.

Interview both the person who maintains the file and someone who acts on its output. The maintainer may want fewer edits while the decision maker relies on context those edits supply. Follow that tension into a concrete case instead of siding with the more senior person.

5. Write a replacement contract before you build

Turn the case into a short list of what a trial must keep and improve. This is a product acceptance list, not a legal contract.

For the made-up agency, it could say:

• A coordinator can represent a changed assignment and distinguish pending from confirmed.
• A director can see whether the staffing decision relies on pending information.
• A team lead can correct an allocation without silently erasing the prior decision.
• The team can retrieve an understandable copy of its current plan.
• When an update fails, the coordinator can identify the failure and recover the affected work.

Tie each line to evidence or an explicit assumption, and note the case and the person who can check it. Keep it to the workflow and adoption boundary you actually investigated, not every feature a spreadsheet has.

6. Test a narrow replacement before promising a broad one

Build a permitted sample with an ordinary case and an important exception. Ask participants to do the same meaningful task with the proposed approach. Record missing context, manual work that moved elsewhere and any help you gave.

Decide beforehand what would make you keep the spreadsheet for this workflow. Perhaps the new system can't represent a common exception without developer help, or the extra approval step costs more attention than the problem is worth. Those are findings. Don't explain them away.

You should come out with a traced case, a map of the handoffs around it and a short acceptance list. With those, you can decide whether to replace the file, improve one stage or leave a working arrangement alone. The opportunity is the unresolved job, and the spreadsheet is only where it lives today.