At this week’s Google I/O, Google VP of Search Elizabeth Reid announced the death of a 30 year old interaction pattern: putting in a search query and getting back a page with 10 blue links. The paradigm of scrolling, reading, and clicking has been replaced by an “interactive experience.”
The Internet’s response has been unanimous: “why?"
That question has many answers, and some of them are even true. It’s a response to users’ changing preferences. It’s a cash grab to sell more ads. It is an attempt to reverse Google’s shrinking share of the search market (which is, in no small part, their own fault).
But anyone who has ever run an ideation workshop with executives will immediately recognize the real reason. "How might we transform our product into an ✨Interactive Experience✨" is inevitably the first post-it note that goes up on the board, immediately followed by a dozen nearly identical ones.
This is a real sticky note from a real workshop. The bar is not high.
The entire purpose of the following 2-3 hours of that workshop is to move past this nothingburger of an idea, towards something actually meaningful. Google’s inability to do this represents the end of a long-running conflict between, broadly speaking, two ideologies of how products create value.
Mo’ problems, mo’ money
One side of this struggle believed that products should solve problems for users, and the less effort users spend on using the product before the problem is solved, the better. While we might associate this user-centered perspective with UX design, designers have never really been able to leverage it as a source of power. But developers did. Companies needed programmers to get working software, so programmers had leverage they could use (to a certain extent) to dictate terms against an all-powerful employer:
The picturing relation is the lever practitioners have outside the firm's interests, because it is the relation between the practitioner's claims and a reality the firm does not constitute. The firm can dissolve teams. It can lay people off. It can replace practitioners with systems that generate fluent outputs at scale. What it cannot do is make the system have different properties than it has, and it cannot easily make the systems engineers have already built behave differently than they were built to.
This side fought bravely for the past 30+ years. Google I/O 2026 marks the day that it has finally lost.
But it didn’t lose against something new. Its opponent for those decades was always the same:
In organizations where the practice's hold on picturing has already been weakened by the reshuffling cadence, by the management of engineering speech for rhetorical effect, by the celebration of fluent generation over committal claim, the AI's outputs slot into the existing weakness. The AI is fluent in the language the management framework already speaks. It can flag risks; it does not insist on them from the position of someone who will bear the consequences of being wrong. It does not have a picturing relation to defend against rhetorical pressure. It is the engineering participant capital has been trying to produce for forty years.
For this winning side, value didn’t come from users putting down the product, but only from them picking it up. The more tasks users could do in that product, the better. “Problems” came from a lack of tasks to do: “we don’t have a feature that does X”.
In other words, these were artificially created problems. And creating those problems was immensely profitable:
Each year, the Annoyance Economy costs American families at least $165 billion in wasted time and lost money—an amount greater than the GDP of 14 U.S. states.
Turning everything into an “interactive experience” is near and dear to an executive’s heart because it lets them manufacture many new problems for the user — assigning users new tasks that they must do — that they can then “solve” by giving the user new tools to do those tasks with.
Any problem caused by an LLM can be solved by an LLM
LLMs are the apotheosis of this line of thinking. In the eyes of interaction-maxxers, massive over-engineering of everything to do with both the models themselves and the slop code they produce is a feature, not a bug. The more unnecessary problems are created, the better.
Real problems have troublesome things like constraints, user needs, and success criteria that you might not meet. But when you invent the problem for yourself, then as long as your vibe code compiles, then the problem was solved. Every output is an outcome, because the outcome being sought is 10x-ing our PRs:
The salient difference here is whether an engineer has mostly spent their career solving problems created by other software, or solving problems people already had before there was any software at all.
LLMs are also really handy for making up problems that you want your users to have, and manufacturing legitimacy for those problems. A whole industry of products calling themselves “synthetic users” has popped up for this express purpose.
The notion of synthetic users has never been more discredited than today, with two proponent studies being retracted and literature reviews of what remains showing that artificial research is only good for lending believability to made-up conclusions. The closer authors are to studying people (as opposed to computers), the more they call foul on the outputs of research slop.
But synthetic user companies aren’t selling insights. They’re selling a permission structure to the “interactive experience” crowd: any problem you can imagine, we can legitimize for you.
And who can blame them? This era’s spotlight has been squarely on the problem-makers. Joseph “the father of AI” Weizenbaum clocked this problem over 50 years ago, and the rhetoric has not changed:
The structure of the typical essay on "The impact of computers on society" is as follows: …the glorious present and prospective achievements of the computer are applauded, while the dangers … are shown to be capable of being alleviated by sophisticated technological fixes… only computer science can guard the world against the admittedly hazardous fallout of applied computer technology.
Every leading company of the AI boom — the OpenAIs and Googles of this world — got to the top because they could create the biggest new problems. Those problems run the gamut from environmental costs and rising energy prices, to industry-wide layoffs, to news orgs fighting to squeeze revenue from the last remaining shreds of traffic, to a deluge of slop code and zero nines reliability across some of tech’s most critical infrastructure. We are then told that we must purchase the solution to these problems from the very people who are creating them.
Instead of delivering services and software that unlocks value for their client industries, the software industry has spent the past decade or so trying to control their customers and their client industries.
Bjarnason’s essay dives deeply into how tech companies were able to get away with this relationship to their users for so long, and why that relationship has already started to break down. Not only are American megacorps less able to keep customers locked in to their ecosystems, but even willing clients are increasingly unable to bear the dollar cost that infinite growth targets demand from them. The risky bets that Big Tech built its business model around are looking less and less like a sure thing.
Rejecting the notion that we are in a brave new world gives us permission to look at the historical record, and draw conclusions. Those conclusions are that the era of “move fast and break things” accomplished nothing worth speaking of:
There has been zero systematic progress over the past 30 years in making startups more likely to survive… The precipitous drop in seed-funded companies raising further capital does not support the idea that venture-backed startups have become more successful over the past 15 years. If anything, they seem to fail more often.
… We have spent countless hours and billions of dollars on an intellectual framework that simply does not work.
AI is the last child of the “line go up and to the right forever” era. It does not offer the industry a lifeline to escape from this decline. It is the decline from which we must escape, or be dragged under with it.
If you skipped over Garris’s and Bjarnason’s essays, I strongly recommend going back to read them — even the uncomfortable parts — and sit with their conclusions for a bit. Because what they add up to is that the “golden age” of tech was not in 2014, or even in 2005. By the time Design Thinking, Agile development, DevOps, etc came on to the scene, it was already too late: practitioners had given up the picturing relation that gave them real leverage.
Finding adequate vocabulary is part of constituting the practice as something the practitioners hold rather than something the firm rents. The recognitive practice and the we-intentional structure are how picturing becomes a sustained collective achievement. The community of practitioners is what holds the practice across the dissolution of any particular firm or any particular team.
When we talk about the “value” we deliver, we are really talking about two different things: the value of the product to the customer who will buy it, and the value of the product to the employer for whom we are making it. Understanding both of these concepts independently of one another is key to reclaiming the vocabulary we can use to leave invented problems behind.
I quote Rob Snyder a lot on the Picnic, as one of the few Sales guys whose understanding of value aligns with UX. He recently shared his entire 3-hour lecture on how demand works — why people really buy things, rather than having things thrust upon them. If you want to move your practice up the value chain, this is definitely on the syllabus.
Another useful resource comes from the prehistoric era (2008) when Kevin Kelly clocked the problem facing the knowledge economy in the LLM era: how do you charge for something when anything can be infinitely copied for cheap or even free?
And if you want to throw off the shackles of corporate employment and throw on the shackles of consultant work, Kevin Riggle has three pieces of advice for you (and none of them are “don’t do it”).
— Pavel at the Product Picnic