Let The User Decide

Was this forwarded to you? Subscribe here to get one leadership framework per week.

This is the fourth post in a series where I'm going deep on each mantra in my Mantra Dashboard. Last week, we explored why the best strategies are grounded in the story of a real person: Tell User-Centered Stories. I said that if your strategy is missing a user story and a user journey, you are missing the foundation that should ground every strategy. Are you solving for a real need? Do you understand how you fit into your customer's life?

This week, we take that principle one step further. Because even when your team agrees on who the user is, they will inevitably disagree about what to do next. And when that happens, most teams waste precious time debating. The best teams have a better answer.

The mantra is: Let The User Decide.

The Mantra Ladder

Here's the full Mantra Ladder for Let The User Decide. The rest of this post unpacks it.

Goal (What We Want): We want decisions to be grounded in real evidence about what works for the people we serve.

Mindset (How We Think): We think that internal debates about what's "best" are often a waste of time. The user has the answer if we're willing to ask.

Value (What We Prioritize): We prioritize external evidence over internal opinion.

Standard (What We Expect): We expect to resolve disagreements by testing with real users whenever possible, rather than arguing from authority or taste.

Mantra (What We Say): Let The User Decide.

Breaking The Deadlock

I have seen this play out more times than I can count. A team gets into a debate about which direction to go in. Two people have strong opinions. Both ideas are reasonable. The team goes back and forth. They debate in meetings. They debate in Slack. They debate in the hallway. And they get nowhere.

Meanwhile, time passes. The window of opportunity narrows. The team is stuck in exactly the kind of paralysis that kills momentum in any organization.

When I step in and suggest that they let the user decide, it breaks the deadlock. Not with a vote. Not with a compromise. Not by letting the most senior person in the room win. Instead, they throw together a few rough prototypes, they get out of the building, and they test them with real users. And guess what happens? The answer for what to do next becomes crystal clear to the entire team.

Here's the part that surprises people. Usually, they figure out that both of the ideas the teammates were fighting over are not quite right. The user feedback reveals a new insight, a better direction that nobody on the team had considered. The debate was never going to get them there. Only the user could.

The User As Referee

One of my students put it perfectly: "The user must be the referee, not our gut feeling."

That framing captures something important. When the team can't agree, you don't need a tiebreaker. You need a referee. And the referee is not the CEO. It's not the loudest voice. It's not the person who has been at the company the longest. It's the user.

This connects directly to what I wrote last week in Tell User-Centered Stories and to the foundational mindset of being human-centered. When you put the user at the center of everything, decision-making becomes a lot easier. The next steps are clear: move forward in the design process, test with users, and iterate. That will show you what to do next.

As I wrote in Be Human-Centered: "Everything comes back to the user for evaluation. Your team begins to operate with a Let The User Decide mentality." That's the shift. It's not just a nice idea. It becomes the default operating mode for how your team resolves disagreements.

Prototype As Clay

So how do you actually do this? The answer lives in being prototype-driven.

Rather than endlessly debating, pick two or three directions that it would be useful to learn more about. Get them out of your head and into a rough, tangible form. And then get out of the building and test them.

I like to think of a prototype like a piece of clay. Your job is to imperfectly shape it based on your initial hypotheses. Then you put it in front of your user and you create an interaction where you can see how they mold the clay. The unfinished nature of the prototype actually invites the user to shape it with you. A polished product shuts down that kind of honest feedback. A rough prototype opens it up.

And here's the key: the primary goal of testing is not to validate your idea. It's to learn more about your user. You are trying to deepen your understanding of their needs, their context, their behaviors. Getting feedback on your specific solution is secondary. When you keep the user at the center and prioritize learning about them over proving yourself right, the right direction almost always reveals itself.

There are a few core rules of testing that I teach in my venture design bootcamps. Treat every idea as a hypothesis, not a commitment. Make your prototypes rough and rapid because perfection wastes time and shuts down honest feedback. Test to learn, not to validate. And iterate relentlessly, because no version is ever final. As I wrote in Be Prototype-Driven: the job of an innovator is to always understand the top risks in their venture and to spend their limited time and limited resources reducing those risks. Endless debate doesn't reduce risk. Testing does.

Not A Democracy

One important clarification. Letting the user decide does not mean your team is a democracy. It should always be clear who ultimately owns the decision. That's the principle behind One Consultative Decision-Maker Per Lane: someone has to make the call, and the team needs to know who that person is.

But a humble leader with decision rights truly does want the user to inform the decision. Not their overconfident vision. Not their gut instinct. They want to know what the user thinks, what the user needs, and what the user does when they interact with a prototype. The decision-maker still decides. But they decide on the basis of external evidence, not internal opinion. That's the difference between a leader who is confident and a leader who is arrogant.

Setting The Norm On Day One

When I run my Point C Training Camps, on the very first day of forming teams I run a team formation exercise where we set norms for how to operate together. One of the norms we establish explicitly is: Let the user decide.

I do this because I know what's coming. Over the course of the week, every single team will hit a moment where two people disagree about which direction to take. It's entirely predictable. And when it happens, the team now has a concrete tool to break the deadlock. Someone says: "Let's let the user decide." They prototype both directions, they go test, and they come back with clarity.

By establishing that norm and mantra explicitly at the start, I give them language to interrupt their own bad habits. Without it, they default to the endless debate. With it, they have a bias toward action and evidence. It has worked wonders. And it's another reason why explicit norms and mantras are so powerful. They give your team shared language for the moments that matter most.

Your Challenge This Week

1. Think about a decision your team is stuck on right now. Instead of debating further, identify two or three directions you could prototype and test with a real user this week. Make the prototypes rough. The goal is learning, not polish.
2. Before you test, write down what you expect to learn. Treat your direction as a hypothesis, not a conclusion. Then go test and see what the user actually does. Pay attention to where the user surprises you.
3. Bring the results back to your team. Share what you learned, not just whether your idea "worked." The insight is more valuable than the verdict. Watch how quickly the next steps become clear.

Next Week

You've built a clear Point C. You've grounded your strategy in a real user story. You've learned to let the user break the deadlock. But all of these tools require you to make hard choices about what matters most. When everything is a priority, nothing is. The best leaders don't just have priorities. They force-rank them and make the tradeoffs visible to the entire team.

Next week: Make Tradeoffs Explicit.

Know someone who would find this useful? Forward this email to them. They can subscribe here to get their own weekly half sheet.

About This Newsletter

The Idea Bucket is a weekly newsletter and archive featuring one visual framework, supporting one act of leadership, that brings you one step closer to building a culture of innovation.

It’s written by Corey Ford — executive coach, strategic advisor, and founder of Point C, where he helps founders, CEOs, and executives clarify their visions, lead cultures of innovation, and navigate their next leadership chapters.

Want 1:1 executive coaching on this framework or others?  Book your first coaching session. It's on me.