Beyond Excel and Google Sheets

What Excel and Google Sheets are good at

Excel and Google Sheets are extraordinary products, and the reason they are everywhere is not inertia. Excel's formula language is the most widely known programming language in the world. Google Sheets solved simultaneous editing, comments and sharing years before most business software admitted those were requirements. Anyone who tells you their product replaces those tools because it has a grid and a SUM is selling you the easy part.

We did not try to beat them at being a spreadsheet. The formula library here is the Excel function library, because relearning it would be a loss and not a feature.

Where the line runs

The line is not about features of the grid. It is that a file is a file: an island with an import door and an export door. Everything a spreadsheet needs from the rest of the company has to come through one of those doors, and everything the company needs from the spreadsheet has to leave through the other.

Everything in the right-hand column follows from one difference: the sheet is not beside the system, it is one of its surfaces.

Two sheets you cannot build in Google Sheets

A sheet that reads from your data model

A sheet can be defined as a view of something else: a dataset, a semantic model, or a saved SQL view - with its own filter, sort and row limit as part of the definition.

Nobody refreshes it. The rows are fetched when it is opened, through the ordinary data plane, and each reader's own access is checked on the way - so two people can open the same sheet and legitimately see different rows. A shared file has never been able to do that: sharing there is a property of the document, not of the data.

A sheet like this is a reading surface - the rows belong to the source, and editing them in a grid would be editing somebody else's data. What you do on it is discuss it: comments attach to a cell or a range, so the question about one figure sits on that figure.

When the work is to build on top of the data rather than to read it, you take it in instead: the rows are materialised into an ordinary sheet, and from that moment they are yours - add columns, write notes, run formulas, enrich it however the job requires. The trade is explicit and the right way round: a live view stays true to the source, a working copy stays true to you.

A sheet that starts real work

Start with the messiest thing a team does: collecting ideas.

Open an empty sheet and type. Campaign ideas, one per row, in whatever order they arrive. Long descriptions where a description helps, attachments where a picture explains it faster, rows deleted when they turn out to be the same idea twice. No schema to design first and no form to fill in - exactly the reason people open a spreadsheet in the first place.

Then the part neither Excel nor Google Sheets has an answer for. When an idea is worth doing, select the rows and press a button on the sheet's own toolbar - Create plan, or whatever the team called it.

What happens next is not an export:

• The button fires a real capability for the selected rows, creating a task of the right type in the right process - one per row.
• What comes back is written into the row: a task column that now holds the actual task, not a reference somebody typed.
• A neighbouring column reads that task's live status and shows it in the sheet. It is read-only, because the status belongs to the process, not to the grid.
• The same tasks are on the board, in the queue, in the reports. One object seen from two places - the sheet where the idea started, and the process where the work happens.
• The action can stamp who ran it and when, so "who turned this idea into a plan" is recorded, not remembered.

And it is a declaration, not a development task: the button is part of the application's workbook definition, mapping the sheet's columns to the capability's inputs and its results back to columns. Adding one is a few lines in the app, not a project.

The idea list stays what it was - a place to think in - and becomes the place the work is launched from and watched from.

Nothing about that button says "task"

Worth noticing what the mechanism is. The button does not know about processes. It takes the selected rows, calls a capability, and writes what comes back into columns. Creating a task is one capability among the set the platform and its applications provide - sending a message, writing to a system, reading a reference, running a job.

So the same few lines of a workbook definition produce a different button. Select the rows and notify the owners. Select the rows and file them into an external system. Select the rows and run the check that says which of them are already covered.

The one everybody thinks of first is not built yet, and it is worth being straight about that: an agent action in that slot - describe the campaign in a row, press the button, and have an illustration generated into the attachment column beside it. That is a capability and not a new mechanism, which is why it arrives as an addition instead of a rewrite. The grid, the button, the write-back into a column and the agents all already exist; what is missing is the wire between them.

Next

Connected to the rest - the rest of what a sheet reaches once it is inside the platform, and the plumbing that stops being necessary.