Let’s set the right mood for the year, by talking about success.
After all, that is the definition of good products, right? They help our users succeed? Even in 2003, when Agile was in its infancy and our job was still called “web design,” Rico Mariani had already come up with an excellent user-centered metaphor called the Pit of Success:
We want our customers to simply fall into winning practices by using our platform and frameworks… [if] we make it easy to get into trouble, we fail.
23 years ago! When this idea was coined, some practitioners weren’t even born yet. So, to put it bluntly, why don’t we build products this way? I would even argue that the opposite is true today: the discourse typically revolves around building a product first, and only then groping around for “product-market fit.”
This is entirely backwards from how satisfying customer needs actually works, but it’s still the dominant mode of creating software, because we no longer share a definition of success with our customers. Thought leaders might beat the drum of outcomes-over-outputs, but VC dollars have erected an entirely different incentive structure: the important part of your pitch is where it’s located on the latest hype train, rather than what it actually does. Any problem solving is delegated to the customer under the guise of “customization.”
“Any way you want” means “I am delegating the most difficult part of product-making to you, the customer.”
The allure of setting your own goalposts
VCs still want to see progress, but it is impossible to measure meaningfully as long as the goal is so ill-defined. And so companies must invent synthetic milestones:
Managers can only justify their place in value chains by inventing metrics for those they manage to make it look like they are managing.
To no one’s surprise, building towards fake productivity metrics rather than real user outcomes makes doing good work essentially impossible. Rather than optimizing the user experience, teams are incentivized to tweak their metrics collection processes to cast the product in the best possible light when the SDLC finally rolls over from “build” to “measure.”
The only real numbers in the entire process are revenue figures, because those are harder (though not impossible) to hide. For example, Meta’s “data driven” approach earns it a cool $16 billion dollars a year from scammers, and so it deliberately refuses to take action to mitigate scams and actively conceals them from regulators, even as those scams degrade the value of their product for their legitimate user base.
So how do we push back?
Historically, designers have tried to flex our influence by appealing to aesthetics. Unfortunately, “taste” and “beauty” are just another avoidance strategy; a poor alternative to thinking about user needs. And while high-profile designers are enjoying their narcissistic design solipsism, the rest of us (who need to use the website and not just look at it) must pay the price:
Defining success by a metric of beauty offers a useful kind of vagueness, one that NDS seems to hide behind despite the slow loading times or unnavigability that seem to define their output; you can argue with slow loading times or difficulty finding a form, but you cannot meaningfully argue with “beautiful.”
Iris Meredith has an even more fitting description for what these efforts amount to, here.
Change starts with uncomfortable conversations
When top-down incentives are misaligned, positive change needs to come from the bottom up. And that means having an awkward conversation with your teams and colleagues about whether you have defined success correctly. Until you have done that, your efforts to measure impact will be (at best) misleading, and at worst get in the way of doing the work that actually matters.
Our job is to face the ambiguity, rather than evade it:
Fundamentally, the work of design is intentionally improving conditions under uncertainty. The process necessarily involves a lot of arguments over the definition and parameters of "improvement", but the primary barrier to better is definitely not how long it takes to make artifacts.
However, it would be a mistake to think that we must (or even can) create this clarity unilaterally. While it is tempting for product professionals to think of ourselves as lone guardians of the vision, nothing could be further from the truth. The rest of our team can be our greatest allies, given the opportunity: beyond the most trivial, junior-level work, the job of software engineers is exactly the same as ours, reducing ambiguity.
Once you know what success looks like, the rest is easy.
Well, no, that’s not true; it’ll still be really hard. But at least that effort will be taking you in the right direction. You’ll be able to stop doing things that don’t matter and prioritize user needs over mere user wants (or worse, the wants of the product team).
And finally, you’ll be able to intentionally design your very environment into a system that enables the march towards success. There’s no one-size-fits-all approach to this work, precisely because everyone’s definition of “better” is different.
Process does not transfer. Team autonomy—the team's ability to define how it works—is the critical element.
For instance, while executives the world over were repeating the same stock phrases around “return to office” being a necessity, Gitlab decided that “better” looked like remote work, and intentionally designed the way they work to achieve that outcome.
And what better time to have this conversation than at the start of the year?
— Pavel at the Product Picnic