As far back as 2001, before “UX” existed, Alan Cooper’s eponymous studio was already struggling with the key issue that still defines our field: what should be the scope of design judgment?

During the “Design Thinking” era, we tried to stretch the boundaries of that scope as wide as possible. What we found was that this type of influence is zero-sum: the more we have, the less other functions get. Wherever design could even get the “seat at the table,” keeping it became the work of corporate politics rather than craft.

Design is once again going through an era of transition. As tools, frameworks, and organizations evolve, we need to decide: what role do we want to pursue? And are we willing to stop designing to get it?

I wrestled with this question for years. But at Justworks, I found another way — one that I think can be a model for our field as a whole.

Subject matter expertise isn’t enough to solve system-level frictions

What makes designing at Justworks unique is that the app is only a part of the whole. While the self-service experience is appropriate for meeting customers’ simple needs, their complex needs are most effectively satisfied by customer-facing specialists. Each domain where Justworks offers a solution (payroll, tax, benefits, and so on) has its own experts, with their own tools.

But to our customers, Justworks is one service. The typical Justworks customer journey flows across all of these verticals; the user experience is not only engaging with each domain, but also transitioning between domains — both on the front-end and in the back-office workflows. To the customer, those transitions can feel like friction — seams in the experience.

But there is another type of seam that impacts the customer experience: transition between the service layers. Every transition between self-service and full service comes with its own frictions. And yet these transitions can’t simply be avoided: if human operators can temporarily close the gaps in the end-to-end customer journey, product teams can deliver keystone features sooner.

But without making a deliberate effort to revisit these decisions, temporary solutions have a way of becoming permanent. Teams may be tempted to write off these pains as the cost of doing business, and continue shipping new features without considering the experience as a whole.

When I joined Justworks, I was not an expert in any of its solution domains. But in a way, that lack of subject matter expertise was an asset. Instead of doubling down on one domain, my expertise was in designing the holistic customer journey. And that was the problem that I was there to solve.

Doing this work helped me see that what I once saw as the trade-off between designing and leading didn’t need to be a trade-off at all. The zero-sum game was not the only game in town.

There is more to influence than just decision ownership

To date, the product triad is the tech industry’s most successful attempt to delineate ownership between designers, developers, and PMs. It does so by subdividing the scope of the product team: taking the decisions that the team as a whole owns, and handing them out based on role.

The triad’s vertical focus on one product, a finite set of touchpoints, is helpful. It ensures that all the necessary decisions are made, and get carried out. But the set of decisions that the team owns is always going to be finite. Anywhere that intents compete (such as between viability and desirability) one option must always give way.

These explicit, intentional decisions often feel the most salient. There are entire ceremonies dedicated to assigning ownership and resolving disagreements. But these obvious decisions are in the minority of all the decisions that a product team ends up making.

For every explicit commitment to “do this, not that” there are dozens of seemingly insignificant decisions that are made unintentionally. Typically, these decisions will be about the fringes of the team’s scope, between the mandates of two different teams. Because these decisions are out of the spotlight, teams only catch them — if they get noticed at all — late in the product delivery lifecycle. By that point, the decision has already been made for them, in the negative space between everything else they explicitly chose to do. The seams between areas of ownership accrue more and more friction.

No one sat down and designed the experience that way. The decisions that shaped it weren’t made by a person. They were made by your process, by default. But because no one owned it, these decisions slipped past standard systems of review.

The reasoning (or lack thereof) behind these decisions doesn’t matter to your user. All they know is that the experience doesn’t meet their needs. And as long as these parts of the experiences are considered outside of formal vertical areas of ownership, they will never get caught, and they will never get fixed.

Fortunately, there is a cure for these gaps in ownership. That cure is Design.

One of Design’s most important contributions to a product team is to surface these unintentional decisions, and fill the gaps between mandates. When user journeys flow across features and product verticals, so does Design’s responsibility. It’s because we are responsible for the experience as a whole that we are the most likely to spot these silent decisions that didn’t make it onto the explicit list of requirements, yet still shape the experience of the seams.

When we bring them to our colleagues’ attention, we expand the whole team’s mandate. The game stops being zero-sum. The decisions become intentional. The seams begin to close.

Design an environment in which good design is possible

This is what design strategy without colliding with PMs can look like. No other function can replicate this function, because it comes from a practice; a mindset, rather than an artifact or a tool.

The reason I joined Justworks was that the Experience Design org clearly understood this. It was apparent from the beginning: subject matter expertise in HR wasn’t listed a requirement for the role, because the work wasn’t envisioned as a tug-of-war over ownership. My challenge would not be pushing a Design Vision through a reluctant group of stakeholders, but in bringing to light the questions that the company did not yet know it should be asking.

Justworks at-large also understands the value of a horizontal, experience-driven model of decision-making. The push for closing the seams between the product’s features came alongside a broader reorganization from vertical, domain-based orgs to horizontal, functional ones. Rather than fight Conway’s Law, we are turning it into a tailwind.

Experience Design is at the forefront of this change. The org pivoted from an embedded model into a centralized team, that could effectively shine a light into the spaces between existing intents. This is a transformation that is still ongoing, but it resonates with one of my most firmly held beliefs: before you can do good design, you must first design an environment in which design is possible. That environment must allow design to lean into its strengths, without ceding its seat at the table.

Experience Design is about finding the gaps in intent was originally published in Justworks Technology Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

I don’t have to tell you that the tech job market is in chaos. But ask anyone on LinkedIn, and they’ll give you the same foolproof solution: simply establish a personal brand, and you’ll be beating off recruiters with a stick.

Obviously, it’s easier said than done. But unlike most advice from LinkedIn, this one actually worked for me.

If you’ve heard of me at all, it’s probably because of my writing. Some of it is even good: one of Medium’s most highlighted sentences of 2024 came from my pen. I’ve been accused of being a thought leader, and since I’ve written for NN/g I can’t claim to be beating those allegations.

Maybe this approach will work for you too.

Writing for the right reasons

Even during the boom years of tech, people often asked me for tips on how to write.

One of the earliest issues of my weekly newsletter explored the overlaps between writing and the design process; and the critical distinction between writing (noun) and writing (verb).

But that’s not what people usually asked about. Usually they asked “how can I get as many followers as you?”

Followers vs Audiences

Among its other sins, social media is a highly quantified space. My modest success in that space, as represented by the number of followers I have, is public information, so it naturally draws other people with a smaller number who want their number to be big.

If all you want is a big number next to your name, writing is not the fastest way to get there. The fastest way to get there is follow-back spam: you follow as many people as the website will allow you to, in the hopes that a fraction of them will return the favor. Some of the most toxic commentators in the UX space built massive followings this way.

But if that’s what you want, go download Michael Sayman’s SocialAI and get guaranteed engagement with everything you post. Sure, they’re all bots, but why should that stop you? Half of everything on LinkedIn is written by bots. X has never been more lousy with bots. Meta desperately wants their bots to be your best friends.

All those gamed followers are not an audience. Whatever goal you want out of your writing, a juiced follower count won’t help you get any closer to it.

Your brand’s audience is people who can hire you

This is doubly true if you are trying to establish a personal brand. While revenue from one subscriber is indistinguishable from another, the usefulness of your brand is determined entirely by the quality of the audience members that it attracts.

It’s not enough to have people reading your stuff. It’s not even enough to have people think that your stuff is good. The people thinking your stuff is good need to be senior enough to be hiring managers, or at least high-level ICs influencing those managers.

I’ve had past colleagues tell me that they wanted to set up a personal brand, and the way they were going to accomplish this was to set up an LLM that would generate posts for them. If you do that, be prepared to accumulate the kind of audience that you’d expect: people who think LLM-generated content is insightful.

Feedback loops, and the role of social networks

Intuitively, one of the prerequisites of getting good writing in front of hiring managers is producing good writing in the first place. Which itself is a combination of writing craft and having good ideas. And no tool in the world is going to be able to do that second thing for you; LLMs by definition will produce commodity-grade thinking and your audience will be able to tell.

Fortunately, as designers we already know that good ideas don’t spring into the world fully-formed. They are created through iteration, with different tools existing to shepherd the idea through different stages of conceptual fidelity.

Stage 0: Riffing

Once upon a time, I was a new Twitter user with zero followers. More recently I’ve also been a new Medium user, Mastodon user, and Bluesky user with zero followers. A big reason behind starting Product Picnic was because audiences do not transfer across proprietary platforms, but emails do.

But in the meantime, I got pretty good at building up those audiences from scratch. And the best way to do that is by finding conversations other people are having, and contributing to them.

Your feed is not really your friend here, because you won’t see any interesting conversations until you’ve found the interesting people having them. Websites have different tools (hashtags, search, LinkedIn groups, Bluesky starter packs and custom feeds) that make this job easier.

Once you’ve found those conversations, join them! But — and this is critical — not before you’ve read the other replies. Being the nᵗʰ person to comment “this is just UX vs UI” is not adding value.

Stage 1: Complaining, and other ways to have a point of view

The world has enough “top 10 UX techniques” posts in it. They are low-effort engagement bait, and will be received as such by the people you most want to impress. Dunking on “bad” designs will get you an equally low-quality audience.

Rather than parade your superior taste, what you want to do is offer a compelling and unique point of view. One of the most common pieces of feedback I receive is that I put into words what others have been thinking; typically the topic at hand is some dysfunction of the modern software development lifecycle.

The SDLC has no shortage of dysfunction. Pick a pattern you’ve observed, or share a story.

The wonderful thing about social media is that individual posts don’t need to be earth-shattering insights. In fact, the less you think about them, the better. Type something and shoot it out into the world; if you have something to add later, that’s what threads were invented for. Since Bluesky has both strict character limits and threading, it’s what I use for this stage.

Analogous domains are another great source of inspiration. For UX, our sister fields of game design and content design have a wealth of scholarship with ready applications in our own space. Other fields that study systems or decision-making such as urban planning can provide unexpected insights.

Stage 2: Refining

Posting half-finished thoughts has two important functions. One, it gets you thinking about how to finish the thought fully. Two, it puts the thought under a stress test from drive-by commenters who don’t share your mental model and probably didn’t even read the whole thing. Like early-stage user testing, this is your opportunity to identify the most obvious gaps in the idea before iterating further.

Once the idea has percolated in my head & in public for long enough, I’ll typically make a post on LinkedIn next. The permissive character count makes it easier to go in-depth where necessary, and the higher conceptual fidelity of the idea at this stage is a better fit for the more professional audience there.

But just because it’s professional doesn’t mean it has to be milquetoast. While you shouldn’t troll solely for engagement, people are far more likely to engage with writing that’s passionate and has a human voice, compared to sanitized corporate speak (another compelling reason to leave LLMs out of this process).

LinkedIn does a better job of surfacing content that’s a bit older (posts hitting the 1 week mark frequently get boosted back into the feed, for no clear reason) so don’t be afraid to let ideas sit and come back to them later. You can keep track of posts by saving links to an external doc when you post them (in the manner of an annotated bibliography), or just use search to find them later.

Stage 3: Combining

This is the secret sauce, except it’s not secret anymore because I’m telling you about it right now for free. The most compelling writing creates connections across ideas; it bridges facts and then articulates an argument for how those facts are related.

You don’t need to overload on ideas. Two or three will do; anecdotally, my articles that are shorter than 7 minutes to read do far better than longer ones. And even if you want to go ham on the word count, don’t play all your cards at once — after all, you’re gonna want to write more later.

Give your reader a familiar staring point (some of my worst-performing articles were too esoteric, but then again, the quantity of eyeballs is not as important as their quality). Then introduce just enough additional concepts to pave the path towards a conclusion (a call to action, or a take-away). Those are what will get people sharing your post beyond your own network where more hiring managers will see it.

What that take-away will look like is obviously going to be field-specific. But giving an example of the right way to do something (from a single tip to a whole diagram or template) is much more likely to resonate than three thousand words about the wrong way.

Building a corpus

Obviously, the best long-term place to post the writing is on your own website. But it’s much easier to do it on Medium. I suppose there are other free platforms, but you really should not be using Substack, and posting on LinkedIn Pulse doesn’t get as many aggregate views as posting on here and then making a LinkedIn post about it.

If you write about evergreen topics rather than just trends, you can also refer back to older pieces. Either share out the same piece with a different summary, or link to an older article from a newer one. Over time it’ll help you form coherent relationships between your entire body of work, which will also make it much easier to move across these topics in an interview context.

And once you’re a bigshot and want to write a book, this corpus will make it much easier to do. Don’t forget to send me a copy.

A lot of ink has been spilled over Large Language Models and their associated products being inserted into just about everything, often against the will of the product’s users. One of the areas where the technology has managed to gain a foothold is software development; even as it slowly drains the will to live from Microsoft developers, their leadership celebrates the extent to which AI-generated code has been integrated into the company’s delivery pipeline. They’re not the only ones — pick a random post on your LinkedIn timeline and most likely it’ll either be gassing up the latest AI tool or lamenting their use.

Something is clearly not right here. How can exactly the same product be simultaneously The Future and less than worthless?

I think I have the solution. Those who find AI most useful have, in a process of convergent evolution, stumbled upon a secret known only to few.

eXtreme Go Horse

When Daniel Alonso dropped the first English translation of the XGH whitepaper in 2018, Brazilian developers had already been practicing it for nearly a decade. But outside of maverick organizations like Tesla, the methodology didn’t see much adoption among English-speaking tech orgs, with the industry preferring to stick to its stodgy Agile ways.

But let’s face it — Agile is old news. Software development in 2025 is a far cry from 2018. Change has come for us in the twin forms of mass layoffs and AI transformation. We are now called upon to do more, with less than ever.

You need to be more comfortable with error, with mistakes, with things that are a little rough around the edges. — Kevin Roose, XGH Black Belt

Which is why eXtreme Go Horse meets the moment in a way that old ways of working simply do not.

I believe that the reports of high productivity increases from GenAI tools are coming from individuals and workplaces that have (unknowingly) reinvented XGH independent of its original developers.

I am a firm believer in cross-pollination of ideas. I think AI tool users will see a lot of value in seeing the full list of eXtreme Go Horse principles laid out for them, and XGH practitioners will have their eyes opened to the power of AI technology.

The New Principles of eXtreme Go Horse

Obviously, XGH was written long before the idea of combining all the data in the world with all the money in the world was a twinkle in Sam Altman’s eye. I’ve taken the liberty of enhancing the original principles with proven capabilities that AI tools have demonstrated. Let’s call it XGH+AI.

I think, therefore it’s not XGH

In XGH you don’t think, you do the first thing that comes to your mind. There’s not a second option as the first one is faster.

The original Agile manifesto emphasized talking to customers. But the “job” that businesses “hired” it to do was increasing velocity, which it’s bad at. XGH+AI is a much better process for improving velocity. You can save a lot of time by outsourcing not only coding but also problem-solving to the AI — just ask it to generate whatever it is that users want.

There are 3 ways of solving a problem

The right way, the wrong way and the XGH way; which is exactly like the wrong one but faster. XGH is faster than any development process you know.

If you learn by shipping, XGH+AI will let you ship the wrong thing much faster than any old way of working, and the shipped thing will be more wrong than anything you could have dreamed of. Therefore we will learn faster than ever. It just makes sense.

You’ll always need to do more and more XGH+AI

For every bug solved using XGH, seven more are created. As all of them will be solved using XGH, then it’s utility tends to the infinite.

This is the perfect consequence in a world where using AI to code is mandatory regardless of whether or not it’s actually helpful. It will never run out of things to do and therefore you will never be fired for non-compliance.

XGH is completely reactive

Errors only come to exist when someone notices them.

AI tools are designed to discourage error-checking. This makes them perfect for XGH+AI’s radical approach to errors: you ask the AI to create tests, it pretends that it did, and then you are blameless for what happens next.

In XGH, anything goes

It solves the problem? It compiled? You commit it and don’t think about it anymore.

AI tools have been found to not boost developer productivity. But that’s only because they stopped to fix the bugs in the AI’s code. If you simply don’t worry about it, you can commit twice as fast.

You commit always before updating

If things go wrong your part will always be correct… and your colleagues will be the ones dealing with the problems.

The fastest gun is always the winner. If you use XGH+AI you’ll always ship faster than your colleagues, taking advantage of anchoring bias to make yourself look better.

XGH doesn’t have schedules

Schedules given to you by your clients are all but important. You will ALWAYS be able to implement EVERYTHING in time (even if that means accessing the database through some crazy script).

Sometimes ChatGPT goes down, and that means you can’t code anymore. That’s just life. I’m sure they will understand.

Be ready to jump ship or blame someone else when it goes down

For people using XGH someday the ship goes down, as time passes by and the system grows into a bigger monster. When that day comes, you’d better have your resume ready or have someone else to blame.

AI is the perfect scapegoat. Just say “it’s what ChatGPT wrote” and you will be off the hook for all problems.

Be authentic. XGH doesn’t follow patterns

Write code as you see fit. If it solves the problem, commit and forget about it.

If you relax your standards and let the LLM write code how it wants, you won’t have to fix it. That improves your velocity (see above).

There’s no refactoring, just rework

If things ever go wrong just use XGH to quickly solve the problem. Whenever the problem requires rewriting the whole software it’s time for you to drop off before the whole thing goes down.

AI can’t refactor so it’s best not to try.

XGH is anarchic

There’s no need for a project manager. There’s no owner and everyone does whatever they want when the problems and requirements appear.

AI has democratized not only coding but also management. You can just work on whatever you want and then say “I’m innovating with AI” if anyone asks.

Always believe in improvement promises

Putting TODO comments in the code as a promise that the code will be improved later helps the XGH developer. He/She won’t feel guilt for the shit he/she did. Surely there won’t be any refactoring.

Believing that AI will get better soon™️ is one of the most important tenets of being an AI powered rockstar.

XGH is absolute

Delivery dates and costs are absolute things. Quality is relative. Never think about quality but instead think about the minimum time required to implement a solution. Actually… don’t think! Do!

AI companies are setting a new standard in launching whatever, whether it works or not. You think you’re better than Apple and Google? Isn’t that a little arrogant of you?

XGH is not a fad

Scrum, XP? Those are just trends. XGH developers don’t follow temporary trends. XGH always was, and always will be used by those who despise quality.

AI is definitely here to stay. That’s what they keep telling us, so it must be true. This means XGH+AI is also here to stay. You will always be able to use these tools for cheap/free and they will never raise prices on them.

XGH is not always WOP (Workaround-oriented programming)

Many WOP require smart thinking. XGH requires no thinking.

With vibe coding, it has never been easier to make 70% of something that works. Simply leave the constraints you don’t like for that 30% and someone else will take care of it.

Don’t try to go against the tide

If your colleagues use XGH and you are the only uptight coward who wants to do things the right way then quit it! For any design pattern that you apply correctly your colleagues will generate 10 times more rotten code using XGH.

Billionaires are telling you to give up and embrace the AI, or else. And they must be really smart, otherwise how did they get to be billionaires? Oh, it’s from selling AI tools? I see.

XGH is not dangerous until you see some order in it

An XGH project is always in chaos. Don’t try to put order into XGH as it’s useless. You’ll spend a lot of precious time and it will make things go down even faster.

Priorities have changed. You aren’t going to win any points for trying to bring order. Let it go.

XGH is your bro. But it’s vengeful

While you want it XGH will always be at your side. But be careful not to abandon him. If you start something using XGH and then turn to some trendy methodology you will be fucked up.

Study after study shows that AI erodes critical thinking. But with XGH+AI you don’t need critical thinking anymore, as long as you never try to stop using XGH+AI.

Reconciling XGH+AI with Reality-Based Business Models

Both traditional XGH and its AI-powered update have a small problem, which is that generating ten times more code that’s ten times worse quality without waiting to see if it solves anyone’s problem or if anyone will pay for it is not actually going to help your company make a profit.

Fortunately, that kind of thinking is obsolete. Pretending to create value is just as good as actually doing it, as long as some rich guy believes in it hard enough.

And if this methodology sounds cynical and heartless — if you cringe to imagine anyone doing this to your product or code base — it’s not too late to stop outsourcing your thinking to a subscription product, and re-learn the skills you’ve already started to lose.

The failure modes of these two common form factors teach us a lesson about the dangers of thoughtless design.

It’s April 1st, which for many parts of the world is April Fool’s Day. While the entertainment value of tricking people into believing the wrong thing steadily declines with age, I still enjoy taking every opportunity to fool around in an industry that often takes itself far too seriously.

And no part of tech takes itself more seriously than B2B software. Forget the design principles of a bygone era; today, every Productivity Tool only needs to follow these two simple rules:

• All serious products must have a dashboard
• All innovative products must have a chatbot

As everyone wants to be seen as both extremely serious and completely innovative, every product now has both a dashboard and a chatbot, despite the fact that neither dashboards nor chatbots are particularly effective at solving the problems they’re created to solve.

This proliferation of dashboards and chatbots creates a nightmare for people who are just trying to get their work done, and therefore the managers responsible for smooth operations — who are, ultimately, the buyers of your products.

All they want is a single source of truth, and we’re about to give it to them in the worst possible way.

Let me take you on a journey; a journey of how “dashbots” come to be thought of as a good idea, and the rakes teams step on along the way of trying to implement them.

Ideation is a failure mode

If chatbots and dashboards are so bad, why are there so many of them? To answer that question, we have to ask ourselves: where do ideas come from?

Ideation, like every other process, follows the path of least resistance. In a post-ZIRP industry that has optimized itself for velocity at any cost, user research processes like “asking if people want this” are simply seen as slowing us down. The only way ideas make their way into the semantic environment is wholly out of the product manager’s head. Gone are the days of discovery; the “build-measure-learn” loop starts with “build” and we are not getting any new data until that first idea has been shipped.

So the PM sits down and thinks of something we can ship. The inspiration for what the product ought to be able to do comes out of other products that the PM is accustomed to seeing. And because we are in an era of measureship, what the PM sees most frequently is dashboards.

Now, “a lot of products have dashboards” is not a bad starting point. A diligent researcher might analyze the workflows running through that product to try and figure out why. Unfortunately, we are following the path of least resistance, so what gets noticed most is just the form factor — and as a result we are building a dashboard to solve the problem “our product doesn’t have a dashboard.”

Notice what we didn’t do: the work to understand what information is relevant or actionable to a given user, or whether a “single pane of glass” is the right vehicle to deliver that information.

Chatbots function on a similar principle. Most of them don’t actually do anything in practice, but there is an endless source of wishful thinking that someday, they might. The goal is to implement GenAI first, and to serve the customer’s needs a distant second.

One of the most popular trains of thought goes something like this:

1. Our website is an infinite lasagne of content sadness
2. Instead of fixing the information architecture we will add a chatbot that users can query for the content

After six months of development, the outcome is that instead of one bad interface, you now have two bad interfaces.

Despicable design

It’s only a matter of time until the two systems collide, and a PM will start conceptualizing how to implement a dashboard as a chatbot. Or perhaps this has already happened. And as your favorite thought leader’s favorite thought leader, it’s up to me to issue the design principles for this up-and-coming genre of “dashbots” — a facetious solution to a facetious problem.

From one point of view, an LLM is the worst possible medium for a dashboard. Firstly, its outputs are non-deterministic; a given query is going to return different results every time. Secondly, it’s going to get those outputs wrong two-thirds of the time. Thirdly, it’s perfectly willing to change its answer when challenged.

But from another point of view, all of these are features.

Giving users relevant data to take action is only a secondary use of dashboards. The first use, by a country mile, is storytelling; as managers report to their own leadership, they are required to increasingly massage the chaos of the front lines into a coherent narrative of inevitable success. That leadership, far too important to delve into the data themselves, is increasingly reliant on “executive summaries” etched in 8pt font onto slide decks marked “confidential.” Roll enough dice and you’re bound to get something that fits their preferred narrative.

However! We are engaged in despicable design, and yet we’ve inadvertently stumbled upon a good idea.

One of the biggest problems with dashboards is the total disregard for the attention economy; its designers slather whatever they can think of onto the screen, with the result being a screenful of garbage information. By allowing a user to compose their own query, they could potentially sidestep all of the data points we’ve decided are important (based on what our stakeholders would like us to show off), and therefore obtain some benefit from this tool.

Fortunately, the push-based modality of chatbots plays into our hands. In order to get that information, our hapless users first have to articulate what they want, without any guidance on what is available, or support for making sure that today’s prompt was phrased the same way as yesterday’s. Rather than making our dashboard glanceable, we have succeeded in making it merely queryable.

The purpose of a system is what it does

If a product team were to build dashbots, they would be the worst of both worlds: not only demanding excessive cognitive load, but also providing unreliable and manipulable data. These are not bug; they are the inherent properties of the form factors — dashboards and chatbots — assigned to the task. If you, as the designer, choose these form factors, then I can only assume that your intention is to produce the inevitable results.

However, if your goal is not to mislead your user after extracting the greatest possible effort in exchange for that information, I hope that you take this article as a warning. By understanding the dimensions in which these form factors can fail, you will have understood the dimensions in which they can succeed — if you leverage their strengths rather than insist upon their weaknesses.

For several years, Design has been in survival mode. In a post-ZIRP economy where investment is driven by fear, the question of “the ROI of design” has returned from the grave with slightly different wording. Today’s managers don’t just want results — they want results fast, and they want to know how UX is going to help them do that.

As the lines between Design and Product continue to blur, one camp of designers has hewed to a line that is familiar to any product manager: that the value of design is not in the race to fastest outputs, but in the marathon towards valuable outcomes. But Product has been escaping the build trap for nearly a decade, and is no closer to making its way out.

Other designers have accepted the challenge, and doubled down on shortening their design process. On the surface, this calculus makes sense: if today “value” means “velocity” then the best way for us to demonstrate value is to hock outputs out the door as quickly as requests come in. If “ship to learn” is real then the faster we can ship, the faster we will learn.

But somehow, the learning has also failed to materialize. Despite what our analytics and user feedback tell us, those requests from upstream never seem to take that data into account. “Build, measure, learn” inevitably remains at “build, build, build.”

The reason this keeps happening is that the feedback loop is broken. It’s being intercepted at its most critical point by one character — a character we’ll call the Fastest Gun in the West.

The “Fastest Gun in the West” problem

“Impactful design decisions are typically made well above the level of product teams” — Charles Lambdin

The name comes from the analogous phenomenon on Stack Overflow: the design of the system artificially inflates the salience of the first answer posted, disproportionate to its quality. A better answer posted late is buried under a worse one that has simply had more time to accrue votes.

There are Fastest Guns in product orgs, as well. But rather than compete for internet points, they race for control of the narrative that frames how the business defines its priorities. The commonly-applied mechanisms of annual and quarterly planning only compound the natural anchoring bias of the first idea on the table.

What makes its way down the planning funnel is neither the most achievable output or the most impactful anticipated outcome, but the minimum viable alignment of the decision-makers involved.

At a glance, this problem resembles the classic Waterfall BRD. But the situations couldn’t be more different. In fact, Fastest Guns often use the vocabulary of agility and design thinking to paper over complexity and delay hard decisions. Rather than resolving disagreements, the Fastest Gun covers them with a cloud of deliberate ambiguity. He knows that the cloud can’t last forever, but it doesn’t need to — it’s only there until the idea takes root as “the thing we are committed to doing” and is embedded in the roadmap.

This is where the Fastest Gun in the West becomes a UX-specific problem. When the goal is to rush the idea from concept to backlogs as quickly as possible, user research is not just an unnecessary time sink — it’s a serious threat. The Fastest Gun will eagerly attack the idea of research, cultivating a sense of urgency, and claiming that it “takes too long” and we can defer learning about the problem until after we ship.

When designers accept this framing under the pressure of “proving their value”, they play right into the Fastest Gun’s hands.

Potemkin Design

“Leaders want the payoff of experimentation but without the cost of any dead ends.” — Scott Berkun

The Fastest Gun’s path to success relies entirely on creating a perception of a fait accompli — that the scrutiny of refinement is not necessary because it has already been completed. The fastest way to do that is to produce outputs that appear indistinguishable from the outputs of a real design process. Rather than do the work, they simply forge the receipts — populating persona and JTBD templates with their own assumptions or LLM-generated drivel.

The one thing they can’t do on their own is produce high-fidelity mockups. The Fastest Gun is utterly dependent on designers to provide legitimacy to their vision, and will put tremendous pressure on design orgs to sacrifice every scrap scrutiny and process at the altar of “velocity” and skip directly to this stage.

But the deadline UX is rushed towards is not for getting working software into the hands of a user. It’s to lock in the Fastest Gun’s assumptions, drowning stakeholders with trivial detail to avoid pushback on the flimsy premise underneath.

A UX design practice that gives in to this working relationship may have a seat at the table, but will have nothing valuable to say.

Design positioned in this way also takes on the entire risk when the idea underperforms the Fastest Gun’s lofty promises. This is because — without the decision-making feedback loops of the design process — UX becomes entirely a delivery function. And if the vision is sound (after all, the stakeholders signed off on it) then the problems must be with implementation details.

This is where the promise of “ship to learn” falls apart. The delivery team indeed learns something from building the product, but the decisions impacted by those learnings are not actually made in the delivery phase. The relationship between the delivery team and the Fastest Gun is not a feedback loop; choices are made based on horse-trading and internal marketing long before anyone on the ground has a say about them.

Fighting fire with design

“You can be efficient or effective. When it comes to innovation, choose effective.” — Christina Wodtke

This is why design’s appeals to quality have fallen on deaf ears — in this influence system, quality is entirely besides the point. The fact that we care about quality and the Fastest Gun in the West does not is precisely what makes them the fastest.

The answer is not to try and compete on velocity. No matter how many steps we cut from the design process, we will never be faster than someone who shoots from the hip. Instead, we need to engage stakeholders on a higher level — illuminate the target faster, to show how badly their shots are missing the mark.

Optimizing time to high fidelity mockups is the wrong strategy because mockups are not the appropriate tool for this. They are a tool for solutions — and at this point, you have not even framed the problem.

To beat the Fastest Gun, designers need to engage stakeholders at the level of the mental model — the desired customer behavior change, the outcomes achieved by meeting their needs, and how they impact the business. A UI mockup doesn’t carry any of that information, because the UI is not the product. It cannot tell you whether or not its premise is valid.

But low-fidelity tools can; they are designed for that purpose. The customer goal and problem, as well as the implications of the proposed solution framing, can be captured in a scenario storyboard or PRFAQ at the right level of fidelity to invite refinement rather than avoid it. These artifacts give enough clarity for a stakeholder to say “no, this would not be a meaningful impact” and create permission to avoid a dead end and choose another direction.

If we have done our jobs right then by the time the Fastest Gun in the West tries to shoot, stakeholders will be able to see that he has missed.

The fastest gun in UX: Why your team is telling the wrong story was originally published in UX Collective on Medium, where people are continuing the conversation by highlighting and responding to this story.

When thinking about product development, I perpetually return to two powerful ideas:

• Design works through abstracting and adapting systems (including from one domain to another)
• A product is a system for delivering value, which means that a design practice is a kind of product that can be designed

Combined, these ideas form a thesis: through studying other systems of value delivery, we can design not only products that are more valuable to our users, but also a practice that is more valuable to our organizations.

And one of the most important aspects of a value-generating system is how that system transforms resources and effort into waste.

Getting nothing for something

If you are asking me to do work for exposure, you have to explain to me why it’s not the kind of exposure people die of. — KJ Charles

Value is a matter of perspective; when we say “we are creating value” the next question should always be “for whom?”

No domain better illustrates this principle than writing. In pure economic terms, the value of a writer’s writing is not the text itself, but in the ability to sell it to someone (such as a publisher who, in turn, derives value from putting the writing next to some ads). In theory, both the buyer and the seller of the writing gain value from the exchange.

However, many writers are offered a much more dubious exchange: for exposure. In other words: if you give me free stuff, others will see what a great job you’ve done.

Writers who follow up to understand exactly what kind of bump in commissions or book sales others have actually seen as a result of this exposure are usually met with abstract promises and few if any figures. They are just being asked to work for free, but with extra steps.

Writers who end up working “for exposure” are still creating value — for their “customer.” But for themselves, this work has no value.

Time & resources spent on outputs without value have another name: waste.

Which brings us back to software.

One man’s waste is another man’s velocity

[Many designers] think that ‘user centricity’ is self-evidently desirable. As a result, they can’t make convincing business arguments for their role. — Jorge Arango

Unlike freelance writers, product teams typically work for a salary. And yet, they do a tremendous amount of work “for exposure.” It’s just that the pitch looks slightly different: instead of “write me this article so that people can read it” we can observe “add this feature to the app so that users can use it” across every product backlog in the nation.

From the perspective of the organization, it’s exactly the same situation as working for exposure, and just about as effective. The resources expended towards these features are converted directly into waste at 100% efficiency.

Who will see it? What will the impact of them seeing it be? How have previous features performed? How will this work actually fit into the business strategy?

Unless you can answer all of these questions, you’re building features for exposure.

Build-measure-learn optimizes for waste

People get obsessed with “change” as a substitution for “leadership” so they interpret “little change” as evidence that leadership is missing. — Joshua Foust

One of the most common arguments used when building features for exposure is “we can’t answer those questions until we ship and see.”

Sometimes, this will be true. For those true zero-to-one products, with nothing at all in production, there’s no replacement for real data from real users (although, once again, you really should be studying analogous domains).

But somehow the same argument ends up dragging past that first release: we still can’t know, we have to ship more. The absence of measurable impact is interpreted not as a lack of value, but as a lack of outputs.

And until the system is interrupted, the cycle of waste continues.

Just like the author must ask how “exposure” will convert into book sales, we must ask how shipping will actually turn into seeing. What will make this release different from every previous release, so that we may at last begin to measure and learn?

Or, when the feature is done, will we begin working on the next assumption-informed feature in the roadmap, until someone realizes that all of this velocity amounts to waste and starts pointing fingers?

Stop building features “for exposure” was originally published in UX Collective on Medium, where people are continuing the conversation by highlighting and responding to this story.

The fundamental job of UX is to propose change. From the basic double diamond to more esoteric diagrams like the analysis-synthesis bridge model, we envision our work as closing the gap between a “problem” current state and a “solution” desired future state.

In many ways, that is the easy part. The hard part of the job is seeing that change through.

While our design tools give us total control over rectangles, designers get no such power over people and “nobody listens to us” is perhaps the field’s most persistent complaint. And yet as a field, design is headed in the opposite direction: by shifting the burden of crafting persuasive arguments onto AI tools that are not fit for the purpose, we are making ourselves less and less convincing.

Technology is not going to save us here. Designers hoping to break out of merely validating stakeholder biases need to reach beyond STEM and start designing arguments.

UX is persuasion

We’ve known since the 60s — before the term “UX” occurred to anyone — that to frame and solve the type of wicked problems that are design’s raison d’être, designers need to not only identify an issue, but to articulate their position and support it with argument.

The argument is critical because the value of UX lies in persuading stakeholders to do something different than what they were going to do.

Work that does not do this has no value. Charles Lambdin explains why through the Sure Thing Principle: if we were going to do the same thing before and after we did the research, then the effort spent on research represents waste.

If our audience doesn’t need to be convinced — if we’re only validating what stakeholders already believe — we are not providing any new insight. If our audience does need to be convinced, and we fail to convince them, then our insight is not acted upon and the result is essentially the same.

Either way, we didn’t actually add any value.

Even when it comes to the “design” part of UX — the work of defining how the product will behave, rather than discovering why — we are not free from the work of having to convince stakeholders. They will never perfectly recreate the system we imagine inside their own heads, and so we do the work for them through diagrams, models, flows, and presentations. The majority of our outputs are something that describes the user experience, but for which the user is not the audience.

And they must describe that experience persuasively, because design is far from the final arbiter of what will be shipped. In a standard “three legged” model of ownership, “feasible, viable, and desirable” are not independent factors. They are always in tension. There is no such thing as “infeasible” without the cost-benefit analysis of “viable” — a sufficiently lucrative business opportunity can justify unlimited investment into technology.

If design cannot make that kind of argument — that a good experience is worth extra effort from the other two “legs” — then we will be stuck in a world where our impact is only in the margins of the business model and the tech stack.

(Un)fortunately, that doesn’t mean going to meetings and shouting the loudest. An argument must work across many form factors — some for when we are in the room, and others for when we are not. In order to persuade across a variety of situations, we first need to design the argument in its purest form.

An essay.

An essay, like in English class?

I will readily admit that there are few things less popular than essays. When I was in school, I didn’t appreciate them either. My approach was similar to that of many students: start typing and stop when the page count meets the rubric.

But of course, all of us were missing the point. The objective was not to write text — the objective was to practice forming an argument.

Over and over, our teachers told us the formula: state your thesis, present the evidence, and then explain how the evidence supports the thesis. Rather than simply asking the audience to trust us, the format of the essay guided us to convince our readers by explaining how we got from facts to the conclusion.

Issue, position, argument.

It’s no surprise that humanities graduates secure some of the highest-paying jobs across industries, often in leadership positions. Being able to comb through texts, pull out relevant information, and combine it into a convincing pitch to solve difficult problems is the foundation of how companies organize strategy in the first place. If we accept Charles Stross’s argument that corporations are a slow, procedural AI then humanities majors are the data scientists that train that AI for the necessary outputs.

And it’s well known that the structure of a company determines the products that it will create. Over the course of many decisions and releases, layer by layer, the system optimizes itself to make the thing it is making. When a designer proposes a change to that output, they are pushing against the collective force of a system producing the one product that it is capable of producing.

If their weapon of choice for that fight is a Figma file, they will always lose. All but the most tactical changes will become stripped away not because they are not feasible, viable, or desirable — but because the established path of least resistance lies elsewhere.

To produce a different product, designers need to change the prevailing system. And in a corporation, that is done through persuading its constituents.

AI can’t do this job for you

Unfortunately, the field of UX — like many fields — is trending away from changing the prevailing system, and towards the opposite goal: racing down the beaten path as quickly as possible. Designers are asked to cut the research process short to focus on the real work…

…except that this is the real work.

Relying on LLMs to lubricate your time-to-insight so that you can go Do Design puts you in the same boat as feckless teenagers who rely on LLMs for writing C-minus essays faster than they otherwise could. You get the essay-shaped piece of text, but not the benefits of having written it. A report that truly embraces X=0 from Lambdin’s diagram by confirming all of your assumptions in the fastest possible amount of time.

Because an essay is not just a container into which a human might place an argument — it is a tool for building the argument in the first place. The most interesting discoveries — the most impactful insights — come from a hunch that two ideas are connected, and the itch to dig deeper into the link between them. When you can go from “customers do this and this” to “customers do this because of this” you find opportunities that no one else can see. The axis between those two points becomes the structure around which everything else falls logically into place.

This connection is valuable precisely because it is not obvious. Its novelty has the power to significantly change the decision being made — but it also means that the argument needs to be that much more convincing. A deliberate approach to the design as an essay is a flywheel for value — it strengthens both the design’s innovativeness (by helping us as authors to find two distant data points) and its persuasiveness (by building a strong connection between them).

When you use AI to summarize (or worse, generate) transcripts and responses, you are just getting back text. An LLM cannot draw the inferences that discover interesting arguments, or make them compelling, because it is just shortening the content fed into it. It cannot “think harder,” but only generates a slightly different list of statistically average ideas.

A well-developed point of view can never be commodified, and so the skills to persuasively articulate it will always be a worthwhile investment.

A good design is a good essay was originally published in UX Collective on Medium, where people are continuing the conversation by highlighting and responding to this story.

They say that good designers fall in love with problems, not with solutions. I tend to agree, and the first thing I always ask new customers to do is describe the problem they are facing.

A couple of years back, a customer came to me with a request: “Our CEO tried to use our product. His transaction didn’t go through and he couldn’t see its status. So customers being able to track their transaction is a priority problem that we need to solve.”

I’m sure you’ve already spotted the snag: the problem in their statement was “users don’t have this tool.”

In other words, it was a solution statement in disguise.

But we couldn’t convince the customer’s CEO to change it. He “fell in love” with the problem of not having a tracker. After two years of bashing away at the problem without moving the metrics, the customer’s team realized what we had told them in the first week: that they were trying to solve a product problem rather than a customer problem.

The road to the Build Trap is paved with product problems

The build trap is when organizations focus more on shipping and developing features rather than on the actual value those things produce. — Melissa Perri, Escaping the Build Trap

This was hardly the only time that a customer’s first stab at a problem statement ended up defining a product problem. In fact, the majority of initial problem statements I see are some twist on “we want to add this feature, can you help us define it.”

This makes sense because of how these teams are typically organized — not as true product teams, but as project teams. They are given an output goal and only make decisions within the bounds of that output. Since decisions about the form factor are typically made for them by executive stakeholders — like that customer’s CEO — they skip right to the form factor.

Because the team was told “build a tracker” by their stakeholder, “users want a tracker” became the animating principle behind the team’s efforts. Other mandates you’ve likely seen pop up in the news include “users want a chatbot,” “users want a dashboard” or “users want a subscription to their mouse.”

Fundamentally, the question all these teams are asking is not “what needs do our customers have?” but “What features is this product missing?”

They are solving product problems.

When low-maturity product teams do engage with outcome goals, the situation is rarely much better. Vanity metrics such as number of queries or email send rate predominate, locking product teams into their most highly instrumented form factor rather than allowing them to choose the most appropriate channel for reaching the customer.

Once the team’s work is framed as a product problem, it becomes extremely difficult to correct that framing. No amount of validating your idea will tell you that you’re on the wrong track.

When you ask “what features do users want the dashboard to have” you’ll never hear “users don’t need a dashboard” unless you’re really good at reading between the lines.

This kind of work is commonly dismissed as UX theater — and rightly so — but it can certainly feel like research to inexperienced practitioners. After all, the PMs talked to customers, and gathered feedback and feature ideas, which they used to create a roadmap and then a prioritized backlog. What more could you want?

But the features delivered from that backlog will all contribute to the user experience rot, because they build on a premise of solving the product problem of “missing features” rather than the customer problem of not being able to reach their goals.

Customer problems make teams; product problems break teams

When a work group establishes shared goals and methods to achieve these goals, it transforms into a team. — A Deeper Understanding of Real Teamwork and Sustainable Quality Culture

Product teams don’t realize they’re making this mistake because it’s baked into the stories-and-features way that PMs are trained to approach problems. Even Marty Cagan doesn’t consider “does it solve the user’s problem” to be one of the four big risks (“will people buy it” is the closest, but not the same thing at all).

Instead, Cagan slotted UX design (the function best suited to catch that risk) into the “usability” bucket, and many PMs followed.

As a result, the majority of time designers spend on product teams is dedicated to solving tool problems rather than goal problems — how to make a feature more usable, or how to add more options and settings. And given that every tool problem is by definition a problem created by the team, the overall impact of solving those problems is extremely low.

Of course, designers are equally guilty of solving design problems over customer problems. Or perhaps even more guilty, as our field is structured around incentives to design for other designers — dazzling our peers with awards and hiring managers with stunning portfolio visuals.

And software developers have their own version of this phenomenon; trying to learn about customer needs by shipping the MVP can quickly evolve into incrementally working out interesting coding problems at the cost of making measurable improvements to the user experience.

As a result, the three “legs” of the product triad end up setting their own goals, and fighting over them. The prioritization process turns into haggling: we will solve this many product problems to this many design problems to this many developer problems.

While everyone is haggling for themselves, there is no time left to exercise all that empathy for the customer.

The result is an entire industry of products solving problems for its employees and the people who live like them.

Forget the product, focus on the customer

“Working backward from customer needs is a huge amount of work. But it will save you even more work later.” — Jeff Bezos

This issue runs deep. It is at the very root of how we talk about products: the framing that products are “desirable” to customers has influenced product thinking for over 20 years.

In reality, no products are desirable to customers. Customers have desirable outcomes, which products can help them reach. And while any successful product strategy must ultimately pick a level of outcome at which it wants to play, choosing to play at the widget level and then flailing for product-market fit before your funding runs out is the least effective level to play at.

Instead of forecasting outputs based on what stakeholders are asking, product teams need to start with what stakeholders hope to achieve and then back-cast from those outcomes to chart possible paths forward.

Then instead of prioritizing features, you can choose a single bet without compromising your flexibility: which next step will help us learn the most about what a viable path forward looks like?

The result might not be the world’s sexiest app. The solution my team convinced the stubborn customer to build in the end had no web presence at all — because their users didn’t want to go to a website. We sent them the information they needed directly by SMS. But it was quick to build, cheap to test and — most importantly — it kept customers informed much better than a tracker on a website most of them would never see.

Stop inventing product problems; start solving customer problems was originally published in UX Collective on Medium, where people are continuing the conversation by highlighting and responding to this story.

Big Tech stocks are tumbling on the news that the industry is losing handfuls of money. Just like last time and the time before that and that other time. Each time, tech leaders were able to reassure investors that despite burning cash like it’s going out of style, the technology that would change everything was just around the corner.

How do they, as the saying goes, keep getting away with it?

Well, there’s a trick.

It’s a trick you’ll see often in newspapers, once you learn how to recognize it. In fact, once I explain the trick, you may start seeing it just about everywhere. And I really do mean everywhere — including in your own thinking.

It’s important to understand this trick not only so you can avoid getting tricked, but also so you can avoid tricking yourself.

In the news, this trick is used when discussing traffic-driving topics; known entities that reliably get clicks and eyeballs on the page, year after year. Donald Trump is one example of such an entity; closer to tech we might pick names like Sam Altman or Elon Musk.

On the surface, it sounds like it would be easy to write about figures like that. They say and do a lot, every day. But that very same property is what makes that job difficult. Because they have been saying and doing things for years, these figures all have a history that is a matter of public record. People writing about them want to tell stories — but the stories have been told. Readers already know the ending.

When they want to sell the same story for a second time, storytellers use the forgetting trick.

Age of Mythology

“Nothing pleases people more than to go on thinking what they have always thought, and at the same time imagine that they are thinking something new and daring: it combines the advantage of security and the delight of adventure.” — TS Eliot

The forgetting trick is dead simple: to avoid reckoning with the inconvenient track record of their subject matter, storytellers turn the frame of their story solely forward. The trick is to lay out a shiny roadmap stretching into the future, to distract from the grimy footprints following from the depths of the past.

Because if they did, the storytellers would have to reconcile the roadmap with that track record. And the track record would tell the story for them.

Instead of using that track record, storytellers ground their story in myth. They fill the gap left from excising the facts with allusions to the myth of the Silicon Valley Innovator whose daring vision changes the status quo. Part of the Innovator myth is that they know how to deliver those results, so instead of answering “can this person deliver what they promised” they can treat it as a foregone conclusion and speculate about what might happen if they did.

The forgetting trick is powerful because we want to believe the myth. Audiences love nothing more than the promise that things will be different from how they are today — especially if things can get better without them having to change what they are doing right now.

Of course, those audiences are set up for disappointment when the promise inevitably fails to pass. The forgetting trick deflects accountability until it suddenly doesn’t and your only hockey-stick growth is in the consequences.

Performing Leadership

“It is difficult to get a man to understand something when his salary depends on his not understanding it.” — Upton Sinclair

Elon Musk is not the only figure in tech who, to borrow a term from constructivism, performs leadership. Every executive is expected — and usually held responsible by the company charter — for presenting themselves as a leader who can Think Big by making announcements that improve investor sentiment and, therefore, stock price.

People further down the org chart are still part of this performance. We discuss mini-CEOs without a trace of irony and say that everyone is a leader. We tell the same stories about vision, and play the same forgetting trick. The only thing that changes is the medium through which we tell the story — instead of journalists writing in newspapers, we see product managers preparing roadmaps for their stakeholders.

In this context, the forgetting trick becomes much easier. Past promises and their outcomes are not a matter of public record; with an average tenure on the job between 6 and 24 months and reorgs happening more frequently than that institutional memory rapidly approaches zero. Both the storytellers and their audiences are highly incentivized to ignore the facts and believe the myth. Is it any surprise that we end up playing the trick?

As a result of this trick, the stories that the roadmap tells come out very convincing. So convincing, in fact, that the job already feels half-done. Product managers who find themselves in this position need to check themselves and ask — if it’s that straightforward, how come no one’s done it already?

Big ideas require big behavior change

“We wanted the best, but it turned out like always.” — Viktor Chernomyrdin

The answer, of course, is that it was never that simple.

But by writing a story in the shape of a roadmap, we accidentally tricked ourselves into thinking that it was a roadmap, and that we had done the work through the vision stack necessary to make it meaningful.

When we substituted the generic, all-capable Innovator persona for the reality of our organizations, we temporarily obscured all the execution challenges that would lie between ourselves and “inevitable” success.

The only inevitable result of this process is that product managers end up holding the bag.

I can’t speak for Elon Musk and Sam Altman, but I believe that regular PMs want to do good work and fall victim to the forgetting trick only inadvertently. Anyone who wants to avoid getting tricked in the future would do well to ask themselves these questions:

1. Was this person or organization able to deliver on promises like this in the past in full, in part, or not at all?
2. If not in full, what needs to change in order to be able to get from here to there, and are we seeing that change?

Chances are that your organization is planning or already implementing some sort of AI project. In which case the questions might look something like this:

1. Has your organization successfully implemented any cutting-edge innovations before, or did they all stall at the proof of concept stage?
2. Do you know why things turned out that way, and what you need to do differently to avoid the same fate?

Hopefully, you’ll be able to avoid tricking your team next time you’re asked for the Big Ideas. But you’ll definitely be able to avoid getting tricked by headlines offering empty promises.

Tech’s stock crash and the Forgetting Trick was originally published in UX Collective on Medium, where people are continuing the conversation by highlighting and responding to this story.

Last week, the former Sr. Brand Director of Nike published a rare deep dive into a marketing blunder four years in the making. As a firm believer in taking inspiration from analogous domains, I think there is a great lesson here for Product and UX to take away.

Why do I think it’s relevant? Just tell me this doesn’t sound familiar:

“Nike invested billions into something that was less effective but easier to be measured vs something that was more effective but less easy to be measured.”

On the advice of McKinsey, Nike’s new CEO John Donahoe decided to pivot to a “data-driven” approach, reorganizing the company towards digital direct-to-consumer sales and eliminating the former model centered on distinct categories. The allure is easy to recognize, and it’s the same trap that Boeing and other companies fell into over the preceding years.

Coming up with new ideas is difficult and requires specialist knowledge. Moreover, it requires specialist knowledge to understand what those specialists are doing and therefore manage them.

Meanwhile, slashing costs works the same way across every industry. And so Nike squared up to eliminate duplicate processes, streamline operations, improve efficiency, and increase productivity — all those phrases that are meant to say “whatever it is you do — do it harder.”

How well did it work? Well, that depends on what the intent behind the strategy was. If Donahoe intended to lose $25B in market cap and tank the stock price 32%, it was a smashing success. For those of us who don’t think that’s what he meant to do, it bears reflecting on where he went wrong.

The hard limits of data

It is wrong to suppose that if you can’t measure it, you can’t manage it — a costly myth. — W. Edwards Deming

Data isn’t worthless. Data is really, really valuable for telling you what has happened in the past. Great expense has gone into producing data that can tell you what’s going on in the present. But as the 7- and 8-figure salaries of quantitative analysts at hedge funds show us, using data to extrapolate what will happen in the future is one of the most challenging things you can try to do with it.

Typically, the way one would do that is by harvesting what’s called warm data — the qualitative data that gives the numbers their meaning — and then using that to tell a story about where the numbers are going.

Unfortunately, that’s not what online advertising does. As Phil Bastien calls out here the most common outcome of advertising data is that if you buy a couch, it must mean that you need more couches.

Human marketers and merchandisers know this — it’s why you might see paper towels next to the BBQ sauce or buns and hotdogs together at the store. Humans could enrich “you are buying bread” with the qualitative data point “toppings go on bread” to create a delightful shopping experience. But getting data — even data fed to an AI — to do this is much harder than you’d think.

Nike’s decision to eliminate individual product categories — who could marshal exactly this kind of expertise — in favor of a generic one-size-fits-all data model created a problem that you can probably predict. This model performed the equivalent of handing out flyers for your pizza shop in the pizza shop’s lobby and signaled the business to reorganize from attracting new customers to pumping more money out of the customers they already had.

The data-driven death spiral

Measuring the wrong things is a fast path to disaster. — Jared Spool

One might propose that the entire profit motive behind the genre of creative work made up by brand, marketing, and design is to drive behavior change. We enable customers to do something new — whether by informing them that an option exists, or making it more attractive and effective to choose that option over others.

And this is where the trouble starts. Nike’s incestuous strategy was bringing in data on existing customers — those whose behavior didn’t need changing.

This is an extremely common mistake in all kinds of industries — the most vocal, most frequent, loudest participants in your research are the least representative of the total addressable market. The people who don’t — or can’t — use your product barely show up on the radar.

It’s tempting to reach only for the data that’s easiest to harvest, and stop there. That’s exactly what Nike did with their online shopping data. As a result, their product priorities rapidly diverged from the kind of things ordinary customers buy, while product with mass appeal rotted in warehouses for lack of places to sell it. And the longer Nike chased these fringe customers, the more ordinary shoppers moved on to a competitor’s product.

Letting data drive you is fixed-mindset thinking

“A fetish has been made of quantitative methods and whole laboratories have been devoted to solving, with elaborate statistical machinery, problems which had very slight importance.” — Gregory Bateson, 1944

With the benefit of time and distance, it’s easy to condemn Nike for making this mistake. It’s even easier to believe that we can avoid it — because we would simply pick the right data to follow, instead of the wrong data.

The fact of the matter is that this mistake was made by experienced, intelligent professionals who also thought that they were doing the right thing. It’s not enough to identify that they were wrong; we need to understand why in that moment, the wrong thing seemed like the best way forward.

And it’s easy to see how it would be. Nike is still one of the world’s most valuable brands, and chasing whales has worked well for many lesser firms. In an environment as risk-laden as 2020 was, it feels good to lean into your strengths and get a practically-guaranteed 10% (or whatever) bump in your metrics.

It’s also very tempting to close your eyes and pretend that the 10% isn’t coming at the cost of larger losses elsewhere, because if you speak up it might be your job that’s on the line in the next round of layoffs. It takes a lot of courage and conviction to push back against the dominant narrative. It takes research skills to form an informed hypothesis and business sense to convince people with budgets that it ought to be tried.

“Validating” what everyone already believes is far easier — but it adds no value. The value of research doesn’t come from elevating people who are already shouting. It comes from finding the people who are not being heard, and adding their voices to the conversation.

Then you can make a real data-driven decision: a decision driven by all the data.

Otherwise, the best you can do is commodity-grade decision-making.

Nike’s $25B blunder shows us the limits of “data-driven” was originally published in UX Collective on Medium, where people are continuing the conversation by highlighting and responding to this story.