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