Hey there, picnickers! It’s a rainy day today, so cozy up with a warm beverage and the latest issue of the Product Picnic.

Reading Material

You’ve probably heard about Chatham House, the echo chamber Marc Andreessen organized to dress up self-congratulatory pablum as extreme thought leadership. This is hardly the only such group chat; other VC and CEOs out there have undoubtedly formed their own spaces where they can perform for one another. Anil Dash explains what’s going on in these chats – as these titans of industry (derogatory) try to one-up each other, they lean in on whatever the latest trend happens to be. Over the past few years it was RTO. Today it’s AI. 

This is the real AI job crisis: not, as the head of Anthropic has promised, machines clocking in to perform the tasks an employee would once have done, but “AI-first” infiltrating the thinking of decision-makers. AI creates more work for workers, adds technical debt, and is an “overwhelmingly demoralizing force” in the workplace. As a product, consumers distrust it and are less likely to pay for products that use AI. 

But leaders are not measuring the success of AI by its effects on productivity (just like RTO – remote work is simply more productive across industries). They are measuring it in terms of innovation theater.  

AI is not a strategy. It is not “the future.” AI is just a capability (or as Salla Westerstrand puts it, it is a product) that you can choose to add to some of your software or workflows. But because execs are incapable of being normal about it, AI now has to be in everything whether it makes sense for it to be there or not – or whether the team is capable of implementing experimental and unreliable technology. 

Every strategy requires prioritization, and “AI first” effectively means “outcomes second”; a foreclosure of thinking. This is a big problem for teams who want to do things that are not AI; your team’s theory of change and survival mechanism become overwhelmed by executive fiat. 

The Timeline

When decisions are made to appease executive theater, everything else about the product development process is equally undermined. After we close our eyes on the actual effectiveness of AI tools, it’s a no-brainer to put AI into your own product, because its ability is already established as a matter of faith. 

And that’s exactly where development starts: from a place of capability rather than need. For obvious reasons, this is a disaster for user-centered design – but it’s not new. AI didn’t suddenly make decision-makers turn away from user research and working backwards from customer needs. That trend has been here for years as the SaaS business model incentivized increasing divergence between what people needed and what they could be billed for. 

Accepting this premise is how design lost its seat at the table. We are stuck talking about usability and taste, because we gave up usefulness so that we could ship useless features. 

I’m not saying “don’t build AI into your product” (although there is a lot of evidence that doing so is risky to the organization while being harmful to actual productivity outcomes as well as to the environment and the information landscape, and runs contrary to the underlying principles of our work). I’m saying that by starting with “we should add AI” you are shooting yourself in the foot as both a UX designer and a responsible professional in general. 

Because AI doesn’t just lie to you when you type a question into an LLM chatbot. It lies to you by how tantalizingly easy it is to nearly solve a problem with it, to roll out a vibe-coded demo that resembles a solution, to fill the Gantt chart of your roadmap with new features that AI makes possible, to execute without stopping to think.  

Hitting the brakes on this runaway train is not easy, but it would be a mistake to think that UX is in this alone. PMs who understand that delivery by itself is not valuable are struggling to make that shift too. Designers aren’t the only people out there emphasizing user goals over shipped features. 

Because at the end of the day, performatively keeping busy is a lot of work for not much gain. Racking up a laundry list of minor wins is just not very impressive in a side-by-side comparison with just one big win per quarter. 

Diagram of the Week

Since I bring up product managers in the context of valuable work, it’s a good opportunity to bring up one of the more harmful notions that has permeated the practice for a while. The three-legged stool model (invented in the mid-00s and popularized by IDEO in 2014, rather than being handed down by divine edict at the dawn of time) is responsible for creating the misapprehension that designers own “Desirable,” developers own “Feasible,” and product managers are responsible for “Viable” (or in some particularly wrongheaded interpretations of the model, “Valuable”). 

Now, this is not really the model’s fault, because none of that is in the model. Desirable, feasible, and viable are dimensions of the product. I could go on for days about why neatly slicing up attributes of the product into role responsibilities is a big part of why your team is dysfunctional (see also endless arguments about “the what” “the how” and “the why”).  

As soon as you stop talking about attributes of the product and start talking about responsibilities, the field changes dramatically. Because while a product can be viable, “owning” viability is not actually possible because it is a function of two things: 

1. Whether the user will want it  

2. Whether the business will want it 

The first of these is pretty obviously “desirability” as in the original model. Does the product enable the user to achieve goals that they value, through behaviors they recognize? So far so good. Conventionally, this is what UX is responsible for: getting an understanding of these user needs and creating an experience that fulfills them. 

But the product exists within a system called a business, and that business (hopefully) has a strategy for how to remain a going concern. The PM’s responsibility is to attend to this half of the equation: whether the business will want to address the user’s need in this particular way. In the same way that UX needs to understand what users want and then deliver a solution-shaped product, PMs need to understand what the business wants and ensure that the product is doing that. 

Anything that isn’t a priority for the business — that doesn’t fit into its strategy — cannot be viable by definition, because it is not an appropriate use of resources.

No product can be “viable” as long as there is no understanding of how it contributes to the strategy. But many PMs are caught in a bind because they are not alone in neglecting priority – when there is no strategy at any level of the business, the answer to ”what does the business want” can only be ”features.” And if it doesn’t matter what those features are, why shouldn’t they be AI? 

The banner image visible in the web version of the newsletter is made with a photo originally taken by Carolyn Ann Geason.