Every regulated-industry team I’ve ever talked to has the same setup: an expensive ALM tool that the program manager uses to generate reports, and a spreadsheet that everyone actually trusts.
The ALM tool costs $50,000 a year. The spreadsheet costs nothing. The spreadsheet wins.
This isn’t a training problem. It’s not a change management problem. It’s a structural fact about how engineers actually work, and understanding why matters a lot if you’re trying to build better compliance tooling.
The spreadsheet is a universal interface
An .xlsx file opens on every computer, in every country, at every company, without a VPN, without a license check, and without reading a manual. An auditor can open it. A subcontractor can open it. A new hire on their first day can open it. The program manager, the QA lead, and the software engineer can all look at the same file and understand what they’re looking at.
No ALM tool has ever achieved this. Not Jama. Not Polarion. Not DOORS. They all require accounts, training, and a browser pointed at the right server. The spreadsheet requires none of that.
This isn’t a bug in the market. It’s a feature of the spreadsheet. Interoperable and ubiquitous. WHat’s not to love?
The spreadsheet is already where the work happens
Requirements don’t start in an ALM tool. They start in a Word document, or a whiteboard photo, or a chain of emails, and then someone puts them in a spreadsheet to make them manageable. By the time they reach an ALM tool, they’ve already been through Excel once.
When engineers update requirements, they update the spreadsheet. When the QA team links tests to requirements, they do it in the spreadsheet. The ALM tool gets updated before an audit, by someone who has to reconcile it with the spreadsheet that everyone else has been using for the past three months.
This happens everywhere. I’ve seen it in aerospace, at medical device startups, and I’m pretty darn sure it’s there at automotive tier-1 suppliers. The spreadsheet is where the truth lives, even when it’s “supposed to” live somewhere else.
The ALM tools optimized for the wrong problem
The big ALM platforms were built for large enterprises with dedicated requirements engineers. Those are the zookeepers: people whose entire job is the care and feeding of the tool. For those teams, the overhead of a structured tool is worth it because someone is paid to manage that overhead.
For everyone else (me included, plus the team of eight engineers trying to hit a CE mark, the startup racing to 510(k), the aerospace contractor writing software for a subassembly) there’s no way we can pay that “overhead tax”. I don’t have time to do the training to be a “site administrator”. The spreadsheet wins by default.
The tools also optimized for features over usability. Every major ALM platform has rich link types, custom workflows, baseline comparison, and a marketplace of integrations. They also have onboarding that takes weeks and UIs that require training to navigate. Engineers don’t use things that require training for tasks they can do in Excel in five minutes.
The spreadsheet’s real weaknesses
None of this means the spreadsheet is perfect. It has real problems.
It has no opinions. A spreadsheet will accept any value in any cell. You can write “the system shall be fast” in a requirements field and it will happily store it. It won’t tell you that “fast” is a vague term with no measurable criterion. It won’t tell you that “the system” is ambiguous. It won’t tell you that you have 47 requirements with no test coverage.
It doesn’t track changes. A spreadsheet reflects the state you left it in the last time you touched it. If a requirement changed three weeks ago and the associated tests weren’t updated, the spreadsheet doesn’t know. You find out when you run the tests, or when the auditor checks the chain.
It’s not connected to anything. Your requirements are in Excel. Your tests are in Jira or TestRail or a Python test file. Your source code is in git. None of these things know about each other. The traceability chain exists only in the head of the engineer who set it up… or, more likely, in a spreadsheet that someone updates every few months and hopes is still accurate.
What to do about it
The answer is not to replace the spreadsheet. The market has tried that for thirty years and failed every time. The answer is to make the spreadsheet smarter.
Give it a schema that maps to what auditors actually look for. Give it a status column that tells you, at a glance, which requirements have no test coverage. Connect it to your source code so you can see which requirements have been implemented, and which commits touched them. Give it validation that catches vague requirements and missing mitigations before the auditor does.
And crucially: keep the spreadsheet as the interface. Don’t ask engineers to learn a new tool. Don’t ask the QA team to migrate their process. Let them keep working the way they already work, and put the intelligence underneath.
That’s the bet RTMify is making. Not that the spreadsheet is the best possible requirements management tool. It isn’t. But that it’s the only requirements management tool that everyone actually uses. And “actually used” beats “theoretically better” every time.
The spreadsheet already won. It’s still winning. It’s time to just be “ok” with that, and give the sheet a big upgrade to its IQ.