Design has little value for a team driven by outputs. But any Product team that hopes to deliver outcomes will never make that shift without embracing design methods.
It is a truth universally acknowledged that value requires working code in the hands of our customers. “Build, measure, and learn” after all has to start with “build.”
The trouble begins when working code becomes conflated with value.
It’s easy for executive stakeholders to start thinking that if we cannot deliver value without delivering code, it means that code is what’s valuable. Often, stakeholder pressure to deliver their ideas on time becomes the primary metric of success. Executives want numbers — and it’s very easy to measure shipping velocity and pretend that it is a proxy for the value we deliver.
In an environment where value and velocity are the same thing, adding any work that impacts timelines goes against the incentives in play. So naturally when UX design shows up to talk about Process and Research and other capitalized nouns, the conversation turns sour.
I hear the same thing from many product leaders: user research slows us down, and UX design process is a waste of time. All we need from UX is visual designs for usable experiences. Why are you doing all this other stuff? What’s the ROI?
Or, more honestly — what’s in it for me?
Yes, indeed — in this context, the design work has little impact on the value delivered. But design is also the key for getting out of that environment. If PMs can stop working at cross-purposes with UX, the outcome is orders-of-magnitude improvements — not only to the product, but to the product practice itself.
In a single-loop learning context, both of you are wasting your time
Process is the clay that product managers shape to make good products. The result of a PM’s work is not so much the product itself as the mold by which an idea gets turned into a roadmap, into epics, into requirements, and so on.
Of course PMs aspire to be the originators of ideas as well; to drive the “customer collaboration” at the heart of the Agile Manifesto that defines truly valuable software. But in many orgs, senior stakeholders — whether in Product, in Sales, or all the way from the executive suite — also have ideas. And depending on org politics, their ideas can carry a lot more weight.
In these orgs, PMs are still expected to perform all the rituals of product management: compose PRDs, fill out strategy canvases, establish metrics, and all the other things that came part and parcel with their latest Agile Transformation. But the real output of these product managers — the thing they are incentivized to do — is features in the backlog, and code in production.
John Cutler once posed an extremely interesting question: if your development team could choose whether or not to hire a PM, would they? Putting on our Jobs-to-be-Done hat, I think it’s worth asking an analogous question here: if you could choose to hire those rituals, would you? Do they help you achieve your goals?
In this context, I think the answer is no.
When decision-making comes from outside of the Agile organization, any process represents a burden imposed from the top down rather than an enabler of value. Ship our ideas, but make it look Agile. Use your own judgment to come to our conclusions.
But that’s the opposite of good Product practice! Product managers don’t want to work like this! So it’s only natural that, faced with the incentives they have, they are eager to sweep away any steps that they can.
Which brings us to…
Design and the win-condition
…”What is the ROI of UX?” Often, this question is asked — and interpreted — as bad faith.
But asked in good faith, I think it’s a very fair question. “What can this new thing do for me?” Regardless of whether you use JTBD, user stories, product hypotheses, or some cutting-edge methodology I’ve never heard of, every product feature will have some kind of “win condition”: this will be our user, the output we produce will change that user’s behavior in this way, and the new behavior will be advantageous for our business model.
That win condition is key to any modern “outcomes over outputs” approach; if you can’t answer “how will it get us to the goal?” then you shouldn’t do it. This logic is at the heart of a product manager’s job, and even mediocre PMs will exercise it when prioritizing delivery work. It’s good to say “no” to ideas if they are not the best way to reach our desired business-level outcomes.
If what you’re working on doesn’t have a clear line back to metrics that matter to the business — why are you working on it?
Those same PMs, however, often don’t hesitate to turn to a designer and ask for some artifact without a clear sense of why. Millions of personas, service blueprints, and wireframes get produced and then abandoned in Confluence because there was never a purpose for them to serve.
These artifacts are not inherently without ROI. The reason they have no value is because they were created without a valuable goal in mind. The question “why are we doing this design stuff?” must be reframed as “is design helping us reach our goal?”
But before we can answer that question, we have to establish what that valuable goal — not just the next task on our checklist — actually is.
Your “best practices” aren’t
What do I mean by task, as opposed to goal? Well, if your answer is “the framework says…” then it’s a task. No matter how widely-adopted it might be, not a single methodology out there is so precious that it has value in its own right. They are all just one way to get you to “the thing” — that customer value that the software you are making is supposed to deliver to the user.
And yet a great number of software development activities have replaced measurable benefit with sheer ubiquity — chosen because of their status as “best practices” rather than a coherent win condition. You don’t have to go any further than user stories — which are now used for things like “as a system I want to connect to the database to get the data” — to see evidence of professionals reaching for the nearest tool, rather than the best one.
A “best practice” is only as good as your understanding of what you want to get out of it. If you don’t know what it is you’re hoping to achieve, no methodology in the world will help you.
Halt and Catch Fire S01E01
When it comes to design, this is a remarkably common situation. After a decade of being sold “design thinking” product teams still don’t really know exactly what it is for. When I ask what stakeholders hope to do with the artifact they’re asking for, most will stop mid-sentence because they lack an answer beyond “we’ve always asked for it.”
Fortunately, designers have become accustomed to answering the question of “what good is this?” Design practice has been developing an antidote — the so-called Danish Design Ladder — to transition from low-impact Design As Decoration to strategic and deliberate Design As Culture that begins with establishing shared and valuable goals, rather than merely contracts around outputs.
This approach to choosing methods is exactly what Product needs to attain escape velocity from the infamous Build Trap.
Thinking like a designer about how you do product management, not just product
Before you ask the question “what can design do for me?” take the time to think about what it is you actually want to do. If you define your goal as “ship the feature” then you are wasting your own time as well as your designer’s time.
PMs who really want to be “mini-CEOs” need to be able to quantify the value of the goals they want to achieve. Once that work is done (and it is work, a lot of work) they should start to investigate all their methods to answer the all-important question: Is this way helping us reach the goal, and are there better ways?
The questions designers ask while designing software are just as effective when asked while designing process.
For anyone able to define real goals measured in terms of outcomes, rather than velocity to outputs, the value of design becomes clear — because that is the environment in which the feedback loops of the design process can actually operate.
Back in the early 2000s, product managers pushed back against Agile as well, until they realized that it was a better way of building valuable software. 20 years later, when product managers wonder whether they should say “no” to design, it gives me faith that they are ready to take the next step — but only if they’re ready to think about what that question really means.
How PMs can turn process from a time-waster into their greatest superpower was originally published in UX Collective on Medium, where people are continuing the conversation by highlighting and responding to this story.
