To find startup ideas in spreadsheets, look for repeated decisions and handoffs around the sheet rather than assuming the grid itself needs replacing. The useful signal is a recurring job that becomes difficult because ownership, exceptions or history are hard to follow.
Spreadsheets are flexible, familiar and often entirely adequate. A founder should explain why a separate product would be worth adopting before treating a business workbook as evidence of obsolete software. Sometimes a better formula or a simpler operating rule is the right answer.
Observe the work around the cells
Ask someone to show how a real item moves through the process. Who adds the row? Who changes the status? How does the next person know it is their turn? What happens when the input is incomplete or the deadline moves?
Notice the places where users leave the sheet. They may open email to reconstruct a decision, message a colleague to identify an owner or compare yesterday's copy to understand a change. Those movements can reveal coordination work that a tidy screenshot hides.
Paul Graham's essay on startup ideas advocates noticing problems in the world. A spreadsheet walkthrough is one practical setting for doing that, without assuming every workaround needs a startup.
Use an exception and routing map
Take a blank page and draw the ordinary path from input to completion. Then add the paths that fail to follow it. For each exception, record five things:
- What condition causes the item to leave the ordinary path?
- Who notices and who has authority to decide?
- Which information is needed before work can resume?
- Where is the decision recorded for the next person?
- What happens if nobody acts?
A product hypothesis becomes more precise when several people repeatedly reconstruct the same answer. For example, the valuable job might be showing why an item is blocked and who can unblock it, rather than recreating every column in a web application.
Keep a separate column for uncertainty. If the user says a problem happens all the time, ask for the most recent example. A memorable incident and a frequent operational cost are different kinds of evidence.
A hypothetical contractor-allocation sheet
Consider a small translation agency using a workbook to allocate assignments to freelance translators. This is hypothetical. The founder initially proposes an attractive scheduling dashboard.
During a walkthrough, the manager shows that ordinary assignments work well in the sheet. The hard cases involve a translator declining after an assignment has been confirmed. Staff must find a replacement, check an altered deadline and tell the account owner what changed.
A narrower experiment could track those reassignment cases with a named owner and a short decision history. It need not replace the master allocation sheet. The agency might test it on an agreed sample using redacted information before granting wider access.
The experiment fails if staff spend more time maintaining two records than they save coordinating. That is not a reason to hide the extra work. It is the central adoption question.
Study behaviour without collecting unnecessary data
A workbook may contain personal information, commercial terms or confidential client material. Ask for a redacted walkthrough or a recreated example when possible. A founder does not need a complete export to learn which handoff is painful.
Nielsen Norman Group's interview guidance explains that reported behaviour has limits, including imperfect recall. Combine the person's explanation with an authorised demonstration of the process. Do not interpret a confident description as a complete record of what happens.
With permission, write notes about the task rather than retaining source data. Explain how you will use the notes. If recording is useful, obtain consent first and agree how long it will be kept.
Test the replacement burden
Before coding, list what the spreadsheet already provides: bulk editing, easy exports, flexible formulas, low setup effort and a format colleagues can understand. A replacement that removes these benefits has a higher adoption hurdle than its demo suggests.
Consider an add-on, a report or a structured service instead of a replacement application. The smallest useful intervention might be a daily exception list generated from an approved export. It can test whether surfacing unresolved items changes outcomes without asking everyone to migrate.
Also identify the authoritative record. If both the sheet and your tool can change status, disagreements will arise. A pilot should state which record wins and how corrections flow back.
Know when to leave the spreadsheet alone
The strongest counterargument is often that the customer already has a good enough tool. Flexible work may genuinely benefit from a flexible grid, particularly when volume is low and one person owns the process.
Stop if the supposed pain disappears after cleaning up a template, no one can name a repeated costly exception, or the team will not change the handoff that creates the problem. A spreadsheet is a useful research window. The business opportunity, if one exists, is in a job people care about improving.