Technology First, Needs Last
Don Norman's short essay arguing that the dominant pattern in tech product development is backwards: technology first, needs last, with user needs reverse-engineered after a technology has been chosen.
The piece is compressed Norman — a pointed argument that reframes a pattern most practitioners would deny they are running while running it.
For product direction the lesson is diagnostic: notice when a project has started from "we should use X technology" and is looking for a use case, versus started from "here is a need" and is looking for the right technology.
Norman's jnd.org is full of pieces like this; read the piece, browse the site. A short, sharp essay.
Central argument
Norman argues that the dominant pattern in technology product development inverts the proper order: organizations start with a technology they want to deploy and then reverse-engineer a user need to justify it, rather than starting from a genuine human need and selecting technology accordingly. The essay names this inversion as the rule, not the exception — a structural tendency in how tech companies and product teams actually operate, despite widespread rhetoric about user-centricity. The core thesis is that 'technology first, needs last' is a diagnostic category that explains a large share of products that launch with sophistication but fail to find real adoption.
Critique
Norman's framing is clean but somewhat binary: it treats 'start from technology' and 'start from need' as clearly distinguishable origins, when in practice the two are often genuinely entangled — a new capability can reveal latent needs that users could not have articulated without the technology existing first. The smartphone camera, for instance, did not emerge from a pre-existing user need for always-on photography; need and technology co-evolved. Norman's essay, being short and polemical, does not engage seriously with cases where technological push has been the legitimate engine of valuable innovation, which limits its prescriptive force.
Why it matters for product
The essay gives product leaders a precise diagnostic question to apply at the earliest stage of any initiative: is this project organized around a capability looking for a problem, or a problem looking for a capability? This matters acutely during discovery and roadmap prioritization, where the framing of a brief — 'how do we build a product using our new ML pipeline' versus 'what do customers need that we cannot currently serve' — determines what gets built and whether it finds adoption. It is also a useful organizational signal: if engineering or platform teams are consistently the originators of product bets, the product function may be operating downstream of the technology inversion Norman describes rather than upstream of it.