Skipping alignment leads to zero-impact UX

Deliverable artifacts are only a small part of the social system that product development entails. Any "productivity" gained by ignoring that system is an illusion.

Imagine that we are roommates. You ask me to restock the toilet paper. To prove that I’ve done so, I show you the receipt.

The next morning, when you are in need of toilet paper, you find that the drawer is empty. This is because I have invented a new and innovative method that I call Lean Shopping. Instead of going all the way to the store, I bought a cash register for my room, so now I can skip the entire shopping process and just print out a receipt for whatever I was supposed to buy.

Lean Shopping saves me a lot of time and money, and produces pretty much the same result as regular shopping, as long as we’re thinking about results in terms of the number of receipts printed out. And because “number of receipts” is much easier to quantify than “roommate satisfaction”, that is the metric I’ve chosen to put on my performance dashboard.

Managers who don't know how to measure what they want settle for wanting what they can measure.

Russel Ackoff in “Management F-Laws: How Organizations Really Work”

You might have surmised that I’m not really talking about toilet paper, but rather the design process, where the receipts stand in for artifacts. Any output — from a mere sticky note to a functional prototype — is only a receipt for the conversations and alignment that led up to it.

The cash register in this metaphor represents a number of things, but more recently, vibe coding tools have taken that particular crown. Once upon a time, producing software you could demo to stakeholders required a process of research, design, conversation, and alignment within a cross-functional team. The artifact’s audience could implicitly trust that to get to that point, those conversations had taken place, and therefore what they were seeing was credible as a solution.

By skipping that entire process and going straight to the artifact, vibe coding now allows any individual to borrow that credibility, without actually earning it. They can print out as many receipts as they want, while the toilet paper drawer remains empty.

And in the system of output-focused short feedback loops that we have constructed to measure the software development lifecycle, this is “close enough.” It resembles productivity, but it is not actually making us more productive. The lines of code increase (as does the time it takes to QA!), but upon closer investigation those LOCs either do nothing or actually cause harm.

The result of tools that put solutioning within our reach is that we are disincentivized from taking the time to construct the problem.

The problem of constructing a problem is not a technical problem. In fact, the opposite is true, you have to construct the problem before you can carry out any technical activity.

Dr. Donald Schön in this lecture

The outputs we produce at increasingly-greater velocities appear to be high fidelity, but in reality they are just sketches; the conceptual fidelity of the output is non-existent. Unfortunately, that deceptive appearance locks in our earliest assumptions about the right thing to build and severely limits our ability to get the right type of feedback.

I often hear well-meaning stakeholders tell me “higher velocity is always good even if we ship the wrong thing, because it means that we will be able to find mistakes more quickly, and therefore fix them faster.” This is a comforting thought, but it is rarely true. The same exact pressures and constraints that made us do the wrong thing this time will also make us do the wrong thing next time unless we intentionally identify and eliminate those constraints. And every time we do it, we permanently damage our credibility with users.

The remarkable thing is that teams know this, even if they’re not used to putting it into words. Shahpour Akhavi has done a remarkable job of bringing together instances of practitioners describing how they work, and presents a vision that is radically different from the way their bosses understand productivity:

Time, energy and money spent on refactoring, story refinement, paper prototyping, regression testing, usability testing, requirements gathering, or virtually any other software practice could all instead be spent on directly outputting code. That teams spend it in collaboration, even though most operate within techno-capitalism, and even in the face of deadlines, competition, performance reviews, market fluctuations and the like, indicates that collaboration is the better investment.

Instead of taking the time to understand and tend to this process, managers are happily hitting the gas on AI-powered tools. This is because understanding is hard while saying “here’s AI, figure out how to use it” is extremely easy.

But “where can AI help” is already the wrong framing. Many of the problems it purports to solve are solved problems; the content and functionality that we are generating already exists.

Managers could be getting improvements much more quickly and cheaply by taking advantage of the underused skills that their workforce already has. Instead, we are asked to adopt tooling that interrupts the habits of mind that experts have. Instead of allowing the social process of collaborative problem framing to unfold, AI tools inject unnecessary steps by encouraging us to do what the tool is good at, rather than what we need next (here is an interesting conversation about the usefulness of wireframes, with veteran designers patiently explaining what they are for to folks eager to skip to high fidelity simply because they have the tools to do so, and here is a similar approach using a spreadsheet to prototype, because that was the appropriate level of fidelity to answer the questions that the team had).

The tools might make you feel like a solitary super-hero, but no one in your org is actually an “individual contributor” and that includes you. The costs of skipping that social process are severe: when you jump straight to a visual output without cultivating a sense of ownership from stakeholders, they tell you to put things back the way everything was, because their mental model is still shaped like the old way of doing things.

"The [Agile] manifesto we produced was idealistic (read 'naive'). It assumed that an entire organization could somehow embrace its philosophy as we all kum ba yah'd our way towards value. When the inevitable impedance mismatch became apparent, half of the agile folks started selling solutions to management, and the rest pretended it didn't matter.

Agile Manifesto coauthor Dave Thomas, in a comment

RTO was another such blunder; managers attempted to bludgeon their teams into cohesion by skipping the hard work of building social bonds and shoving everyone into a room. Predictably, it had the opposite effect to what they expected would happen. In a way, the emphasis on velocity of outputs is a strategy to hide the massive productivity drops that teams are experiencing, but the hustle drummed up by this artificial sense of urgency can only hide the underlying problems for so long.

I often get accused of saying what not to do without being very helpful about what you should do instead. That’s because it depends (😈) — but also if it was easy, you wouldn’t need me to tell you how to fix it. I’m doing my best to find the answers, just like everyone else. When I figure it out, I’ll let you know.

Fortunately, on Tuesday Jen Briselli and Kyle Godbey will be leading a discussion and sharing some stories of how they were able to make things work out in the “swampy lowlands” of our practice (this is not an ad; the event is free, I’m just a fan). I hope to see you in the audience!

— Pavel at the Product Picnic