Stop Agonizing Over Big Decisions: Prototype, Test, Learn and Iterate

Business leaders are often told that their job is to make good decisions. But that seemingly simple responsibility can create an enormous amount of pressure.

The bigger the decision, the more daunting it can feel. Should we launch the new product? Redesign the website? Enter a new market? Invest in a new technology platform? Change our pricing? Hire more people? Develop an app?

Soon, the questions multiply. What if customers don't like it? What if we spend too much? What if we're solving the wrong problem? And, of course, the question lurking behind nearly every major decision: What if we get it wrong?

That’s when analysis paralysis sets in.

Organizations commission more research, schedule more meetings, create more spreadsheets and ask for another round of opinions. Leaders convince themselves that if they can just gather enough information, the correct answer will eventually reveal itself.

Sometimes it does. But often, there's a better way to make a big decision: Stop trying to predict exactly what will happen and create a small, inexpensive way to find out.

That’s one of the most valuable lessons business leaders can borrow from design thinking.

Design thinking is fundamentally human-centered and iterative. Rather than assuming that the first solution is the right one, teams develop ideas, make those ideas tangible, test them with people and use what they learn to improve the next version. Design thinking pioneer IDEO describes the process as flexible rather than linear, moving teams from uncertainty toward insight through activities including framing questions, gathering inspiration, generating ideas, prototyping and testing.

In other words: prototype, test, learn and iterate.

And you don't need to be a designer to do it.

Start With a Hypothesis, Not a Final Answer

One reason major business decisions become so difficult is that we frame them as all-or-nothing propositions.

Instead of asking, Should we completely redesign our website? try asking, We believe changing the way we explain our services will increase the percentage of visitors who contact us. How could we test that?

Instead of Should we launch this new product? ask, We believe customers will pay $49 for this product. What's the cheapest and fastest way to determine whether that's true?

That subtle change is important. You aren't making an irreversible decision. You're creating a hypothesis and looking for evidence.

Business experimentation can provide valuable evidence for decisions involving everything from product design to organizational practices, and Harvard Business Review and other researchers have long argued that companies can improve decision-making by designing experiments rather than relying solely on intuition.

Once you have a hypothesis, create the simplest possible prototype or experiment that will help you learn something.

And simple really does mean simple.

A prototype of a new website could be a hand-drawn sketch.

A new package design could be printed on paper and wrapped around an existing box.

A new mobile app could begin as a series of static screens that users click through.

A new service could be offered manually to 10 customers before you invest in the technology required to automate it.

A new restaurant concept could begin with a pop-up dinner rather than a five-year lease.

A new marketing offer could be tested with one email and a unique coupon code.

The goal isn't to make something beautiful. The goal is to make the idea tangible enough that someone can react to it.

Low-cost prototypes are a recognized part of the design-thinking process precisely because they allow teams to investigate ideas before committing the resources required to build finished solutions, according to the Interaction Design Foundation.

Get Something in Front of Real People

This is where things get interesting.

Once you have something tangible, put it in front of people.

Not just executives sitting around a conference table.

Actual users.

Let them click it, read it, hold it, try it, buy it or reject it.

Then pay attention.

If you're considering a new marketing message, test two versions in an email campaign.

If you're considering a new product, create a landing page describing it and see whether people click "Learn More."

If you're considering a discount to attract first-time customers, create a unique coupon code and measure redemptions.

If you're developing software, give users specific tasks and watch what happens. Where do they hesitate? What do they misunderstand? What are they trying to do that you didn't anticipate?

Testing isn't simply about determining whether people "like" something. It can expose assumptions the development team didn't realize it was making and produce insights that send the team back to rethink the problem itself.

That last part is critical.

Sometimes the most valuable result of a test is discovering that your original idea was wrong.

Failure Is Information

Businesses understandably don't like failure. But there is a huge difference between discovering that an idea doesn't work after investing $5 million and discovering it after spending $500.

That's why leaders should distinguish between failure at scale and failure during experimentation.

Failure at scale is expensive. Failure during a carefully designed experiment is learning.

Maybe customers don't understand your new product. Great. Now you know.

Maybe they love the product but won't pay the price you expected. Useful information.

Maybe users keep looking for a feature your developers never considered. Even better.

Maybe nobody clicks the button you were convinced would transform conversions. Change the button. Change the message. Change the offer.

Or abandon the idea altogether.

The purpose of experimentation isn't to prove that you were right. It's to discover what's right before the stakes become unnecessarily high.

What an App Development Team Can Teach Us About Design Thinking

Imagine a team of talented IT developers who are building a new application.

They knew technology. They knew how to write code, build functionality and solve technical problems.

What they didn't have was extensive experience in the businesses that would actually use their application: field service businesses, construction companies, HVAC contractors, plumbing and electrical companies, real estate businesses and property managers.

That's a significant knowledge gap.

The developers could imagine how the software should work. But they didn't necessarily know how someone managing 20 technicians, 75 properties or dozens of construction projects would actually want to use it.

Fortunately, they can create an early beta version in a safe sandbox environment.

Rather than waiting until the application was finished, they can walk an early beta user through it.

"What if I wanted to do this?"

"What happens when a customer changes this?"

"What if the manager needs to see all of these projects together?"

"What if the employee using this isn't sitting at a desk?"

"What if the customer wants to accomplish this without calling someone?"

Those questions exposed assumptions embedded in the initial architecture.

And instead of defending what they'd already built, the developers can do exactly what good product teams should do.

They can go back to the drawing board, reconsider workflows, and change functionality. They can rethink portions of the architecture and coding. They can look at the application less from the perspective of the people building it and more from the perspective of the people who would eventually use it.

The next beta version will likely be vastly superior.

Not only would it work better for the original use cases, but the revised functionality could potentially broaden its appeal to other users.

After another round of sandbox testing, the team can began making additional iterations to simplify the user interface and make the application easier and more intuitive.

That's design thinking in action.

Their development approach still incorporates elements of waterfall and Agile development, but adding a design-thinking mindset would change an important part of the process: they can begin testing assumptions about users earlier rather than waiting for the market to test those assumptions later.

Design thinking itself is intentionally non-linear; testing can lead teams back to redefining the problem, generating new ideas or creating another prototype.

Make Big Decisions Smaller

The same philosophy can be applied far beyond software development.

If you're considering opening a second location, test demand in the new market before signing a lease.

If you're contemplating a major rebrand, test several concepts with customers before selecting one.

If you're thinking about introducing a subscription model, offer it to a small group first.

If you want to change your sales process, have one team test the new approach.

If you're considering a new employee benefit, pilot it within one department.

If you're wondering whether AI can automate part of your customer service operation, prototype one workflow rather than replacing the entire system.

The pattern is the same:

Form a hypothesis. Build something small. Put it in front of real people. Observe what happens. Learn. Improve it. Test again.

That's not indecisiveness.

It's disciplined decision-making.

You Don't Need Certainty. You Need Evidence.

Leaders often believe confidence comes from knowing that they've made the right decision.

In reality, you rarely have that luxury.

Markets change. Customers surprise us. Employees behave differently than expected. Technologies evolve. Competitors react. The spreadsheet that looked convincing in the conference room encounters the messy reality of the outside world.

Design thinking offers another source of confidence.

Instead of saying, "We're confident because we've thought about this for six months," you can say:

"We're confident because we've tested it."

You showed customers something.

You observed their behavior.

You collected data.

You learned where your assumptions were wrong.

You changed the idea.

And then you tested it again.

IDEO describes prototyping and experimentation as ways to turn ideas into evidence, reduce risk and accelerate learning. That mindset can be enormously powerful for business leaders because it changes the objective from making the perfect decision to creating a process that progressively produces better decisions.

So the next time your team finds itself trapped in a conference room debating a major decision, stop asking how you can become 100 percent certain.

Ask a different question: What's the smallest, fastest and least expensive thing we could do to learn whether this idea actually works?

Then build it. Test it. Learn from it.

And make the next version better.