Hello picnickers!

With January almost over and Q1 roadmaps already slipping, let’s dive into this week’s issue. 

I’m going to break my own rules yet again, and link to an entire conversation rather than a post - because I think it’s the back-and-forth that makes it valuable. Duncan Sussex and Simon Rosenqvist went head to head on customizability a while back. 

I’ve long held the same opinion as Simon - that “we’ll let the user pick” is fundamentally lazy and betrays a lack of understanding the one core benefit that the product presents to users. A laundry list of options is a sign that the designer didn’t develop one coherent vision.

But Duncan’s rebuttal is frankly the best point I’ve ever seen to the contrary: often we get a vision that is coherent — but still bad. And without customization, users are stuck with a turd.

To me, these are failure cases of two different approaches. 

The overload of options is extremely common because it is the outcome of the standard building-to-learn loop, with its standard failure modes. By putting learning after building, we create a ratchet effect where more and more things are added, because “build” usually means “add”.

But the other case — the singular, bad vision — comes from an older way of making software, and one that the austerity environment is driving companies back towards: find a subject matter expert who will tell you their opinion on what to build, and then build that. This is, for some reason, understood as a risk-reducing practice.

Of course, hiring managers want to reduce risk even further. So they hire people who have already rubbed shoulders with an SME in their previous roles, and ask them to build the same thing again. In other words, while the title may say “product manager” what they are hiring is a user proxy.

Instead of building to learn, they are hiring to learn. 

The problem, of course, is that by focusing on hiring proxies, orgs stop hiring people who know how to build product. They are optimizing for rote expertise, which is not only useless for making good products, but is detrimental to developing adaptive expertise, the type necessary to solve wicked problems. The more we normalize this approach, the more we will forget that doing design is even possible.

This mode of hiring used to be limited to product managers, but Darren Hood calls out a post suggesting that this is now happening in UX.

The solution to the customization problem requires an extremely nuanced view of equity.

One of the biggest problems with the User Proxy mode of product development is a hidden normative basis that underpins every decision. Instead of “basing decisions on talking to five people” we are now basing decisions on one person’s opinions.

We used to have a thing called diversity and shared a broad understanding that it was good. Building a diverse team was the perfect cure to the user proxy problem, because different worldviews in the same room prevented groupthink and let designers remember that “the user is not like me” so they could do the research with an open mind.

Some workplaces still understand that value. But elsewhere, efforts to bring different worldviews into the room are being quashed. Meta and Amazon are leading the pack in hiring for conformity rather than merit, and RTO mandates are disproportionately affecting underrepresented groups in addition to hurting productivity.

Filtering out diversity from your teams and hiring people to copy what they were doing at other companies is the perfect recipe for commodity-grade thinking. This is exactly the kind of thinking that can be replaced by a machine designed to produce statistically average outputs. Attempts to produce AI-generated “synthetic diversity” predictably collapse into stereotype and cringe.

Instead of using a proxy or a robot, learn how to do good research and build a useful persona.

To close the loop on “building to learn” vs “hiring to learn” from the start of the issue, I have long since proposed an alternative approach, originally inspired by Tatiana Mac.

Yes, it’s true that shipping working software to real users is the only way to learn some things. Similarly, hiring someone who has already made expensive mistakes elsewhere is a good way to learn from those mistakes without incurring the cost.

But to do it for everything is slow and wasteful.

Chances are that your company already has some employees and has already built some things. You do not need to build anything or hire anyone to start learning - building and hiring has already occurred!

The other advantage of curating your existing resources (aside from winning handily on speed and cost) is that you will learn about pitfalls unique to your company. There are no shortage of “best practices” resources and “canonical” research out there. What happened when the last fresh-faced newbie tried to implement those things? What technical or political problems got in the way? If you don’t learn from those mistakes, you’ll just end up repeating them.

— Pavel at the Product Picnic