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

Welcome back to a sort-of part 2 to last week’s post, where we started to wrestle with the explosion of aimless prototyping.

The key insight from that week that I’d like you to carry forward is that prototyping is a qualitative research tool. But the semantic environments of our orgs are quant-driven, and struggle to understand this. The only thing we know how to do with a prototype is to ship it and see if the numbers on our dashboard go in the right direction.

This kills the product.

User Experience Rot

One of the most memorable presentations from IAC26 this week was Jared Spool’s hand-drawn rendition of his classic piece on user experience rot. Unfortunately, eight years of knowing about it hasn’t helped our software resist the trend. Version numbers creep up. Features aggregate. The cognitive load of understanding what any of it is for continues to stagger users.

LLMs make this trend even worse (as you might expect would happen when you scale up a broken process):

Sure, code generators might be a solution for the problem of “not having enough features.” But that is not the problem with your product. The problem with your product is that there is already too much shit, and none of the shit is organized in a way that makes sense to people.

One line in my notes from Jared’s talk has a star drawn next to it. That line is: by the time you notice experience rot, it is too late. You need to prevent it from occurring in the first place.

C.R.E.A.M. (Content rules everything around me)

One of the classic moves to deal with experience rot is to slap on some labels that try to explain it to the user. This never works. And it’s not because users don’t read — it’s because your product was not designed coherently. Individual labels do nothing for sense-making if the system as a whole defies understanding.

The problem comes from looking at text as labels, things that are attached to the interface. But if anything, that relationship is the other way around: the interface wraps around the text and serves it to users. Interfaces are touchpoints of the system, but the text is the system. Take away all your <div>s and <script>s and the system should remain coherent; if it doesn’t, you did it wrong.

A lot of people do it wrong. And it starts with prototyping a page or a widget — an interaction — without taking care to establish what the user is meant to be interacting with.

In other words, you should prototype content first. Rather than prototyping content despite its unimpressiveness to stakeholders, you should do it because of that. Because a page of text resists being demoed. It does not try to seduce you into designing for the presentation, so you can stick to its intended purpose, which is learning. You can figure out what the moving parts need to be, and only then devote your focus to rendering them visually.

And because it doesn’t look like an app, a content-first prototype resists thoughtless integration into the product. Instead it becomes a valuable decision-making artifact against which product design work may be judged.

Everyone is always telling me how UX designers are becoming generalists, but for some reason that always means "learning to code” and content design ends up being treated as a separate thing. Prove me wrong. Start your next project with content design. Do it. Do it now.

And I actually have two links for how to do content-first design! One from the public sector (part 1, part 2). And another from the private sector (part 1, part 2). The principles of design are still the same. Only the medium is different.

— Pavel at the Product Picnic

Spring is here in the Northeast, just like it was here two weeks ago, and three weeks before that. But this time is for real. Definitely.

A similar sentiment follows the design process, which continues to be declared dead in the hopes that someday the accusation will stick. I think that unfortunately this proclamation will never entirely go away — at least, not while designers continue to be confused about the shape of the design process, and our place in it.

The double diamond describes only one dimension of the process: it shows how an idea moves in time, from its inception to its execution. But if you could take a vertical slice of the diamond and look at its flat side, what you’d see is a set of two feedback loops. One between the team and the external customer, and the other with the internal customer (more on this idea and its implications here).

Once you understand this, the distinction Andy Polaine makes this week slides into focus: what everyone is suddenly obsessed with producing (via vibe coding) is not actually prototypes. It’s demos.

The only thing these demos are helping you test is whether your stakeholder likes what they see (the first loop) and as soon as they say “yes,” it becomes good enough to ship.

Whether that second loop (releases go out, measurements come in) ever gets tracked or not is not something I’d be willing to put money on. Because once the demo is productionized, it goes from the realm of delivery velocity (which gets you shoutouts and promotions) into the realm of maintenance (which tends to be ignored even as it eats up more than half of the team’s bandwidth).

Nothing ends up being learned, which is to say integrated into decision-making about the product. The impact might be reflected on some dashboard that everyone ignores — but until that change is incorporated into decision-making, it can’t actually be described as learning.

And the sooner designers reckon with how knowledge is actually created and acted upon in their organizations, the faster they can start making prototypes that actually help them learn.

“Hard data” is always downstream of pure vibes

It’s unfortunately very common in tech to reach for the ironclad armor of “data driven” without knowing anything about what drives data. But there are professionals who study that for a living, and now we have a study to confirm what the humanities have been saying for decades: quantitative data is always, always skewed by the extremely qualitative work of choosing what to measure and how to measure it.

The softness of hard data: Discursive psychology, conversation analysis, and psychological science.

Qualitative methods are sometimes criticized on the grounds that they do not provide “hard” data. However, on inspection, hard data turn out to be produced by unavoidably “soft” human interaction and activities.

psycnet.apa.org/record/2027-40060-001

There is a childish notion that being “data driven” allows one to avoid distractions such as office politics. But rather than allowing us to rise above that morass, data-gathering is politics. This should also be obvious: data is power, and the process of creating and distributing power is always political. Far from being a neutral arbiter of truth, data is the medium through which prevailing power is exercised:

And chasing this power is not a neutral activity, either. Attempting to shape the narrative through carefully selected metrics instantly runs the whole organization afoul of the old adage: when a measure becomes a target, it ceases to be a good measure. And if your target is an aggregate measure, it screws you twice: once through the questionable logic of the metric itself, and then a second time through the inevitable gamification exercises that spontaneously occur downstream of that metric.

Qualitative research is your only competitive advantage

Any experienced researcher will tell you that the plural of anecdote is not data, but when an anecdote conflicts with the data, you should start paying attention. This is because qualitative analysis is what lets us make sense of the numbers. It’s the only way to tell whether our metrics are measuring the wrong thing.

Good qualitative research is fundamentally different from good quantitative research. This should be obvious — after all, they are different things, different disciplines, different formats. And yet, quant dominates our imaginations to such an extent that qual ends up being judged by the same metrics. We expect qualitative research to get better with scale (it doesn’t), simply because its sibling, quantitative research, gets better with scale.

In fact, I’m on the record as going one step further: often, scale defeats qualitative research by drowning out the outliers — the voices that are not being heard — with a tidal wave of statistically average responses (it will not surprise you that jokesters are now using generative AI to do this exact thing).

To close the loop on the theme of this essay: this is exactly why AI-generated prototypes are not working, and have not helped anyone do anything ever. Some have accused me of going too far with this assertion, but I stand by it, because it is rooted in the very nature of what a prototype is (and is not), and what makes it successful (or does not). As above: a prototype is not a demo. It does not succeed when we have shown a thing to a stakeholder. Shoving out more prototypes is not a heuristic for success; it is a heuristic for failure because it shows that you don’t know what you are trying to learn.

Fixing your prototyping with cognitive estrangement

One of the reasons I love this field is that it ties in ideas from every sphere of human endeavor. Among my favorite nuggets is “cognitive estrangement” which comes from science fiction literature. Simply put, it’s the idea that placing a familiar topic amid lizardmen and laser guns will cause a reader to think about it without any preconceptions. This has obvious applications to our field, where we often have to nudge our stakeholders out of the business-as-usual rut.

But this same technique can (must?) be applied to our own work. Because while UX design is mesmerized by the lure of the visual fidelity anglerfish, our sibling practice of content design has fared somewhat better. Because the analog of a design system is a content model, and its nature as a model means that conceptual integrity is a requirement rather than a nice-to-have.

If you have been making (generating?) prototype after prototype without any visible impact, try this next time: put the visuals to the side. Start with the content that your users need to understand the options available to them, and to help them form a meaningful response.

More on content-first prototyping next week!

— Pavel at the Product Picnic

Welcome back, picnickers! We’re picking up where we left off last week: as making becomes easier than thinking, teams are shoving things into prod faster than they can evaluate them for quality. Everyone is in a rush to get nowhere in particular. Urgency without direction is eating the industry alive.

A paper from earlier this year gives a name to this phenomenon. It’s not mere cognitive offloading (which was already studied as a problem last year). It’s full-blown cognitive surrender: abandoning our own judgment entirely, and letting AI take the wheel. Props to David Dabscheck, whose summary put this paper on my radar a month before Ars Technica did their feature about it.

I wrote about this phenomenon for NN/G a year ago, but I’m not a scientist, just a guy typing words into the internet.

What’s happening was pretty obvious, however. Generating working (for a given definition of “working”) code or plausible text has never been easier, while validating that the output was correct is getting proportionally harder. Every time someone involved in the process decides to “just AI it,” the chain of provenance breaks. Instead of building a mental model in manageable increments, we are now asked to absorb massive chunks of output being flung our way all at once.

Cognitive surrender is a leadership failure

Surrendering to this onslaught is far easier than asking for thoughtfulness: you get branded as an innovator rather than a party pooper, and leadership is thrilled at the prospect of more velocity. Getting Claude Code or Figma Make to do something is infinitely easier than getting it to do the exact thing that you need it to do. As a result, we are being trained to expect less of our tools, and to fit what we want into what we can get.

But when something goes wrong, who is responsible? It’s certainly not the model provider: after all, legally, these chatbots are for entertainment purposes only. When the little text at the bottom says “AI can make mistakes,” you must understand that someone is still responsible for those mistakes, and that someone is you:

Even when the LLM doesn’t make an outright mistake (in the sense of a verifiable fact) it will still produce underwhelming outputs. And not only are LLM users unable to detect that the outputs are underwhelming, but their internal bar for quality progressively degrades to the point that even their own work begins to approach the mediocrity of the machine.

I don’t want to blame workers for this. People I know & respect who have surrendered to AI have done so under extreme duress. I’ve been writing about AI usage mandates here and there on the Picnic, and especially how those mandates are accompanied by a lack of other concrete guidance.

In the presence of demands to use a tool, without a clear understanding of what using the tool is meant to accomplish (beyond “more velocity”), workers are increasingly forced to abandon their own judgment in favor of the logic built into the product. Workers must either do their jobs in spite of the tools being forced on them (and thus drown under the deluge of added workload), or follow the path of least resistance and become a clerk for the machine:

While designers are accustomed to sitting on our hands and complaining that we have no power, notionally there is some leader in your company responsible for the design practice. But those leaders have largely abdicated these responsibilities. VPs and CXOs who built their entire careers on governing pixelfucking can do nothing for their subordinates now.

“Faster outputs” was the governing principle of their life’s work, but today “going faster” means going without designers entirely. If we want the profession to remain relevant, we need to avoid cognitive surrender, and ditch the leaders whose limited skillset drives them to advocate for it.

Prevent cognitive surrender from leaking into your work

Outputs without outcomes may be the default, but it’s far from the only option available to us. Managers with a real point of view can make all the difference between shipping as much as possible in case good ideas will arise by chance, and making a choice about where the team can make real impact:

This kind of pivot can’t happen beneath the level of strategy. Tactically seeking out pain points to solve has extremely low returns, no matter how quickly you can churn them out. And if your leadership isn’t up to the task, you need to get some design judo going — for which no amount of high-fidelity prototyping will help you.

Artifacts that don’t exist on the fidelity cascade (such as power maps) are the only thing that will help you break the cycle. And as with all such maps, it’s the work of making it, rather than the thing itself, that creates value.

— Pavel at the Product Picnic

Howdy, picnickers!

The “news” part of this newsletter brings some coverage of the drama at grammar police company Superhuman brewing all month long, when Wired found that Grammarly had sneakily added a feature that creates AI impersonations of famous writers without their permission. After a week of non-stop intense backlash (and a class action lawsuit) they quickly rushed to take it down.

Superhuman’s CEO Shishir Mehotra then did an interview about it. Malka Older¹ has a great close reading of it over on Bluesky, to which I would like to add two things:

• We find out from the interview exactly what kind of advice the feature gave out (nothing like what the writer it’s impersonating would have said).

• We also learn that engagement with the feature was poor; turns out crime doesn’t pay.

There’s a lot to say about the cavalier attitude towards both other people’s intellectual property, and what it means to receive knowledge and apply it. Christine Haskell puts it well:

Reading between the lines, Mehotra’s interview paints a picture that I think many tech workers will find familiar: features are conceived, coded, and shipped as quickly as possible. He is happy to admit that the feature was a mistake… in retrospect. But in the moment it actually mattered, critical thinking was swept away by the false urgency of pushing things out.

The industry is in the grip of directionless urgency

We often hear about how AI is “empowering” people to do this or that. Next to “democratizing” it is probably the most common techno-solutionist cliche. But just like the “democratizing” line is full of problems if you stop to think about it, so too is “empowering.”

Lara Hogan has a very good framing in this talk (see also the blog post). Empowerment, you see, is the opposite of direction. It’s good to empower people when you want them to explore and play around in a low stakes context. But under time pressure or when there is risk, what teams crave is direction.

Remember when we had a diagram segment? Maybe I should bring it back.

Look at that list, and then think about how LLM coding tools are being rolled out. The entire conversation is around urgency: you must be more productive yesterday. Work directly in code, because it’s faster. Commit your vibe PRs.

But no direction is forthcoming. We are being told to run faster, but not where to run to. There’s no clarity beyond a demand for outputs. No wonder teams feel lost.

The result is that businesses are faking their results from AI adoption. Those outputs are easiest to measure, so that’s what gets trumpeted as success:

This mindset has taken over tech to such an extent that even designers are trying to show our value by contributing to these metrics. Unfortunately, this is counterproductive; the entire purpose of our role is to provide the direction. When we abdicate that responsibility, we make it that much harder for our colleagues to do good work.

Because there’s a rhetorical sleight of hand involved with “empowering” everyone to write a line of code. A line of code does not have quality in and of itself, because it does not really have meaning on its own. You might as well pick an individual line of this blog and try to evaluate its quality. Code is a credence good (I truly recommend this article if you’ve only ever read AI takes from a tech perspective before), which is a fancy economic term for things whose quality is not apparent to the buyer:

This naturally makes one wonder: if we can’t know whether what we ship is “good” until it reaches the user, surely we do our best to observe that interaction!

Well, no. Of course not. How could you ask that? That’s not very agentic of you. The highest velocity — and remember that you are solely being measured on velocity — is obtained by yeeting things into the void and never checking if they worked.

Vibe prototypes undermine our ability to provide direction

Let’s take the claim at face value: some things can only be learned by shipping. That is, we must observe user behavior to learn what we need to know (if you don’t know what you are trying to learn when you ship a prototype, do not ship a prototype).

Having LLM-generated code within arm’s reach feels like the best approach for this. It’s so fast! It’s so magical! But it also undermines your ability to decide what it is you want to test. If you want to test direction rather than mere execution, you do not need any code at all: Andrea Ong is launching a business with a poll and a Notion page plus talking to a bunch of people. The list of features was not the most important thing for her to test, and so she didn’t.

At a time when hotshot thought leaders are proclaiming the death of design tools because now everyone can just “do” code, we seem to have forgotten that the point of the tools was to realize our intentions rather than merely manufacture a product:

This is not to say that code is not a design material. It is; the same way as paper, or a canvas, or boxes and arrows. But the wonderful thing about design materials is that they are not just one thing. When people say “code is a design material” they are often talking about UI and how Figma does box models wrong. Which is fair, but it’s a tiny sliver of the whole story.

If code is a design material, then coding is designing. If coding is designing, then the job is not to actually write code, but to create a theory for how a system might behave:

When we reduce programming to lines of code deployed to prod, we obliterate this process of theory-building. The computer transforms from being a part of the system into being the entire system. Which is a critical mistake, as Nilay Patel emphasizes in that Grammarly interview: for most of us, the margin on bits is gone, and what remains to most people is the margin on atoms. Things happening in the real world make money. Things happening on a computer just send money to a platform landlord.

But doing this is hard. It’s much easier to just push out new features. This was always true, and it’s even more true nowadays. There’s even a name for this phenomenon of giving up and letting our tools dictate what we do next: cognitive surrender.

We’ll cover that next week.

— Pavel at the Product Picnic

1: While Dr. Older has impeccable academic credentials, she is also a fantastic fiction author. Her book Infomocracy is a must-read for anyone who sees themselves as a systems thinker. I’m not even being paid to say this.

Today I want to pull out two ideas from Cameron Tonkinwise’s Service Design and Social Complexity (although it goes without saying that the essay itself has many more ideas I won’t have a chance to touch on in this format).

The first idea is a tidy formulation of what design is. Cameron talks about service design specifically, but this idea is broader: that there is complexity, and regularization, and we broadly associate design with the latter. Linux vs Apple. “Don’t make me think.” But designing is not solely regularizing:

The second idea is the keystone for this issue of the Picnic. Cameron doesn’t say it outright, but it jumps out at me from between the lines: process design is service design. The design process — hell, the entire product delivery lifecycle — is a structure that manages relationships of service between parties. The entire thing is governed by formal and informal agreements of exchange.

Or, it used to be. Because one of the highest-profile promises of the so-called AI era is that service relationships are for dopes, and you can opt out of them. People can be replaced entirely, or at least pushed to arm’s reach, by agents who will perform the same tasks for you.

Design undermined its own service relationships.

Not all service relationships are equally impacted. Those that were deliberately designed will endure. But ours were designed by circumstances; design was in the room because stakeholders needed someone to draw the pictures. We never managed to convince them otherwise; our appeals to craft and taste reinforced the notion that our value was that of an artist, not a strategist.

Design made itself very vulnerable to this disruption long before ChatGPT came about. We were already letting tools and templates think on our behalf. The AI part is just a small increment on top of a design practice already defined by dropping the right pattern in the right slot along the user journey:

Even today, the reflex of the designer is to demonstrate how good we are with these new tools. But stakeholders who didn’t already care about design won’t start to care just because you “learned AI.” The value proposition of AI tools is not “more productive colleagues” but “no colleagues at all.”

We cannot repair the service relationship by getting really good at the tool made for rejecting service relationships. All it does is accelerate the collapse of those relationships — and along with them, the collapse of design’s professional identity. The feedback loop between making and thinking is replaced with a unilateral, janitorial responsibility: stakeholders make, designers clean up.

What’s left of the design process is now in tatters. We already talked about the “brain fry” associated with checking an endless stream of AI outputs in a prior issue. But when design is the designated janitor, all that brain fry becomes concentrated in ourselves; the pain of using AI tools is invisibly displaced onto people told that they should be happy to still have a job.

The worst part is that you can’t QA your way into faster velocity, because each review cycle makes you 10x slower. You can only accelerate delivery by eliminating the need for review stages, which requires teams to embrace a culture of quality. And when designers refuse to serve as a backstop for sloppy thinking, we see that the opposite has happened: without our help, the entire system has rapidly eroded. AI has managed to 10x the noise, but not the value.

The tools can’t help us anymore. We have to help ourselves.

Fortunately it's not too late, because being the person who made the tool do the thing is not design, and it was never design. Mastering Claude Code to push out prototypes more quickly will only intensify the problem that we find ourselves in, by putting more and more focus on a thing that lets us feel productive while the value-creating relationships around us fray into uselessness.

Prototyping was only ever just another tool to help us make one of any types of artifact that could then scaffold the design process. As soon as we began to over-index on the thing and not what we did with it, everything fell apart.

Because that’s where the actual productivity comes from: the relationships. Socializing your idea is the real value of the prototype:

The most immediate way in which socializing helps the prototype is that other people (experts in the domains you are not) can tell you that it’s wrong. Which is something that often feels forgotten: the purpose of prototyping is to try something in the cheapest format possible, so that we can come to know the ways in which it is wrong.

The promise of the AI industry — that you too can become a Leonardo da Vinci style polymath — is thus counterproductive to how ideas evolve and mature. People can have contextual knowledge; nuance that turns yet another generic app idea into a success. AI can only give you assumptions rendered down from one hundred million solutions, divorced from the problem in front of you. You end up shipping the same template as everyone else.

You learn nothing that way. And trying to accelerate that process by talking to even fewer people will lead to a lot of waste that can never produce the right solution. The AI will keep telling you that you are brilliant, and nobody else will care, because you will have automated the process of not listening.

Juicing up your AI skills makes you a better handmaid to the process of not listening. But it is not the process from which design derives its legitimacy, nor the process by which it creates value.

To close the loop with the first link: think about what you are choosing to regularize (or what is being chosen for you), and whether it makes space for beneficial complexity or drives it underground.

— Pavel at the Product Picnic

Hey there, picnickers!

It seems like only yesterday that everyone was talking about how UX is dead (it was actually almost a year ago). But if you missed that discourse, good news: UX is dead again. Or specifically the design process, if the head of design at Claude is to be believed. Replaced by AI, of course.

Design is the applied science of decision-making

But while the breathless claims of design’s demise were taken at face value in 2025, people have caught on to the game at this point. When reading beyond the headline, it becomes clear that what AI proponents are actually mean by “design” is specifically production design.

The alleged death of the design process has nothing to do with AI at all; production designers abandoned it years ago as they fully switched gears to mastering Figma layouts for a living, and AI is just an excuse for them to finally admit it. But this approach to design relies on someone else doing the rest of the work for them:

We can actually trace back this obsession with ever-faster cycles to the erosion of the design process. Without strategy, throwing things at the wall to see what sticks (frequently described as “build to learn”) is literally all you have left. You must ship an order of magnitude more things just to learn what research could have told you in an afternoon. You must “validate” all ideas in production, because you have no clear problem framing that would let you evaluate “good” in any other way.

The allegedly-dead design process has this cycle of trying and checking, too. But it can do this faster than an AI-generated prototype pipeline, because showing sketches to your team is always going to be a tighter feedback loop. And unlike validating in prod, this feedback loop also feeds back into problem definition. We can know we are wrong before we write a single line of code, because we realize we are solving the wrong problem.

AI makes you worse at design decisions

In this respect, the more AI you have in your process, the worse you are at it. Chatbots make you less likely to collaborate with other humans. They constrain your thinking towards a single, monotonous mode. And because they push you to move at a machine pace, while research with users happens at a human pace, it becomes ever-more tempting to lean into the illusory productivity of “building” in complete isolation from customers.

Baldur Bjarnason wrote a longer piece last year on the extent to which LLM usage can hijack our judgment — and thus our ability to evaluate its effectiveness. We feel like we are more productive, but we end up being misled by those feelings, because we can never be dispassionate observers of our own activities. Yet another study out this week shows how AI use actually intensifies work, but it is also interesting to look at the qualitative, self-reported data: AI proponents largely brag about the volume of work they do, not its fruit. They are, as the kids say, hustlemaxxing.

The bitter irony of it all is that the more of ourselves we invest into knowledge work, the more our judgment is undermined:

Designing the solution without framing the problem

LLM-driven tools afford making outputs, so we make lots of outputs with them. But orienting towards outputs means orienting away from thinking about the problem. This works fine when you are a production designer and answering “what should we be doing?” is someone else’s job. But if it’s your job, outsourcing this question to AI is going to be a disaster.

Because the real problem is in the world, and you are in your office. Good designers — designers who don’t see the design process as a waste of time before you get to the “real” work of making outputs — know that they need to get out of the technology to find the problem.

I think by this point, it is clear that the real design process bears no resemblance to the linear “one-and-done” approach that design students take when practicing the Double Diamond for the first time. Discover, Define, Design, and Deliver do not have a secret 5th sibling named “Done” — the process is a cycle, a feedback loop, and like all loops it never actually starts at the beginning. No matter how early on you’ve been brought in, someone somewhere has already been doing something. Your job is not to hit them with a prototype at the highest possible velocity, but to understand what it was. Excavate what has already been done. Talk to humans.

— Pavel at the Product Picnic

I’m sure you have heard that LLMs are inevitable. One of the figures cited to demonstrate this inevitability is the adoption rate of ChatGPT, which hit however many million users so much faster than the previous record-holder. The details of the claim change periodically and frankly are not all that important for people who understand the dynamics behind technological adoption.

Adoption for truly revolutionary technologies is still slow, just like it has always been. Adoption is quick for incremental technologies that are highly compatible with existing social processes. The adoption curve of cellphones was steeper than for landline telephones, even though going to a cellphone from a landline is a much smaller improvement than going to a landline from nothing.

At this point, the darling of the AI discourse is Claude Code. It is popular precisely because it is not revolutionary. It fits neatly into the values software orgs have been adopting ever since managers heard of Agile and thought it meant “faster software delivery.” “Data driven” is the name of the game, and speed has been the north star of data driven orgs simply because it is much easier to measure:

AI is, of course, the technology best suited to emulating vigorous activity. With a prompt, you can produce in seconds what it would take a mediocre programmer hours of work. This is a clear velocity improvement, as long as you’re measuring velocity as time to outputs, rather than time to outcomes.

“AI can make mistakes”

People tell me that this works better for code than it does for other things, because code quality can be checked by automated tests. This is a very 2003 way of looking at the world: our requirements are knowable because someone else (the business) gave them to us. We are only responsible for making sure that our outputs check those boxes.

This is why code can never be the source of truth. Kevin Muldoon lays it out clearly: code can be the ontological truth (what is), but it can never serve as a source of normative truth (what must be). For that, you need some kind of specification that says what the code is supposed to do, and then the tests can confirm it is doing that thing.

The trouble, of course, comes when the people responsible for writing those requirements are the ones vibe coding. And maybe your “requirements” are just a slopotype with a sticky note slapped on top that says “ship this.”

First of all, you should never ship vibe code in a professional capacity. Just don’t do it. It’s probably fine for n=1 users, but for anything remotely real what you have is just a spicy sketch. Ben Werdmuller’s feasibility rubric is the perfect demonstration of how much maintenance and risk eclipse the momentary euphoria of code that works in a demo context. In a fundamental sense, all code is technical debt, and the most maintainable code is measured in negative LOC.

Tests (especially tests written after the fact) can only tell you so much about whether the code is fit for purpose. It’s always better to just not ship the prototype than to “check the AI’s work.”

But even if you are willing to completely refactor the vibe coded prototype in the pursuit of shipping it, there is an even tougher problem at play: there is no automated testing for requirements. How do you know whether the sketch is fit for purpose?

AI is a machine that turns quality assurance into burnout

Spoiler: the AI’s output is mathematically guaranteed to fall short of the right thing. When it comes to creative problem-solving, an engine based on statistics is only ever going to output a statistically average response. And sometimes that is good enough. The trouble with LLMs is that they can’t tell you when it isn’t.

The burden of determining whether the proposed solution fits the problem in question is placed entirely on the operator, as Jennifer Moore explains. Not only on their judgment, crucially, but also their attention. After a dozen cases of the AI giving a good enough answer, how determined will you be to keep checking? Especially when higher oversight of AI outputs directly correlates with higher mental fatigue?

When the work happens inside your brain, you get into a flow state. When you have to keep checking the outputs of an artificial brain before you can continue, you burn out. And the very same volume of these outputs that makes you feel productive keeps you chugging along long past your body’s natural stopping point.

So it’s no surprise that people, in practice, don’t “check the work” of their AI assistant. In a way, they are preserving their own peace of mind by choosing not to do so. Great for them. Bad deal for anyone downstream who has to turn their AI-generated prototype into a product.

A common refrain in today’s UX discourse is that designers are uniquely suited to this kind of checking because they have great taste. But you will not be able to convince anyone that the design they generated is bad by saying “I looked at it with my great taste and I can see that it’s bad.” No one cares about your taste.

The definition of Good

The way you check if AI requirements (AKA specs, AKA designs) are fit for purpose is the same way you check if a human design is fit for purpose: critique. I went on a rant about this over on Bluesky but Rachel Been explains it thoroughly here in an article format:

Why is this depth missing? Because it requires conceptual understanding of a problem, which only emerges as you engage with it. That is what good design critique seeks to strengthen. It is structured to stress-test decisions: what was the purpose, why did you choose to do it this way? Did you try other ways, was there a better one?

Having AI extrude a prototype robs you of the opportunity to interrogate those decisions throughout the process. The answer you got is not the best answer of many; it’s just the one the machine gave you, that looked alright to pass on down the line. Understanding whether the artifact is fit for purpose is part of a feedback loop of understanding the purpose; both evolve in parallel as we work on the problem and the evolution does not occur when the work is skipped.

Sure, AI can type a million words a minute. But productivity isn’t capped by how fast you can type. It’s capped by this process of developing conceptual fidelity. Attempts to skip it by adding more detail don’t actually add more fidelity to the design. The detail becomes a distraction.

The LLM won’t help you understand the user’s goals any quicker than human pace. And understanding their goals is the prerequisite of understanding their problems. Only then can you define success, and therefore start iterating on solutions that arrive at that success.

The LLMs might be able you help you with production work. But skipping straight to the production work, because that’s where the magical tools live, is doing yourself a disservice.

— Pavel at the Product Picnic

I was going to write about something else this week, but then on Thursday, this happened:

this is not the actual tweet Jack sent, but it might as well have been

So instead, I’m writing about AI again. At this point the ground has been well-tread, but if you want a primer on all the problems (especially if you think, but AI is useful to me personally!) I strongly recommend Eryk’s piece here:

Layoffs are not productivity-related, so you can’t protect yourself through productivity

The company Jack Dorsey is talking about is Block, formerly known as Square. And while people paying attention to the company noted its poor structure (operating three redundant orgs) and lack of leadership (Block’s stock price is down 70% from its peak), internet commentators latched onto Dorsey’s claim that the layoffs were due to AI-driven efficiency.

The commentariat rolled out the same claims as always: of course AI tools make you more productive, so if you don’t learn AI skills, you will be replaced by people with AI skills. However, it is difficult to reconcile these claims with reality: among the victims of the layoff were many high-performing AI enthusiasts.

Not that the connection between AI and productivity is exactly well-established. Keeping the APIs functional is a part of the job LLMs still can’t do, and reliance on AI agents has caused some high-profile outages lately. The successes, meanwhile, seem to be illusory: Cursor’s claim about vibe-coding a browser falls apart under scrutiny, and the Anthropic-funded study claiming that AI replaced 11% of workers was actually referring to simulated tasks (in other words, Claude marked its own homework). Accenture has been reduced to logging employee hours in AI tools, because the productivity of people who use it is otherwise indistinguishable from people who don’t.

Seniority makes you a target

A common claim from LLM proponents has been that only senior, experienced users get these benefits, because you need a high level of competence to know where to use the AI and how to check its work. Early-career workers are the ones most likely to have their skill formation negatively impacted by AI (this thread by Jennifer Moore dives deep into the mechanics of this).

So you’d expect Block to ditch these low-performing juniors and retain only high powered 10x developers who can harness the power of AI, right?

Take a guess. Then read Jürgen’s article, and guess again.

Those affected in Block’s layoff came from the ranks of senior developers and PMs. Because layoffs are always a cost control measure. And in a world where leadership sees every role as fungible anyway, cheap junior devs banging away on ChatGPT are just as good as the expensive people. Maybe better, as models don’t handle complex tasks nearly as well as churning out boilerplate code for less-demanding users:

We see this effect manifest itself in a benchmark test of how good various models are at making web UIs accessible: in multiple cases, expert guidance actually produces a greater number of defects, because the model simply cannot comply with what is being asked of it.

So getting rid of the pesky experts who get paid more to slow down the process with unnecessary things like “checking if the code does what it’s supposed to” is a win-win. In a race to the bottom where the value is solely blasting through to the next set of deliverables, your skill and craft and taste are maladaptive.

Cultivate skills to bounce back from a layoff

But it's no picnic for juniors either. The rate of hiring early-career workers was slowing long before ChatGPT stumbled into the spotlight, due to a confluence of related crises caused by chasing short-term wins. Hedgpeth’s advice (to take ownership of your career development) may be the reason that seniors bounce back at a faster rate: they can fall back on the presentation skills they’ve honed over the years, the networks they have nurtured, and the unique intersections of interests that make them stand out in a crowded market.

The best time to give this some thought is before it becomes existential. Despite (or perhaps because of) the AI hype cycle entering its disillusionment stage, the layoffs show no sign of stopping. But after those layoffs come waves of rehiring, as companies experience AI buyer’s remorse.

And when that happens, the people filling the roles won’t be the ones who became the most reliant on AI tools. The people who will stand out will be the ones who learned how to write.

— Pavel at the Product Picnic

Open your favorite thought leadership page and scroll for a few seconds. Chances are, you’ll quickly find some screed about how the reality of software development is changing and we have to adapt to it.

Well, I have news for you. The reality of software development changed decades ago, and we still haven’t adapted. Today’s teams are using LLMs to push black-box code they don’t understand into production — but between plentiful open-source libraries and StackOverflow copy-pasting, they were already doing that.

Code hasn’t been the real limit on productivity any time in this century, and yet all of our work processes are structured as though it is.

The social systems of work are coming apart

What was (is) the limit? Getting signal from customers.

You don’t need high fidelity to learn that you are barking up the wrong tree. The easier coding becomes — and the more you produce before showing it to a user — the more effort you end up investing into being wrong. It’s no surprise that while HBR has found that AI intensifies work instead of reducing it, execs forecast an anemic 1.4% productivity growth over the next 3 years.

Alas! It turns out that all the other people in the office with you aren’t merely decorative. Work is a social system and productivity improvements localized to a part of the workflow that was already completely unblocked are not going to reflect in the bottom line.

Unfortunately, companies have been doubling down on obliterating the coherence of that system with endless waves of layoffs (which they blame on AI — and even Sam Altman isn’t buying all of these alleged productivity gains from his own product). This, not LOCs per second, is the #1 blocker for productivity growth.

Rather than help, the presence of AI is actually making it worse.

An atomized team is the antithesis of UX

It’s easy to pretend that continuity isn’t important, as long as you can get your deliverables over the line every two weeks. But is that really what you want to write in your promo doc, or on your resume? No one cares about your story point velocity. Managers want to see impact and ownership. And without engaging with work-as-a-system, you will never achieve either of those.

Long before AI rolled onto the scene, the “build to learn” ideology had already done irreparable harm to people’s ability to understand this system, through the simple means of convincing them to pretend that the system does not exist.

But no matter how hard you try to ignore it, the system is there. You can’t just build your way into PMF. You have to do all the uncomfortable, squishy work around the software. Like research.

Unfortunately, research means talking to people, which means that research can only ever happen at a human pace. It can be tempting to skip that research by relying on heuristics (for example assuming that efficiency is always good, and optimizing for that) but that approach is always going to burn you. The state of the art moved past simple time-and-motion optimization in the 1960s, and it’s time to get on board.

Good user research, not output velocity, unblocks productivity

It’s easy to assume that someone else already talked to users, and figured out what they wanted. Even the Agile manifesto carefully excludes the work required to actually compile requirements. And in the decades since it was written, the situation has only gotten worse: tooling has helped us deliver more quickly, but it has done nothing to help us learn what to deliver.

This perverse incentive has led a lot of people to foolishly use AI to counterfeit research data (which is often sold to low-maturity teams under the moniker of “synthetic” research) just so they can get back to shipping deliverables, which is easier and smoother and less complicated. And also provides zero actual value.

There are many excuses for not doing real user research. But if you want to anchor your work in real data instead of sparkling assumptions, you’re going to have to get over those excuses. Once you’re ready to do so, Stephanie Walter has made it easy with a comprehensive guide to user interviews that will get you started even if you’re not an expert.

Which brings us back to the thing about code. Why doesn’t the ability to reach high fidelity faster accelerate our learning? Because the “blockiness” of our research artifacts is actually a beneficial property. Good research isn’t looking for a yes or no; it’s creating a dialogue with the participant, and low fidelity leaves the possibility space open as wide as possible.

And when you’re finally ready to write working code? We’ve known for ten years that testing by launching a viable product is foolish. Good research will not only give you answers, but also let you develop a sense of what data is convincing enough, and which assumptions actually warrant testing in prod.

— Pavel at the Product Picnic

“AI can make mistakes.”

This phrase might as well be the slogan of our era. It follows on the heels of LLMs being hastily jammed into various places, from software development to courtrooms to surgeries. But for some reason, it’s seen as a get-out-of-jail-free card: AI can make mistakes and yet we should still use it (must use it, at some companies). AI “will get better someday” but we must use it today, while it still confidently makes such catastrophic errors.

We are extending unearned grace to LLMs

It’s common to talk about AI “replacing” such-and-such jobs. Implied within that word is some equivalence: that the AI is meeting the same bar that the person had set. Nothing could be further from the truth: the AI does a subpar job, far below the bar set by a professional. Even in coding, where proponents self-report the most benefits, LLMs actually create more bugs, more technical debt, more cognitive load.

In the public sphere, we also see AI behaving like a bad citizen. Their creators ignore no-crawl directives in the search for more training data. Small hosts are drowning under what is effectively a VC-funded DDoS attack. Between these scrapers on one side, and anti-browsers on the other, AI is killing both the infrastructure of the Web and the livelihoods of people who make it the vibrant place that it is today.

I want to call out this particular essay because it simultaneously highlights the ransacking of the public square and points to a piece of the puzzle I’ll talk about in a bit: the social structure that AI toolmen create to place their products beyond reproach:

If a colleague had the reliability rate of an LLM, they would be fired. If ordinary software did, it would be banned (indeed, we are seeing social media crackdowns for much lesser harms than chatbots inflict by design upon their users). Instead, companies give LLMs responsibilities that they would not trust their top humans with.

So how did AI tap into some endless well of grace? And why are companies putting up with it when it repeatedly threatens their own reputation and bottom line?

The intelligence illusion

The ELIZA effect is familiar to anyone who knows that AI wasn’t invented in 2022. A chatbot is anthropoglossic — it communicates like a human — creating an illusion that there’s a there there. I know a number of designers who are frustrated with “chat” being the dominant interaction pattern with LLM tools, but the reason for that is simple: without the illusion of another intelligence on the other side, these tools just aren’t very impressive; certainly not “VC billions” impressive.

Unless the design signals “this is AI!” at every turn, the illusion of magic disappears. It becomes regular software, and stops being forgiven for its unacceptable failure rate. But because it is a chatbot, we are willing to lend it our humanity endlessly. The same people who lose patience with a delivery team (for having to explain what they want the team to build) will be willing to go through endless iterations of prompts with a bot, burning credits with every cycle.

We are willing to put up with more from our new robot overlords, and expect much less in return:

Is it because of the sycophancy? Because of the halo effect? Because we mistake faster for better?

I propose that it doesn’t actually matter.

Empathy for colleagues

The LLM experiment has taught us one thing: people are willing to tolerate error, explain themselves, collaborate, trust. Today, they are choosing to invest this positive energy into a synthetic slop extruder. But tomorrow, they could invest it into their fellow human beings, if they chose to do so.

I’m asking you to make that choice, and to help others around you make it too.

Take the grace you reserve for Claude, and instead extend it to the people you work with. Be patient when explaining what you need (in writing specs, and in critiques — both design skills). Set expectations that emphasize what matters. Take the time to understand their limitations, and leverage their strengths. Polish only what’s important, and don’t sweat the stuff that no one cares about.

Make the effort — because unlike an LLM, this relationship can go both ways. People can teach you new things. People can ask clarifying questions that help you refine your own thinking. People can provide their own experience, their own point of view. People can take initiative, and make progress towards goals you share.

And perhaps most importantly, people can build collective power. If you are going through some bullshit at work, ask a human colleague if they also think it is bullshit. You might be pleasantly surprised.

— Pavel at the Product Picnic