intermediate 2 min answer

A workspace product's engineers propose an architecture optimised for flexibility, letting users model anything. What product-thinking questions should shape the decision?

product-thinkingflexibilityconstraintsusersnotiontrade-off
Show the full answer Hide the answer

The questions

1. What is the user actually trying to accomplish? Maximum flexibility means the user must design their own solution before getting value. For some users — the enthusiastic minority — that is the product. For most, it is a blank page and an abandonment.

2. What does flexibility cost the user? Every degree of freedom is a decision the user must make. A product where everything is configurable is a product with a long time-to-value and a support burden.

3. What does it cost the architecture? A fully general data model cannot be optimised for any particular access pattern. Query performance, search relevance, permissions and mobile rendering are all harder when the shape is arbitrary. Flexibility at the model level is paid for in every feature built on top.

4. Which constraints would users welcome? Templates, opinionated defaults and structured types give most of the benefit of flexibility with none of the blank-page cost — and they are far easier to optimise for.

The architectural consequence

The workable pattern is a flexible core with opinionated surfaces: the underlying model can represent arbitrary structures, and the product presents templates, typed views and defaults that cover the common cases well.

That is harder than either extreme, and it is what allows the product to be approachable and extensible. It also means the performance work concentrates on the common shapes rather than being spread thinly across every possible one.

The trade to state explicitly

A flexible model makes every subsequent optimisation harder. Search over arbitrarily-shaped content, permissions over arbitrary nesting, and rendering arbitrary structures on a phone are each substantially harder than their constrained equivalents. Those costs arrive later, are paid by every feature team, and are invisible in the initial decision.

Product thinking here means asking whose problem the flexibility solves. If the answer is "the engineers, because we cannot decide what users need", the flexibility is deferred product work, and the cost of the deferral will be paid by every user who faces a blank page and by every engineer who optimises over an arbitrary shape.