No tool or design process can fix a poorly conceived product

Unpopular opinion: Tools that you use in the design process do not matter. What matters is the user response to the product. No LLM can fake that.

I met a lot of designers who obsess about their design process, about the toolset, about the latest and the greatest "AI" tool they employed. All of this matters to designers only - but not to the users.

The users do not care about the tools you use to build the product. Whether you use pen and paper or the computer is not relevant. They care about the experience and the utility of the final product.

And you can only know about the user response when the product is shipped. Before that you can only anticipate and guess. This the reason why the shipping is the crucial part of the product lifecycle: it triggers users' response. Only then you will find out: does that product work for them? does it solve their problems? is it efficient? does the user like the product?

This came as a comment to John Cutler Linkedin Post, with analogy about restaurants and product teams:

Imagine if a restaurant behaved like your average product team.

The kitchen is packed. Everyone is moving. Every station is busy. Prep lists are long. Meetings are constant.

There is always something to do.

Chopping, rearranging, documenting, planning, replating.

But plates rarely reach customers.

When they do, they’re late. Or wrong. Or cold. Or oddly disconnected from what the diners said they wanted. Yet the kitchen isn’t “failing,” exactly. It never looks like a crisis. No one storms out. No one flips a table. Diners don’t riot. They just lower their expectations and stop coming back.

Inside the kitchen, though, the staff feels productive. Everyone is exhausted. Everyone is “at capacity.” Everyone can point to a dozen tasks they completed. They can even argue those tasks were important. And in isolation, many of them were.

But restaurants are not judged by how busy the kitchen is. They are judged by how consistently they deliver great food, on time, to the people who ordered it.

Product development is strange because this feedback loop is muted.

There is no instant revolt.

A team can be unbelievably heroically busy without producing much that actually moves the needle.

That’s the trap: in software, effort is easy to generate, activity is easy to justify, and impact is surprisingly easy to avoid.

User perception is everything; no tool can fix a product that feels wrong to users.

Continue reading