Published on: 17 March 2026
Written by Michael Jendryke
Every product starts somewhere. But where you start determines everything.
Six drivers shape how products get designed:
User-driven: Solve the problems people have now. Strength: High adoption. Solves real pain. Risk: Bespoke solutions. Technical debt compounds. Nothing generalizes.
Data-driven: Build from what you can measure. Strength: Empirically grounded. Risk: Integration nightmare. Different formats, resolutions, coordinate systems. Each new dataset is a custom project.
Policy-driven: Build what compliance requires. Strength: Built-in adoption (it’s mandatory). Risk: Bureaucracy over usefulness.
Object-driven: Build around persistent identities. Strength: Clear provenance and traceability. Risk: Identifier hell. Registries, resolution services, governance.
Physics-driven: Build what the universe allows. Strength: Inherently correct. Risk: Ignores human factors and adoption barriers. Infinite precision.
Model-driven: Build the ideal abstraction first. Strength: Transferable. Solve once, apply everywhere. Risk: Over-engineering for simple cases.
The tensions:
User-driven creates efficient single-use solutions. Six months later you’re copying code, creating an R-script called project_v2_final_ACTUAL_final. Nothing transfers.
Model-driven creates frameworks that work everywhere but feel abstract. Users ask “can it just do X?” Generality comes at a cost.
Physics-driven gives correctness without usability. The simulation is physically accurate but takes 3 days to run.
Data-driven gives patterns without explanations. X correlates with Y, but why? And will it hold tomorrow?
The one you START with shapes everything:
Start user-driven → fight technical debt, struggle to generalize Start model-driven → fight adoption, “just make it work” requests Start physics-driven → fight practical constraints Start policy-driven → fight the compliance-usefulness gap
Most spatial products fail because they’re user-driven when they should be model-driven. We build for this client, this project, this deadline. Then wonder why nothing generalizes.
The hard truth: transferable solutions require starting with abstractions, not use cases. Takes longer. Costs more upfront. Pays back every time you apply it to the next problem without rewriting everything.