Every PM wants to kill the spreadsheet

Every PM wants to kill the spreadsheet. Almost none of them read it first.

Two of the products I've shipped started as the same thing. A spreadsheet nobody admitted was load-bearing.

One tracked leave. One ran the whole company's rewards and recognition. Managers pre-filled nominations in a workbook, then on a fixed day everyone dialled into a call, someone shared their screen, and the room walked the Excel row by row, marking "Yes" in the final column.

The leave one ran on the same instinct, just quieter. A shared workbook and an email chain stood in for an approval process, with a different unwritten policy for every entity in the business, held together by whoever had been there long enough to remember all of them.

Read it like an archaeologist, not a critic

It's easy to stroll in as the product person and sneer at all that. Don't. That spreadsheet is the most honest requirements document you will ever be handed.

Read it like an archaeologist, not a critic. It survived for years because it worked, well enough. Every column is a real need someone had. Every ugly merged cell is a workaround for a real edge case. The mess isn't incompetence. It's accumulated truth.

Three questions to ask the file

So before replacing it, I read it like a PRD, and I asked it three questions.

Where does the data drift? Casing, blanks, a "Yes" typed into a number field. Every drift is a validation rule waiting to be born.

What decision does this column actually record? Half of them recorded nothing reliably. That's your workflow gap, sitting in plain sight.

What ritual surrounds the file? The screen-share call wasn't overhead. That call was the product.

The spreadsheet also tells you what not to build. Anything the org never bothered to track in it probably matters less than your roadmap thinks.

Every problem I'll walk through in the rest of this series, the meeting nobody thought to redesign, the data model that let people misspell their own team, the policy that couldn't bend, started with taking a file like this seriously enough to read it first.

Keep what made it trusted

Let me put the point plainly, because I nearly missed it myself: I never set out to kill Excel. I set out to keep everything that made it trusted, and delete everything that made it painful.

So next time you meet the spreadsheet quietly running a critical process, skip "why are they still on this?" Ask instead, what does this file know that I don't yet?