This email looks a little different: it’s the Product Picnic’s inaugural Buttondown-hosted issue. Please let me know if anything broke in the migration, and look forward to some other changes coming soon!

As someone whose career has surfed across domains and industry verticals, I have a healthy degree of respect for analogous domain research — the process of abstracting a mechanism out of one context in order to understand other contexts. So bear with me for a moment while I start this article by briefly talking about curation.

Two articles on that theme came up this week: one from Ethan Marcotte, lamenting the experience of a digital world driven almost exclusively by the advertisement logic of recommendation algorithms. Despite the claimed improvements in both the algorithms themselves and the amount of data they have on us, it boggles the mind that “you bought a bathtub, so here are some ads for bathtubs” has essentially remained the median internet user’s experience.

Interestingly, the other article on curation comes from the other side of that wall — Matt Jukes writes about building an automated account for sharing his archive of street art on social media. But the experience was ultimately unsatisfying for both his potential audience and Matt himself:

I have no actual interest in automating it at all. Realising I could was journey enough but I am going to stick to being ‘Manual Matt’.

— Matt Jukes, Manual Matt – more misadventures with AI

Matt’s conclusion resonates with me (after all, I manually round up my links, unlike some aggregator lists out there that have hundreds of thousands of followers and no soul to speak of). But it likely also resonates with you, if your workplace has been caught up by “AI transformation.” For some inexplicable reason, one of the things these transformations always end up trying to do is automate work definition and prioritization.

Unfortunately, automated prioritization fares about as well as automated curation, and for exactly the same reasons.

Lowest-common-denominator curation of roadmaps

The thesis of AI-driven operating models is pretty straightforward:

• Premise 1: Coding is only a small part of the time involved in bringing software to market

• Premise 2: AI can help with coding but can’t help with alignment (agreeing what to build)

• Conclusion: The ideal operating model crunches the work of alignment down to near zero

The premises, of course, are quite sensible—but they don’t actually add up to the conclusion.

They don’t add up, because there is a hidden third premise missing from this equation: the idea that going faster is always better. In a world where "move fast and break things” is now understood to have been a detriment to the industry and to society, that premise can’t be taken for granted.

We can accept that an operating model that automates alignment will certainly move faster than one which takes the time to determine if what everyone’s working on is actually a good idea. But we can no longer equate faster with better. Not only because clearing away stage gates and sober review lets low-quality crap out into the world. Not only because working 10x faster requires 10x context switching.

I can't think of a single "time-saving" workplace technology that saved anybody any time. Instead, it forces us to work harder. It increases density.

— Allen Holub

The work of alignment is our opportunity to make sure that all the bricks we are laying actually add up to a building, and not just a lovely artisanal pile of bricks that someone is going to trip over because we left it in the middle of the sidewalk.

Alignment and creating a shared vision take time, precisely because this is hard work. Leaders worth their salt can “look around corners” and see farther than a programmer with a half-hour to kill and some spare Claude tokens.

Whether we call them ‘wicked’ or ‘sticky’ problems, they’re the ones that take years to make an impact on and involve multiple organisations collaborating to overcome. As such, because they’re not perceived as urgent, we’re often extremely under motivated to look at now (especially if we’re experiencing austerity service design). 

Without focusing on them now though, those long-term problems quickly become short-term emergencies…

— Lou Downe and Sarah Drummond, Short-term thinking does not fix long-term problems

A strategy of “get out of the way and let people just do things” is therefore the opposite of leadership. There is a very low ceiling on the amount of value you can actually create if all you are doing is solving “low-hanging fruit” problems. While some valuable problems are salient, and some require low effort to resolve, it is a rare problem indeed for which all three (valuable, salient, and cheap) happen to be true — especially when you remember that the solution spec is always going to be wrong.

Individuals, nested deep in domain silos, will always lack the context to look at the org-wide problem space more broadly. Especially when the message they hear is “use AI, move faster, ship more.” And of course, if they never slow down, they will never have a chance to realize that what they are shipping is no good:

People with good purpose and people who are completely lost move forward and it’s impossible to differentiate them. Only stopping enables a moment to clarify what is going on.

— Alastair Somerville

“Cheap, fast, good” — pick none

Of course, the management fad of chasing “velocity” above all else is nothing new. When businesses heard about Design Thinking, the primary take-away was “we can get solutions cheaper and faster than business driven design.” When they heard about Agile, the primary take-away was “we can get solutions cheaper and faster than Waterfall development.” Even though “cheaper and faster” was never actually what these concepts promised, that was the only thing bosses cared to hear.

This is why Agile transformation went sideways almost as soon as Agile kicked off. A large part of the efficiency gain came from ripping out coordination:

In counteracting the waterfall approach, they ended up removing structure and replacing it with individuals working on small projects.

— Trond Hjorteland, Agile is not working: the IT industry is a “patchwork of contradictions and confusions”

To be fair to Agile, we know this was not the intent because one of the signatories says so over on Mastodon. But that is how things shook out.

And now the same bosses that sacrificed coherence for velocity have taken a long hard look at AI and decided that — surprise! — it is also an opportunity to get work done cheaper and faster. And much like previous “transformations” those gains are meant to come from reducing coordination, leaving the transfer of context between bosses and workers to a piece of software, and letting dashboards pick up the slack of real thinking about the value of delivered outputs.

When I say this, people often object, and usually the excuse they give is the same: we are simply going to learn from what we ship, we will iterate towards big impacts in small chunks. This is almost always wishful thinking, a hope about the forward-facing roadmap that is not supported by the track record of what was actually delivered up until this point. If your company is practicing shipping low-value increments, it will only ever get better at shipping low-value increments, which will never add up to high value impact:

I you want to be more customer-led, you need to do more customer-led things and fewer internal-led things. You need to prioritize based on value delivered, not revenue generated. You need to engage often and deeply with your customers (through whatever avenues are available to you). You need to monitor what people are actually doing with your product. You need to hold things back when they're not ready, and focus on time to value over time to market.

You are what you do, not what you say you want to do.

— Clifton Gilley

To bring back coherence, invest in Design, not AI

I wrote about the effect that a good design practice has on coherence, earlier this year. And last month, Peter Merholz echoed the sentiment: design owns coherence, that work of making sure that all the different pieces that come out of the software factory get assembled into a useful product on the other side.

Unfortunately, the industry trend is the opposite: away from coherent workflows that bring people together, and towards a saturation approach to product. Everyone on the team shows up with their own vibe-coded prototype, which is a terrible medium for coherence work. Code is too fine-grained to anchor the conversation about what we are trying to achieve (and slop code where some decisions are real and most are unintentional, doubly so):

Once the prototype gets passed around for review, feedback starts coming in from everywhere. Some people take screenshots, paste them into Miro, and leave annotations there. Others send feedback over Slack. Others still suggest changes directly in Github.

…

The hardest part, though? Tracking the context, decision-making, and constraints behind each copy change.

— Jolena Ma

What might that coherence work actually look like? Peter’s article has some theories, but in this piece about AI note-taking, Bianca Wylie points to designing the meeting itself. Her example (circulating a draft agenda to create “a chance to pause” and be intentional about how we want to use our time) is exactly the kind of thing designers should be doing more of.

It may not seem “efficient” if all you’re counting is minutes spent on task, but doing the wrong thing quickly will always be slower than taking the time to do it right.

— Pavel at the Product Picnic