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 designmethods.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 withbuild.The trouble begins when working code becomes conflated withvalue.Its easy for executive stakeholders to start thinking that if we cannot deliver value without delivering code, it means that code is whats valuable. Often, stakeholder pressure to deliver their ideas on time becomes the primary metric of success. Executives want numbersand its very easy to measure shipping velocity and pretend that it is a proxy for the value wedeliver.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 turnssour.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? Whats theROI?Or, more honestlywhats in it forme?Yes, indeedin 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 improvementsnot only to the product, but to the product practiceitself.In a single-loop learning context, both of you are wasting yourtimeProcess is the clay that product managers shape to make good products. The result of a PMs 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 soon.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 stakeholderswhether in Product, in Sales, or all the way from the executive suitealso have ideas. And depending on org politics, their ideas can carry a lot moreweight.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 managersthe thing they are incentivized to dois 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 its worth asking an analogous question here: if you could choose to hire those rituals, would you? Do they help you achieve yourgoals?In this context, I think the answer isno.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 thats the opposite of good Product practice! Product managers dont want to work like this! So its only natural that, faced with the incentives they have, they are eager to sweep away any steps that theycan.Which brings ustoDesign and the win-conditionWhat is the ROI of UX? Often, this question is askedand interpretedas badfaith.But asked in good faith, I think its 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 Ive 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 users behavior in this way, and the new behavior will be advantageous for our businessmodel.That win condition is key to any modern outcomes over outputs approach; if you cant answer how will it get us to the goal? then you shouldnt do it. This logic is at the heart of a product managers job, and even mediocre PMs will exercise it when prioritizing delivery work. Its good to say no to ideas if they are not the best way to reach our desired business-level outcomes.If what youre working on doesnt have a clear line back to metrics that matter to the businesswhy are you working onit?Those same PMs, however, often dont 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 toserve.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 ourgoal?But before we can answer that question, we have to establish what that valuable goalnot just the next task on our checklistactuallyis.Your best practices arentWhat do I mean by task, as opposed to goal? Well, if your answer is the framework says then its 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 thingthat customer value that the software you are making is supposed to deliver to theuser.And yet a great number of software development activities have replaced measurable benefit with sheer ubiquitychosen because of their status as best practices rather than a coherent win condition. You dont have to go any further than user storieswhich are now used for things like as a system I want to connect to the database to get the datato see evidence of professionals reaching for the nearest tool, rather than the bestone.A best practice is only as good as your understanding of what you want to get out of it. If you dont know what it is youre hoping to achieve, no methodology in the world will helpyou.Halt and Catch FireS01E01When it comes to design, this is a remarkably common situation. After a decade of being sold design thinking product teams still dont really know exactly what it is for. When I ask what stakeholders hope to do with the artifact theyre asking for, most will stop mid-sentence because they lack an answer beyond weve always asked forit.Fortunately, designers have become accustomed to answering the question of what good is this? Design practice has been developing an antidotethe so-called Danish Design Ladderto 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 aroundoutputs.This approach to choosing methods is exactly what Product needs to attain escape velocity from the infamous BuildTrap.Thinking like a designer about how you do product management, not justproductBefore 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 designers 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 betterways?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 clearbecause that is the environment in which the feedback loops of the design process can actuallyoperate.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 stepbut only if theyre ready to think about what that question reallymeans.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.