The roadmap review was a Tuesday in late January 2026. The head of product at a document management company had prepared twelve slides; the tenth was titled 'AI everywhere,' presented in the same typeface and tone as the eleven around it, as though it described a plan rather than a direction. By Q2, every major workflow in the product would surface an AI assistant. The budget for this had been allocated separately, at board level, in a session the product team had not attended. The question of what problem the AI features would solve, for which users, in which part of their working day, was not on any of the twelve slides.
We had been in that meeting before. Not the same meeting: the same meeting structure. The slide in 2015 had said 'mobile-first.' The slide in 2018 had said 'blockchain-ready.' A client in 2022 used the phrase 'cloud-native by default' to describe a platform that had been running without incident on the same AWS configuration for four years. The board-level mandate, the budget outside the product team's normal process, the quarterly deadline, the absence of a user problem the technology was selected to solve: these have been the same meeting for over a decade. Only the noun changes.
Understanding how this meeting recurs requires, I think, taking seriously the economic mechanism that produces it, rather than treating it as the result of ignorance or haste. It is not irrational. A technology achieves enough adoption in adjacent industries to generate analyst coverage. The coverage generates board anxiety. The anxiety produces a question: are we behind? That question carries a cost, because failing to answer it looks like negligence. So the company responds, not necessarily because anyone has evaluated the technology against a user need, but because responding is less costly, in the short term, than not responding. The mandate follows from the anxiety rather than from the opportunity, and it has followed from that source reliably, across multiple technology cycles, for as long as such cycles have existed.
The shape of the mobile years
The mobile-first mandate, which ran roughly from 2012 to 2016, produced three categories of outcome, distinguishable in retrospect even if not always at the time.
The first category was products genuinely transformed. These were businesses whose core user activity mapped naturally to mobile usage patterns: discrete, low-latency interactions that fitted a hand-held device. Mobile banking is the clearest example. The workflow had always been a series of short, well-defined tasks; the phone was simply the right form factor for them. Teams in this category tended to arrive at mobile-first through a user observation rather than a mandate. They asked what their users were actually trying to do, found that mobile was where they were doing it, and built accordingly. The mandate, when it arrived, confirmed a direction they had already chosen on other grounds.
The second category was products that added a mobile companion to an unchanged core. For a certain class of enterprise product, the companion was genuinely useful: expense submission, leave requests, procurement approval workflows, tasks users needed to complete occasionally and away from a desk. A simple mobile interface served that need without requiring the whole product to be reconceived. The investment was smaller than the mandate implied, the outcome was proportionate to it, and these features have mostly persisted.
The third category was products rebuilt for mobile because the mandate required it. Document editing tools optimised for touchscreens where the users had keyboards. Analytics dashboards rebuilt for small screens where the users sat at large monitors. Business intelligence products whose core user activity was multi-step configuration, not easily decomposed into the atomic interactions mobile patterns demand. These features existed for a roadmap cycle or two, generated low engagement, and were deprioritised as other demands accumulated. No formal decision was made to discontinue them; they fell out of the product through attrition. The teams that built them had answered the mandate question: they could point to mobile features. They had not answered the product question: what were the users actually trying to do, and was mobile the right place to do it?
The distribution across these three categories was not what the coverage of mobile-first suggested at the time. The first category was real, but smaller. Most products fell into the second or third, and the market could not, at the time, tell them apart. The mandate had no mechanism for making that distinction; it asked only whether the product had a mobile presence.
The blockchain mandate was faster and left less behind
The blockchain mandate of 2017 to 2019 compressed the same cycle into roughly two years and produced a sharper sorting. The products that emerged from it intact had, in most cases, a clear and specific answer to one question: why does this problem require a party who is not trusted by all participants, and why does that requirement justify the overhead of a trustless architecture?
Supply chain provenance, in the form in which it was actually deployed rather than as it was described in conference presentations, is the clearest survival: goods crossing jurisdictions, with producers, shippers, customs authorities, and buyers in different countries, none of whom shares a common registry authority. Multi-party credential verification, where an issuing institution and a verifying institution have no prior relationship and no shared root of trust, is another. These were real use cases, and the technology addressed them specifically. The teams that built them had been able to say, before writing a brief, what problem they were solving that a trusted database, governed by a named administrator, could not.
The products that did not survive were those solving a trusted-party problem with a trustless architecture. A database with write permissions and an audit log does the same job as a blockchain for a single-organisation record of internal decisions; it is cheaper, faster, and legible to more engineers. The blockchain version of that feature added overhead without adding the trustless property that justified the overhead, because there was no untrusted party in the problem. These features did not survive contact with the first budget cycle that required justification, and in retrospect they could not have: the technology had been selected before the problem was named, and the problem, when examined, did not require the technology.
The lesson from the blockchain cycle was narrow and precise. A mandate creates a feature category, 'blockchain-powered' in that case, that often precedes any articulation of why the specific property of the technology is needed. The features that survived were the ones where someone had been able to write down the problem first. The features that did not survive were the ones where the technology had been chosen before the problem was understood, and where examining the problem in retrospect revealed that a simpler solution would have served as well.
The document management case
The document management company shipped its AI features in April 2026, on the Q2 timeline the board had specified.
The first was an assistant that summarised documents as users opened them. The users of that system retrieved documents they had already reviewed; they had selected them from search results based on title, author, date, and the tags they had assigned themselves. The summary appeared between the document title and the body. It described, in three sentences, information the user had already reviewed before opening the file. Engagement with the summary panel, by October 2026, was low enough that the product team had stopped including it in weekly reporting. Nobody was surprised.
The second feature was a generative search interface that allowed natural-language queries over the library. This was more considered. The users had a genuine problem: documents in the library accumulated across years and teams, the tagging was inconsistent, and finding the most recent authoritative version of a specification or policy was genuinely difficult by keyword search alone. The generative interface helped, in a limited way, for a subset of queries. The useful subset was retrieval of recent authoritative versions; the unhelpful subset was ambiguous queries where the model's confidence exceeded its accuracy, and the user received a plausible but incorrect summary of what the most recent version said.
The feature that would have served that second use case better, had it been designed from the problem rather than from the technology, was relevance ranking at the moment of search rather than generative summary at the moment of opening. Users in the procurement workflow retrieved documents under time pressure, often looking for the most recent authoritative specification against which to validate a supplier commitment. The problem was retrieval confidence: they needed to trust that what the system returned was current and authoritative, not to receive a rephrased version of it. That feature, designed from the problem, would have used the same underlying models differently. It was not what the AI everywhere slide had described, and so it was not what had been built.
The question the mandate does not ask
What the mobile years, the blockchain mandate, and now the AI mandate share is not a technology: it is a decision sequence. The mandate creates the investment. The investment creates the feature. The feature is evaluated, if it is evaluated at all, on usage metrics that can be engineered through placement and defaults rather than through solving a user difficulty. The question that separates useful features from mandate responses is asked before any of that: what are the users trying to do that they currently cannot do, and does this technology address that specific difficulty?
The discipline of asking that question before the investment, rather than after the feature is in production and the engineers have moved on, is not new; it is as old as product management as a practice. What the mandate cycles do is create conditions where it is expensive to ask, because asking it delays a deliverable that has a board-level deadline attached to it. Teams that have navigated this well, in this cycle as in the previous ones, have tended to separate two questions that the mandate structure collapses into one. The first is whether to invest in the technology at all, which is the board question. The second is where to invest it, which is the product question. These can be answered on different timelines, by different people, and with different tools. Answering the first does not require having answered the second.
What goes wrong when this separation is not made is predictable and consistent across cycles. The feature ships because the mandate required a visible deliverable by a named date. It runs in production, used by a fraction of the users, with no mechanism to determine whether the users engaging with it are the users who most needed it or simply the users most likely to explore new interface elements. The metric for success, where one exists, is usage volume rather than task completion for the user problem the feature was supposed to address.
The objection worth taking seriously is that some mandate-driven features have become genuinely useful over time, through iteration after the mandate pressure lifted, in ways that would not have been reached without the initial investment. That happened in the mobile years: some products rebuilt for mobile under mandate discovered, through user behaviour with the new interface, that the mobile context had genuinely changed what users wanted from them. The mandate had been wrong about the specific form the feature should take, but the investment had opened a conversation with users that produced the right answer eventually. This is a real mechanism and I do not want to dismiss it. The question is whether it is reliable enough to justify treating mandate-driven investment as a sound product strategy, rather than as an occasionally fortunate outcome from a process that also produces a great deal of waste.
The question I return to is not whether AI is different from mobile or from blockchain. It is different. The underlying technology is more capable and more general; the range of tasks it can plausibly accelerate or improve is broader; the gap between the claims made for it and its genuine application is narrower than in either of the previous waves. These are real differences and they matter.
But they do not change the mandate mechanism. The board anxiety, the external budget allocation, the quarterly deadline, the feature category defined before the user problem: these are properties of the economic structure of enterprise technology adoption, not of any particular technology. They operated in 2014, in 2018, and they are operating now. The fact that AI is more capable than blockchain does not reduce the probability that features built from the mandate rather than from the user problem will fail to serve the users they were built for.
What comes through these cycles is the work built by teams that could name the problem before they named the technology. In 2014, those teams built mobile products that survived. In 2018, they built trustless systems for genuinely untrusted-party problems. In 2026, they are building AI features designed from a specific user difficulty in a specific part of a specific workflow. The document management case has not resolved. The summarisation feature is running. The board question was answered correctly: the product now has AI. The product question is still open, and the technology that could answer it is still in the product, waiting for someone to point it at the right problem.
“What comes through these cycles is the work built by teams that could name the problem before they named the technology.”