The trap hiding inside transformation
On October 14, 1806, the Prussian army was decisively defeated at Jena and Auerstedt. It was a force well-equipped with the latest technology. Prussia still drew confidence from the legacy of Frederick the Great, and its officers believed that its tried and true approach made it superior to any other force on the continent. But Napoleon had changed the operating logic of war. Recognizing how technological advances offered him new capabilities, he reimagined what was possible. He restructured his army to use a more flexible corps system, with separate staffs and administrative services, and he combined that structure with greater speed and maneuver. At Jena and Auerstedt, Prussia was not simply beaten by a stronger opponent. It was beaten by a different paradigm. (Britannica, "Battle of Jena")
That is the danger in every technological shift. An organization deploys new tools but the results are only marginal. Worse is if their opponents figure out that the paradigm has changed first.
Today's organization are issuing all sorts of tools (e.g. agentic coding assistants, copilots, and intelligent automations) but they keep the same organization, the same assumptions, and the same ways of working. The technology arrives, but the operating logic does not change.
As David Rogers puts it, transformation is “not about updating your technology but about upgrading your strategic thinking.” (Rogers, 2016)
And product development organizations are just as succeptable as any. When product design falls into obsolete paradigms I call it accidental skeuomorphism.
Accidental skeuomorphism is what happens when people translate a new technology into the existing paradigm without reassessing or in many cases even recognizing the underlying assumptions. They preserve the old mental model, the old workflow, and the old interface grammar, and in doing so they overlook possibilities that later, in retrospect, seem obvious.
That is what I see in Product Design today.
A team takes a workflow built for declarative software and adds an LLM to the front. A report becomes more data rich (not more intelligent). A dashboard gets a chat panel (because ChatGPT). A rigid process gets wrapped in prompts and suddenly we call it "AI". The surface gets more cluttered with features, because building is easier and faster. Now every idea we ever had is on the backlog.
But the product logic stays largely the same. We are still asking the user to do the hard work. We are still preserving the same screens, the same forms, the same assumptions about where structure should live, and the same rituals for how work is supposed to move. The new medium gets absorbed into the old world. And in many ways by stuffing more features into the digital world, we make things more comprehensive but not more comprehensible (Weisz et al., 2024)
The mistake is not that teams are using AI. The mistake is that they are often using it inside the assumptions of traditional software.
That matters because large language models are not just another UI enhancement. They are not calculators, databases, or deterministic business rules engines. They are language systems. They are good at interpreting intent, handling ambiguity, generating and transforming text, summarizing complexity, and participating in multi-turn interaction. Recent design research argues that generative systems present “unique design challenges,” while explainability research shows that people with and without AI background interpret the same systems differently. In other words, technical understanding is not downstream from design here. It is one of the inputs to design. (Weisz et al., 2024)
So the argument of this essay is simple. Most people are not yet designing for the new medium because they are still thinking in the mental model of the previous one. They are optimizing inherited containers instead of redesigning the work from first principles.
Why obsolete paradigms persist
This pattern is older than AI, and the literature on it is precise.
Kuhn's argument in The Structure of Scientific Revolutions is not that change is slow because people are slow. It is that communities of practice do not abandon a paradigm because a better one has been proposed. They hold it until the accumulated weight of anomalies forces a reconstruction of prior assumptions and a reevaluation of prior facts. In the interim, practitioners continue to interpret the world through the concepts, problems, and standards of legitimacy that the old paradigm supplied. Even after a new framework has been articulated, the language of the old one persists, because it is what trained observers know how to see. (Kuhn, 1962)
I have written before about why this makes paradigm shifts so costly from the inside: the practitioners most competent inside the old logic are often the least equipped to perceive the new one. Fluency in the prior paradigm becomes the blind spot. Transformational change, as I framed it in that earlier piece, "produces a genuine and ongoing reassessment of prior assumptions and behaviors and the subsequent emergence of new, homegrown responses." It is not a single moment of recognition. It is the slow, uncomfortable work of rebuilding vocabulary. A new paradigm, in Kuhn's framing, does not arrive fully formed. It stands in stark contrast to the old one, remains deliberately open-ended, and is filled in only through experience. That is also why the old form keeps pulling new technologies back into familiar shapes while the new paradigm is still being articulated.
That cognitive inertia has an economic analogue. W. Brian Arthur's work on increasing returns and path dependence shows that early technology choices accumulate complements — trained users, supporting investments, standards, metrics, governance — that make the incumbent form cheaper to extend than to replace. What survives is not necessarily the form best suited to the new medium. It is the form that reached critical mass first and accrued enough surrounding structure to lock itself in. The choice that looks rational at each step can, in aggregate, keep an industry stranded in a dominated design. (Arthur, 1989)
The clearest historical quantification of that lag comes from the second turn of the Industrial Revolution: the shift from steam to electric power inside the factory. I have written before about how steam itself was a paradigm shift — one that, as I put it then, "initiated a shift towards larger-scale, centralized factories" with "far-reaching implications for how businesses were structured and operated." Electrification was the next paradigm shift of that same revolution, and its payoff took decades to arrive.
Paul David showed that the productivity gains from electric power did not come with the motor. They arrived roughly three decades later, once firms stopped laying out factories around the geometry of centralized steam. The tall multi-story buildings, line shafts, belt drives radiating from a single prime mover, a layout dictated by the physics of mechanical power transmission (a remanant of the steam power that previously had filled them). When factories began redesigning around unit drive, lighter single-story plants, flexible floor layout, and continuous flow they finally realized the benefits of electrification.
The power source changed in the 1890s. The system it made possible took until the 1920s to emerge. The lag was not adoption speed. It was the time required to dismantle one paradigm's assumptions and build the next. That is the clearest empirical benchmark we have for how long accidental skeuomorphism can tax an industry. (David, 1989)
The same inertia is already measurable inside generative AI, and the empirical evidence is starting to stack up.
Zamfirescu-Pereira and colleagues put that extrapolation under direct observation. In a CHI 2023 study of non-AI experts attempting to design LLM prompts, participants transferred habits from conventional software, treating the model as a rule-bound system, writing prompts as if they were configuring a form, and failed in a characteristic pattern. They did not lack effort or intelligence. They were fluent in the grammar of the previous medium, and that fluency is what led them astray. The failure mode is the essay's thesis in miniature: users reach for the new medium with the grammar of the old one. (Zamfirescu-Pereira et al., 2023)
Weisz and colleagues generalize the pattern beyond prompting. In a design-principles study drawing on interviews and design analysis across generative applications, they find that users construct mental models of LLMs by extrapolating from prior experience with conventional software. They systematically misattribute capabilities, trusting deterministic correctness where the system is probabilistic, and underestimating inferential reach where the system is strong. Those mismatched expectations shape usage before any interface decision has been made, and they compound when the interface itself mimics pre-LLM software. (Weisz et al., 2024)
The effect is not uniform across users. Ehsan et al. ran an empirical study of 107 participants comparing how those with and without AI background interpret the same explanations, and found the divergence is structural rather than incremental. Non-specialists read model output through the grammar of conventional software, assuming determinism and hidden rules. Specialists read it through the grammar of model behavior, assuming distributions and failure modes. The implication for product teams is important: when those mental models mix inside a room, the legible compromise is almost always the one inherited from traditional software. (Ehsan et al., 2021)
The contagion runs in both directions. Jakesch and colleagues, in a CHI 2023 study of 1,506 participants, found that co-writing with an opinionated language model shifted users' own expressed views toward those of the model, roughly doubling the rate at which users adopted the model's stance. The system inherits our mental models of software, and in using it we inherit some of its dispositions back. That feedback loop is another reason the old paradigm is hard to shake: the tool does not sit outside the user. (Jakesch et al., 2023)
Three forces therefore compound:
- Cognitive anchoring on the prior paradigm — the Kuhn problem.
- Economic path dependence on the prior complements — the Arthur problem.
- And an empirically documented divergence in how practitioners even perceive the new medium in the first place — the XAI problem.
The past persists not because people fail to see that a new medium has arrived. It persists because seeing it clearly requires dismantling the vocabulary, incentives, and professional standing already built on top of the old one. That is the first trap.
Why organizations keep copying the wrong thing
If the last section explains why the past persists, this one explains why organizations keep reproducing it.
Because under uncertainty, firms rarely move toward the strange thing that is most native to the new medium. They move toward the familiar thing that is easiest to recognize, explain, fund, govern, and sell.
DiMaggio and Powell captured this dynamic with unusual precision: “rational actors make their organizations increasingly similar as they try to change them.” Their point is not that organizations are lazy. It is that imitation lowers perceived risk. It creates legitimacy. It makes a new investment look less like a leap and more like a sensible extension of what already exists. In moments of ambiguity, similarity can feel like prudence. (DiMaggio & Powell, 1983)
That helps explain a great deal of what we are seeing in Product Design today. When teams do not yet know what a product built around the new medium should look like, they reach for categories that already make sense inside the market. Dashboards. Workflow tools. Coding Assistants. Copilots. Those categories are easy to position, easy to compare, easy to procure, and easy to sell. But they are also often the wrong starting point.
James March gives us the second lens. Organizations are pulled between “the exploration of new possibilities” and “the exploitation of old certainties.” Exploitation is easier to justify. It has shorter feedback loops. It fits existing teams and planning cycles. Exploration is ambiguous and disruptive. It threatens established structures. So companies tend to improve the known before they truly investigate the new. They make the dashboard smarter. They make the workflow faster. They add more features to the form. But they stop short of asking whether the dashboard, workflow, or form should remain the primary object at all. (March, 1991)
There is a third problem. Different groups inside the company are not actually seeing the same technology in the same way. One team sees a conversational interface. Another sees a probabilistic system with unstable outputs and edge cases. Another sees a roadmap item. Another sees a sales story.
Research on AI explanations shows that the presence or absence of AI background materially changes how people interpret the same system, while tools like fAIlureNotes were built precisely because designers often “lack technical knowledge” and practical ways to inspect model limitations early enough. When those mental models diverge, people usually choose to preserve the old structure and place the new technology on top of it. (Ehsan et al., 2021; Moore et al., 2023)
That is why organizations keep copying the wrong thing. They are not only inheriting old software patterns. They are inheriting old categories of legitimacy, old incentives, old planning habits, and old conventions for what a serious product looks like. The result is that the familiar form keeps winning before the deeper product question is even asked.
What Product Design today requires instead
If accidental skeuomorphism is the habit of forcing a new medium into old forms, then Product Design today starts by doing the opposite.
Value Stream Mapping
The first design question is not “where do we add AI?” It is what problem are we actually trying to solve? Once that is honest, the next move is to map the current-state process from end to end. This is the Lean tradition of Current State Value Stream Mapping — a technique I described before in the context of strategic discovery. You diagram the steps the work actually takes, work and waits both, annotate them with real numbers (cycle times, queue depths, error rates, rework loops), and you do it in a workshop with the people who own those steps.
The point of doing this is not the diagram. The point is the observation. Until you see the work end-to-end, you are designing for a stylized version of it — the version in the org chart, the slide deck, or last quarter's roadmap. Almost every team I have worked with discovers, on the first honest current-state map, that the dominant cost is not in any of the steps the existing software touches. It sits in the waits, the handoffs, the reconciliations, and the silent rework after the system claims a step is done.
That observation is what defeats accidental skeuomorphism before it starts. If you skip the map and go straight to "where do we add AI?", you will bolt the new capability onto the most visible step — usually a screen — because that is where the existing software has trained you to look. If you map first, the candidate problems surface in their actual proportions: the painful handoff, the brittle reconciliation, the ambiguous request that takes three rounds to clarify. Those are the problems where probabilistic systems can earn their keep. The screen is rarely where the value is leaking.
This also reframes the unit of design. The unit is not the feature you would add. It is the segment of the value stream you intend to compress, eliminate, or restructure. That framing forces a budget conversation up front: what part of the current-state process is this redesign meant to remove, not just decorate?
First Principles Ideation
A current-state map tells you where the value is leaking. It does not tell you what to build instead. That move requires a second discipline — first-principles ideation — and it deliberately runs against the grain of how most experienced product teams generate options.
I have [written elsewhere][own-anatomy] about first-principles thinking as the bridge between raw observation and a usable diagnosis: the work, as I framed it then, is to "break down the problem to its most basic elements and reassemble it from the ground up." The same technique applies to ideation. Strip the candidate problem to its non-negotiables — what the user actually has to accomplish, what the constraints really are, what counts as evidence of success — and only then start generating solutions. The discipline is to refuse, on first pass, the solutions that look like the existing product. Those will reassert themselves in implementation soon enough; the ideation phase is the one place you get to suspend them.
Design Thinking gives this a useful grammar. Two prompts do most of the work:
- "How might we…" reframes a constraint as a design question. It is a deliberately permissive form: it presupposes that the team can act, but it does not presuppose what action to take. It also forces specificity. "How might we cut the time from request to first usable answer in half, without adding a new screen?" is a very different brief than "let's add AI to the request flow."
- "What if…" suspends a constraint to test whether it is structural or merely inherited. What if the form did not exist? What if the user never had to choose a category? What if the right answer were assembled from the conversation rather than retrieved from a record? Most "what if" prompts produce nothing usable. The few that do tend to point directly at the parts of the inherited paradigm that no longer earn their place.
The ideation is not the deliverable. The deliverable is a small set of candidate problem framings, each one stripped to first principles and each one paired with an explicit hypothesis about where in the value stream it would compress cost or expand capability. That is what feeds the next move: choosing which of those candidate problems is genuinely a problem the new medium is good at.
The Right Problem for the AI Solution
To start thinking about AI we need to be triggered by the nature of the medium itself.
Language models are good at interpreting intent, handling ambiguity, generating and transforming language, supporting explanation, and participating in loops of clarification and refinement. They are not ideal substitutes for deterministic systems when precision is non-negotiable. So the right problem show up when we spot this kind of problem: probabilistic, ambiguous, and iterative. (Weisz et al., 2024)
That distinction sounds obvious, but many products still get it wrong. Teams hand deterministic work to probabilistic systems. They ask language models to behave like calculators, source-of-truth databases, or rules engines. Or they bolt a conversational layer onto an unchanged workflow. In both cases, the system is being assigned the wrong job.
This is why the better starting point is often not the screen. It is the user’s actual question.
The strongest research on explainable AI design proposes a “Question-Driven Design Process” that grounds user needs, technique choice, design, and evaluation “all in the user questions.” That is a very different orientation from conventional enterprise software, where the screen and workflow often come first and the user’s intent gets squeezed into them. In many cases the central design object is no longer the static interface. It is the loop: the user expresses intent, the system interprets it, asks clarifying questions, calls the right deterministic or probabilistic tools behind the scenes, and returns an answer, action, or next-best step. (Liao et al., 2021; Amershi et al., 2019)
This does not mean every product should become a chatbot. Sometimes the right answer is still a table, a workflow, a form, or an explicit state model. Or it might be an SMS, Email, or phone call. Or the absence of an interface. The point is to stop assuming a specific structure must always sit at the front of the experience.
That is also why technical understanding belongs inside design. Not because every designer must become an ML engineer, but because in products built on probabilistic systems, capability and limitation are part of the design material. The research is unambiguous here: people with and without AI background interpret systems differently, and designers need ways to explore model behavior and failure patterns early if they want to choose the right use cases and the right interaction model. (Ehsan et al., 2021)
This is where the call to action gets specific. You would not ask an expert horse-trainer to design a car. You would ask someone who understands how cars work — their mechanics, their failure modes, how to test them, what they can and cannot do. The same principle holds here. Anyone designing products on top of language models needs genuine expertise in the underlying technology and in the process for evaluating it. Not because they need to train the model themselves, but because they need to recognize what it is actually doing, where it fails, and what counts as evidence that it works. Evaluation literacy matters as much as technical literacy: probabilistic systems are judged by benchmarks, adversarial probes, human evaluation with inter-rater agreement, and regression tracking across model versions — not by the assertions that deterministic software allowed. Designers who cannot reason about those methods end up shipping by vibe, which in this medium is indistinguishable from shipping by accident.
The second call to action is about hiring and training. In periods of paradigm disruption, organizations must deliberately recruit and develop people who think in first principles. First-principles thinking is a specific discipline — decompose the problem to its irreducible constraints, reason upward from the technology and the user's intent rather than from precedent — and it comes unnaturally to practitioners whose careers have been built on identifying and applying best practices. Best-practice thinking is a rational response to a stable paradigm: imitation lowers risk and compounds. In a paradigm shift, best practice is sediment from the old medium. The people who thrive are the ones who can set precedent aside and ask, "What does this technology actually make possible, and what is the simplest system that uses it on its own terms?" That skill is rarer than résumé markets recognize. It has to be hired for, protected, and taught.
The practical test I would use is simple:
- What is the user actually trying to accomplish?
- What part of that work requires deterministic correctness?
- What part benefits from language, ambiguity resolution, or explanation?
- What interface elements exist only because older software needed structured input up front?
- What should happen in one turn, and what should happen in a loop?
- What can shrink, move to the edge, or disappear altogether?
That is what Product Design today requires instead of simply adding intelligence to inherited software furniture.
What leaders and teams need to change
This is not just a design problem. It is a leadership and operating-model problem.
The Prussians did not lose because they lacked courage or competence. They lost because they tried to fight a new age with an old logic. The same thing happens in companies when new tools are dropped into old systems of authority, coordination, and product thinking. If leaders keep the same approval chains, the same metrics, the same internal boundaries, and the same assumptions about how work gets done, the “new” technology gets absorbed into the old world and loses much of its power. (Britannica, "Battle of Jena")
That is why David Rogers’s formulation matters so much. Digital transformation, in his framing, is not primarily about the technology layer. It is about the underlying strategic assumptions. His book uses case studies like The New York Times to show what real transformation looks like in a legacy firm. The Times paywall launched on March 28, 2011. By the company’s 2025 annual report, it had reached 12.8 million subscribers. That is not the story of simply digitizing the newspaper. It is the story of redesigning the business around a new logic of relationship, distribution, and value capture. (Rogers, 2016 — NYT case)
The same principle applies inside product teams. New tools will not deliver much if product, design, engineering, and go-to-market are all still interpreting them through the old model. Teams need shared mental models, sharper division of labor between deterministic and probabilistic systems, and the courage to challenge the categories that make the work feel familiar. They need to stop asking how to add the new capability to the existing product and start asking what parts of the existing product existed only because the old medium demanded them.
The real winners in a paradigm shift are rarely the ones who merely deploy the new technology first.
They are the ones willing to redesign the logic of the organization around it.
Stop translating the future into the past
The promise of the new medium is not that it makes old software slightly faster.
It is that it changes the shape of the product, and if we're not careful, we'll can miss it. We'll preserve the old interaction model and decorate it with intelligence. We'll inherit old assumptions about where structure should live, how users should provide input, what the interface is for, and what kind of work the machine should do. Then they wonder why the result feels incremental.
Accidental skeuomorphism is the name for that failure.
It is what happens when we translate a new technology into the old paradigm without noticing the assumptions doing the translating. We preserve the form, miss the opportunity, and later look back at what should have been obvious.
Factory electrification did not deliver its full value until factories stopped organizing themselves as if the central steam system were still there. Early automobiles began life as horseless carriages because people could not yet see the car clearly on its own terms. Prussia was defeated at Jena and Auerstedt because it brought old assumptions to a new model of war. The lesson is the same in each case. The cost of missing a paradigm shift is not just slower adoption. It is preserving the old logic so effectively that the new technology gets trapped inside it. (David, 1989)
Old software required users to speak the language of the machine. The new medium gives us the chance to let the machine work much closer to the language of the user. If we miss that, we will miss one of the greatest opportunities for innovation of our lifetimes.