Main idea

Tables, columns, filtered views, forms, hierarchical pages and folders were not chosen because they matched the way we work. They were chosen because something had to be stored somewhere, fields had to be defined, search had to be made possible, and a stable shape had to be given to what came into the company. They are answers to machine constraints.

Nobody thinks in tables. When a product manager works on a topic, they handle objectives, decisions, risks, contradictions, hypotheses, evidence, weak signals, implicit rules and examples — and they connect them, rank them, tie them to a goal. The head works by links, by priorities, by contexts; the tool works by objects.

That gap is not an ergonomics flaw a better interface would fix. It lies in the nature of the forms chosen, and it is paid for every time a piece of work has to be flattened to fit into a field.

Why it matters

It rules out reading the current organization of information as a considered design choice that ought to be respected. What was built under technical constraint does not have to survive the disappearance of the constraint.

It also gives the reason users fill fields badly: they are not careless, they are translating. Every entry is a conversion from connected thought into a structure that is not, and the conversion loses something every time.

Nuances and limits

These forms are not bad for all that. An orders table, a workflow state, a permissions system do exactly what is asked of them, and nothing more flexible will replace them.

The limit therefore does not bear on the business objects, it bears on what was asked of them on top: to serve as working memory as well.

Open questions

• Which structures resist flattening — a graph, a set of connected notes — without becoming unreadable again at the scale of a company?