The discourse loves a dichotomy. Framing any disagreement as a difference of opinion between two sides, and then asking everyone to pick a camp, is intellectually convenient. It also happens to be a really bad way of actually wrapping your head around the possibilities present in the world.

This tendency manifests itself in lots of different ways, but this is a product blog, so we are going to talk about product development stuff. Specifically, how orgs learn. For which there are (of course) two main camps: the Agile way (where we build to learn); and the Waterfall way — usually defined simply as the opposite of the Agile way, because it’s less of a methodology and more of a rhetorical device. The Waterfall way of “big design up front” is implied to be practiced by some other people, outside the room. Inside the room are only innovators, who are above that kind of thing.

At least, that’s what we say. But what we actually do couldn’t be further from the truth:

This is why we are still doing Agile transformation 25 years after everyone agreed Agile was the right way to build stuff. The dichotomy between up-front definition and iteration was always wrong and trying to stamp out one tendency in service of the other will continue to fail, no matter how much AI we pour onto the problem.

The eternal quest to get BDUF for free

No amount of manifestos could suppress the simple human tendency that certainty feels good. To the people in charge of calendars, there is nothing more alluring than the idea that you can simply know the right thing to do up front, and then do that thing exactly once, never having to budget time for testing or rework.

The motivating factor for perfect up-front learning is not “doing a good job.” It’s actually exactly the same motivation that got orgs to pay lip service to Agile in the first place: spending less time before teams can start producing outputs. That Waterfall-ish desire for data up front is not in contrast to “build to learn” but another way of arriving at the same goal: permission to ship the thing we wanted to ship in the first place.

This is the world in which synthetic users are considered to be an alternative to real research; not because they are good but because they remove the friction of challenging your existing opinions. Their dismal accuracy (you’re better off flipping a coin) is besides the point, because the product being sold is not real insights. They are worse than simply having nothing, because when you have nothing then you at least know what you don’t know.

The pursuit of velocity has led many to argue passionately that the “discovery phase” should be abolished. I think that is completely the wrong lesson to draw from the industry. It’s not that up-front discovery is wrong, it’s that it’s insufficient by its lonesome. To be effective, it must work in concert with the rest of the process:

This is where synthetic insights will always fail. Because they are an excuse not to do discovery (rather than a real discovery activity) they are incongruent with the creative process. When the answer is “AI told me to,” one cannot give a compelling explanation for choosing one direction over another — at least not one that is immune to being overturned by a stakeholder telling the same AI to give a different answer.

Only a human expert — bolstered by both an understanding of the data and the confidence drawn from professional experience — can prevent this process from being perverted into going through the motions and defaulting to the thing the stakeholders wanted in the first place. Which brings us back to Strawbridge’s piece from the beginning of the issue:

Up-front certainty was always a fool’s errand, at whatever cost. To try and attain it at bargain-basement prices is not a “hack” that your competitors have yet to discover. It’s simply doubling down on the foolishness.

Prototype ≠ experiment

Ultimately, an ersatz discovery phase (either one driven by synthetic user research, or one focused on “validating” what executives already believe) gets you to the same place as not doing discovery at all: writing the code you wanted to write from the beginning. This, some people suggest, is a reason to avoid doing discovery entirely.

And I don’t just mean up-front discovery. There is an increasingly popular notion that because code is cheap now (hah!) you can simply ship whatever you want and let analytics sort the wheat from the chaff. This is, of course, a radical misunderstanding of the nature of wicked problems. Attempting to solve the problem changes the problem; without giving deliberate thought to the lifecycle of your experiments (including the clean-up) you are merely polluting your product and praying that users won’t notice.

A real experiment is not just a shipped feature that was poorly thought out by its designers. An experiment is a deliberate task that a team undertakes to learn something it does not already know. It requires a hypothesis — and “users will like it” (or worse, “stakeholders will like it”) is not a real hypothesis. And once that thing is learned, the experiment comes to an end.

Teams whose so-called experiments are launched without that arc in mind are not running experiments at all; they do not know what they are looking to learn, how the experiment will help them learn that thing, or even when that will come to pass. They cannot reverse the experiments where the hypothesis was disproven. They can only double down on experience rot.

The confounding factor is that for most orgs, this feels like it works. Things ship, middle managers are happy — and yet nothing really gets better. The simplistic notion of “this feature will make that number goes up” is ground underfoot by the complexity of socio-technical systems. The impacts of any change are inherently delayed, difficult to observe and isolate any attributable cause unless you know exactly what you are looking for.

Making your systems work for you

It’s easy to take one side or the other in this dilemma. If you favor iterative development, then there are many examples of discovery done badly to point at and say “we can’t do it that way.” But at the same time, if you are coming from the other side, it’s equally simple to point at any number of terrible products produced by teams who could not iterate their way away from their thoughtless starting point.

The argument between “up-front research” and “ongoing research” is a rhetorical trick that only serves people who care for neither. Those people come to the meeting with a quiver of excuses for why we mustn’t take any time to think before shipping the thing, and yet simultaneously can’t look back at what we’ve shipped to see if it worked because it’s time to ship the next thing.

This is the fake double diamond: substituting real divergence and convergence with artificial alignment and a synthetic sense of urgency, whipping the team ever-forward at a pace that ensures the appearance of brilliance as no decision can ever actually be revisited.

For those of us interested in actually making useful software, we can’t get rid of either up-front problem definition nor the pace-limiting effect of observing and iterating on what we have already produced. In fact, we need both of these stages — and both need to be embedded within a shared system. A system that lets us define what we want to learn before we build, so that we set ourselves up to succeed when we are looking for evidence of the ways in which actually worked (and the ways in which didn’t).

Charlie Fountaine published a short list of principles for creating prototypes that actually do something within that socio-technical system, above the banal level of screens with clickable buttons. But that prototyping loop ought to itself be grounded in an evidence-driven semantic environment. Rachel Coldicutt sets out a good overview of such a system here.

Anyone who thinks that AI can replace the need for conceptual clarity at the level of these two documents is trying to sell you something.

— Pavel at the Product Picnic

I’m going to kick off this issue by going back to my favorite piece, which I’ve cited on here before — a 1985 interview with Joseph Weizenbaum (the father of the chatbot and a pioneer of commercial computing systems). I love this interview precisely because — in stark contrast to today’s crop of programmers — Weizenbaum still remembers that making the computer do a thing is merely a step in creating value, and it is neither the first step nor the most important one.

The productization of thoughtfulness

It is a great irony that 41 years later, it is precisely chatbots that have turned this sober perspective on its head. It has never been easier to fool yourself that extruding a “functional” prototype is the same as building a valuable product, and that everything else between you and wealth is just a sales problem.

But it would be a mistake to call this an AI-era phenomenon. The industry spent decades cultivating fertile ground in which today’s prototype mania could take root. Corporations carefully peeled the things they wanted (methods for making software widgets) away from the humanist context in which those methods were originally born, and stamped their own brand on each one. Instead of design, research, and thinking, there is only product design, product research, product thinking. And now, there is not even that; one only has to take a look at their LinkedIn feed’s many self-appointed “AI product managers” and “AI-native designers” who spend all their time pretending they invented “build to learn” yesterday.

There are few bigger cliches in the industry than complaining about the crass commercialization of craft. But the priorities of the computer people are hardly being overridden by the iron law of the profit motive! There has never been a more money-losing technology than the large language model, and yet it is aimed mainly at creating business problems rather than solving them:

AI boosters acknowledge this problem only in passing: it is early days, today’s more powerful models are larger than yesterday’s, so if we keep making the models larger, eventually they will get so powerful that all the problems will become solved, somehow. Possibly by creating AGI (or is it ASI now?). And perhaps some companies think this already exists, because we are now seeing models have unprecedented access to internal systems. Meta’s much-hyped Muse, for example, can see its own file system, and (because it’s an “everything app” and guardrails are more of a suggestion) will happily dump that file system for any user who asks. Multiple people have now combed through the code and there are some very funny moments there, so check it out.

Nevertheless, the mystique of Artificial Very Special Boy Intelligence has accomplished one thing: to allow OpenAI and Anthropic (and now Google) to get away with admitting that they are literally doing cybercrime every day and leverage that into an argument for reduced regulation rather than simply go to jail:

To be normal about LLMs, we must be able to be normal about computers

No one I know is excited about the incoming GPT-6, possibly because they have things like “a memory” that allow them to compare the hype around previous model releases to what was actually delivered, and how quickly Sam Altman turned around from “this one is the one” to “this one is crap, actually, and the next one will be the one.” Instead, the real eggheads are stoked for something called Jev, which has achieved the ground-breaking intellectual leap of using normal technology we already had to do things cheaply and reliably like we always could.

New larger models are only driving up the total cost of inference, in exchange for diminishing returns. But the frontier of “what if LLMs were just normal technology and could be combined with other normal technology” remains pretty much unexplored, because developers are blinded by the hype of AI as a special thing rather than just another SaaS product. But SaaS itself has been in a slump — indeed, has been relying on AI as the last hypergrowth opportunity — because it has reached exactly the same frontier: everyone involved has forgotten that computers are just a normal medium:

Waking up from the dream that “computer” is a special class of thing may just be the breakthrough that we need to unwind four decades of decay and embrace the perspective that was so obvious to Weizenbaum: the actual product is not digital, and value does not originate in bits. In light of that, this guidance for business people looking to commission some software is extremely clear-headed: it buttresses the obligatory “you can use AI to prototype” in between “you must first define the business logic that you need” and “you can’t just hand over the AI’s prototype to a dev and ask them to ‘build this.’”

Normal technology is an empowering force

Some readers may remember an earlier era’s (valiant but ultimately failed) attempt to wake computer people up from the Web’s doom spiral: the motherfucking website (which was down for a decade, but is now back). Its banner has been picked up by the modern motherfucking website, a is a nice reminder that tech has not actually stood still all those years, and that the modern stuff is actually possible to incorporate into your code without bloating it with a million calories of Javaslop.

via Andy Bell

But the project I’m personally keeping an eye on — one that is truer to the vision at the top of this article than anything else I’ve seen — is Bianca Wylie’s Less Computer, a series of strategies aimed at decentering computers from our decision-making. This piece is my favorite (so far):

Reading through the piece brought back a memory, or perhaps a mosaic of many identical memories: a design workshop with a sentence that starts with “how might we…” and inevitably ends with “…using the power of generative AI?”

Do the difficult thing, and cut that last part off. Baking a solution into your vision statement will never serve you, in the end.

— Pavel at the Product Picnic

The discourse around LLMs is so focused on the future — what models will be able to do, with enough dollars or megawatts or datasets — that it can be easy to overlook their past. But original-flavor ChatGPT is already turning four years old in November! It’s even been nearly a year since Anthropic’s hype supernova around Claude Code eclipsed OpenAI in the public eye. You hear “I asked ChatGPT” less and less often, and “Claude said…” more and more.

This does not necessarily have anything to do with the quality of one product over another. Instead, Claude has gained popularity because it’s easier for users to anthropomorphize something with a human name.

Anthropic has leaned into that tendency with its entire might, and anyone who wants to think clearly about these things needs to push back against language that incorrectly grants the machine personhood and agency. Getting into the habit of writing is actually a fantastic antidote:

But unfortunately, framing Claude as a colleague instead of as a computer program has broader consequences than tired debates about whether language models are “alive.”

From workslop to warslop

In the distant past (the year 2022), when someone handed you a document, you could trust its contents to be accurate. Or at least, you could estimate its accuracy based on how much you trusted that person. It was more or less safe to use that doc as an input into your own work, because the accountability lay with a real human being. And if something in the doc didn’t make sense, you could call them up and ask.

Today, you are likely to hear back: “I don't know, Claude wrote it.” What appears to be a confident statement of fact made by a professional is unmasked as a work of fiction with the least bit of pressure — but critically, not any sooner, meaning that information could go through multiple rounds of hand-offs before anyone bothered to ask if any of it is real.

CEOs who were bullish on AI as recently as earlier this year are now calling out the damage that “slop grenades” have done to their businesses. The blast radius of thoughtless human-laundering creates hours of rework for everyone on the receiving end, and the scale of the effect is only increasing with time. In a way, this is like the “10x engineer” of yesteryear: every person who feels like they are more productive because of AI only does so because they can shift the consequences of cutting corners onto someone else.

The most extreme example of this comes to us from the United States military, where an analyst generating a report with AI did not bother to check whether the claim of nuclear materials on a Chinese ship bound for Iran was actually true (and possibly did not even read that the report said that before hitting “send”). Naval commanders in the Middle East had no way of knowing what parts of the reports they received were essentially made up, and were much further removed from the actual data than the person who decided not to do their job.

This time, things worked out. But what about next time?

LLMs obscure the provenance of agency

When one considers Claude.dmg (a program file on your computer) to be a colleague, it’s easy to think of its workings as a black box, and interrupt any critical thinking process that might be taking place. “Yeah, Claude came up with that. I don’t know why. It’s pretty smart though, so I’m sure this is correct.” We see this anthropomorphization happening in the headlines about OpenAI hacking Hugging Face (with Anthropic and Google chiming in to say that their models also hacked other companies, and are just as super cool and powerful and dangerous as GPT-6).

Eryk Salvaggio calls this the “system from nowhere”:

An LLM does not have agency. Full stop. But this does not mean that it is “just” a tool that’ll do exactly what you ask, and no more. Like any tool, LLMs are designed to behave in a particular way and do a particular thing. And like any other tool, some of the ways they change user behavior are intentional and some are not.

Consider for example the frontier labs’ desperation for training data, leading them to hoover up sources like Russian disinfo, Iranian propaganda, or any old thing someone decided to post on Reddit. The provenance of this data is conveniently erased; it is laundered by the model & spit out at users, producing measurable shifts in attitudes and beliefs.

It is no surprise that using AI as a “writing assistant” ends up completely changing what users were trying to say — even when explicitly prompted not to do that:

More habitual LLM users are already asking Claude to tell me that you can simply engineer your prompt in such a way that you get only good responses instead of bad ones. Except there’s absolutely no guarantee that the prompt you enter is the prompt the model actually receives; the practice of shadow prompting is as old as LLM products themselves.

Branding Claude as a colleague and even collaborator neatly obscures these issues. But as soon as we buy into the idea that a model acts independently of — or even contrary to — its manufacturer’s wishes, as soon as we start to believe “Rogue AI” is real, we immediately absolve that manufacturer of the harms they use their own, human agency to cause.

The “black box” is load-bearing for AI industry narratives

In recent years, the rhetoric has shifted from attributing agency to individual models, to attributing agency to the idea of AI itself. “AI is coming, AI is dangerous” is a neat rhetorical device that once again redirects responsibility from the companies building the AI to some intangible notion of a unified artificial intelligence. To listen to AI boosters speak, it is a force of nature that mere humans cannot hope to understand.

The result of this branding is a sort of fatalism disguised as optimism: it’s happening, so you might as well get on board. You don’t want to be caught unarmed when your colleagues start slinging slop grenades in your direction. You don’t want to be the solitary fool trying to hold back the “wave of AI”:

But if we were able to think of AI tools as products, ordinary systems built by people, we start to see that nothing about the choices those people are making on our behalf is inevitable. We can always make different choices about how transformers are productized, and how we change our own conduct to accommodate those products’ intrusion into our lives. We can always set the boundaries of those spaces where we are willing to entertain this technology, and spaces where incursions of AI can (or even must) be weeded out.

This starts with thoughtfully reflecting on what impact AI is actually having on your practice, rather than what the industry is telling you ought to be happening. Are you actually more productive? Are you getting to spend more of your time on higher-leverage tasks — and is that leverage reflecting in customer outcomes? Or are the tools leading you away from the necessary work?

Nothing is inevitable. The predictions we made about the future hardly ever come to pass; wondering what will happen is another way of folding your arms and doing nothing. Instead, look around, and ask yourself: is this what I want to happen next? And if not — what is?

— Pavel at the Product Picnic

For those of you keeping track, this was the first time the Picnic has had a two-week hiatus. There were a bunch of reasons for it, chief among them being that it was the Labor Day holiday and I was in Canada taking photos of herons. But also, I didn’t really want to write the issue, because it’s about AI and I’m tired of talking about AI.

Ironically, this would have been the perfect time to spin up Chatty G (to borrow Candi Williams’ name for the thing) and ask it to extrude 800-1000 words based on my draft. Hell, if I did that, I could probably send out a Picnic every day instead of every week.

But what would be the point? Almost every other website is already written in that hauntingly uncanny voice that is instantly recognizable as AI.

“Uncanny” is, in fact, the technically accurate term. Naomi Saphra goes into detail on how AI-generated text (I will never call it “writing”) has dragged all electronically mediated interfaces down into the uncanny valley. The companies who produce our software claim they are making things easier and more intuitive, and then go on to slap on a massive cognitive load onto every user: the subconscious work of figuring out if the service experience you are having is real or not.

The cognitive load of the scam economy

That hypervigilance is warranted: AI is best at scaling up scams, so now scams proliferate, often indistinguishable from ordinary publishers caving to the pressure of feeding the algorithm with “optimized” AI-generated slop. Everything we touch on the internet now has the dubious, sticky texture of a scam. Authors are being overwhelmed by waves of book club scams. Colleges are swamped with fake students farming financial aid. The same people who are funding frontier labs are pouring money into services that flood social media with spam. Job applicants are having their personal information stolen by entire phantom companies, via simulated Slack instances — and recruiters have to dig through piles of fake resumes that have never been easier for unscrupulous candidates to produce.

Human-to-human interactions are not safe, either. Even healthcare professionals (who should honestly know better) are hiding their AI use from patients, resulting in made-up referrals and incorrect prescriptions.

Over 50 years ago, Herb Simon described an attention economy — the world evolving from a system in which information was the bottleneck to one where an information surplus overwhelmed human capacity to process it. For Simon, the new bottleneck became the amount of things to which we could devote our attention. But Simon could not predict that some of that information would go from merely irrelevant (low value) to adversarial (negative value). In a scam economy, a constant, low-level anxiety pervades our daily lives: is the thing I’m engaging with real? Or is it a phantom, a facsimile, even an antagonist? Count the fingers, count the teeth.

Wang mentions a suite of AI detection tools, now rising in popularity as people rebel against being fooled. In Europe, disclosure of AI use is now a legal requirement. Some companies (Libby, for instance) are even kind enough to build those filters directly into the product for worldwide users.

Others fumble the ball completely, because their business model depends on slop pipelines; consider SurveyMonkey telling survey-takers that their submission is slop so LLM-powered bots can take a mulligan, or Grammarly laundering its own AI generated content as human. Social media sites, naturally, refuse to let you filter out AI posts, even if they are the ones providing users with tools for extruding post-like content, because they can shift more ad inventory this way.

Your design thinking has been incepted

At this point, it almost doesn’t matter whether the slop we read is AI-generated. That soulless, shiny plastic cadence comes from somewhere, after all: reams of training data, chiefly from placed like LinkedIn, that some hapless data scientist tagged as examples of good writing. Now that style is being fed back into the ecosystem, reinforcing a monoculture we all hate and yet feel obliged to participate in.

And this is why I dragged you through 1000 words on the harms done by slop. These harms don’t only exist in an abstract “out there” that we engage with after 5pm on weekdays. They do also exist there, and make those hours far more tedious than they need to be. But the more you read the not-quite-human content, the more you internalize it. And the more it begins to eat away at your own writing, and your own thinking.

To get a little LinkedIn for a moment: consuming slop trains you to write slop, and so it directly undermines your value to your employer and your competitiveness in the job market. The bread and butter of software companies is knowledge work; if cognitive diversity is its only competitive advantage, why would they want a worker with a commoditized thought process?

One of the most common pieces of advice I give to people trying to express themselves in natural, human-sounding ways is to explain to me what it is they want to say, and then just write that down. This is not, however, advice that I often take myself. So it was refreshing to hear it directed at me for once, in a touching essay by Mike Monteiro about the importance of writing using your own brain. Even if it’s hard. In fact, because it’s hard.

This piece was going to be a lot longer, so tune in next week for part 2 about the extent to which reliance on LLMs replaces your thinking with someone else’s thinking (and, if it’s not already obvious, why that is a bad thing).

— Pavel at the Product Picnic

Time-sensitive item up front: Cameron Tonkinwise, whom I quote incessantly on the Picnic, is doing a talk about Design Futures at the University of Technology Sydney with Lucy Kimbell. You can sign up to attend live (all 5 of my Australian readers; say hi to each other in the comments!) or to download the recording after the session runs.

There is a vicious cycle in Product that I’ve written about before: we all hate meetings, because our meetings are poorly designed. But instead of designing the meetings to be better, we go all-in on a culture of handoffs. Then when our vision reaches production in a mangled and unrecognizable state, we end up having those meetings anyway, and they are all the more painful for being put off for so long.

Designers are the most guilty of this, but I’ve worked with many PMs who throw a Jira ticket over the fence and expect their vision to materialize in working code sometime within the next two weeks.

You can see how, in an environment where people don’t know how to talk to each other, LLMs feel like liberation. Suddenly you don’t have to fix the thorny problem of working together with other humans. You can pretend that you are the expert on every part of your business, and replace everyone else with an app that your company pays for (at least for now). Said app will give you such quick and confident (but not necessarily correct) answers that it will start to feel like asking humans is now obsolete.

Meetings are the only real influence we have

But don’t get too comfortable. Studies show that this magical feeling drives us further into isolated modes of working — and as we do so, we give away any influence we might have had over how work actually gets done.

Wylie’s piece collects several articles (by Elizabeth Ayer, Kevin Baker, and Marc De Pape) that are themselves worth reading. The picture that Wylie paints by bringing these sources together is one that will feel very familiar to us all: automation obscures the logic behind business processes by making it appear to be beyond reproach. A signal that efficiently passes through a company towards its designated recipient without mediation is a signal that cannot be questioned in any meaningful way by the workers who carry it out.

And unlike prior kinds of automation, AI automates the driver rather than the carriage — we are still doing the same tasks as before, but now you are responsible for how the robot “decides” to execute them. In a “human in the loop” system designed to prioritize efficiency, the human is always going to be brought in only after the AI has already made a mess of things:

As a result, our ability to control what is done in our name continues to shrink, while the scope for which we are accountable continues to expand.

Making meetings work is work

Meta’s AI org was staging a maximalist experiment in whether this could all really work: a system where AI-powered managers can handle many more direct reports, where meetings are cut down in favor of a widget throughput vision of productivity. I say “was” because it was a well-publicized disaster, and the company has already committed to rolling it back.

But more modest versions of this experiment (a low simmer compared to Meta’s rolling boil) are now taking over all knowledge work. The hyperfocus on the individualistic mode of productivity is leaving workers depressed, because it turns out that interacting with other humans was what made the work meaningful — to an identity-forming degree that we are now struggling to replace.

So why do we keep running these experiments? Perhaps because we collectively decided that beacuse meetings don’t work, they can’t work. After all, even masterfully-facilitated workshops by professionals at the top of their game end up going nowhere. And usually, this is because their conclusions are rejected by widget-mode incentive structures that rule the broader organization:

A good meeting (remember: a workshop is just a meeting with rules) facilitates more than just the action. Its success also requires social alignment and internal synthesis, which that take place outside of the official agenda (and even outside of the calendar block).

If we want to have a real say in the future of work, this is what we need to be thinking about: how do we come together, and how must the outcomes of that collaboration continue to resonate once we are apart?

— Pavel at the Product Picnic

Cost is one of the most basic concepts of systems thinking. No outcome — no matter how desirable — can be divorced from the cost of its attainment.

UX designers most often come across this idea when it is weaponized against them in the industry’s oldest bad-faith question: “what is the ROI of UX?” It is a bad question for many reasons. One of the reasons it’s bad is that it’s an incomplete thought: what is the ROI of UX…compared to what? The choice is not between UX and nothing, but between UX and other things that cost money, time, and attention.

In finance, this is called alpha: a measure of how much your portfolio outperformed a standard index fund. In plain old decision-making, we call it opportunity cost. The real cost of a decision is the loss of the roads not taken, and the beneficial outcomes of all the options that are now closed to you.

Opportunity cost is the real constraint on product decisions

The same logic applies to product work itself, except instead of investing dollars, tech orgs invest story points and person-hours. It’s easy to come up with a feature that makes money or makes users happy. The real job is to come up with a feature that makes more money (or makes users more happy) than the best available alternative. In a functional, mature organization, defining what “best” means (and how to measure it) is the value that UX design provides.

Unfortunately, design work was never rationalized to make it legible to the business. The exploratory work to define the possibility space (from which we may then make informed decisions about investments) is illegible to businesses. Bean counters can’t process that we chose the top 1% of ideas, but they can see that 99% of our ideas never got shipped, and so the business perceives design work solely as waste.

The thing that is most legible to the business is features. The thing that is least legible is the quality of the user experience. So it comes as no surprise that businesses erroneously believe adding more features automatically results in an improved user experience.

This is where I think Merholz’s thesis could go even broader: it is not only the work of UX that is illegible to an organization. The work of prioritization as a whole — the politics, coordination, experimentation behind choosing an org-wide direction and sticking to it — comes across simply as a distraction from the Fordist metric of how many work-units were delivered into customers’ hands. Delivery now occurs (and is demanded to occur) at such breakneck speeds that it can outpace any rationality:

Opportunity cost is illegible to an organization that thinks this way. It can’t understand choosing between doing A and doing B. The only comparison it can draw is between doing something and not doing that thing. And doing something is obviously better. Why have 99 features when you could have 100? Why settle for 1000 linear meters of software when you can have 2000 linear meters?

Overproduction of software

Prior to 2023, managers had to face reality that they could never outrun opportunity cost. Things would always take time to build. However begrudgingly, they were forced to prioritize some features over others. Comparing features to one another inherently required a common understanding of user needs, against which the relative impact of each option could be judged. Skipping that work was seen as an abdication of responsibility, rather than a flex.

But that era is over. We are now in a new era that is defined by a single belief: AI will somehow reduce the cost of delivery to zero, and therefore we will never have to prioritize features or think about their fitness-for-purpose ever again.

This line of thinking has a load-bearing axiom: that all problems stem from not having enough software and therefore may be solved by adding more software. In reality, we face precisely the opposite problem: the system we created overproduces software (part 1, part 2). Every additional story point of velocity is likely to produce net-negative ROI.

The silver lining on this particular cloud is that, in theory, high delivery velocity can be used for iteration (through the mythical build-measure-learn loop that many product managers talk about but few manage to practice in real life).

Unfortunately, the same systemic factors that prevented teams from iterating on features in 2016 are going to be preventing teams from iterating on features in 2026. When the only thing legible to your leadership is the number of features shipped, the opportunity cost of every iteration is staggering: you are forced to choose between doing a good job, and doing the thing that is rewarded. Science shows that even when “powered by generative AI”, people choose the latter:

The illegibility of quality is not inevitable

Today, even teams that want to iterate are doomed by this problem of legibility.

Rob Whelan has a great example of this in practice: the frustration of customers who just want to order lunch but must bear the burden of installing an app and creating an account is completely invisible to the business responsible for said app. Only clicks are visible, so more clicks means we are doing a better job. Thus, the system that produced the app is set up in such a way that it can never reach the obvious conclusion: the experience was better without the app.

Can iteration be saved through the application of AI? To answer that question, look no further than Steve Yegge himself. As the author of the original Gastown piece, Yegge is perhaps the ultimate standard-bearer of the AI era. He has now admitted that Gastown didn’t exactly work out — admitted it in a new manifesto for a town with even more gas. The proof of concept for this new approach to building software (which is just Gastown but with $87,000 worth of tokens blown every month on iteration) is the worst MMORPG you’ve ever seen, with the player base peaking at five concurrent players. The only way to have fun with it is to read Jonny Saunders’ scathing analysis of all the ways Yegge’s output falls short of his astronomical claims.

This infinite vortex of garbage is not, as Yegge claims, the shape of things to come. In fact, we are seeing a broad, societal-level rejection of such “inevitability”. AI, after all, is only the latest in a series of technologies that undermine the agency of their users. Yesterday, we still believed that these technologies will also be our future. Today, we are waking up to the fact that we still have a choice in the matter.

— Pavel at the Product Picnic

A long time ago, you might have heard from Jared Spool that everyone is a designer. But over 5 years before that bombshell, Ian Bogost put forward an even more maximalist thesis: everyone is everything. We are all hyperemployed; in addition to our official job, technology has heaped on countless minor tasks that we are obligated to perform to Get Things Done (a similar thesis was explored in book-length format 30 years prior to that by Ruth Schwartz Cowan in More Work For Mother, which has never been more relevant).

Silvio Lorusso’s piece on the history of design’s collision with Web 2.0 made that explicit connection, and then some:

Enabling this ruinous democratization of design was the notion of the template. It’s not that anyone could now do design; merely that everyone was now expected to fiddle around the edges of an artifact that was already designed by someone else.

I love Lorusso’s essay, and I think everyone in the business of user-facing software development should read it. I especially like the equivalence made between design and sending emails. Because, as you might have heard, there is now a machine that can generate “a design” as easily as an email. A machine that ingested millions of “designs” and billions of emails and turned them all into one big template that it can fill out for you. A machine that had no equivalent in 2017, when that essay was written, and is now everywhere.

Writing email is an art

But people have been noticing that while an LLM can send an email, it is not at all capable of doing it well. And the frustration with workslop has only intensified over the past year. We have long been begging our colleagues to give us their own thoughts in their own words instead of sharing the output of a chatbot that we could prompt just as easily as they did (if that output was what we wanted).

I’ve written about workslop on the Picnic before. Heck, I’ve also written about templates. Twice, even — once specifically about the templatization of design, and once about the templatization of thinking in general.

The insidious thing about templates is that they are frictionless to use. 99% of the work has already been done for you; you do little more than sign your name and then send it off into the world. But each email authored this way is a burden on the person (or people!) who must read it using their human brain and their human time. It is a gesture of profound disrespect. One may go as far as calling it cognitive littering.

An effective message is not formed by unidirectional template-slinging. It is a social process of telling your story and then hearing it told back to you to learn what was understood.

Unfortunately, we live in a world where everyone is an email writer, and the baseline quality of email writing is predictably atrocious. Who will notice if you phone it in and ask Gemini to generate the email that your boss is making you write? (I will, and your colleagues will, and we will make fun of you in the group chat).

But it gets worse.

Taking notes is also an art

You might have seen the term “world model” bouncing around. It’s a weighty-sounding phrase for a simple concept: executives don’t know what is going on, so they want to upload every scrap of data from the company into an LLM, and then ask it. This job used to be filled by a highly paid manager who pasted screenshots of dashboards into a PPT and took credit for the numbers, but now it seems AI is taking their jobs away.

This use case produces the greatest template of all: a template not for a generic report that reads the same as every other report, and not even a generic website that looks like every other website, but a simulacrum of a company that runs like every other company (which kills your margins because it makes your product a commodity).

Anyway, the world model won’t do anything for the same reason that a parade of Gannt charts didn’t do anything: boiling everything down into a big vat of stuff destroyed the context that made any of that stuff meaningful. It’s actually even worse now, because at least those charts were based on something real happening. In a world of LLM-generated documents, scraping everything indiscriminately will produce a thin broth that contains no real understanding.

Even if you write down (or, let’s face it, have an AI transcribe) a meeting or an interview into a document¹ , knowledge does not automatically come along with that text. Knowledge is something that is produced in your brain as you transcribe the text, because transcription is an act of metacognition. It is synthesis. It is thinking.

Doing that thinking made you valuable, because you had insights no one else did. You were the only one with the entire corpus in your flesh-and-blood “context window” that we used to call institutional knowledge, and stitched it together with an agentic workflow we used to call “expertise” (the very expertise, by the way, that you need in order to check the output… you are checking the output, aren’t you?).

Pick up your cognitive trash

Maybe the AI aesthetic was cool, for a brief moment in time. The images felt novel. The writing may have seemed crisp and professional. But it’s not the early days of AI anymore; everyone can recognize it and everyone is tired of it.

There is even nostalgia for a moment that was not so long ago, which everyone complained about at the time:

c/o Jia Liu on Discord

Businesses are now going out of their way to prove they have nothing to do with AI. Some are even investing into painstaking analog methods; it would be trivial to generate a Stable Diffusion equivalent, but that is sort of the point. Even LinkedIn, which has a “generate slop” button right on its home page now has a second button to report when you see someone else posting slop.

Everyone has seen enough of this stuff to tell the difference between the genuine article and a synthetic imitation. And if you can’t, it doesn’t actually mean that you are somehow just that good at prompting.

— Pavel at the Product Picnic

The unfortunate implication of running a newsletter is that the content has to be at least news-adjacent. And sadly, the articles making the news are centered on LLMs — which I am tired of writing about, and you are probably tired of reading about.

For those of us familiar with pace layers, language models (or as they are called in marketing lingo, artificial intelligence) manifest solidly in the “fashion” layer. AI is used because it feels cool; it is the sports car of productized technologies. The underlying tech may be ”here to stay” but as soon as it falls out of vogue, it will “stay” in users’ garages, because trotting it out would be less of a status symbol and more of an embarrassment.

Execs are all-in on AI justifying their poor choices

Five separate people, unprompted, have sent me this excellent essay on how the present-day coolness of AI has captured executives in an AI prisoner’s dilemma in the past week. The entire essay is worth your time; honestly, if you are pressed for time, I would click on no other link in this issue and re-read this one twice. Nikhil’s piece nails the current crisis of decision-making perfectly: regardless of what you think about AI, you cannot argue that it is a novel technology, and is therefore subject to all the concomitant risks on top of the ordinary risks of any software project.

Many industry leaders (misled by the sports car aura of LLM tech) have forgotten that AI is, after all, just ordinary software. Last week, the first automated reasoning program celebrated its 70th birthday. Bragging about your AI-native org is about as impressive as bragging about a transistor radio native org. Or a Xerox photocopier native org. In other words: you were already behind, you were always behind, and any commercial wins you have achieved in the meantime have been despite your technological maturity rather than because of it. This is worth thinking about, but I’m not going to do it for free.

So how do you run a software project effectively? What a coincidence that you should ask! I had just this conversation with Jason Knight on his podcast the other day.

AI Can Build the Solution... You Still Have to Design the Problem (with Pavel Samsonov)

AI Can Build the Solution... You Still Have to Design the Problem (with Pavel Samsonov, Principal Experience Designer & Author of Product Picnic)

Jason Knight @ One Knight in Product

If you don’t want to take my qualitative findings as data, Peter Merholz has some quant-based insights for you: only execs are excited about AI, and everyone else is already exhausted by the hype — because it does not match up to reality.

Execs are abdicating their responsibility because “AI can fix it”

As far as executives are concerned, one of the major draws of AI has always been exculpation. Whatever they have provided (or failed to provide) to their employees no longer matters; AI is pitched as a great reset that is meant to wipe away all other material conditions. Part of the all-permeating hype of the AI industry is that every org is just full of ideas ready to burst forth and LLMs are the mechanism that will somehow effortlessly unlock them.

To any experienced professional, this concept should be laughable on its face. It is self-evidently not true. And yet it continues to echo in AI marketing, possibly because that is the only way this trillion-dollar bubble can continue to justify itself.

Cory Doctorow has a deep dive on why the core value proposition of AI (increasing throughput by maximizing productivity) is fundamentally flawed: that formulation has only ever been a top-down mandate, and top-down mandates always result in a degradation of quality. This is because computer applications do not eliminate work; rather, they transfer it from managers (who buy the products) to their reports.

(As an aside to myself: Dean Peters’s comment reminds me to do a piece sometime on the value of speculative fiction to product management practice.)

This issue doesn’t have a neat conclusion where I tell you how things are getting better. The trends we see today will continue until organizations feel like stoking the AI boiler burns more fuel than it is worth. In the meantime, the most important work you can do may be to look after yourself, and manage your own burnout.

— Pavel at the Product Picnic

Howdy, picnickers! Now that the Northeast is no longer inundated with wildfire smoke, it’s time to head out again and touch grass.

First off, announcements: catch me live this Friday (July 24, 2026) on Dan Hon’s sensational internet show How People Work (sign up here). If you think I have no filter on the socials, just wait until I’m on air. Come tune in, it’ll be great.

How People Work, Live (with Pavel Samsonov)

How People Work, Live! is based on Dan Hon's How People Work workshop: a free, candid, ad-hoc series of gatherings on Zoom where we chat about what it takes to build software together.

Calendly

Now, onto the main feature.

The ham biscuit sign approach to design

I love analogous domain case studies. Sadly, the term is underused to the point that searching for it gets you some electrical nonsense. Fortunately — before you reach for a chatbot to explain it to you — there’s a paper for that. Unfortunately, the paper itself is from an analogous domain (in this case, whatever biomemetics is). But the idea is quite straightforward: you go look at what related fields are doing and then steal their ideas.

Software engineering (not to be confused with programming) is one of my favorite analogous domains to mine. Game design is another. But once you get off the computer, the world really opens up, because the real world is where service design lives, and almost everything is service design.

Which brings me to what you’ve been waiting for three paragraphs: the ham biscuit sign (specifically: Eric Bailey’s excellent write-up of what this is, what need it solves, and why this elegantly simple solution actually presents a myriad new problems for customers who are ravenous for a ham biscuit).

To me, the ham biscuit sign perfectly encapsulates how design is actually done in almost every organization. Someone (a non-design stakeholder) notices a problem. They draft up a solution and send it off to be implemented. The feature makes it into production (here: the ham biscuit sign is electrified) and the problem is therefore solved. Then the first actual designer to encounter the feature comes up with a dozen different ways it’s a bad solution — but it’s too late. The stakeholder pushed their requirements through faster than anyone who knew what they were doing could catch them.

Now, let’s go back to our own domain (software design) where everyone is now required to create as many ham biscuit signs as possible, as quickly as possible, on pain of layoff.

Now you can generate more ham biscuit signs than ever, faster than ever before

To be fair to AI, this problem has always been with us. Role responsibilities got sorted neatly into “coming up with ideas” and “executing the ideas.” This split insulated the idea-havers from any consequences of what they were doing; they could be judged solely on how novel and creative their ideas were, and leave little details like “does it actually solve the problem” or “is solving this problem even important” for the production-oriented silo downstream of them to sort out.

And sure, coming up with ideas is not easy — especially if your strategy for ideation is to stare at an empty Google Doc and think really hard. Because without being exposed to real user needs, the only place those ideas can come from is other software you’ve used. Predictably, the ideas “generated” this way are extremely boring: we will add “end of year” to our product (not because it makes sense, but because Spotify did it); we will add an FAQ page to our product (not because it makes sense — the FAQ format is just a dodge from doing real IA work — but because other websites have it); we will add dark mode (solely because Discord has it); we will add a task counter to your everyday life (solely because Jira has it).

In an effort to rationalize this, someone inevitably says “we are jamming pointless features into the product because a long feature checklist makes it easier to sell.” Which sounds neat, but is not actually true. Sales work is a narrative and every random widget Product adds makes it harder for that narrative to be coherent. The secret to selling well is to minimize the number of things you talk about:

AI’s role in all this should now be obvious: by now, every feature from every public-facing repo has been scraped into your model’s training dataset. Getting it to regurgitate the code is therefore a trivial exercise; far easier than doing the work of determining whether the feature is necessary or not.

So let us strike at the heart of the problem: that despite the appearance of completeness, the user stories being assigned for development are in fact without substance, filled with weasel terms like “users want to manage XYZ” that do not explain the expected user behavior, or its business value, in any meaningful sense. The necessity of these individual features may even be “validated” by asking users “do you want this feature?”

Taking down the ham biscuit sign

The title of Robin-Yann’s article sort of gives away the game here: the solution to the ham biscuit signs in your product is to think about them from a holistic point of view. Not as individual touchpoints (encountered by users who, thanks to the user story format, come pre-defined as wanting to use them) but as stages of a workflow. This is exactly what Eric does with the original ham biscuit sign in his own article, by the way: position it as a step in the user’s journey towards the ham biscuit, which enables him to think about how it is helping, and how it might actually be harming.

But frankly, the first step is not “think per workflow.” It is really just “think.” And the main cause of the ham biscuit sign is that no one did think. A stakeholder asked for “a design” (noun) without design (verb). And that is what they got.

AI, of course, is a tool for not-thinking. But there is a useful set of tools for thinking specifically about workflows that designers have come up with over the years.

First of all, the much-maligned JTBD, as it turns out, is much more than the tired “when X I want to Y” phrase. There’s a whole toolkit (actually there are many, with various organizations) that you can easily wedge into your team’s process if they are already using the phrase in Jira tickets.

To focus on key workflows rather than “wouldn’t it be cool if…” features, there’s Duncan Stephen’s very accessible write-up for how to employ the top tasks method.

And finally, a useful filter for your most critical failure cases; the ones that don’t appear in any “happy path” demo but are nevertheless something real users experience every day. Failure cases are especially interesting to me as a designer, because no features can get you out of a situation that broken features got you into in the first place. The resolution requires excellent content instead (and Amy Hupe has some tips for good error message design over on the Picalilli blog).

— Pavel at the Product Picnic

Welcome back, picnickers, to what is shaping up to be a loosely connected series of posts. Last week we talked about how tech weaponizes empathy language to insulate decision-makers from users. But I’ve come across a few more articles since then that helped something click inside my head.

The reason empathy has failed to produce better user experiences is the same reason that a decade of “delight” has only made apps more frustrating. Respect is entirely missing from this equation. And empathy without respect is nothing more than pity.

The lack of respect permeates every layer of this system, but it starts with us. Designers’ passion for helping users can quickly curdle into a messiah complex: a belief that we are the only ones who can help users. In this worldview, the users themselves are helplessly waiting for our genius to help them. Our colleagues cannot be user-centered because they are not designers. Even other designers become reduced to hangers-on following our unique, individual brilliance:

Our systems do not respect the user by design

I try to avoid quoting articles more than once on the Picnic. There are enough links in here as is. But there are pieces I come back to, because of how rich they are with meaning. The Turing Complete User is one such article. It traces the journey of a well-meaning idea across over forty years of evolution from “computer users are busy and their time is valuable” to “computer users are stupid and must be sheltered from complexity.”

The problem is that friction is inextricable from control. Being exposed to the complexity was the only thing that gave users agency for how to deal with it. The “automagical” computer championed by the likes of Jobs and Norman is frictionless but also texture-less; there is nothing to grab on to, no way to steer it.

Which is fine (sometimes) as long as it’s working. But nothing works forever, and a frictionless product is also one that the user cannot course-correct or fix. Indeed, the very experience of dealing with an error is infantilizing — oh no, the page did an oopsy whoopsy!

Unfortunately, taking away user choice is efficient. This extends beyond products, into service design: soft and squishy human relationships don’t fit neatly into boxes, so the software must first standardize everything into one type of transaction. And the easiest way to accomplish that standardization is to push the associated bureaucratic work down onto the user via endless sets of forms:

LLMs generate disrespect at scale

Let’s put aside the inconvenient facts that modern large language models exist only because of the greatest act of intellectual property theft in history, the imposition of data centers onto unwilling communities, and record-breaking carbon emissions violating the various climate pledges made by these hyperscalers over the years.

Instead, I want to talk about how LLMs are productized; what uses the design (both the chatbot UI and the model’s reinforcement training) of the tool affords. I have long observed that these tools primarily scale up existing systems, so it is no surprise that we see them propagate all of the issues I mention in the previous section. The lack of control is almost entirely the point; LLMs will do it for you whether you want to or not:

The errors that a model produces (an inherent aspect of LLMs as a technology rather than anything labs can “fix”) are brushed away by the cutesy term “hallucination.” While we are ostensibly supposed to check LLM outputs for these hallucinations, the effort to do so inevitably exceeds the effort required to just write the words yourself in the first place. Indeed, much of the process around AI product use is designed to shift the error-checking burden from bosses onto their employees.

It’s a form of arbitrage: the cost of producing text is now far lower than the cost of consuming it, even though length and detail still feels like a sign that more thinking and more work had been put into something. This imbalance encourages long-winded texts that carry little meaning. This too is a form of disrespect.

Unfortunately, the incentives of workplace systems are such that this disrespect is perpetuated and encouraged. The designers of these systems pay lip service to human judgment, and immediately design systems that shut this judgment out, for the sake of nothing more than volume:

The disrespectful product roadmap

This disrespect inevitably trickles down to users. Without the friction of collaboration, ideas hit the roadmap before anyone can ask if it’s a good idea. Strategy is diluted into soup, prioritization falls apart. In the same way that it’s cheaper to generate outputs than check them, it costs more to push back against slop PRs than to just accept them and pass the pain onto the user.

The features that make it through this pipeline are nothing short of baffling. Generating podcasts from a PDF is merely the tip of the iceberg; it’s just a waste of developer hours and UI real estate. Some of these ideas instead lead to grievous and extremely preventable harm, as Meta learned when a feature designed to deepfake everyone on Instagram somehow made it into production without any employee stopping it.

Google, of course, has taken this one step further, by blowing up its entire product. Not only is the experience of actually using web search comically painful for end-users, it’s also been ruined for publishers. Google’s crawlers simultaneously index pages for search and scrape them for training data — ensuring that no user will actually visit the page that the content was lifted from. Cloudflare (which underpins a full one-fifth of the entire internet) has been forced to make a stance: knock it off, or we block your crawlers by default.

Thoughts on respectful software

I’ve previously written about the ubiquitously hated interaction pattern of nagging: your “accept cookies” banners and “remind me later” update prompts. The answer for how to make those touchpoints more respectful is obvious: honor the user’s choice properly.

But “how not to do it wrong” and “how to do it right” are two different questions. Making software that is inherently respectful, rather than merely not disrespectful, is not easy. Accessibility is one high-profile area where even noble intentions often fall short. For folks interested in doing better on that front, Laura Kalbag recently open-sourced her book, Accessibility for Everyone.

The notion of respect also crops up in another place that’s not immediately relevant to user experience: Grice’s Maxims. While they are not immediately related to UX, the maxims cover the cooperative principle: how conversation creates mutual meaning between two participants (note how LLMs break each of these rules):

• Quantity: give as as much information as needed, and no more.

• Quality: do not give information that is false/not supported by evidence.

• Relation: say things that are relevant to the discussion.

• Manner: be as clear, as brief, and as orderly as you can.

One need go no further than Erika Hall’s fantastic Conversational Design (now also free) to link these back to software interfaces, or indeed to systems design in general:

If you take care that your product is both accessible and a good conversation partner, you’re most of the way to achieving respectful software.

— Pavel at the Product Picnic

Design is in crisis. But this is business as usual. Design is permanently in crisis, such that we probably wouldn’t know what to do with ourselves if the crisis ever ended.

There are two parts to the permacrisis: a lack of trust, and a lack of rigor. And the “progress” that is currently being painted as inevitable is taking us in the wrong direction on both of these issues.

Productivity comes from trust, not tools

Lack of trust is not unique to design; it permeates the entire product development lifecycle. That’s why designers attempting to pivot to product management in hopes that they will get to call the shots end up in exactly the same place:

We touched on this subject last week: orgs built for trust can get the right people together in a room and crunch through deadlocked issues extremely quickly, regardless of the tools they use. Ironically, this kind of collaboration (delivering actual velocity) is in direct opposition to the thing orgs “hire” to try and achieve velocity: Agile development. Even before it mutated into a Scrum-monster, Agile was designed to solve the goalie problem for software developers: they were at the end of the waterfall and didn’t want to catch the blame for things being late. Devs had to find a way to write software in an environment where cross-functional colleagues could not be trusted.

Diagram by John Cutler

But in an environment with trust, these ceremonies are obsolete. The cutting edge of organizational innovation is concerned with dismantling them as fast as possible and watching immovable backlogs melt away simply by giving people ownership over doing so and trusting them to do it.

AI is a calorie-free trust substitute

There’s an interesting side effect to our current stage of the LLM hype cycle: in the race for maximum agility, organizations have given it functionally unlimited trust. Ten years ago, you wouldn’t dream of giving everyone in the company access to Github (ask me about filing Jira tickets to change a static string on a website); today, Claude is trusted to run roughshod over the codebase.

Is that trust earned? Of course not! The wave of low-quality code is driving devs crazy! But for managers who do not have any other strategy, the allure of letting Builders “just do things” is impossible to resist. Perhaps if they build the right thing, it doesn’t matter so much that they didn’t build the thing right?

Wrong! The solutions are also bad, because research takes time (spent on, among other things, building trust and establishing credibility) but vibes are instantaneous.

AI is making teams feel super productive by skipping that trust-building process. But the orders-of-magnitude increases in lines of code to prod are not producing any customer value, or for that matter economic value: a survey of app stores has shown that no one is using all the apps that have cropped up in this “agentic” coding era.

Accelerating the pace of delivery from once a month to once a week doesn’t actually make you get to a better product four times as fast if you still need that month to go through the rest of the OODA loop: observe, orient, decide. Anything you do under “act” before you’re done with the other three is waste.

Fake empathy is out, fake ethics are in

Real insights always run on human time. Data needs to roll in. Analysis needs to happen, at a pace slow enough to actually pay attention to the data and not just mine it for what you expect to see. Then all that knowledge needs to propagate throughout the organization. Mental models needs to update, to wrap around the “so what” of it all.

But taking people’s problems seriously takes time, and sometimes it turns out that you shouldn’t do the thing you really wanted to do. That really hurts your velocity, so it’s important to insulate yourself from this outcome.

It used to be that we did this through fake empathy: designers described themselves as “empathetic” and product teams performatively left an empty chair in the room to represent “the user” in order to justify why they never actually go out and talk to people. But somewhere along the line, we insulated ourselves from users so much that even that paper-thin excuse vanished. Even pretending got too hard.

Designers stopped talking about empathy and started talking about taste. And orgs as a whole pivoted to a new word, as if merely invoking it could make it real: ethics. Ethics language has been adopted across the industry, at a superficial surface level, to obscure the fact that this insulation is fundamentally unethical.

Build enduring trust for design, not for Claude

Not all empathy is fake, far from it. And not all ethics are fake, either. But when these things exist solely at the individual level, they may as well be. For example, Google’s DeepMind team had a clear ethical line (no militarization of their work) — a promise that Google unilaterally broke. Now the team is unionizing as a way to make those ethics meaningful.

Ron Bronson’s talk from last year is a really good take on why and how all the empathy in the world is powerless without the infrastructure to turn it into action:

Of course, the question underlying all such calls to action is “who is going to let us?” The Google example shows one approach. But faced with a stakeholder who is not antagonistic, merely wary, it is worth to put conversations around taste aside and look for more effective leverage.

Hence my emphasis on consequence above. Unless you have the muscle to buck the system (think more DeepMind union and less design auteur), you are going to have to work with it.

What the system want to do is simply go faster, in the mistaken belief that faster outputs automatically lead to better outcomes. But the outcomes themselves are still the goal. And outcomes across the industry are showing us that the path to “good” does not go solely through “fast.”

AI’s well of unearned trust is deep, but not inexhaustible. Our bosses are currently learning an expensive lesson: that rigor is not optional and tacit knowledge (both our own, and that of our users) cannot be automated. That realness cannot be faked.

When that lesson sinks in, rigor is what will let us seize the moment. But doing so will require a lot of trust. The acts of play that make design so powerful are incomprehensible to a spreadsheet. The autonomy we need to do the work — real ownership of the process — requires us to, first and foremost, build trust. That trust can only be built through rigor.

— Pavel at the Product Picnic

As George Lucas once said, for some reason: history is like poetry. It rhymes.

Our industry is certainly rhyming with a historical era I love to pick on: the boom in tech investment that followed the one-two punch of the Dot Com Bust and the Financial Crisis. Companies and their investors were desperate to find that one silver bullet that would turn everything around. Back then, that silver bullet was Design Thinking. Big tech poached designers from celebrated consultancies and airdropped them into pure chaos without a plan beyond “fix the product for us.”

Ten years after design thinking’s heyday, there’s a new silver bullet that everyone has pinned their hopes on, without a clear idea of what exactly it will do. At this point in the hype cycle, you’ve seen the numbers for yourselves: billions in investments, and loud cricket noises for returns. Anecdotes of individual productivity gains are easy to come by, and yet they do not translate to improvements in the bottom line!

What’s actually making teams move faster is org design. Taking care of organizational dysfunction may be a side effect of “AI transformation” but it sure seems to be offering the majority of the benefits.

The purpose of a system is what it does

“AI works” vs “AI doesn’t work” is an exhausting debate; no one is ever convinced of anything and the only winners of the arguments are keyboard manufacturers. I’m not going to go over the various hallucination rates and studies on how much longer it takes to check an AI’s output for errors than to just do it yourself. Even with 0% error rates, those figures would be besides the point. The biggest problem — and don’t take my word for it, listen to some Nobel laureate guy — is that the bottleneck lies upstream of your Jira ticket:

We are not in the future. It is still 2016. It is still 1986, if you are so inclined. We have hardly made any strides in our ability to define tasks and their context. What baby steps we’ve made in the right direction have been swallowed up by a great cloud of noise. For every Toyota Way book written in the 90s, there is a Ford counterexample being eagerly practiced today.

AI has intensified this problem, as it intensifies all things to which it is applied. But the problem did not originate with AI. Before Claude could learn to talk like the median LinkedIn influencer, the median LinkedIn influencer had to arrive at that mindset under their own power:

The bottleneck is the context in which the work takes place

For every step a would-be thought leader took towards “synergistic leadership” or “growth-hacking paradigms” they took a step away from reality. And corporate bullshit (not my name for it but a real term of the art, take it up with Cornell!) is not the only layer lubricating a product’s slide into slop. Robert Fabricant has a good layman’s overview of how little a modern product is influenced by a given design decision, and how much is a consequence of business and technology decisions that stack up over time without a single decision-maker deliberately steering things to be so. I recommend giving this one a read, as a means of cognitive estrangement from the ways of working we take for granted, because we are too close to them to realize how ridiculous they really are.

Unfortunately, many tech leaders do not take the time to reflect on whether the system actually makes sense. They shirk the responsibility given to them — to build an effective system — and instead whip the existing, faulty system to run faster and faster, until all the wheels fall off:

But how do we make this reframe happen? How do we seize control of our discipline’s story?

That’s where my head’s been at for years — before the Picnic, before my work for NN/g, even before I started publishing with the UX Collective. But only lately have those thoughts come together into something actionable enough to share. I’ll be writing on this topic through July, but the capstone of these ideas will be my one-day workshop with Throughline on July 31st.

Summer Intensive: Influence by Design | July 31 in Philadelphia

You try to speak up for human-centered design, but it feels like you’re shouting into the void. You ask to be included in strategy, but your product partners bring you in too late to do deep work. And if you hear one more senior leader telling you to “influence without authority,” you might scream. We hear about challenges like these all the time in our work. And it’s time to do something about them.

Throughline Conference

Flex those professional development budgets and join me in taking back control of the conversation.

— Pavel at the Product Picnic

One of the enduring themes on this blog is that none of the issues we face are truly new. Today, the old issue rearing its ugly head once more is data — specifically your data, specifically your data getting hoovered up to power modern Big Tech.

These kiosks were conceived during the age of techno-optimism, which many in the industry confuse for a time when design was good. But all of the problems facing tech workers today were already baked in by 2016. The attitude tech brought to urban planning — elbowing experts out of its way to proclaim that Computer Science will solve all these trivial problems — is timeless.

Unfortunately, a city is not a computer, and so here we are a decade later, a few years into the “techlash” that gets blamed on any number of things instead of the real reason: none of the problems tech promised to solve ever got solved. What it did instead was unleash new problems onto urban populations. Primarily surveillance, where impacts can range from privacy violations by rich individuals to getting dragged into a legal nightmare by overhyped facial recognition technology. The societal panopticon continues to expand, driven primarily by fear-based narratives seeded by the industry itself:

Another trend that seems to be back from the “golden age of UX design” is pointless wearable tech (hi, Sir Jony!). Ever since the dawn of the Apple Watch and its desperate search for a use case, the only thing tech has been able to find was fitness. Unfortunately, many have since gone on to confuse step counts with medically meaningful data:

Mostly, the impact of this tech has been to encourage quantification fixation. People have come to trust the number they see on a screen because it’s made to look like a fact — even though in reality, it is a rough estimate. Sort of how facial recognition tech that could at best promise “this is sort of like that guy” was dressed up to shout “this is definitely the guy!”

The new wearable form factor is “smart” glasses. The idea is from the same era as the smart city stuff (Google Glass in 2012, Snap Spectacles in 2016, etc) and floundered for the same reason: it didn’t actually have any purpose. But now they are back in a big way. Meta (and more recently, Snap again) have partnered with fashion houses to put out glasses that look merely regular stupid instead of “MIT in the 1980s” stupid, with billions in advertisements backing these things everywhere from TikTok to optometrist offices.

But between sending all their video recordings to contractors and making everyone users look at a victim of that shoddy facial recognition tech from earlier in the article, Meta’s glasses have already earned their reputation as pervert glasses.

At the same time, former Millennial darling Pokemon Go was caught selling the environmental data it recorded through players’ phones to military drone operators, and Anthropic is now sending your ID to Persona (the same Peter Thiel-funded startup that was too stinky for Discord).

All of this stuff is a preamble to a much more immediate concern for most of the people reading this: AI “note taker” apps that many tech workers now bring to meetings as a matter of course (or worse, send the app to a meeting in their place). The many issues with doing this got brought to light at an AI note taking etiquette event last month — but in the context of the rest of this newsletter, I’d like to add one more.

AI agents are not your agents. They do not represent your interests as a real (legal) agent would. And you have no idea what is now happening with those notes it took.

— Pavel at the Product Picnic

In theory, there is no difference between theory and practice. But as anyone who’s ever tried to apply lessons from books/courses/posts about Best Practices to their work can tell you, the difference is real and it is vast.

I’ve featured Jen and Kyle’s Complexity Lounge on here before, but last month I finally got a chance to appear on the show myself. We talk about some of the things that make reality so…well, complex, compared to the neat simplicity of theory books.

As with many of my rants, the conversation eventually comes to the topic of systems thinking: being able to understand not only the thing you are working on, but the forces around that thing that frustrate your efforts to change it. Last week, I wrote about one way this can manifest: higher output velocity never brings you closer to valuable outcomes without your org being able to deliberately form intent and hold on to it.

Put down your tools to engage with the system itself

The good and bad news is that solutions to systemic problems don’t live inside our tools. It’s good news because AI is never going to be able to take this part of the work away from us. It’s bad news because it means we have to leave our comfort zones (exit Figma, close vim, log out of Jira) and go talk to people about complex things that don’t fit into a Slack message.

This method works really well for solving seemingly intractable problems, for example engineers saying “that’s not possible” (which often simply means “I don’t know”):

However, since this is the “not so fast!” issue of the Picnic, we must immediately admit that “just talk to people” is not a magic cure-all. Any product manager will tell you that they became disenchanted with UX when “we talked to users, but the product was still bad.” Similarly, the way in which professionals (including designers!) talk to their colleagues often falls prey to the curse of knowledge, where we cannot imagine what it is like to not know all the stuff we know. Conversations with cross-functional partners are not a delivery system for our brilliant insights.

Erika Hall has some good advice for how we can avoid that curse. One line especially stuck with me: “seek feedback, not approval.” While Erika uses it in the specific context of self-improvement, it has many facets and all of them are true. After all, feedback is the core of feedback loops, which are the things that the entire product development lifecycle runs on.

Unfortunately…

Feedback loops need a system that can provide real feedback

Broadly speaking, any feedback loop has two stages: theory formation and experimentation. We come up with a thing to try, and then we try it. Design and development, if you want to be overly prescriptive. Each stage repeats until its output is fit for purpose; we continue to form theories until one is worth trying, and then we keep testing it until we learn what we wanted to learn.

Both of those loops get absolutely wrecked as collaborators retreat further into LLM-driven tools.

Feedback unmoored from prioritization destroys the value of critique

Let’s start with the first part: theory. The way we typically decide a theory is worth testing is through critique (which I talk about in an older issue). This was already something orgs struggled with: most people’s idea of a good critique was a brutally harsh critique, maximizing nitpicking and pushback for its own sake. Figuring out which feedback mattered has always been a challenge that collaborators struggled to meet.

Now let’s put our heads together and see if we can’t think of a technology that is really good at generating “feedback” up to an arbitrary word count, and then emailing it to the poor designer who now has to implement it.

An org that sees critique as something you can win by picking the most nits will never be able to adequately finalize a theory. It will keep getting sidetracked by low-priority minutia that doesn’t actually bother anyone, but costs far less to identify than to fix. And that’s assuming that the feedback is even correct, which it’s not likely to be. The “best practices” baked into LLM training data are not actually true: the 7±2 rule is bunk, the “less clicks is better” rule is bunk, the “laws” of hierarchy depth are bunk. And yet you can count on any or all of these appearing in feedback from a robot (or a human who trained themselves to think like a robot).

Learning is not a natural outcome of shipping

Some orgs have opted to downplay the necessity of theory formation entirely, appealing instead to velocity as the solution to all their problems: we don’t need to prioritize ideas if we can get them all out the door and see how they fare.

Just like bad critique, this is not an AI phenomenon (which is a theme that repeats over and over: most problems with AI are preexisting problems that have been intensified by thoughtlessly scaling the systems where they appear). This was a problem with Agile for as long as Agile has existed: the assumption that teams could ship small and then iterate never bore out in practice. Calling out flaws during theory formation is cheap & therefore encouraged; calling out flaws with the finished product leads to expensive changes, and so it is systemically discouraged.

This creates an effect known as learned helplessness. Employees become conditioned to keep their mouths shut. Everyone knows that they are expected to sit down and ship — even if they can plainly see that what’s being delivered is steering the product away from the company’s stated goals.

Now AI is here to intensify this effect. Agents are eye-wateringly expensive and only getting pricier as frontier model providers aim for IPOs. Our bosses expect the return on that investment to be similarly sky-high. They don’t want to hear any doubts — and rank-and-file employees are scared to speak up. One is expected to produce good news, no matter what they actually see:

But reality can’t be held at bay forever. There is always a feedback loop. And if you can’t run a fast feedback loop, you will run the slow one: increasing your costs with every line of code you ship until the company is no longer able to function at all.

That feedback loop is less OODA, and more FAFO.

— Pavel at the Product Picnic

The design process. Love it, hate it — you have an hour to spare for listening to me talk about it. Or 45 minutes, depending on the speed you play your podcasts on. I don’t judge (out loud).

Design Overtime: The Design Process Is Not Dead — It Just Feels That Way

Guy Segal and Pavel Samsonov challenge the recurring claim that the design process is dead — arguing that for many, it was never really alive in the first place. Effective process is not a sequential checklist, but a decision-making framework that allows you to say "no" without rupturing your relationships with stakeholders.

RSS.com

This episode of Design Overtime is not a prerequisite to today’s issue of the Picnic, but it does touch on an important theme that I want to expand on today.

Velocity has always been a commodity

It’s almost a cliche that the only thing executives want from product managers is faster feature delivery. So it’s refreshing to see a C-suite executive ask:

Crucially, Michalik recognizes that we were making progress on fixing this, up until AI showed up. Suddenly, teams had an excuse to avoid doing anything that was hard. Design teams were told “we don’t need information architecture because AI can do it.” And product teams were told, “we don’t need to fix out process anymore because we can just ship really fast now.”

And this felt like a huge step forward. Because those teams were struggling with process at the most fundamental level. Forget “outputs vs outcomes” — many teams were struggling to stitch together their various deliverables into a single output that might actually reach prod. What a breath of fresh air to jump straight to “everyone writes code.” How liberating to ask Claude for changes and see them render live.

Just one small problem with that: code was never actually the goal.

These teams had set outputs as their goal for so long that they forgot what the outputs were for in the first place. The only step they could imagine after “ship the thing” was “go back to the backlog and ship another thing.” And this lack of imagination is because they never resolved the central problem that the process definition was meant to fix: the definition of the intent behind the work.

The team never had a problem with pushing code to prod. No teams truly do. Software engineering orgs hire programmers for their ability to push code to prod. What was missing is the intent. What AI let people do was skip intent formation — a prerequisite when working with one or more colleagues — and have every person strike out as their own designer, coder, and PM. The forcing function of convincingly explaining why we are doing the thing was something we got “for free” with a real product development lifecycle. Now everyone can make ten thousand bowls of oatmeal.

“Skipping process” is a corruption of intent at the system level

As a side effect of the “you can just do things” antiprocess, all the thinking that used to lead to strategy is obsolete. What’s the point of a startegy doc when your developers are shipping one feature every hour based on a cool idea they had during lunch?

And what do we do with pointless work? We delegate it to AI. Now, a synthetic strategy doc is feeding into a synthetic PRD into synthetic user research findings into synthetic design into synthetic code into synthetic deployment. At the pace of AI, no “human in the loop” can afford to take the time to read any of this without being branded as a blocker.

The trouble is that by the end of that workflow (even if the original idea originated from some kind of real need — which is not at all guaranteed) the intent behind the work has been hopelessly corrupted:

It sure would be a shame if we had “democratized” this work and every person in the company had generated pages and pages of contradictory research and strategy docs. That would exacerbate the degradation severity, so it’s definitely something orgs are working hard to prevent.

Haha, just kidding. They are scapegoating designers for not being “systems thinkers” instead.

The truth is that it’s not design’s fault that systems are broken, and not our mandate to fix them:

Scott gives a lot of good advice in that article for how to make the system work for you instead. But with the industry increasingly undermining its systems for the sake of intentless velocity, don’t be surprised if you have to start rebuilding that system yourself.

— Pavel at the Product Picnic

The Product Picnic has gotten big! And rather than pass the cost of hosting it onto my readers, I’m funding it through some side projects. Now is your opportunity to support one of those: I’m doing a full-day workshop together with friend-of-the-picnic Sara Wachter-Boettcher in Philadelphia on July 31st. Come learn how to stop waiting for permission to kick ass, and start practicing UX without excuses.

Back to our regular programming! We pick up where we left off last week, when we discussed how the “more is more” approach to software — the paradigm that AI embraces and accelerates but did not invent — is running out of gas. And if you don’t want to take my word for it, read a serious newspaper citing serious people who are worried about what’s being done with their money.

But “AI ruined everything and now we’re doomed” is not sufficient analysis (indeed, many criticisms of AI slop end up a kind of slop themselves). For an industry that’s always struggled to prove its worth, proclamations of the end of the world are just another Tuesday.

So in a way, this essay is actually an extension of a much older Picnic: design is not dead, but has not yet arrived.

And the reason that design has not yet arrived is that the logic of the industry has — so far — allowed companies to avoid having to do it. As long as you can scale through simply doing more, there’s no reason to think about better. Better is a qualitative change. Better is risky. More is safe, and the more we are boxed in by half-heartedly justified layoffs, the more appealing safe becomes.

But the honeymoon period of more fades with the first token bill, and the conversation inevitably transitions into: would it be possible to still get more from our employees, but give them fewer resources and support to achieve these new targets? In other words: can we shift the consequences of our shortsightedness from the employer to the worker?

The answer, by the way, is no. But on the journey to that “no”, a lot of ordinary people have their livelihoods ruined. And yet, there’s only so much we can do now that “more” has run its course and the formerly infinite money supply shows signs of running dry. Companies will soon be forced to admit that the contradiction of “do more with less” cannot be resolved at the individual employee level.

I won’t pretend that they will suddenly have an epiphany that design offers an escape from this dilemma. But I do want to cover some ways we can get ready to seize that moment.

What does it even mean to scale?

At the root of “do more with less” is the idea that we can achieve more leverage if we apply the same amount of force to somewhere else in the system. But the highest bang for your buck comes from applying that force to changing the system itself. This is called service design, and it rules:

Now, I don’t actually care about titles. A UX designer can still do service design. Hell, service design at your company is probably being done by a product manager (if you’re lucky). But it’s worth calling out the implications of this paradigm shift from unilaterally designing a product for consumers, and designing a service that mediates interactions between entities (power centers, even!) with agency.

The former is very easy to scale through the logic of more. Users are fungible because they are rendered fungible by the product. This is no accident of the material, but an axiom of non-LLM software business models: it costs almost nothing to replicate a program, so if you can bear the initial cost of writing it, the unit economics guarantee pure profit.

The problem is that the huge cost of writing code returned every time users demanded changes to the product, which messed with the economics. The more you allowed the nature of your business to evolve, the more expensive it would be — and so the trick is to grow like a plantation, getting bigger and bigger without allowing transformative relationships to form:

Agency is not just for “agents”

The notion that computer science is not sufficient to explain interactive systems is not a new one: this paper from 1993 may be older than many people reading this, but somehow has ideas I’ve yet to see implemented in the practice. Instead, tech has set itself upon the doomed trajectory of replacing as many humans as possible with programs. Even before LLMs, we had Big Data — the idea that a system could just Know, and then Do the Right Thing. Analysis and decision-making became standardized and commoditized; the entire concept behind SaaS was founded on locking your org’s spreadsheets in a prison and then charging for visitation rights.

But as we all know, the “automagical” approach only worked until it suddenly didn’t. As soon as real life deviated from the tidy “use cases” we were sold, we found that the designers had sawed off any controls that would let us steer it back onto the right path. The people who knew what to do when things broke were the very ones laid off in pursuit of the new “agentic” vision.

As the result, the more outdated a system is, the more resilient it is to error — and the more we can learn from it when designing automation that grants agency to humans instead of solely to machines. These are the systems that will remain standing when they encounter reality.

This is the pivot point where “scale the thing for ever” thinking fails. Despite the best efforts of product managers, the emergent properties of software change its very nature as it scales. There is a very low ceiling on how useful up-front decisions can be.

The result is that a release plan (what is usually and incorrectly called a “roadmap”) packed full of features is the worst way to engage with this kind of complexity. The problem you are solving does not sit still. They are wicked problems.

Tools for seeing are not tools for shipping

Fortunately, design has tools for dealing with wicked problems. Design is a tool for dealing with wicked problems. But this moment demand that we learn to apply that tool above the feature design level:

One of the biggest mistakes the industry has been making so far is conflation between “action” and “shipping software.” This logic has led vibe coded slopware to colonize every company’s PR queue today: we will simply ship every half-baked idea and see what happens. Not only is this extremely wasteful — burning everything from tokens to user trust — but it doesn’t even work, because no amount of small-scale tweaks will ever add up to one big, transformative idea.

The answer is to embrace action that takes place outside of the “fidelity cascade” of a software interface, outside of the spectrum that begins with wireframes and ends with production code.

Ecosystem mapping is one such action — and I will emphasize that as with all maps, is is the activity of mapping rather than the resultant map that produces value.

Persona landscape mapping is another approach to work that enables deep thought over layout design, though all the caveats with personas apply:

• Personas come from synthesis of real data, not assumptions or wishes

• Personas need scenarios to be meaningful

• Personas are a tool for making decisions, and if they do not let you make a “no” decision then they are useless

Finally (lest I continue to receive accusations that I’m claiming UX is at a dead end) I want to spotlight a very cool project in the early stages of development. Jason Hobbs has been putting together a framework for Information Architecture to engage with the challenges I’ve talked about in this issue:

Hobbs has shared a three-part lecture series (1, 2, 3) which is much more penetrable than the IAD website itself for understanding what this framework is trying to do. It’s dense, juicy stuff, so you may come away from it with nothing more than a sense that new and interesting things are happening — but in this day and age, even that sense is a precious commodity.

— Pavel at the Product Picnic

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:

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:

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:

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:

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:

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.

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:

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.

The part of the newsletter where I give practical advice rather than just complain

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.

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

Howdy, picnickers!

Last week we talked about dashboards no one uses and reports no one reads. This is the perfect segue into an essay I’ve been meaning to cover for a very long time:

From Interactive to Interpassive

Where AI Art Meets Cognitive Offloading

Doing and making are referred to as obstacles to the pleasures of not participating

Cybernetic Forests

As we stumbled into the digital age, the promise of interactivity turned sour. It turned out that while it was nice that you could interact with stuff, having to do so became a slog. So products appeared that could free you from having to use them. A taped show or a photocopied article would sit on the shelf forever, freeing you from the obligation to watch it or to read it (a more modern example might be your inbox chock-full of unread newsletters).

LLMs represent a new frontier of interpassivity. Now we can make a robot read the article for us; the pleasure is not merely deferred indefinitely but farmed out entirely.

This shows up most acutely in vibe coding. The systems (both the “agentic harnesses” themselves and the hype whipped up around them) take great pains to paint the user as the programmer, the active participant who is merely engaged in distributed cognition on an unprecedented scale. But in reality, Claude Code is a consumer product, and vibe coding is an act of consumption.

And that relationship is trending further towards passive consumption. Now, “reasoning” models even talk to themselves for you: let Claude Code rip and it will happily describe all the things it’s doing on your behalf; your opinion is superfluous. It is nothing like pair programming — the robot calls the shots and you disengage your brain:

AI did not usher in the phenomenon of interpassivity. It emerged under the flickering glow of the very first blinkenlights. But it has scaled the problem up to an unmanageable level, like it has every other problem in the industry.

The crisis that UX finds itself in, for instance, is also nothing new. We were already overwhelmed by cross-functional partners agitating for the feature factory over system thinking. The ability to trivially generate a functional demo faster than you could think about what you were doing just pushed teams further over the edge:

The feature factory approach was always pure self-indulgence: living out the fantasy that we could simply know the right thing to build, knock it out of the park on the first try, and then move on to the next feature — and somehow they would all add up to inevitable success. That we could get there from here, and the only thing stopping us was velocity.

That was the logic behind UX theater that diluted real research practice a decade ago. It has now returned with a vengeance to AI-ifiy what little rigor remains:

But the pleasure interpassivity can bring you is never going to be as good as the real thing. The industry has managed to displace the costs of playing make-believe. Some of those costs are displaced into the future, in the form of enormous maintenance costs involved in keeping systems coherent two, five, ten years from now. Other costs are displaced onto employees — such as the permanent hypervigilance demanded from any operator of tools that fail in unpredictable ways.

That is the ideal environment for interpassivity to take root. Too much is asked of us. We crave being able to disengage, to say “no.”

It feels like we have two choices: to give up on the pleasure of doing a good job and replace it with the ersatz alternative, or we burn out trying to hold the line against low-quality garbage being shoved out the door.

The only cure is to find those other people who still care, and still choose activity over passivity. Be where the crafters are. Refuse to let your brain atrophy.

You'll end up ahead of the pack, as the rest of the field painstakingly rediscovers that rigor and process were never optional, and cannot be substituted with a software tool.

— Pavel at the Product Picnic

Today’s issue starts with a little joke:

UN report finds UN reports are not widely read 

Last year the U.N. supported 27,000 meetings and produced 1,100 reports, a 20% increase since 1990.

www.reuters.com/world/un-report-finds-united-nations-reports-are-not-widely-read-2025-08-01

This probably doesn’t come as a surprise to anyone working at a company of more than five people. Every team gradually becomes a machine for turning meetings into reports — and other content like emails, docs, and memos — that no one reads. Companies produce so much text that it’s now being mined for AI training data.

And the AI is probably the only one who will ever read it, because the author had an AI draft it, and the recipient had an AI summarize it. At this point we know more about what Claude thinks about something than about our colleagues’ own opinions.

This is a good opportunity to remind the audience that AI does not actually summarize, because summarizing requires the ability to draw a conclusion from a text. Even when there is an author-written abstract available, the AI will give you something else.

It’s that very act of reading and summarizing that makes knowledge stick in your brain. Even when you are the source of the text (for example, a transcript of an interview that you conducted) the repetition that comes from going over those notes is a key part of learning. A human-written summary is equal parts “what happened” and “why you should care” — and with that last part missing, your company will never take action on any insight produced.

Skimming the dashboard is not a product strategy

This is why every company is addicted to dashboards. They are designed to be perfectly skimmable. The data is already massaged to draw conclusions for you: hundreds of decisions have gone into reducing the complex multidimensional real-world events into “green number good, red number bad.” This pre-digested thinking is critical because when we skim, we do not have time to think:

Paradoxically, this marvel of automation (insights on tap!) ends up exactly where the automated emails and the automated memos go: the garbage, without once passing between the ears of a human being. Attention at the organizational level is just as flighty as an individual’s. Companies stand up dashboards and move on, leaving behind a swamp of dashboard rot.

Perhaps the reason these get left behind is exactly the same reason, too: there was never really a “so what” beyond a general feeling that it’s good when numbers go up.

Perhaps this is why people can get away with fake metrics and AI-generated “citations” not supported by the text: everyone stopped caring about the thing being measured as soon as they started to measure it.

The Conway-Sturgeon Law of Garbage Software

This dynamic creates a sort of organizational illiteracy: no one reads because there is nothing worth reading. Incoming insights are rendered meaningless by a semantic environment of organizational bullshit (a real scientific concept, there’s a paper and everything). A decade ago, we manufactured facts to fit our preconceptions; today we do not even need to bother.

Predictably, the disconnect between insight and action leads to poor decision-making once someone actually has to do something:

This lack of clear goal-based prioritization percolates downwards into a toxic working environment. Workers are constantly simmering in a pool of fake urgency, rushing from “critical” task to “critical” task. Teams are stuck trying to convince each other that their direction is the most important one and everyone should drop everything to follow them (everyone nods politely for 3 hours and then goes back to what they were doing in the first place).

In product design, this manifests as a shouting match: individual teams operating off individual dashboards try to make their individual numbers go up by making their part of the software louder, bigger, more frequent, more urgent. Naturally, the product as a whole goes to shit — the design system might be consistent, but the product is incoherent because the underlying org is incoherent.

It’s not fair to dump that mess at the foot of UX and say “fix it.” But that’s what’s happening anyway. We have to equip ourselves with tools for wrangling organizational complexity and make improvements there before we can hope to see those improvements show up in the software.

Oh, and if you still have to write some reports: there’s good advice here on how to make them as readable as possible.

— Pavel at the Product Picnic

First off, a time sensitive note: Frank Elavsky (whose great essays I’ve previously cited) is having his thesis defense this week! If “Tool-making as an intervention on the accessibility of interactive data experiences” sounds like it’s up your alley, and you have a spare hour on April 29th, check out the details here.

(This is not an ad — but it turns out newsletters ain’t free so if you do want to advertise with the Picnic, you know where to find me.)

The wrong kind of productivity

For your regularly scheduled Product Picnic, I want to return to the idea of velocity, and specifically what it means to do our work “faster” (although the subtext of that statement these days is always “having our work done for us by an LLM”). But instead of discussing how much time design work takes, I’m interested in what kind of time it takes.

I like these better than Kahneman’s “type 1 and type 2 thinking” because they are simultaneously more tangible and encompass a broader idea. Clock time is hours of butts-in-seats, eyeballs-on-screen, hands-on-keyboard. If you’re familiar with David Pye, the “workmanship of certainty” — production processes — runs on clock time. Clock time is how you measure commodities.

However, the organizations that produce and distribute those commodities operate on calendar time. Consider a package scheduled to arrive in “2-3 business days.” While your package may physically get from the sender to the warehouse faster if the train it’s on runs more quickly, it will still sit overnight until it’s time to load the trucks.

This problem shows up in every delivery process, including the one for software, because we need to deliver insights from one part of the org (where they are produced) to another (where they are consumed):

This is how an organization actually thinks: not as a collection of individuals, but as a system. Individuals may “know” things that the system does not register, and vice-versa — the system may compel individuals to perform actions they “know” are wasteful or even counter-productive.

Aligning org-level thinking with reality is the real work of leadership (this is why I say that design is a leadership skill). It’s hard work. And as with all hard work, managers have long hunted for “one weird trick” that would let them avoid doing it. They always fail: coordination is expensive, and when you try to sweep it under the rug, it just becomes more expensive.

If you skipped that link, I want you to go back and read it, because Hochstein makes a distinction towards the end that is highly relevant:

The industry as a whole is making one big bet: that it is possible to make individuals fast enough at solving acute problems on clock time that the complexity of managing chronic problems across calendar time takes care of itself. This is the trend that is leading many to (mistakenly) proclaim that “the design process is dead.”

But unfortunately, it also poses an insurmountable problem for industry leaders backing the idea that designers can now “do strategy” — because in this world, there is no strategy. Any horizon beyond the tip of your nose is outside of the organization’s semantic environment. The moment of “workmanship of certainty” that Pye promises never arrives; it’s risk all the way down.

Instead of strategy, we need to do something a little different, and a lot more human.

Designing for the compost heap

Mike Gallagher has a charming metaphor for this: a garbage can system in which decisions happen “by collision, rather than intention.” There are two interwoven themes in the piece that I want to highlight:

• In garbage can systems, there are no shared conceptual models. Everyone has a different idea of what the problem even is, solutions circulate without associated opportunities, and every decision is made based on an incomplete, random sampling of available knowledge that people making that decision happened to have.

• Design is the only way to make this system produce useful outcomes, but the work of design looks very different from what we are used to doing. The majority of the work becomes a maintenance activity: keeping problem frames and solutions salient enough that they are within reach when the decision gets made.

Individual productivity reaches diminishing returns almost immediately, and from that point onward, investing in coordination gets you much better returns. Hyper-optimizing outputs in your own context is a waste of time, because the chance of your context being important for any given decision is ~0.

Keen-eyed readers will notice that the tools we keep being told “will kill UX” do not help us do this and in fact make the problem worse by accelerating design drift and knocking the scaffolding out from underneath complex ideas that need time to percolate. The iterations that a designer would have gone through to flush out bad ideas instead get picked up as user-facing deliverables.

Scott Jenson writes about design principles for tools that resist this pressure. But you can also apply all of those lessons to choosing which tool to use in the first place, and deliberately reject clock time conceptions of productivity where they don’t make sense. If you normally work in visuals, interrupt your impulses by writing. If your tendency is towards high fidelity, spend some time on shitty first drafts.

And if your tendency is to throw yourself against a problem until you burn out, give yourself permission to clock out. The problem will still be there tomorrow.

— Pavel at the Product Picnic