Same Designer, Different Job
Two companies each brought me in to lead the reimagining of a legacy software platform.
Same title. Same skills. Same research methods. Same sticky notes on the wall.
One company asked me how to mitigate risk.
The other asked me to complete the tickets on its roadmap.
I was the same in both rooms. The companies were not.
Design does not get its job description from designers. It inherits one from the company, long before the first designer is hired.
Excuses, and What They Reveal
Ask why design stays tactical, and the answer often starts the same way: “We’re not ___.”
Sometimes the blank is Apple. Fair. No one is asking you to be Apple, or Airbnb, or Spotify. But it is strange to treat Apple, one of the most valuable companies in the world, as a reason to stay incurious about design.
Sometimes the blank is quieter: “We’re not a software company.” Manufacturers, banks, and hospitals say it, and mean that software is not the real business. Some build sophisticated software that is never sold on its own, so nothing forces them to ask whether anyone wants it or would pay for it.
In 2011, Marc Andreessen argued that software was eating the world. He was right. But it did not make every company good at building software. It made almost every company dependent on it—to deliver the product, support the customer, manage the workflow, explain the value, or run the business. So the question is not whether you are a software company. It is whether software delivers the experience your customers, employees, or partners actually have.
Then there is the dismissal of discovery. Not every project needs a formal process. Still, in The Brown M&M Test, I wrote about small signals that reveal how an organization thinks. This is another one. When discovery is called unnecessary, research a blocker, and problem definition just another name for solution definition, the dismissal is the signal.
I saw it happen. At the second company, design process was dismissed as theoretical, out of step with an assembly-line way of working where the job is to keep output moving.
In that room, design was expected to unblock engineering.
It was not asked whether the right thing was being built.
The Factory in the Building
This way of working comes from the assembly line: define the requirement, assign the work, track the output, ship the thing.
That logic works when the problem is known, backed by evidence, and the goal is predictable delivery. But product work is full of uncertainty. The question is not only “Did we build it?” It is “Did building it change anything that matters?” Organizations adopted the language of outcomes and kept the expectations of certainty, which is the subject of The Outcome Certainty Trap.
Output is easy to count. Outcomes are not. So the organization counts output. Assumptions about customer needs become requirements. Requirements become commitments. Roadmaps become production schedules. And the schedule becomes the strategy.
At the second company, research was cut. Research produces learning, not tickets, and in a factory that looks like overhead.
Before the cut, that research, and easy access to subject matter experts, had given us insight, aligned concepts quickly, tested assumptions, and mitigated risk in our design solutions.
In a factory, then, design is tactical because the schedule has already decided what matters: what ships, and when.
Where the Definition Comes From
Design is strategic in some companies and tactical in others. The difference is rarely talent. It is origin. Every company inherits its definition of design from the function that first taught it how value gets created: most often selling, building, or solving customer problems.
That function usually decides what design is for, which is why the diagram in Avoiding the Design Cycle of Doom begins with a question about it: who do designers report to?
Marty Cagan describes four risks every successful product must address: value, usability, feasibility, and business viability. Each origin tends to focus on one early and assume the rest.
In a sales-led company, value begins as persuasion. The customer said yes. The deal moved. The promise mattered. A signed deal seems to answer business viability first; customer value is assumed. Design is asked to make the promise clearer, more compelling, easier to sell: the polished demo, the cool UI that closes the deal.
People react to the shiny object, and these days it is often an AI-generated dashboard: impressive in seconds, untested against anything a customer needs. The danger is not sales itself. It is that the customer’s yes becomes a substitute for understanding the customer’s outcome.
In an engineering-led company, value begins as capability. The system works. The architecture scales. The feature exists. Feasibility gets answered first; customer value and usability come later, if at all. Design becomes the surface layer on top of technical achievement. The danger is that what can be built becomes a substitute for what should be built.
In a product-led company at its best, value begins as judgment. What problem is worth solving? What should not be built? What behavior needs to change? What evidence would change our mind? Customer value gets tested first, which means design can contribute to the riskiest question and not only the last one. Cagan assigns value risk to the product manager. In practice it is tested through research and prototypes, and design often leads both.
Notice what the first two share: design serves another discipline. It makes the sales promise easier to sell, or it puts a surface on what engineering built. That is the “another discipline” branch in the Cycle of Doom diagram. Usability is the risk Cagan assigns to design, and in both it is often the only one design is invited to address, after value has already been decided.
None of these origins is wrong. But each one sets a precedent and creates default beliefs about what design is for before the first designer walks in.
Design maturity is not only a question of design skill. A company can hire excellent designers, buy better tools, install a design system, and run research, and still keep design tactical if the organization believes design exists to refine decisions made elsewhere.
Three Ways Design Arrives
Some companies are born with strategic design. Design, product judgment, and customer understanding are present early enough that design becomes part of how the company thinks.
Some companies earn it through scar tissue. A failed launch, a churn problem, a support burden, or a competitive loss creates enough pain that the organization finally becomes willing to listen.
And some companies add design later, into an organization that has already decided what design is. The second company was one of these.
Where the Cycle Begins
Any company that brings design in after the decision is at risk of the Design Cycle of Doom. It bites hardest where the company hired design expecting something different.
A company hires design leaders because it wants more strategic impact. But the operating model still brings design in after the problem has been framed, the solution named, the roadmap hardened, and the customer request promoted to a requirement.
Design improves the artifact. The artifact ships. The result disappoints, because the original assumption was never tested.
Then design is judged by an outcome it was not allowed to shape.
So the organization learns the wrong lesson: that design doesn’t create enough value.
Next time, design is brought in late again.
That is the cycle. Designers can feed it too, by arriving without a business case or checking out when they’re brought in late. But the missing piece is rarely skill. A company hires competent design leaders, but its operating model is built for tactical design.
