What Gets Removed When You Ask Too Much

The designer was pulled from the project without warning.

No dramatic confrontation. No performance review. A product leader had a conversation with the executive team, and within days our team was reorganized around the feedback: we needed to refocus on design.

What had the designer done wrong? They had asked questions.

Not adversarial ones. Not premature ones. The kind that any serious practitioner asks before building something that’s supposed to move a business: Who is this for, exactly? What do we know about how they make this decision? What happens after they submit?

The internal team found it unsettling. Their own designer, watching it happen, felt not inspired but threatened, as if a different way of working was an indictment of the current one. The product leader framed it as a culture fit issue. The message to us was clear: we hired you to design, not to interrogate.

So we refocused. On design.

And something interesting happened: things got better. Not the product. The relationship. The team started to gel. We iterated on look and feel, sharpened the design system, improved the UX in ways that were visible and easy to respond to. The client could see progress. They could react to it, approve it, feel ownership over it. Daily check-ins became weekly ones. Weekly ones became occasional. At some point the exec team largely stopped showing up, not because things were broken, but because things felt like they were running smoothly.

That feeling is the most dangerous part of this story.

Because what looked like a maturing engagement was actually a team getting increasingly comfortable executing in the wrong direction. The relationship improved. The work was polished. The problem we were hired to solve remained untouched, not because anyone was avoiding it, but because the version of “design” we’d been asked to do had no mechanism for finding it.

Six months later, a self-serve onboarding flow for a financial services product launched. And it produced almost no measurable effect on their business.

The exec team ran the numbers. The screens were good. The flows were clear. Users could navigate the product without confusion. By any execution standard, the work was solid.

But the curve didn’t bend. Leads stalled. Conversion didn’t move.

When they dug into why, the answer wasn’t in the interface at all. The real problem was downstream. The handoff between the self-serve flow and the sales team was broken. Users were arriving at sales conversations without context, and the team on the other end was picking up cold leads with no shared frame of reference. The funnel wasn’t leaking where anyone had been looking.

Product got blamed. A few team members were told to work harder. And the connection between what happened and why it happened, the skipped research, the removed designer, the questions that never got asked, was never named out loud.

It became what most failed initiatives become: a quiet lesson that never gets institutionalized.

Here’s what’s worth understanding for leaders reading this: the product leader wasn’t confused about what we were doing. They understood the difference between execution design and strategic design, between making something look and feel credible, and pressure-testing whether it is credible.

They made a trade. And named it honestly: startup culture. Move fast. Show results. Iterate after launch. It’s a coherent philosophy, and in the right circumstances, it’s even correct.

But it rests on an assumption that was never examined: that they understood where the value in the work actually lived.

This wasn’t a scheduling decision. It was a budget decision, they just didn’t know it. When the research and validation work got cut, it wasn’t trimming a timeline. It was eliminating the activity most likely to determine whether the rest of the budget would return anything. The six months of design and engineering that followed weren’t faster because of that decision. They were just less informed. The spend continued at the same rate. The risk quietly compounded behind it.

This is what “move fast” actually means when it’s applied to an unexamined thesis: you’re not saving time. You’re allocating capital without understanding where it creates value and where it disappears. Speed is only an advantage when you’re moving in a validated direction. Applied before that validation exists, it just gets you to the wrong outcome faster.

It’s worth being precise about what that trade actually was, because “design” is a word that obscures more than it reveals.

What the client team meant by design: make it look good and work reliably. Polish the interface. Clean up the flows. Make the product feel trustworthy. That is real and valuable work. We are exceptionally good at it. We can take almost any idea and make it look like a fundable, shippable product. We can give a weak thesis a professional finish, credible enough to demo well, solid enough to launch.

That is exactly the problem.

What strategic design actually does is different in kind, not just degree. It asks, before the interface exists: Is this the right problem? Is this segment actually motivated to act? Does the pricing match how they think about value? What does the funnel look like after the form submits? It is, at its core, pressure-testing the bet before capital and engineering time compound behind it.

The product leader knew this. They chose to skip it because the cost felt immediate: slower timelines, uncomfortable questions, a designer who kept pulling the conversation upstream. The downside of not validating lives in the future. The pressure to ship lives in the present.

What they didn’t account for is that we can make a bad bet look exactly like a good one. That’s not a feature. In the absence of validation, it’s a liability. The product launched looking sharp, feeling solid, and moving nothing.

This is the organizational logic of removing doubt. It feels like decisive leadership. It often looks like it. A team that executes without friction, that ships clean work on time, that doesn’t slow down to interrogate the brief, that team looks healthy until the numbers come in.

The problem isn’t that the questions are uncomfortable. The problem is that the questions are right, and by the time the organization discovers that, the money is spent and the moment is gone.

By the time our team arrived, the problem was already defined. The direction was scoped. Engineering had estimates. The self-serve flow wasn’t a hypothesis to be tested. It was a commitment to be executed. We were handed a brief, not a question.

I raised concerns throughout, not passively, but directly, with leadership. About the funnel. About the sales handoff. About what we didn’t actually know about how this segment made decisions. I could see the shape of the problem clearly. What I couldn’t do was change the conditions that were producing it.

That gap, between what you can see and what you’re empowered to change, is where organizations quietly cap their own upside. And the gap doesn’t stay open forever. It closes.

It closed the day the designer was removed. After that, the message was structural, not just personal: questions have a cost here. The team understood it without anyone saying it again. We gelled, we delivered, we stopped pulling the conversation upstream. The check-ins got easier because we’d stopped introducing friction. What looked like a healthier engagement was actually a team that had learned where the walls were.

And when the launch underperformed, none of that history made it into the postmortem. The lesson that surfaced wasn’t we skipped the work that would have caught this. It was we need to work harder next time. The ceiling stayed exactly where it was, and no one in the room had the institutional memory to explain why.

There was no structural reason validation couldn’t have happened. A modest budget allocation, run alongside the design system work rather than instead of it, would have surfaced the funnel problem before a line of production code was written. The two workstreams weren’t in conflict. The choice to skip one wasn’t forced by circumstance. It was a preference, dressed up as pragmatism.

What that preference produced, in the end, wasn’t speed. It was a longer, more expensive version of the same journey, one that arrived at the wrong destination.

The wasted budget is the visible part. But the fuller cost rarely makes it into the postmortem. The team that spent six months executing on a flawed thesis, that learned to stop asking questions, that watched a designer get removed for doing exactly what good design requires, that team didn’t emerge unchanged. Morale doesn’t recover on a timeline. Culture shifts quietly and doesn’t announce itself. And when leadership moves on without naming what actually happened, the people who were closest to it are left holding a lesson that the organization never institutionalizes.

The product leader made a budget decision while thinking they were making a scheduling one. That’s the cautionary part of this story. Not that the product failed. Products fail. But that the conditions which produced the failure were built deliberately, justified confidently, and never examined afterward.

So the question this story leaves is not really about design. It’s about what you believe your capital is actually buying when you fund a product bet. If the answer is execution, if the assumption is that the problem is understood and the work is to build, then validation will always feel like an interruption. It will always lose to the pressure of the present.

But if you understand that design, at its highest leverage, is the work of finding out whether the bet is worth placing before the money is in, then cutting it isn’t efficiency.

It’s just a more expensive way to be wrong.

Agustin Sanchez is a Design Leader at 8th Light. He works at the intersection of design and capital allocation, helping teams validate their bets before execution compounds behind the wrong one.