This is the 52nd edition of the Picnic, which I am writing exactly one year after the first one landed in just over a hundred inboxes. How far we’ve come!

I’m not going to do some kind of annual “state of the industry” post; we already know that the industry is in a state. But I do want to take this opportunity to talk about a topic that is near and dear to my heart, which is problem design.

And it’s a topic that is curiously missing from the discourse around the “real value” of our jobs now that LLMs are taking over the “make outputs and don’t think about it” slice of our discipline. Even the formerly-unassailable fortress of programming is now under siege (although as Iris Meredith shows in an extremely nuanced piece, devs who want to write working code that meets requirements have nothing to fear).

So we’re back to the old challenge: how do we elevate ourselves from the kinds of outputs that are swiftly becoming commodity grade? Everyone is talking about taste (or “product sense” if you’re a PM) or strategy as differentiating factors. But those arenas are contentious. Everyone thinks they have taste, and everyone wants to set the strategy.

The focus, in other words, is entirely on the solution. But the ur-problem is to define the problem in the first place.

This is a skill that has almost completely atrophied in an industry realigning around solving product problems (“put AI in it”) rather than customer problems (“as a user, I want to buy my juice”). Executives don’t want to just sell juice anymore. They want to empower you with an agentic, customizable, and seamless juice experience, because that sounds better to investors, even if no one has paused for a second to think about what any of that means. We’ll just “build, measure, learn.”

Unfortunately, what happens when you build first and only later trouble yourself to think about what you want to learn, is that you end up measuring the easiest thing to measure, which is usage. And then your feedback loop becomes an exercise in getting more usage. Value is no longer determined by what people get out of the product, but by how many buttons they click along the way. This is a complete inversion from people-as-customers to people-as-labor.

As a result, users are tired. Not merely tired of the other demands placed on them by their lives (although this is also true, and a critical factor of good design). They are tired of products that are designed to extract the optimal amount of pain. They are tired of experiences that are designed poorly on purpose. They are tired of pages that claim to provide one thing, while their design is dedicated entirely to making the opposite thing happen.

This is the backdrop to every argument around “strategy” and “good taste.” Doing strategy downstream of a problem that was incorrectly defined is a fool’s errand (and lest I be accused of making up a guy to get mad at, here’s a designer asking what to do when user feedback contradicts the design vision).

But how do you design a problem well?

I don’t think there’s a book (maybe I should write one) but there is a set of approaches you can try. One is simply to see if you can articulate a solution without a reference to a specific technology. Another is to talk about the expected behavior change as a result of your intervention. If your answers to these questions amount to “users will click our widget” then you have failed to design the problem correctly, and need to go try again.

This is impossible to achieve with “build to learn” because building is oriented entirely around technologies; it is subject to the same logic of metrics that has already led you astray. But you still have a chance if you “sell to learn.” Find the problems people are willing to pay you to solve — problems so painful that customers don’t care about which specific widgets or customizations your solution will support.

This is not a new idea. Many businesses and product teams do this. However, then they immediately throw all of that learning away by neatly packaging their findings into Jira tickets and bringing user stories like “as a user I want to click the button to go to the next page” to engineering leads for estimating.

As soon as any of the people responsible for solving the problem do not have a holistic understanding of that problem, you’re back on track towards a product users hate. A contractual, mercenary checklist of acceptance criteria will always produce a contractual, mercenary experience. When problem framing is not done together, it does not work.

If you know how to do this, then your job is safe, to the extent that AI is the driver of the layoffs rocking our industry, rather than a post-facto excuse. Because LLMs cannot do this; they cannot even help you do this, because the doing of the work is how that shared mental model comes into being to begin with.

There are tools that can help create this model. Tools For Thinking has a long list of strategies that let you create shared understanding. Jim Kalbach does a deeper dive into the value of experience mapping for alignment. But as Jim points out, the artifact is not the point. You need a process, and a culture, that cares about this stuff. It should not be something individuals go out of their way to do, but an intentional and intrinsic part of a cultivated practice of collaboration.

— Pavel at the Product Picnic