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

A side effect of Design Thinking was the penetration of design terms into the collective consciousness. For better or for worse, it gave stakeholders some limited vocabulary to express what it was they didn’t like about a product.

“Intuitive” is the perfect example of this trade-off. Users demand software to be intuitive. Stakeholders and cross-functional partners use “it’s not intuitive” to strike out design decisions they don’t like. And yet, no one can precisely define what “intuitive” actually means. Because at the end of the day, there is nothing intuitive about user interfaces. The word is, instead, a shorthand for “familiar”: I have seen this before, I recognize how it works, I can reuse lessons I learned in the past.

Toxic metrics have propagated from the socials to businesses

This is one of the many reasons that design patterns tend to reproduce themselves. The other main reason is that it’s easier to copy what someone else did than to come up with your own solution. Which creates a perverse incentive: the memes that propagate within UX and Product are whatever is most salient to practitioners.

In simpler terms: if one product yells at you, other products are more likely to decide that they should yell at you too.

Anxiety (2026), pixels on LCD matrix.

Anyone could tell you that people are overwhelmed, that the attention economy is struggling with inflation issues, that what we need is more calm technology. But it’s not what we are building.

Instead, what the paradigm of salience-driven copying has given us is universal phantom obligation. Every experience is being designed to yell at us, whether it makes sense for the context or not, because that is what stakeholders have seen other experiences do.

But recall: our tools shape how we think (I feel like I need to add a section to this site for evergreen essays, and this one just may be at the top of the list). Our notification-heavy software trains us to behave in ways that appease it. Not only to rush to attend to the notifications, but to create notification-worthy outputs so that our work may be granted attention in turn.

Through this mechanism, the toxic logic of algorithms that nudge and influence and control consumer tech makes its way back to its very designers. Our professional decision-making becomes influenced by the exact same factors. Individual contributors ask: what will show up on the dashboard? Managers ask: what figures from the dashboard can I present to my leaders?

This is not value. And the more you lean into dashboard thinking and let algorithm vendors privatize your brain, the less actual value you will produce.

Chasing metrics is not a strategy

Sure, the metrics are supposed to be a proxy for value. But long-time readers will know that this is rarely the case. Bureaucracies prefer to track what is easiest to measure, rather than what is most relevant. Often, what trickles its way down to us is not the actual strategy, but merely these metrics. And if you want to do work that actually matters, you owe it to yourself to reverse-engineer the strategy out of these metrics.

This will let you tell which part of the dashboard is noise — present only because it is easy to track — and which part anyone actually cares about. And the latter may not appear on the dashboard at all!

Because what people tell you to focus on is rarely “strategic.” The attention economy rears its ugly head here again:

But what is urgent is not always important, and developing a reputation as a product janitor is not equivalent to long-term career prospects. Valuable, strategic action is coherent action and it behooves us to resist the noise fueled by snake oil sold as “best practices” and think about what we are actually doing. And of course, to propagate that thinking throughout the organization.

Counter-intuitively, this means that under-appreciated domains such as internal tooling, to which no one in your org has actually given any thought before, may be the best opportunity to set your own definitions of success — one that meaningfully aligns with the strategy, and not just the most salient vanity metric at the time the dashboard was being built.

— Pavel at the Product Picnic

One of my most controversial opinions is that designers are not special; the “everyone is stupid except me” attitude is not only counterproductive but downright wrong. Our enemy is not Product and Engineering; our enemy is Projects and Coding.

Coders vs Engineers

Iris Meredith’s Becoming an AI-proof software engineer makes the distinction stark. The entire essay is worth your time, but there are two key points I want to pull out for my purposes. The first is the importance of maintenance (regular readers of the Picnic will remember I’ve talked about maintenance before, in the context of UX):

Engineers can’t think in short-term projects and features, because they take responsibility for what they build. Someone who sees their job solely as writing code is missing most of the job of being an engineer. And if all they do is code, they are merely a coder.

Unsurprisingly, the second piece of advice I want to emphasize is for engineers to learn something that isn’t code. Not only because it helps stretch the mind, but because it creates an appreciation for expertise from other fields. Coders lack this appreciation:

This framing benefits from a callback to Olia Lialina’s timeless 2012 essay, the Turing Complete User, which itself cites a 1987 piece by Ted Nelson. After all, there is nothing new under the sun. What bedevils us today is the same thing that bedeviled us in Lialina’s time, and in Nelson’s time, and in the decades prior: the myopic belief of coders that the computer is the only thing that matters, that in some sense only the computer is real.

Yes, finally we are getting back to UX (Don Norman makes an appearance!) but this is very much an engineering text. The very same people we assume “don’t get it” write this:

Hopefully, the distinction is clear. Engineers think in systems, and those systems include real-world components. Coders only care that they finished writing their code, and now the finished code is someone else’s problem. Because coders only contribute code, they can can be easily replaced by Cursor or Claude, which can contribute much more code, much faster.

Projects vs Products

This is why I love delving¹ into analogous domains. Because we can take the exact same lesson and apply it to product and design. If the way to AI-proof your developer career is to stop being a coder and start being an engineer, then the way to AI-proof ourselves is to stop thinking about the work as projects and features.

In other words, cure yourself of computer brain.

When people talk about how AI is causing roles to merge, these are the roles they are talking about. Being able to prompt up a prototype before the problem has even been framed is not a design skill, or a product skill, or an engineering skill. The people chasing this niche are all going to be replaced by middle managers who can do the same thing just as well.

Or do the thing even better. Because the manager’s unit of output is not actually projects. It’s predictability. Within management, the computer brain manifests itself as an organization driven by burndown charts. Data points exist only to be put into a slide deck and presented to the level of management above. And doing it yourself is always going to be more predictable than delegating it to a worker.

The definition of success becomes “check the box by the deadline.” The consequences of the box-checking exercise are not within the computer, and therefore unimportant, so long as the box became checked. If the outputs are regular, it’s ok that they are pointless, because we are Doing Agile (where “doing Agile” really just means doing two week sprints even though the sprints are killing us).

This is the thing AI is really good at. Click a button, and outputs appear. Ignore the coarse early signals of impending issues, and let the salience of vibe-coded prototypes carry you down the lazy river of false certainty.

To companies still practicing agency thinking and treating Agile as a way to squeeze more velocity out of waterfall, this is revolutionary. Now they can cut out 75% of their staffing costs, and still check off all the boxes. Wow.

Threading the needle between false certainty and helpless ambiguity

It should be obvious that the way to compete with this logic is not to get better at clicking the buttons yourself, but to play a different game. Stop chasing pure velocity as the only value you can offer.

It’s not an easy task, because bringing up problems without solutions is usually stigmatized by the types of managers who don’t want to be snapped out of the artificially logical computer world, where the dashboards and the chatbots (and the dashbots) whisper only stories of inevitable success.²

One of the really effective ways of pushing back against this false certainty is to give managers exactly what they want: granular transparency into the work. The key difference is that this transparency is not modulated through a Gantt chart, but through the lens of your choice. Unpacking tasks not only helps you estimate better, but it also helps identify gaps in the thinking that the slick vibe coded prototypes paved over: if we expect X to happen, what is the user behavior that leads to X? Do the users know that’s what they are meant to do? Are you sure?

However, don’t over-index on the estimating too much. Chasing estimates is also project thinking. Estimates only have value to project managers, the computer-brained overseers of the burndown chart.

If you really want a deep dive into how chunking work into small pieces & making it visible pays off, read Dorian Taylor (specifically ROI of a Solved Problem and The Principle of One Degree).

To aim the course of your product development down a more productive path, there are two tools you should know. One is the pre-mortem (here’s a practical case study about using pre-mortems to get a design systems team off the ground). The other is the Futures Cone, which is simple enough that you can throw it up on a slide and dazzle stakeholders with your diagram prowess.

⸻

1: Do people still assume that using “delve” means the text was AI-generated? It’s a good word. I’m taking it back.

2: If I was using AI to write, would I have produced this horrible sentence?

Back when there was a Design Twitter, someone asked me: what should Design want? And I’ve been thinking about it ever since.

Individual designers want what most workers want: fair pay, and to be left alone so they can get some good work done. But of course we can’t get those things just by wishing for them really hard. Because: systems. And so my answer to the question of what should Design want — as, a practice, all of us together — is to create an environment where good design is possible.

What does an environment where good design is possible look like?

I’ll be digging into some of it next Friday at Throughline conference, but there are two things that didn’t make it into the talk that I want to cover on the Picnic.

Your process is a product, and the users are your colleagues

“Designers should do strategy” is the new “design should have a seat at the table.” But no one will ever just let us do it. We need to re-learn how to show up as equals, and reframe design’s relationship with the value delivery process

www.throughlineconf.com/speakers/pavel-samsonov

First: an environment in which good design is possible is an environment that nurtures a culture of maintenance. There is actually another talk at the conference on this very topic, by Ron Bronson — who wrote a piece on this theme last year. This is where those systems come into play: designers already do a lot of maintenance, but doing it within a culture that treats maintainers as janitors actively discourages those efforts.

Second: this environment should enable getting weird. We already talked a little bit about the inherent necessity of play and psychological safety for design to function last year, and the counterproductive erosion of our effectiveness by managers pushing predictable, linear delivery flows.

By now, readers of the Picnic might be confused, because I usually leave the “how to do it right” part for the end of the issue. But don’t worry: we didn’t just skip over the “how it’s being done wrong” section. Here it comes now.

AI created an environment where good design is impossible

The opposite of getting weird would be commodity-grade work: normalized, low value, large scale.

The opposite of a culture of maintenance would be a culture that valorizes velocity, of throwing things at the wall to see what sticks, and leaving what didn’t stick strewn across the ground for someone else to pick up.

If you guessed that I’m talking about vibe coding prototypes, you get a prize. What I specifically want to talk about is the system that vibe coding prototypes creates around itself. Even when the LLM does what it’s supposed to do (once in a while, the vibe coding slot machine really does pay out), how does it affect the great big social system we call work?

It turns that system into hell. Because while scrupulous professionals can get out of the addictive chat UI and deliberately evaluate the tools on the merits of getting important work done…that’s not how these tools are being adopted. Instead, they get picked up by executives hopped up on promises that they can ship their ideas right into production, bypassing all those tedious worker bees who used to be able to push back on bad ideas.

This has two important consequences. Firstly, while those managers fool themselves into thinking the AI is making everyone more productive, the reality is the opposite. Instead, the thoughtless introduction of LLMs into every process is a massive drag on environments that were already productive. Every expert’s job transforms into “workslop sifter.”

For any ordinary tool, people could say “no thank you” or — if someone else’s behavior was dragging down their ability to do work — raise it as an issue to a manager. But AI is The Future™, and you’re not allowed to refuse. Everyone is incentivized to slop as hard as possible by the very management whose job it was supposed to be to stop this.

And as productivity falls, the second consequence rears its ugly head. Managers feel the pressure to release something. The phantom velocity of the slopotype becomes the only thing capable of catching up and making the output metrics look good again. Teams give up on problem framing or divergent thinking. Assumptions — rather than being carefully interrogated (which is hardly done well even in functional environments) — become established as laws of physics.

Resisting the vibe code trap

Unfortunately, the trap that teams are falling into has irresistible bait. Prototypes are flashy and instantly appealing. Vibe coding lets you quickly do a thing that used to take a long time. The combination feels like a dream come true, even as the focus and rigor of your team unravels.

But none of this is inevitable.

One thing we can do more of is figuring out what the stakeholders are really asking and changing the conversation to focus on that. Forget the prototype for a second; what question are you trying to answer with this, or what decision are you trying to make?

LLMs can also be a “contrast dye for where resources are lacking” — they show up where people are being asked to do too much, without appropriate support. Without the LLM, the problem would express itself some other way. Is it possible to provide your colleagues with the necessary resources to do critical work well, and simply wind down the work that was never important to begin with?

These are just some of the ways we can start repairing the system that AI has wrecked, and getting back to a place where it’s actually possible for the field to move forward.

— Pavel at the Product Picnic

This is the 52nd edition of the Picnic, which I am writing exactly one year after the first one landed in just over a hundred inboxes. How far we’ve come!

I’m not going to do some kind of annual “state of the industry” post; we already know that the industry is in a state. But I do want to take this opportunity to talk about a topic that is near and dear to my heart, which is problem design.

And it’s a topic that is curiously missing from the discourse around the “real value” of our jobs now that LLMs are taking over the “make outputs and don’t think about it” slice of our discipline. Even the formerly-unassailable fortress of programming is now under siege (although as Iris Meredith shows in an extremely nuanced piece, devs who want to write working code that meets requirements have nothing to fear).

So we’re back to the old challenge: how do we elevate ourselves from the kinds of outputs that are swiftly becoming commodity grade? Everyone is talking about taste (or “product sense” if you’re a PM) or strategy as differentiating factors. But those arenas are contentious. Everyone thinks they have taste, and everyone wants to set the strategy.

Everyone must be a problem designer

The focus, in other words, is entirely on the solution. But the ur-problem is to define the problem in the first place.

This is a skill that has almost completely atrophied in an industry realigning around solving product problems (“put AI in it”) rather than customer problems (“as a user, I want to buy my juice”). Executives don’t want to just sell juice anymore. They want to empower you with an agentic, customizable, and seamless juice experience, because that sounds better to investors, even if no one has paused for a second to think about what any of that means. We’ll just “build, measure, learn.”

Unfortunately, what happens when you build first and only later trouble yourself to think about what you want to learn, is that you end up measuring the easiest thing to measure, which is usage. And then your feedback loop becomes an exercise in getting more usage. Value is no longer determined by what people get out of the product, but by how many buttons they click along the way. This is a complete inversion from people-as-customers to people-as-labor. 

As a result, users are tired. Not merely tired of the other demands placed on them by their lives (although this is also true, and a critical factor of good design). They are tired of products that are designed to extract the optimal amount of pain. They are tired of experiences that are designed poorly on purpose. They are tired of pages that claim to provide one thing, while their design is dedicated entirely to making the opposite thing happen.

This is the backdrop to every argument around “strategy” and “good taste.” Doing strategy downstream of a problem that was incorrectly defined is a fool’s errand (and lest I be accused of making up a guy to get mad at, here’s a designer asking what to do when user feedback contradicts the design vision).

But how do you design a problem well?

Good problem design is a practice of collaboration

I don’t think there’s a book (maybe I should write one) but there is a set of approaches you can try. One is simply to see if you can articulate a solution without a reference to a specific technology. Another is to talk about the expected behavior change as a result of your intervention. If your answers to these questions amount to “users will click our widget” then you have failed to design the problem correctly, and need to go try again.

This is impossible to achieve with “build to learn” because building is oriented entirely around technologies; it is subject to the same logic of metrics that has already led you astray. But you still have a chance if you “sell to learn.” Find the problems people are willing to pay you to solve — problems so painful that customers don’t care about which specific widgets or customizations your solution will support.

This is not a new idea. Many businesses and product teams do this. However, then they immediately throw all of that learning away by neatly packaging their findings into Jira tickets and bringing user stories like “as a user I want to click the button to go to the next page” to engineering leads for estimating.

As soon as any of the people responsible for solving the problem do not have a holistic understanding of that problem, you’re back on track towards a product users hate. A contractual, mercenary checklist of acceptance criteria will always produce a contractual, mercenary experience. When problem framing is not done together, it does not work.

If you know how to do this, then your job is safe, to the extent that AI is the driver of the layoffs rocking our industry, rather than a post-facto excuse. Because LLMs cannot do this; they cannot even help you do this, because the doing of the work is how that shared mental model comes into being to begin with.

There are tools that can help create this model. Tools For Thinking has a long list of strategies that let you create shared understanding. Jim Kalbach does a deeper dive into the value of experience mapping for alignment. But as Jim points out, the artifact is not the point. You need a process, and a culture, that cares about this stuff. It should not be something individuals go out of their way to do, but an intentional and intrinsic part of a cultivated practice of collaboration.

— Pavel at the Product Picnic

The foundational myth of our practice looks something like this: we find a big problem, we have an idea that can solve it, and executing on that idea unlocks orders of magnitude in measurable improvement. This is actually a humanities skill, called problematization, but never mind that for now.

For those of you who are hockey fans, or perhaps just fans of Heated Rivalry, Jen Briselli has a great new piece on how the game is a microcosm of a complex system. Every actor in that system has to anticipate not only the movement of a puck, but the movement of everyone else. Success comes not solely from technical skill, but also from positioning yourself to exploit multiple opportunities.

The whole piece is well worth your time. But there’s one quote in particular that is relevant to our Picnic:

Sounds familiar? It’s exactly this skill that actually lets a player “skate to where the puck is going to be.” If you assume that everything is perfectly going to follow your ten-step plan, you’re likely to find yourself on the opposite side of the rink from where all the action is.

This is where most product teams are. They are told “don’t overthink it.” They are told to build before they measure and learn. And so they must rely on their sense of what is supposed to happen; they solutioneer for imagined use cases.

Under this paradigm, research is limited to confirmation bias. Rather than being an ongoing activity of sensing, it is a one-off box checking exercise. Consultation happens only after the decision is already made. Inevitable success has already been asserted, and now we are only waiting for our users to play the part they are supposed to play.

“Better than nothing” is worse than nothing

This type of validation will usually be pitched as “better than nothing,” as though you should be grateful.

And this (sadly, inevitably) brings us to the most “better than nothing” product of all time: generative AI. Because when the purpose of research is to cherry-pick favorable anecdotes from data, it doesn’t actually matter whether the data is real. In either case, it is the reader, not the author, constructing the meaning:

Harry Brignull takes us on a deep dive of why Synthetic Users, the flagship tool of the “better than nothing” field of user research, is a load of plausible nonsense. But this is not the only place LLMs show up in research. Industry heartthrob Anthropic is now advertising their bot’s ability to act as an independent researcher, which is horrifying if you actually take a look at its interviews and think about what Anthropic believes acceptable research looks like. This is no “PhD-level intelligence.” It consistently makes mistakes that even an undergraduate wouldn’t be allowed to get away with: leading questions, inserting its own meaning, and generally acting as a confirmation bias machine.

This kind of research epitomizes the “remind me later” world in which we now live.

This is not a “glitch” in the AI. The technology is not “going to get better.” This is a design decision; this is what Anthropic wants Claude to do. The success of LLMs rests entirely on affirming and reinforcing the prompts of its operator. It is an extension of the sycophancy that is trained into the model during tuning. It is a deceptive pattern without which the AI industry simply does not exist.

The opportunity cost of AI

It should be obvious that using these tools in your research destroys your ability to problematize the system you are studying. Instead, what you get is an onanistic feedback loop that interpolates within existing knowledge, forever. The individuating fibers — those unexpected moments that seem at odds with everything else you know, that signal untapped possibilities — are strained out. You fiddle around the edges. Order-of-magnitude improvements are not coming.

It feels like you are getting something for nothing (generated instantly, the energy costs externalized, the compute costs subsidized — for now) and so “better than nothing” is sufficient ROI. But you’re just taking out a loan against a future burden:

And that burden manifests itself pretty much everywhere we’ve seen chatbot adoption:

• Employers are now far more likely to reject high-quality applicants (19% decrease), and end up hiring an underskilled candidate (14% increase);

• Where accuracy is important, employee costs go up alongside AI adoption: the more AI “speeds up” work at a company, the more time and money goes into checking that the work is actually fit for purpose;

• Outright fabrications still slip through, leading to reputational damage;

• The LLM’s output may look “close enough” but the actual work necessary to make it fit for purpose is colossal.

In all of these cases, filling in nothing with a “something” only absolved the chatbot’s user of responsibility. But the responsibility didn’t disappear; it was just transferred onto someone else. The alleged humans in the loop are swamped; senior leaders tell them that “productivity” and “innovation” are the most important things. They do the bare minimum to cover their own backs, and send the product downstream to the next hapless stakeholder.

What we can do about it

There is a defeatist streak within not only our industry but society in general. “It’s here to stay.” “If you don’t use it, you will get left behind.” These stock phrases get the cause and effect entirely backwards:

My favorite one of these concessions is one that seems the most innocuous at first; the wise middle ground between the skeptics and the boosters. “There are no bad tools, only bad people; you have to learn these tools in order to use them for good.” It is insidious because it paints the message as a moral obligation, and asks you to imagine capitulation to be resistance. Meanwhile, research shows the opposite: the more someone uses AI, the lower quality their outputs become. To understand the actual impact of LLMs, you’re far better off maintaining a critical distance:

There are many more of these stock phases, typically lifted straight from the marketing teams of AI companies. Gregg Bernstein writes a solid take-down of many that relate to research specifically.

But it is one thing to say no, and another to offer an alternative. Anil Dash rings in the year by talking about what the hell we are supposed to do now that tech and AI have become synonymous, which focuses on analyzing the system within which you work and finding leverage points beyond simply trying harder as an individual.

Once you have done that work, you might realize that we are being played for fools. The specter of AI casts a long shadow over our livelihoods. But when we try to push back against it — negate their argument — we are implicitly accepting its framing. “AI will take jobs, just not my job.”

That argument is still shaped like their frame. Instead, be like Kirby. Eat their frame:

And so we come back to “better than nothing” and the frame of that argument: that “there is nothing” was the whole problem, and by giving “something” we have solved it. It is brazen solutioneering. It is checklist thinking that allows executives to make it look like they did something.

The real choice is not between something and nothing, and it never has been. The real choice is between solving a problem and leaving it to fester. “Better than nothing” allows executives to pretend that they have done one, while actually doing the other.

The discomfort of “nothing” is a signal that someone’s duty was not carried out, a blinking red light on a dashboard. Breaking the lightbulb is “better than nothing.” The warning went away, and the pilot is off the hook up until the plane crashes.

Take Anil’s advice. Understand the system you’re a part of. But most importantly, identify whether your function is a need, or merely a want. Does your business model require that a thing be done well? Or is it merely satisfactory that it be done, and quality is someone else’s problem?

Needs get funding, and wants get “better than nothing.”

Remember: don’t assume that what’s happening is what’s supposed to happen — for example, that business decision-making about wants vs needs is rational:

— Pavel at the Product Picnic

Let’s set the right mood for the year, by talking about success.

After all, that is the definition of good products, right? They help our users succeed? Even in 2003, when Agile was in its infancy and our job was still called “web design,” Rico Mariani had already come up with an excellent user-centered metaphor called the Pit of Success:

23 years ago! When this idea was coined, some practitioners weren’t even born yet. So, to put it bluntly, why don’t we build products this way? I would even argue that the opposite is true today: the discourse typically revolves around building a product first, and only then groping around for “product-market fit.”

This is entirely backwards from how satisfying customer needs actually works, but it’s still the dominant mode of creating software, because we no longer share a definition of success with our customers. Thought leaders might beat the drum of outcomes-over-outputs, but VC dollars have erected an entirely different incentive structure: the important part of your pitch is where it’s located on the latest hype train, rather than what it actually does. Any problem solving is delegated to the customer under the guise of “customization.”

The allure of setting your own goalposts

VCs still want to see progress, but it is impossible to measure meaningfully as long as the goal is so ill-defined. And so companies must invent synthetic milestones:

To no one’s surprise, building towards fake productivity metrics rather than real user outcomes makes doing good work essentially impossible. Rather than optimizing the user experience, teams are incentivized to tweak their metrics collection processes to cast the product in the best possible light when the SDLC finally rolls over from “build” to “measure.”

The only real numbers in the entire process are revenue figures, because those are harder (though not impossible) to hide. For example, Meta’s “data driven” approach earns it a cool $16 billion dollars a year from scammers, and so it deliberately refuses to take action to mitigate scams and actively conceals them from regulators, even as those scams degrade the value of their product for their legitimate user base.

So how do we push back?

Historically, designers have tried to flex our influence by appealing to aesthetics. Unfortunately, “taste” and “beauty” are just another avoidance strategy; a poor alternative to thinking about user needs. And while high-profile designers are enjoying their narcissistic design solipsism, the rest of us (who need to use the website and not just look at it) must pay the price:

Iris Meredith has an even more fitting description for what these efforts amount to, here.

Change starts with uncomfortable conversations

When top-down incentives are misaligned, positive change needs to come from the bottom up. And that means having an awkward conversation with your teams and colleagues about whether you have defined success correctly. Until you have done that, your efforts to measure impact will be (at best) misleading, and at worst get in the way of doing the work that actually matters.

Our job is to face the ambiguity, rather than evade it:

However, it would be a mistake to think that we must (or even can) create this clarity unilaterally. While it is tempting for product professionals to think of ourselves as lone guardians of the vision, nothing could be further from the truth. The rest of our team can be our greatest allies, given the opportunity: beyond the most trivial, junior-level work, the job of software engineers is exactly the same as ours, reducing ambiguity.

Once you know what success looks like, the rest is easy.

Well, no, that’s not true; it’ll still be really hard. But at least that effort will be taking you in the right direction. You’ll be able to stop doing things that don’t matter and prioritize user needs over mere user wants (or worse, the wants of the product team).

And finally, you’ll be able to intentionally design your very environment into a system that enables the march towards success. There’s no one-size-fits-all approach to this work, precisely because everyone’s definition of “better” is different.

For instance, while executives the world over were repeating the same stock phrases around “return to office” being a necessity, Gitlab decided that “better” looked like remote work, and intentionally designed the way they work to achieve that outcome.

And what better time to have this conversation than at the start of the year?

— Pavel at the Product Picnic

Happy holidays, picnickers!

At the start of 2025, shortly before I started the Picnic, I left a five-year stint at Amazon. My announcement of the departure is my second most popular LinkedIn post this year, topped only by this image of a particularly funny sandwich.

Now that the year lurches to an end, the dumpster fire that began in 2022 is only burning hotter. People who were laid off are exhausted from endless bait-and-switch of ghost job postings. Those who survived are forced to take on double or triple the work. Social media is full of people looking to career switch (into tech and out of tech; no one is happy anywhere).

And it’s easy to blame ourselves for these struggles. But the narrative that you can avoid the upheavals of the industry by simply being the best at what you do is a false comfort — and chances are that what you think of as merit isn’t even what executives are looking to reward anymore.

That is to say: shit sucks, and it’s not your fault. (In the spirit of the end-of-year wrap, I’ll be linking issues where I’ve covered the topics before; this one was in #26: Fear vs Play).

The goals are made up, and the points don’t matter

One of the things that working at Amazon made me realize is that even crushing it can be demotivating, when the goals you’ve been given are essentially meaningless. Working towards outcomes that nobody really cares about — not even the people who asked for them — is the fastest way to poison your company culture and encourage people to mentally check out.

And the most common source of these bad goals is bad leadership. When orgs are not cultivated with intention, the people who rise to the top are the ones you would want there the least. And these managers end up creating a double whammy of bullshit goals:

• Metric-driven success theater where “performance” is measured by data that is easiest to gather (meaningless output metrics) rather than by any real contribution towards strategic goals. We talked about this phenomenon, called measureship, in #5: Verschlimmbessern.

• Jerking people around with arbitrary requests that often contradict previous requirements or are in conflict with prioritized work you are already on the hook for.

The effect of this dynamic is to elevate a select few individuals as modern-day shock workers, while suppressing the likelihood of organic bottom-up leadership emerging — which is the connective tissue that makes all of those “high performers” able to deliver anything in the first place (we talked about glue work in #21: The glue is the work).

Instead of owning the team’s value by placing people where they can do the most good, these mediocre managers are demanding that employees prove their individual value, all day every day. Which, predictably, takes additional time and mental energy.

Burnout and the road to recovery

So yeah! Everyone is burnt out. And burnout isn’t something that a holiday break can solve — or ought to solve. Because refreshing yourself just to come back to the same grind that crushed your spirit in the first place is self-defeating. Jen Dionisio’s reflection on her burnout is extremely powerful, and I urge everyone to read it, just in case you see yourself in it as well.

So take the end of the year as an opportunity for a reset, as people often do. Even if you don’t decide to change your job, you should still consider changing your relationship to that job, if the current relationship no longer nourishes you.

I don’t mean that in a hippie way; I am a firm believer in spite-driven personal development. But that spite can only give you energy, not direction. Direction can only come from thinking hard about what you want, and whether what everyone else is telling you that you ought to want has any overlap with the goals that actually matter. Sometimes (as in Nicole Johnson’s case) the solution is 180° from the “universal success story” of rising up the hierarchy in big tech.

To close out the issue with something nice: I’ve been following Ruth Malan’s systems thinking advent calendar as it has run its course through December. It’s an excellent toolkit for modeling your career, if you want to use it that way! But it’s also good for thinking deeply about pretty much anything else.

— Pavel from the Product Picnic

Welcome back, picnickers.

Last week, we started talking about UX cheerleading — when the purpose of research is diverted away from learning about customers, and towards soothing executives during the “build” stage of the project.

But “build” eventually graduates into “learn.” And the learning tears their false comfort to shreds.

In the Headlines

“We’re finding a lot of AI fatigue among our users,” reads an internal memo.

Adoption of LLM tools has stalled, and sales orgs are fiddling with their numbers to pretend otherwise. Even vibe coding — once the poster child of AI’s transformative potential — has run into the limitations of the technology, with enthusiasm evaporating as teams realize that all the automatically generated code still needs to be maintained by human hand.

This backlash has caught executives with their pants down, because for months and years they were told that AI was the future and everyone was going to love it.

• Microsoft AI CEO Mustafa Suleyman finds it “mindblowing” that people hate his bait-and-switch products, which fail at the tasks shown in their own ads. Suffice it to say that customers are less than enthusiastic about having that sub-part experience welded onto even more products.

• Dedicated fans are calling Mozilla “astoundingly out of touch” after the abrupt announcement of Firefox’s pivot towards becoming an “AI browser.” Mozilla has since backed down; the AI features are still coming, but they will now be opt-in rather than opt-out.

• “It’s a beta” is WaPo’s defense of a dismal AI-generated podcast offering where 84% of the content did not meet the company’s own journalistic standards, but which was launched anyway over objections from staff (I actually covered their AI-focused mission statement nearly a year ago; it’s not surprising that this LLM_first strategy ended up putting customers last).

• "I think at this point everyone at the company is more or less OK with the way we’re using it," claims Larian’s new CEO in response to fan and staffer outrage that LLM tools would be used to create the formerly-hotly-anticipated game Divinity.

These are not just cherry-picked examples. Aside from the Microsoft one (which has been a slow motion train wreck for years) these are from the same day last week. I could go find more, but I don’t want to talk about LLMs for the rest of the year.

The important thing is not the technology. It’s the determination of these people to ignore any sign that contradicted the narrative of inevitable success.

The Timeline

This lack of executive foresight is a direct result of what Adam Thomas calls “polite failure” — saying “yes” to your manager’s face and shipping an experience you know users will hate. Because the people dealing with the consequences of those decisions are in some other room. The manager is right in front of you. It is easier not to rock the boat.

And so, product orgs have optimized themselves for polite failure. The sensing mechanisms (the processes meant to do the “measure” and “learn” parts of the SDLC) have been pared down to the bone. The minimum viable, democratized, high velocity research process looks something like this:

• Find the noisiest people who agree with you (and don’t worry that they are guaranteed to be outliers).

• Take what they are saying at face value (ignoring the nuance of feedback).

• Immediately start building (without doing the necessary sense-making to integrate your learnings into the wider body of knowledge).

• Test the solution for usability (even though usability without usefulness is good for nothing).

• Collect some cool metrics (and don’t worry that they will never be capable of informing a decision)

• Find a new job before the chickens come home to roost.

Good Questions

User-centered design is like a court jester (wait, don’t close the tab!)

On the surface, the court jester is entertainment. Ringing bells, telling jokes, and keeping everyone’s spirits up until The Simpsons comes out. But the jester’s real role is to say the things no one else is permitted to say. The jokes are the only way to question the wisdom of the king’s decisions without undermining his authority.

UCD is the same. The job is not to come back and tell everyone “turns out we were right all along.” It’s to identify the problems before they become problems.

Hence, our question of the week:

This is where you should be starting. Not mining your data for nuggets that indicate success. But aligning on the signs of danger, and then designing a data collection apparatus suitable for more than just leadership optics.

As an aside, I’m thrilled that I was able to make today’s post fit into the Picnic’s classic section headers. What do you think? Did they help you pick what links were worth clicking? Or do you prefer the contextual ones that were more like an article?

This may be the year’s last issue of the newsletter, so it’s a perfect time to send in your feedback!

— Pavel at the Product Picnic

Howdy, picnickers!

Although, with the season’s first snowfall upon us here in New York, it may be time to admit that the picnic season is over. And as the year draws to a close, I can already hear hundreds of keyboards banging out takes on “UX trends to watch” or “the state of UX in 2026.”

My personal hot take is that UX in 2026 will be almost exactly the same as UX in 2025, which was the same as UX in 2024, and so on and so forth. Oh sure, the tools will change a little. People’s patience with Figma continues to evaporate, and your various Penpots are rising to compete with it. But two things about UX will remain immutable, and these two things constrain the possibility space of the entire discipline:

• The first is the broad strokes of how design creates value. We talk to stakeholders to understand what they want to accomplish for the company, and talk to users to understand what they are trying to do. Then we find the overlap; what user behaviors the product needs to enable to help both the business and the customer to achieve their respective goals.

• The second is the reason that this process does not work. Because our stakeholders do not come to us with business goals. They come to us with ideas, but those ideas are inevitably ideas for outputs. Dictating what a thing should look like or how it should make users feel has been elevated above such humdrum everyday concerns as “why we are doing it,” and highly placed executives want a piece of the pie.

In the two years since Chuck Wendig wrote that essay, his assessment of the situation has only become more accurate. The friction we talked about last week has steadily dissolved in a soup of LLM-generated prototypes that shout “my idea is possible, and therefore it should be built.”

As with all Gen AI use cases, this is not a new pattern; merely the scaling-up of an old, dysfunctional one (resulting, naturally, in more dysfunction). And the dysfunction also stems from how stakeholders choose to use this pattern. I’m talking, of course, about “build, measure, learn.”

In the abstract, there is nothing wrong with it. It even approximates the scientific method. But rather than being a tool for creating good products, it is deployed as a smokescreen to prevent that outcome.

“Build, measure, learn” is supposed to be a feedback loop, but usually gets deployed as a sequence. We will first set our goal as building the thing. Once we have finished building it, we will measure its impact. And — somewhere down the line — we pinkie swear that we will learn something from what we did.

This pattern assumes that we already know everything we need to know to build that first slice. Unfortunately, nothing could be further from the truth.

A functional “build, measure, learn” process would generate learning from the very beginning. As soon as we learn that the thing we’re building won’t meet our goals, we would stop building it. But in a context that privileges short-term execution of ideas above all else, the build must be completed, because getting to “done” is its entire value.

Effectively, we have circled all the way around to waterfall in two-week chunks, except worse. The stakeholder’s idea is not a complete design. It is a sketch; it creates the impression of substance. What we learn through delivery is not “how well does the product do its job” but rather “where are the inconsistencies in our requirements?”

What this produces is, essentially, anxiety.

You often hear “comfortable with ambiguity” as a key trait that leaders ought to have. But there are two kinds of ambiguity. One is the ambiguity of the path; we know where we want to go, but we don’t yet know how to get there. “Build, measure, learn” works fine here, on short time scales: we try something and see if it brings us closer to our end goal or not. But the other — far more harmful one — is the ambiguity of the goal.

And this is the death of any design-oriented culture. Without understand why we are doing what we’re doing, teams end up inventing their own arbitrary benchmarks of what “good” looks like; each discipline becomes siloed and insular, concerned over small things no one else cares about.

The lower the maturity (and therefore, the slower the release cycles) the more this tension builds. Without external, objective validation that what teams are doing is the right thing to be doing, they invent more and more arbitrary measures of quality, and spend hours polishing things that just don’t matter, and will never make a difference in the long run.

Enter UX design. Or at least, enter the tools of UX design. Similar to what happens with UX theater, the processes of our craft become hijacked towards the goal of releasing this tension. The developers (who are, after all, the highest-paid constituency in the room) need to be assured that what they’re doing is not a pointless waste of time.

And so we arrive at validation. Just like “build, measure, learn” it is not inherently a bad thing. But when deployed for projects that have no clear goals beyond “build the thing,” validation ends up being nothing more than UX cheerleading. The goal of this work is to soothe the team and the project sponsors that what they have been doing all this time was not wasted.

This is research slop.

The idea is not new (Simon’s original article is over 8 years old) but it has also been scaled up exponentially by LLMs, and its harms scaled with it. And some of those harms are harms towards designers. In the article that best articulates my personal thesis around what design is (and is for), I emphasize that doing design must be safe; safe not just for our users, but also safe for the designer’s reputation within the organization they serve. Because when we make assumptions and bets, we are frequently wrong. The design process works by learning from the ways in which we end up being wrong, but it needs that extension of grace in order to function.

Try, observe, try again.

But what if it’s not safe to be wrong? What happens when our feedback loops are slow, and our roadmaps leave no room to course-correct? Well, then our experiments are guaranteed to return positive findings — regardless of what was actually observed.

That is what we see as research becomes “democratized.” Rather than reduce the risks that a project faces, the work becomes a pacifier to convince teams and stakeholders that everything is fine, and delay the reckoning with reality for as long as possible. The ROI of design is reduced down to an accountability sink, so that there is a designated function to take the blame whenever anything goes wrong.

Design leaders have gotten away with following the path of least resistance for this long. But following that path any further — embracing design’s role as a soothing function and accountability sink — will destroy us. Absent ideal circumstances, the ideal process simply does not work.

Next week, we’ll talk about how the industry can pull out of this nose dive.

— Pavel at the Product Picnic

Welcome back, picnickers! This is going to be another one of those “thinking about the intersection of two themes” posts. Both are themes that I’ve explored extensively in the past:

• The risks of frictionlessness, and the importance of friction to the experience

• How the tools we use to build products apply equally well to designing the process through which we make the products

Add those two together, and the thesis writes itself: the friction of a process is a valuable constructive constraint. Thoughtlessly eliminating friction from our process does us a disservice, doing so makes us less effective rather than more.

If you want to hear more on this theme, join me at the IAC in April:

The Process of Least Resistance – Information Architecture Conference

Design has shifted to a post-hoc reasoning model where our decisions are retroactively linked to the goal. But this shift has undermined UX as a strategic function. To reverse this trend, we must revise our relationship with our tools.

www.theiaconference.com/sessions/the-process-of-least-resistance

But here are my initial thoughts on why (and how to) bring helpful friction back into design.

Frictionless is thoughtless

LLMs are the elephant in the room here (although this should not be surprising, as they are the elephant in every room right now, and we will not dwell on them too long).

AI tools are the poster child of the “just go faster, at any cost” crowd. And we see just what costs proponents are willing to pay: taking the computer’s word as the truth rather than the mere outcome of statistics, and then inventing falsified post-hoc justifications to back up the AI’s guesses and assumptions.

Users of these systems become reliant on getting one quick and authoritative answer; they lose the ability to evaluate the quality of that result, and the output of their work reflects that:

It is one thing to read a fact and memorize it — and entirely another thing to connect it to other facts, draw a conclusion, and become invested enough in that conclusion to advocate for it in a persuasive manner. In order to meaningfully understand and use new information, it is essential to linger.

We are now going to stop talking about AI, and come back to talking about product development. Because the reasoning behind AI being thrust into everything — go faster or fall behind, adapt or die — echoes the arguments used to “optimize” that process, reorient towards a mode of thought driven by product needs rather than user needs, and turn designers from system thinkers into technology implementers.

Interestingly, the designers who chose frictionlessness are the ones who are now in a panic because product managers have access to the same AI that scraped the same design systems and generates the same “good enough” screens.

Even an appeal to relevance on the basis of taste is an appeal to friction: stop, slow down, ask me what I think first, wait for me to think about this design and articulate why it’s good or bad. But when the name of the game is velocity, that argument will always fall flat. No one cares. No matter how far you pare down your design process, it will never be faster than doing nothing.

We have to compete on other terms; which means we have to make friction compelling.

The value of choosing friction

The main problem with choosing friction is that it’s easier not to.

It is easier to design the feature in isolation than to investigate what context it will appear in.

It is easier to smear GenAI over everything than it is to figure out whether the bottleneck users face is even technological in nature.

It is easier to let product managers worry about “the what” than to ask difficult questions and then reckon with the answers. It is easier to focus on “usability” over substance. It is easier to align the team around a feature than to dwell in the ambiguity of the discovery process. It is easier to come to a consensus around a solution no one hates, than it is to advocate for one that some might love.

And the path of least resistance has produced some awful design. Because it’s also easier to create “simplicity” by sweeping complexity under the rug, than it is to reckon with making the complex understandable. It’s easier to go for your first cool and clever idea than it is to consider boring but practical alternatives. And unfortunately it is easier to give in to our biases about who uses our product than it is to fight against those biases (and no, you can’t “just use AI” because AI is just as biased as the training data, and deliberately adjusting prompts to account for that is — surprise! — additional friction).

For a while, the path of least resistance served designers very well. Going faster was incentivized, even when the results were poor. Many designers became successful by baking the speed-over-quality ethos into their practice. It is understandable that they are still attached to it.

But the game has changed. “Going faster” now means “going without designers.” And because we did not build our own influence and power (it was easier not to) our attempts to say “design isn’t optional” have withered on the vine.

When design is optional, we cannot dictate to our colleagues what they ought to want. We can only pitch them our services on the terms that they already value, in circumstances where our intervention is wanted and needed.

Making friction constructive

One of the interesting things about friction in product experiences is that there are two distinct kinds, which we tend to conflate into one. There is the friction of the medium, and the friction of the design. Frictions that are inherent to the material, and frictions that are a result of that material’s shape.

Most attempts to create constructive friction end up being the latter; think about those annoying “are you sure?” popups that never work because in the moment of clicking the button we are sure, and doubts only creep in seconds or minutes later.

Similarly, most attempts to remove friction try and use design decisions to compensate for frictions in the material, which also usually fails. Consider lazy loading (a design decision) which unsuccessfully tries to compensate for throwing megabytes of poorly optimized website at every user (a material friction).

So too is the case with process. Despite the efforts of everyone involved to design a frictionless process, frictions still peek through those design decisions when they result from the material, and the material of process is people.

If velocity was the only goal, then every stakeholder meeting would be resolved in 15 minutes through mutual compromise and camaraderie, instead of the hours, weeks, and months of vicious power struggle that these conversations become in reality.

The main superpower of design thinking was that it let us cut through this Gordian Knot. For designers looking to rebrand as product managers, that skillset remains the best weapon for building influence. But you don’t need a PM title to do stakeholder alignment. If anything, it’s the reverse: designers can successfully pivot into Product because they have this skill.

A table where everyone is agitating for their own super cool idea has extremely high natural friction, and a need to resolve it. A small friction (the design process) begins to look like a palatable alternative. Rather than throw our own super cool idea into that arena (or worse: wait outside the door and try to impose a taste-based veto) designers can take that opportunity to align stakeholders around a shared vision — and place our own thumb on the scales while we do it.

— Pavel at the Product Picnic

There’s a quote I’ve been trying to work into the newsletter since August. I say “trying” not because it is hard to fit in to the topics I cover, but because it is a perfect fit for pretty much everything I write about:

The quote is part of a discussion about professionalization, and has some nested threads that are also worth reading. I’ve written about Design’s halting process towards professionalization before, and the idea that we don’t actually know what we want as a practice. As a result, when we try to shear off “unnecessary” things, the things we give up are often against our own interests.

One of the things design has given up is systems thinking (Yvonne is worth following for this topic). Last week, I wrote about how the disciplines that have split off from UX (content and service) are rediscovering it, but emphasized the user-facing experience. Today, we’re going to talk about the flip side.

Because quite frankly, many product teams have a really bad mental model of their own products — and it shows.

Even the names of the features are a dead giveaway. If you find yourself wading through a soup of Proper Nouns, chances are that the guiding principle is marketing, rather than clarity (similarly, “this feature lets you manage your X” is a sure sign that no one thought very hard about what the value proposition is).

“AI” is the epitome of this conceptual confusion (I put it in quotes because everything from LLMs to decision trees is now getting bucketed under AI, to signal innovativeness). We are told: the product now has Gemini. We added Rufus. You can talk to Bixby. The focus is completely on the name, rather than what the thing can do, which is not much. But AI is not the sole perpetrator of this design crime: just count the number of capital letters on this description of Samsung’s absurd feature that makes their $3500 fridge show you ads.

You may even have heard “bad services are nouns, good services are verbs” bandied about. I appreciate Duncan Stephen’s nuanced take on this: you need both nouns and verbs; bad services are impenetrable jargon. This jargon is not only unwelcoming to users, but also ineffective for internal teams who need to think clearly about what they are actually doing.

Instead of holding teams to account for these sloppy conceptual models, designers are often choosing to avoid challenging conversations, and instead lean further into craft. Which is the perfect recipe for a feature factory.

The “unnecessary” thing that got optimized away ended up being the fundamentals of the work that we do. We got faster and better at making things that merely looked like design, to the point that we can now design the whole thing without ever wondering how it is meant to be used.

That “we” is not just “designers,” by the way. I try to avoid drawing lines and creating silos unnecessarily; there is a reason the newsletter is called Product Picnic rather than Design or UX. No, the entire software development process happily went along with this pivot, doubling down on synthetic “definitions of done” rather than whether or not it really, actually works.

So what are we supposed to do about it?

Well, the number one thing not to do is to assume that everyone is stupid, and check out of the conversation:

It’s a systems problem; trying to solve it through individual willpower is the surest path to burnout. You are most likely not currently empowered to make the kind of changes you need to make to fix your workplace, and neither are most of the people you are mad at (otherwise you or they would already be fixing it). And you have probably seen attempts at that change get co-opted in the interest of the status quo (a personal request here: help me bully Glenwood to finish writing that article, it is the kind of writing that this moment needs).

Lauren Pope has an extremely useful model for thinking about how to drive systemic change (little coincidence that she is also a content designer): allocate your energy based on what you can control, what you can influence, and what may be a concern but is not something you can do anything about.

It is easy to say that the conceptual model is beyond our control as designers, and give ourselves permission to sit on our hands. But even the domain of implementation (what happens after the scope of work is “approved”) has a vast range of opportunities beyond the mere production of artifacts. Opportunities for us to exercise our professional judgment. Opportunities for us to enrich our discipline, rather than shave away everything but the bones in the name of the “necessary.”

— Pavel at the Product Picnic

Nowadays, everyone is talking about design leaning into strategy, ostensibly because AI is going to eat our lunch in the arena of producing visuals. That’s not actually true, but a lot of executives think it’s true, and that confusion is guiding their investments, which amounts to the same thing in the end.

And sure, design should do strategy. But that binary framing of strategy & production as the only two jobs that need doing is part of the problem. There’s a secret third thing that design excels at, which gets downplayed in a world dominated by feature factory thinking and output-driven productivity metrics.

That third thing sits at the intersection of architecture and maintenance. I’m going to be calling it experience governance: the process by which we prevent experience rot, or at least organize its abatement.

The Sludge Audit

Because I’m one of those “the interface is not the product” people, I’m going to give you an example that has nothing to do with software: pandemic social distancing signs. They addressed a very important problem; in software terms they were a priority one feature (aside: if your planning process has a priority zero, you need an intervention). Effort was put into implementing them. But long after we learned that 6 feet of distance wasn’t much help against COVID-19 and implemented a better mitigating feature in the form of vaccines, they’re still there.

This is an example of a good feature that has outlived its usefulness, but many features start out being bad (either by being poorly designed, or by being a “build, measure, learn” effort that mysteriously forgets to do the latter two steps). And in a tech industry that mistakes velocity for productivity, no one is incentivized to slow down and think about the emergent properties of all those features. No matter how delightful they are individually, the aggregate of all that delight is misery.

Productivity without governance just turns your website into sludge.

Which brings me to perhaps the coolest innovation in product development that I’ve seen in a while: the OECD sludge audit. This is the maintenance part of experience governance: providing value through removing things that no longer serve (and perhaps never actually served) user needs, rather than simply covering up the sludge with a new layer of paint.

And I don’t think it’s a coincidence that it comes from the public sector and from content design — two areas that are far less captured by the output bug than front-end design and the private sector. The public/private split should be obvious (business models rarely follow the pattern of “make thing people want” because there are more profitable approaches) but I want to dwell a little on the other half of that contrast.

The opposite of “UX/UI” is architecture

One of the most pervasive mythologies in this field is that it was ruined in the 2010s by graphic designers who started calling themselves UXers (paired with the laughable claim that graphic designers actually invented UX back in the 60s or something). There is a parallel story told by product managers about people they don’t like: that they are merely project managers who changed to a trendier title.

Those distinctions are pointless. It doesn’t make a difference what you call yourself if feature releases are the heartbeat of your entire practice. As long as your work is fully contained within the boxes laid out by Figma, Jira, and the logic of the “use case,” you’re adding to the sludge.

The real story of how the field was “ruined” is that — counter to the common narrative of generalization — UX design continued to specialize. As the challenges facing information architecture changed, designers abandoned the right side of this diagram and focused entirely on the left:

The problem with the left side of the diagram is that to our stakeholders, it might as well be called “look and feel.” The left side presents the content provided on the right side; if you look closely, navigation (which in a hypertext system is not just the top-nav, but going from page to page) is on the right. The system determines how you can get to an interface and what that interface can do; the interface design itself attends only to the how. My colleague Molly Misek provides an excellent example: no interaction pattern can make up for notifications that are governed by frustrating anti-user logic.

Fortunately, while many designers left the right side up to chance (or worse, to back-end developers), two entire disciplines emerged to attend to that work: service design and content design.

The reason these fields excite me so much is that their practice doesn’t treat architecture as someone else’s job. Governance and information architecture are at the core of content design. Service design isn’t distracted by screens, and is thus well set up to attend to the systems that connect those screens with the people who use them.

The self-imposed silos

One of the most emblematic beliefs of “new UX” is that designers can shop out “useful” or “valuable” to product managers. This often takes the form of “they own the what and we own the how” (or sometimes, they own the why and we own the what and engineering owns the how). Not only is this a very silly and counter-productive framing, but it has now locked us out of the very thing designers want to reclaim: strategy.

In a world of cost-cutting layoffs, no product manager is going to give up “doing strategy.” These roles are perceived as a zero-sum game, and every function is busy building moats around what they think the company considers indispensable.

But chances are that no one “owns” experience governance at your company, because it’s not on anybody’s radar. And leaning into these neglected skills of maintenance and architecture could be your road out of production design.

— Pavel at the Product Picnic

Howdy, picnickers! Today’s post is another reflection ahead of an upcoming talk (“Strategy happens in low fidelity” at EvolveDigital; come say hi!) about, as you might expect, low-fidelity design artifacts.

Honestly, the fact that the topic of lo-fi work is such a third rail in Product never ceases to amaze me. Whenever I propose that low fidelity is valuable, I am met with a parade of comments that it is simply no longer necessary, because we have design systems. Nowadays, the responses also mention vibe-coded prototypes as well: why spend time in low fidelity when an AI can regurgitate an approximation of a mockup in a few seconds?

This is a rhetorical question, but nevertheless Scott Kubie has a great answer here: when you are solely focused on high-fidelity execution, you are just fiddling around the edges of what has been set in stone by the work done on the conceptual and operational levels. High fidelity artifacts distract us from decisions at that level, by making us think that those decisions have already been made.

This can be difficult for designers to understand, because we are not accustomed to being involved in those decisions, or more accurately, being involved in the painful drawn-out conversations that lead up to those decisions. We like to think about our artifacts as standing on their own, rather than as part of a sense-making system.

Though to be fair to designers, this is a fault shared by almost everyone. Consider, for example, those hideous PowerPoint slides with multiple columns of 10pt bullet points that get read out monotonously at meetings where nobody pays attention. They are like that because no one pays attention at those meetings, so the decks need to stand up on their own when people skim them afterwards to pretend that they were listening.

You might notice that this is a bit of a vicious cycle. The slides have to be bad as slides because they won’t be consumed as slides, and the reason they won’t be consumed as slides is because they are bad slides.

This is because, unlike our products, our meetings are rarely designed. Outside of tedious Scrum stand-up status reports (which Tom Kerwin helps us avoid) or nice-sounding but ultimately nonsense frameworks like Team Topologies, meetings tend to take shape entirely by accident. Attempts to fix them tend to be limited to crude measures like time-boxing that fail to make them any more productive (this is actually a good example that “meetings make me less productive” is a nonsense claim because we cannot measure productivity).

Thus, people came to the erroneous conclusion that since their meetings are bad, all meetings are bad, and therefore getting rid of them is good. Shopify did this two years ago (if you’ve been following this newsletter at all, you’ll have a sense for how good Shopify’s org design is — which is to say, not very).

One of the things that happens when people don’t talk to each other is they start Just Doing Things. We had a series (1, 2, 3) on that phenomenon recently, but one quick example of what happens when teams don’t properly communicate is Sebastian Hans’s API of Endless Possibilities, where the lack of shared mental models creates an unmaintainable monster. When people do reach the end of their personal knowledge or agency, they are inevitably forced to reach out to others; this creates shadow power structures within your organization that get in the way of executing good ideas and empower the worst people to push their own agendas. And there’s no shortage of such situations: 80% of Americans work in a toxic environment and (to glibly summarize a thorough scientific study) ain’t paid enough for this shit.

So, stop designing your collaboration by accident. Part of that is going to come from low fidelity artifacts, the beauty of which is that anyone can make them, and they don’t give conceptual ambiguity anywhere to hide. But the other part is going to come from the feedback loop between the artifacts and the people; thinking out loud together; meetings. Showing up as a peer, rather than a concierge of other people’s decisions. And knowing how to disappoint people when you need to.

Happy meetings!

— Pavel at the Product Picnic

Howdy, picnickers!

Sometimes, the posts I curate for the Product Picnic have me reaching for theory, to connect the disparate parts of the discourse into a coherent narrative. Sadly, today’s issue is going to be much more tangible.

In a move that could only be described as Grinch-like, Amazon has abruptly laid off 14,000 people by SMS ahead of the holiday season (and its earnings report, which they needed to find some way to juice because they spent too much money on nVidia chips).

Andy Jassy, like other Magnificent 7 CEOs, has taken a step back from beating the AI drum and isn’t crediting AI for the layoff. Rather, it is a continuation of last year’s equally massive layoff aimed at hollowing out the middle of the corporate ladder.

The AI hype bubble is deflating

Despite Jassy’s denial, the layoff announcement immediately got podcasters baselessly speculating that Amazon has finally cracked the code, and actually gotten AI to replace some jobs like hype artist Dario Amodei keeps promising will happen “by the end of the year” every year since 2023. We are once again asked to believe that tech is on the precipice of inevitable transformation and the next release will change everything, just like the last one didn’t.

The technology is not the product; as Scott Jenson explains, the hype is the product. Even mainstream media like CNN has gotten tired of this bait-and-switch, and started picking up what critics have been putting down for years:

The article is a good overview of the actual state of AI adoption: a lot of demos, a lot of promises, not much in the way of realized gains — because the magic does not survive contact with reality. Not only have the 500x productivity gains not materialized, but (at least in our field) the very things AI tools do today are the wrong things for anyone to be doing in the first place, and using the tools to accelerate those tasks just makes us more wrong.

Instead, employers are using AI as an excuse for short term cost-shedding exercises. Depending on your degree of cynicism, you might consider companies hiring back the same people they laid off “in anticipation” of AI efficiency to be an admission of error, or the plan from the very beginning. Certainly, a lot of job postings going up today read like “we did a big oopsie and need someone who knows what they are doing to fix it.”

Some companies are only at the beginning of the FAFO curve; others, like Klarna and Duolingo, have already reached the end and rapidly backpedaled. Accenture is somewhere in the middle: after failing to “re-skill” their own workforce to be productive with AI they simply fired 11,000 people and now want to sell this process that doesn’t work to enterprises. Again, the product is the hype, rather than observable and tangible benefits.

Andy Jassy’s war on process

As for Amazon itself, Jassy’s explanation that culture, rather than finances are behind the latest round of layoffs certainly sounds like yet another industry titan tacitly admitting that going all-in on AI will not pay off.

The AI focus may be gone, but the impossible dream of magically improving productivity remains. This time, the silver bullet isn’t tooling, but slashing the decision-making process. We are asked to believe that this is a culture problem, and can be fixed by mass layoffs.

But trying to fix your culture with mass layoffs is like that old joke, fighting a war for peace. Layoffs damage your culture irreparably, and cause your high performers to head for greener pastures.

And using layoffs to fix the specific thing Jassy is worried about — improving the speed of making decisions by eliminating process — is especially counter-productive. I’ve written more than enough about how good process actually makes us go faster. Hell, this is basically Good Process Makes Us Go Faster: The Blog. But this post by David Demaree hits the nail on the head for why what Jassy is doing won’t work for Amazon specifically:

But Pavel, you might object, that post is about Meta and not Amazon. Maybe Amazon’s problem is actually different.

Alright, let’s take a case study: Amazon Prime Gaming — a platform that aimed to compete with video game marketplace Steam, but that most PC gamers didn’t even know existed.

Does this sound like an execution problem? Were teams taking too long to make decisions, like Jassy claims? Or were half-assed PRFAQs getting rammed into roadmaps as quickly as it was possible to write them, without the friction of a real process to get everyone to pause and figure out if any of it was valuable?

There’s no such thing as “no process.” There’s either intentional process, or unintentional process. And actual innovation requires intentional process.

Sure, it needs to be the right type of process (bottom-up adaptive, rather than top-down predictive). But trying to do “no process” means that what you have is an unintentional process, with teams left to fend for themselves against the prescriptive whims of highly placed stakeholders. In other words, it’s the perfect way to scale the dismal failure of Prime Gaming to the rest of the company.

Managing deliverables rather than outcomes — trying to chase certainty of the design process, rather than finding certainty through the design process — will always fail to achieve real impact.

And while Amazon has consistently failed to learn this lesson, the public sector is managing a lot better. James Plunkett wrote about the long journey of shortening feedback cycles in government tech with a list of great examples and lessons. If dense government bureaucracy can do it, then a tech company can do it too. Just not through firing all the people with a clue.

— Pavel at the Product Picnic

Howdy picnickers!

This one’s a bit late (I think beehiiv actually lets me backdate the posts but I’ll own up to it). Pre-writing these posts is tricky since I want them to stay fresh with the headlines and discussions that take place. However, a lot of issues have turned into essays rather than strictly speaking, newsletters. The format is always evolving; please let me know what you think.

Today, we continue with the final part of our discussion on why aimless outputs (sometimes rebranded to Just Doing Things) often produce negative value. In the first part, we talked about how “just doing things” causes work that is visible to crowd out work that is valuable; in the second part we looked at value production as a social system, made up of stakeholders and mental models rather than tools and artifacts.

The laser focus on artifacts is a grave error, but a forgivable one. After all, our tools mainly produce pictures of websites — though this limitation has its upsides. Chris Coyier goes into quite a lot of detail to explain how overloaded our design tools would be if they had to deal with the full complexity of the Web up front. Code is a design medium, but not automatically the best one; deferring the complexity of code allows us to think more about the holistic experience we want to create, and iterate on those experiences more quickly and cheaply.

However, by the time the product delivery lifecycle has transformed those pictures into websites where a user can have that experience, the designs have gone through countless hands, and have not always survived the process intact.

“The designer should just write their own production code” is certainly one approach to solving this problem. But where does it stop? Should the designer also build the backend? Manage the AWS configuration? Compose the roadmap? Create the business case? Do sales? Learn fundamental physics and invent a time machine so they can fit all of these things into business hours?

At some point, unless you are a one-person indie shop, you are going to have to work hand-in-hand with another human being to deliver value to customers. And if your approach to Just Doing Things requires that no one else do anything without you there to make sure your vision is being faithfully executed, then you’re not accelerating velocity — you’ve actually become the new bottleneck.

Some managers might be thinking “AI can do it!” but that is a technology solution to a social problem, which has never worked for anyone. AI cannot engage with a social system because it has context, but not intent:

It can be hard for low-maturity product teams to tell the difference, however, because volume of artifacts has been used to disguise lack of intent for decades. And it doesn’t actually work! Testing two or three different versions with customers (a hold-over from advertising agency practice of putting two or three different versions in front of the client) is slower, more expensive, and less effective than just testing one version when you have a clear idea of what questions you want that test to answer.

Successive iterations of artifacts without intent creates significant conceptual debt for your product — not only because you don’t have the framework to determine whether a design decision is good or bad, but because those unintentional design decisions pile up. The individual building blocks may look really polished and test well, but when they come together within an unintended architecture, they are of no value to anybody. Eventually, that conceptual debt will come due.

The most cost-efficient way of dealing with this debt is to avoid incurring it in the first place, by maintaining a shared mental model across the team for the entire duration of the project. The only way to do that is to cease surrendering control over what we want to say, and think about communication, not artifact, as the substrate of our practice.

All design (whether in code, in images, or in words) is theory-building before it is “crafting.” Employers are looking for people who know how to engage with the work at that level before diving into the nitty-gritty.

By the way, when people say “in the age of AI, designers should start doing strategy” this is what they are talking about — but it has nothing to do with AI. The fundamentals of our jobs haven’t changed. Designers should always have been doing this.

Not knowing how to communicate with our stakeholders has been the bottleneck in our impact for decades. If you want to stand out as a leader, this is where you need to start.

— Pavel at the Product Picnic

Welcome back, picnickers! Although, the season to go out and touch grass is quickly wrapping up here in the North-East as we head into autumn. So, you know. Get a move on.

Today we’ll be picking up where we left off last week: on the pitfalls of “just doing things.” The obvious rebuttal to this thesis is: “what, you want me to stop doing things?”

Well, I want you to at least think about it. I’m actually going to be talking a bit more about that at Button Conference next week — how doing all the things is detrimental to your ability to get the important things done right.

A focus on “just doing things” is the epitome of local optimization. Any productivity gains obtained through decoupling yourself from your organization’s systems of value production are illusory, for obvious reasons. The “cost of going faster” may not be as visible to your organization as measuring the number of tickets closed, but that doesn’t mean it does not exist — only that you are not prepared to deal with it.

There is often value in not making new things, for example. We are often trained to think of all problems as blank-slate, but it is often wiser to evolve or mutate what is already there.

Or just take a breather and think about what you are trying to achieve.

Sure, sometimes you have to “just do” something, because the alternative is that you get fired. And then you should absolutely do it — because it’s an opportunity to earn trust, which you can then “spend” on long-term improvements. Stakeholders are just people and “I trust this person because they often get it right” is more powerful than any theory. Ray Newman outlines a good, simple framework for how to balance “just doing things” with working towards long-term changes.

Because that is the goal, actually. If your prevailing system holds you back from getting things done, successfully going around the system is just a stopgap measure. The long-term goal should always be making the system better, so that it can help you get things done rather than get in the way.

But that’s hard, and flooding the zone with thoughtless outputs is easy. You don’t even need AI to do it — the Extreme Go Horse framework has existed for a long time — although AI might certainly help you churn out outputs more quickly. Of course, amplifying a broken system only makes it more broken.

The first thing you can do to start fixing your system is to insist on accountability so that the Thing Just Doers cannot degrade the system any further than they already have.

The second thing is to understand that the system is made up of people, and the people are exhausted. Trying to simply muscle past them will quickly outstrip the broader system’s ability to assess whether outputs are fit to be inputs into any downstream process, and turn your entire pipeline into slop.

If you hope to make any kind of lasting change — which many Thought Leaders refer to when they talk about lofty things like “design should pivot into doing strategy” — you are going to have to give up the dream of the lone Design Desperado and start learning how to play nice.

These are people problems, which can’t be solved with technological solutions.

For systemic change to happen, you need to bring people with you. Which — surprise! — is design’s greatest superpower, and always has been. Jon Kolko wrote a very long and very good piece about synthesis as a sense-making process 15 years ago, and every part of it still rings true today. Kolko called out that synthesis is often performed privately, within the designer’s head, and this is a barrier to getting other people to understand what you are on about. The teams that succeed are ones who can get everyone (including execs!) to show up for these sense-making sessions.

Meanwhile, the individuals and teams who just yeet their work at the next person in line inevitably fail to make any real impact. Those people may be churning out deliverables, but they are also racking up comprehension debt. No one understands what they are on about because it is not possible to derive rationale out of the output alone. And if people don’t understand something then they can’t act upon it, and we are back to designers complaining that Product is “ignoring their designs.”

This effect is only intensified when no one can explain what the thinking was, because the output was generated by a stochastic parrot rather than a person. The cost of sorting out what was poorly explained and what was simply hallucinated quickly eclipses the organization’s cognitive resources.

That’s what we are going to talk about next week: intent. How to create it, propagate it, and maintain it throughout the entire product lifecycle.

— Pavel at the Product Picnic

Howdy picnickers,

It’s talk submission season — and if there is anything better than writing for both helping you think and getting your name out there as a thinker, it’s speaking. Plus you get to have a cool photo of yourself on stage that you can use in the company Slack and on LinkedIn to project influence. Win-win.

All the calls for submissions have got me thinking about the axioms of my own product development practice; I hesitate to call it a design practice because there are so many other moving parts that are necessary before your users can actually have an experience.

Reviving the diagram of the week section; this one is from my article here

One axiom is: doing design requires that you first establish an environment in which design is possible and valuable. It is insufficient to be able to practice the methods of design if the goals those methods help you reach are not valued in your context.

Another axiom is: doing design means following a design process. While it is possible to produce outputs that resemble design artifacts without practicing the process, you are not designing as such. Of course, there is no hard line between what is and is not a design process; for me it is a set of principles rather than linear steps one can follow.

Unfortunately, that is not the popular understanding of process. Process, in tech circles, has come to mean “following the steps by the book.” This type of process, typically imposed top-down, is universally hated, for good reason: it’s not seen as helping reach valuable goals, but rather solely as a goal unto itself. Workers must achieve their goals despite the process, working around what they are meant to do in order to do what they need to.

This kind of process “transformation” didn’t start with AI, although AI certainly kicked it into high gear. Various “agile” processes like SAFe have been imposed on unwilling developers for the past two decades, with one common goal: attempting to make releases more predictable through managerial control.

These top-down processes all failed, and will all continue to fail, for one simple reason: certainty can only be achieved through bottom-up understanding of reality, rather than top-down dictation of what executives want to be real. And from the ashes of that failure, a new idea rises: that since everything is broken anyway, the only remaining course of action for a “high agency” contributor is to ignore the system and “just do things.”

That is what the hype-o-sphere around AI promises: forget those ordinary people bound by things like rules and process. Be a heroic knight-errant who can get things done by themselves, and present everyone else with a fait accompli.

Alas, the simplistic narrative is never true.

Human collaborators are infinitely more flexible than artificial ones. Anyone determined to work with a machine must inevitable train themselves to think like a machine — because even the most cutting-edge AI is not capable of translating intent into action in a useful way (and the process through which the human operator must do it on behalf of the machine is complex enough to deserve its own academic paper).

The reprogramming goes deeper than that. Learning good AI habits doesn’t prevent you from also developing bad ones. Picking up these tools without extreme intent for what you want out of them will always cause you to fall in line, and adopt them for what’s easiest to produce with them, rather than what you want.

Executives are very happy to nudge this transformation along, because it redirects attention from “is the system (which execs are responsible for) working?” to “are individual workers being productive enough?”

That is the logic being embraced at Meta today: developers are being ordered to become 5x more productive, without management having the least bit of a clue about how that might be achieved.

And without a coherent strategy for what “more productive” is supposed to achieve, workers prioritize outputs that are easy to produce and measure. Supply-side outputs.

• Flooding the information environment with emails and summaries, because that’s what AI is good at.

• Solving attractive problems regardless of their value to the customer.

• Juicing metrics that show users like the product, which is one of the most irrelevant metrics imaginable.

• Fulfilling feature requests without value even entering the equation.

• Prioritizing improvements that show up on the dashboard, even if they degrade revenue.

Next week, we’ll talk about what you should do instead: how to design the macro-system that governs what experience ends up being developed.

— Pavel at the Product Picnic