Q: What if people say my idea is bad?

"I don't think that's a good idea," says the project manager, dismissing your work with a wave of her hand.

You suspect she's only saying the idea is bad so that she can hit her project deadlines. But it's her opinion against yours.

You know you shouldn't take it personally, but you do.

Your body reacts for you as a tear forms in the bottom of your eye.

Remind yourself of this:

Feedback on screens isn't feedback on people.
Stakeholders don't determine the goodness of an idea...that is up to the user.
Ideas themselves aren't "good" or "bad." They're bets on human behavior.

When we make bets on human behavior, we're often wrong. There have been studies that show most ideas are bad.

72% of new products and services fail. (Kucher 2014)

If most ideas will fail, how do you know which ones will succeed?

It's impossible to predict the future, but it is possible to de-risk an idea.

Today, I want to talk about a culture of experimentation that can help you avoid personal judgments of ideas on your team.

It's a way to do user-centered idea evaluation.

1.) Challenge assumptions, not ideas.

An assumption is something that you accept as true without question or proof. (Cambridge Dictionary)

Instead of arguing about which idea to build, find assumptions hidden within the idea. It's the assumptions that will kill an idea so find them.

Try these questions on stakeholders:

Q: Are we making assumptions that could cause this idea to fail?

Q: What's the riskiest assumption here? How sure are we that this assumption is true? 10%? 90%?

Q: What would it take to test this assumption?

Questions like this help us see the risk in our ideas. It helps avoid a binary "right" or "wrong" mentality.

It's less combative to talk about assumptions rather than ideas.

If you take it personally when your ideas get shot down, the CEO does, too. Listen for the difference in these two examples.

Example without assumptions:
"Hey CEO, can we test your idea to see if it's good or not?"

Example with assumptions:
"Hey CEO, can we run some tests on the riskiest assumptions in your idea?"

Hear the difference?

2.) Seek evidence for risky assumptions

Assumption Maps are a great place to think about the priority and evidence of assumptions.

If we have an important idea without much evidence, it’s good to find evidence before you build anything.

You might realize you have pretty weak evidence on most of your ideas.

That's where a product experiment like a concept test or a hypothesis-driven design prototype could help.

People sometimes call this approach “data-driven,” “lean,” or “experimental,” but those words don’t do the concept justice.

It's a way to reduce bias and judge ideas objectively with small, scrappy, user-centered evaluations.

You don't need to be a data scientist to design based on user data.

If it’s early in the product design process, an experiment might look like an interview, a card sort, or a survey.

Once you know how to set up a proper experiment, you can stop relying on subjective feelings and let customer behavior decide.

3.) Process every idea

I've noticed that when ideas come from the intern or the junior, they're assumed to be bad and shot down immediately.

But if they come from a CEO or a VP, we grumble and build them anyway.

That's a problem.

It's a problem because users don't care who has the idea. They only want it to work for their lives.

A process is how you save good ideas and ensure you're not biased.

In my career, I've designed dozens of features that were a "good idea" for the company, but the customer didn't find them desirable.

We were so clueless that we didn't even know they were unwanted features until we checked the analytics months after launch. Checking the analytics is a pretty slow, blunt way to check if users like an idea.

You need a process for testing ideas as they come. And instinct or salary is not a good test.

Here's what a process could look like: