The spreadsheet is the spec
Every business I have built software for was already running when I arrived. Not on software — on a spreadsheet, a group chat, a shared folder of PDFs, and somebody's phone. That is not a failure state. It is a business that found demand before it found tooling, which is the correct order, and it is why there is something worth building at all.
The temptation at that point is to sit down with the founder and write requirements. Resist it. The spreadsheet is a better specification than anything the two of you will produce in a meeting, for one reason: it records what people actually do under time pressure, and a requirements document records what they believe they do.
Read the columns nobody planned
Open the file and look at where it stopped being designed. Every operational spreadsheet
has a tidy left half and a chaotic right half. The left is what someone set up on day one. The
right is what reality demanded afterwards: a column called NOTES2, a column that
is sometimes a date and sometimes the word "pending", three columns that are obviously one
field split apart because somebody needed to sort by part of it.
That right half is the most valuable thing in the building. It is an unfiltered list of the requirements the business discovered the expensive way, and not one of them will come up in a meeting, because they are not thought of as requirements. They are thought of as how the spreadsheet is.
Find the cell that is really a workflow
Somewhere there is a status column with values like sent,
waiting, waiting 2, chased, done?. Those
are not statuses. That is a process, written by the people who run it, in the order they run
it. It is the state machine you are being asked to build, and it took the business two years
to learn.
Ask what happens between two of those values and you will get the real answer — usually that someone phones somebody. Ask what makes a row go backwards, because rows always go backwards, and the exception path will fall out of the conversation without anyone having to imagine it. Exception paths are where software projects die, and they are impossible to invent and trivial to observe.
Separate the habit from the requirement
Not everything in there deserves to be built. A good half of what looks like a feature is a workaround for a limitation of the spreadsheet itself: a duplicated row because there is no way to represent one-to-many; a colour code because there is no permissions model; a second tab that exists purely because the first one got slow.
The test is to ask why, twice. If the second answer is about the tool rather than the business, do not build it — and say so out loud, because a founder who watches you delete half their list will otherwise think you have misunderstood the job. You have not. You have found the part of their week that the software makes disappear, which is the thing they are actually buying.
Count the manual steps and price them
Walk one real case end to end and count the human actions: copy this, paste there, send that, remind someone, retype the same name a fourth time. Then multiply by how often it happens.
That number is the business case, and it is almost always larger than the founder thinks, because nobody adds up their own week. It is also how you decide what to build first — not the most requested feature, and certainly not the most interesting one, but the step that occupies the most hours. In one care agency it was not scheduling, which everybody talked about. It was re-typing the same client details into three documents, which nobody mentioned because it was too boring to complain about.
Take the data before you take the brief
One practical thing: get a copy of the actual file, with the actual data in it, before you design anything. Not a sanitised sample. The real one, with the misspellings, the two customers who share a name, the row where somebody typed a phone number into the postcode column.
Those are your edge cases and they are already enumerated for you. Every one of them will otherwise arrive on the day of launch, wearing the costume of a bug.
A business that has survived on a spreadsheet has already written the specification. It just wrote it in the only notation it had.
What this actually buys
Two things. The product is right the first time far more often, because it was derived from observed behaviour instead of remembered behaviour. And the founder trusts you early, because in the first week you told them something true about their own operation that they had not noticed — which is worth more than any demo, and is the only reason anyone hands over a piece of their company.
Written by Liana Grigory, also written Liana Grigoryan — entrepreneur, technology founder and U.S. Army veteran in Los Angeles. More at Writing.