Customer discovery for a product that replaces spreadsheets

If you are building a product to replace spreadsheets, start by following a real piece of work through a file. “We use spreadsheets” tells you little about the opportunity. The file may be a calculator, an approval queue, a shared memory, an informal database, or a report someone exports and never edits.

The research question is what people accomplish with that arrangement, where it creates trouble, and what a replacement must preserve. A spreadsheet that looks untidy to an outsider may embody years of useful local knowledge. Your product has to understand the job before it can credibly improve it.

Follow one recent item from arrival to decision

Ask a participant to choose a completed example they are permitted to discuss. You want to follow one row, request, case, or reporting period through the process. A tour of every tab often produces a feature inventory; a single case reveals how the parts connect.

Useful opening questions include:

• “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 deliberately: a narrated walkthrough is useful, but it is not identical to observing undisturbed work. Read the contextual research guidance.

If a live file contains information the participant cannot share, work from a redacted example or a synthetic case that preserves the relevant structure. Record the limitation. A cleaned example may hide the messy exception you most need to understand.

Build a workflow canvas, not a list of spreadsheet complaints

The following canvas is an original tool for this investigation. Fill it with one concrete case before generalizing to the usual process.

Add a side column for artifacts outside the workbook: messages, emails, meeting notes, other systems, or someone’s memory. A spreadsheet replacement that ignores those dependencies may simply relocate the visible table while leaving the difficult work untouched.

Keep observed steps separate from the participant’s explanation of what usually happens. Both are useful; they have different evidentiary weight. Mark anything you inferred so it can be checked later.

A worked example: an agency staffing workbook

Imagine a fictional agency planning staff assignments across projects. A coordinator maintains a workbook. Team leads send changes in chat. A director uses a weekly summary to decide which projects can accept more work. This is an illustrative scenario, not a documented customer case.

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

At first glance, the opportunity seems to be “replace manual data entry.” The case reveals a more specific uncertainty: the summary may be read before the team lead has confirmed the new allocation. The colored cell carries that pending state, but the summary does not expose it.

That changes the next interview. The researcher should ask the director about a recent staffing decision and the coordinator about how pending changes become final. A request for a prettier dashboard would not address the question yet.

The product might eventually need an explicit confirmation state. It might instead need a small check before the summary is exported. The research has identified a boundary to investigate, not proved that an entire new staffing system is needed.

Ask what the spreadsheet does well

Investigate 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 requires an extra field? Can people export a version for a client or work when another service is unavailable?

These answers identify capabilities a replacement could accidentally remove. Do not treat flexibility as mere technical debt or assume every manually colored cell should become an automated rule. The color may communicate a judgment that the team has not fully defined.

GOV.UK’s user-needs guidance emphasizes understanding the problem and desired outcome without turning a preferred solution into the need itself. For this project, “needs a spreadsheet replacement” is a proposal. “Needs to distinguish confirmed assignments before accepting work” is a researchable outcome. Read the guidance on learning user needs.

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 needs context that those edits currently supply. Follow the tension to a concrete case instead of choosing the more senior person’s preference.

Write a replacement contract before building

Translate the case into a short set of things a trial must preserve and improve. This is a product acceptance tool, not a legal contract.

For the fictional 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.

Each statement should map to evidence or an explicit assumption. Add the relevant case and the person who can check it. Avoid expanding the list into every feature a spreadsheet possesses; focus on the workflow and adoption boundary you have actually investigated.

Test a narrow replacement before promising a broad one

Create a permitted sample containing an ordinary case and an important exception. Ask participants to perform the same meaningful task using the proposed approach. Record missing context, manual work moved elsewhere, and any assistance you provide.

Decide beforehand what would make you retain the spreadsheet for this workflow. Perhaps the proposed system cannot represent a frequent exception without developer help. Perhaps the extra approval step costs more attention than the problem warrants. Those are useful findings, not objections to explain away.

Your research output should be a traced case, a map of the surrounding handoffs, and a small acceptance contract. With those artifacts, you can decide whether to replace the file, augment one stage, or leave a working arrangement alone. The opportunity is the unresolved job, not the spreadsheet extension.