Testing risks in customer solutions
 August 23, 2025 | Career, Product Discovery

Testing risks in customer solutions

Run small tests to build confidence, or catch failure before it’s too late.

Teams don’t build confidence by guessing. They build it by testing.

— Kristy Sullivan

You’ve named the riskiest assumptions in your idea. So now what?

Most teams plow ahead and start building. But strong teams pause and ask: What has to be true for this to work? And then they test it.

That’s the focus of this step: testing your riskiest assumptions before you commit.

You’re not testing everything. Just the 1–2 biggest risks. You run quick, focused experiments. If the assumption holds, great, you move forward with confidence. If not, even better. You learned before wasting time, money, or customer trust.

This article covers:

  • What to test (and what to skip)
  • How to choose the right test
  • What a useful signal looks like
  • How to act on what you learn

What it is

Testing risks means running small experiments to get real evidence around the assumptions that matter most.

You’re not proving the whole solution. You’re checking for cracks before they cost you.

A strong risk test is:

  • Tied to a clear assumption
  • Quick and cheap
  • Focused on behavior, not opinions
  • Designed to reduce uncertainty

What to test (and what not to).

✅ Test:

  • Critical assumptions — if this is wrong, the whole idea fails
  • Behavior — what people actually do, not what they say
  • Unknowns — the things your team is least sure about

❌ Don’t test:

  • Things you already know from past research or product data
  • Personal opinions without context
  • Low-risk stuff like colors or microcopy if value hasn’t been validated

Testing is not validation theater. It’s about getting to the truth early.

How to do it

Step 1: Pick your riskiest assumptions.

Start with the one or two assumptions that are both:

  • High importance — if this fails, it kills the idea
  • Low confidence — you’re mostly guessing

Don’t overthink it. Just ask: What’s most likely to break this solution?

Step 2: Match it to a test type.

Each assumption maps to a type of risk. Pick a lightweight way to test it.

Desirability: Do people want it?

  • Fake door
  • Click-through prototype
  • Interview question
  • Survey or ad test

Feasibility: Can we build it?

  • Two-hour spike
  • Tech review
  • Backend prototype
  • Check with partners or vendors

Viability: Does it work for the business?

  • Cost model
  • Revenue model
  • Pricing test
  • Legal check

Usability: Can people use it?

  • 5-person walkthrough
  • Unmoderated test
  • Task completion

Ethical: Could this cause harm?

  • Scenario review
  • Accessibility review
  • Legal review

Start simple. Choose the fastest test that gives you a useful signal.

Step 3: Run the test.

Put it in front of real users if you can. Watch what they do, not always what they say.

Tips:

  • Stay scrappy. There’s no need for polish.
  • Set the scene clearly.
  • Watch for hesitation or confusion.
  • Ask: “What would you do next?”
  • Record it if possible.

Step 4: Look for the signal.

Ask your trio:

  • Did their behavior support the assumption?
  • Was anything unexpected?
  • Is the signal strong or fuzzy?

You’re not looking for proof. You’re looking for direction.

✅ A strong signal is:

  • Behavioral — actions, not opinions
  • Clear — you set a threshold upfront
  • Unambiguous — the outcome is obvious
  • Comparable — you can measure against current behavior

❌ A weak signal sounds like:

  • “They said it was nice.”
  • “They’d probably use it.”
  • “We got survey clicks but no follow-up.”

Step 5: Make the call.

Once the test is done, decide together:

  • ✅ Proceed — signal is strong, move forward
  • 🤔 Pause — signal is fuzzy, re-test or reframe
  • ❌ Pivot — assumption failed, rethink the idea

Then move to the next risk and do it again.

Framework to follow:

Learn → Decide → Adapt → Repeat

Fun Examples

The button nobody wanted to push.

The setup:
The team built a one-click “Cancel My Policy” button to reduce support calls.

The assumption:
“People want to cancel their policy on their own.”

What they did:
Ran usability tests with a prototype.

What happened:
Users hesitated. Some said, “I’d rather talk to someone first.” The idea added stress, not clarity.

The fix:
Added in-app guidance and a clear path to support. The confidence stayed; the confusion dropped.

Everyone said yes, until we asked for their email address.

The setup:
A checklist download looked like a great lead magnet. Customers loved it in interviews.

The assumption:
“People will trade their email for helpful content.”

What they did:
A/B tested gated vs. ungated versions.

What happened:
Ungated got 4x more downloads. Gated got fake emails and drop-offs.

The fix:
They delivered the value first, then asked for the email. It built more trust — and better leads.

The two-hour spike saved us a quarter.

The setup:
An idea hinged on integrating with a third-party API.

The assumption:
“This API will handle what we need.”

What they did:
Ran a quick two-hour engineering spike to test key endpoints.

What happened:
The API failed on key functions. Support was spotty. It would’ve sunk the timeline.

The fix:
They scrapped the dependency and scoped a faster, first-party solution.

They didn’t hate it. They didn’t get it.

The setup:
The team redesigned how couples track shared goals. It looked clean and intuitive.

The assumption:
“People will understand how to use it right away.”

What they did:
Put it in front of five users and asked them to walk through a scenario.

What happened:
Zero completed it. Confusion everywhere.

The fix:
They added a walkthrough, simplified the interface, and saw success rates rise fast.

Conclusion

Testing risks is how great teams stay smart.

If you skip it:

  • You over-invest in shaky ideas
  • You ship guesses instead of answers
  • You don’t know why something failed

But when you test:

  • You catch problems early
  • You move with clarity
  • You make stronger bets as a team

This step is about focus. Confidence. Speed without regret.

You’re not chasing perfect. You’re making smarter decisions faster.

Take Action

1. Pick one risky assumption.

Use your story map or OST. Choose what feels most make-or-break.

2. Choose a simple test.

Match it to the risk type — desirability, feasibility, etc.

3. Run it with real users.

Watch behavior, not words.

4. Review the signal with your trio.

Is it strong enough to move forward?

5. Decide the next step.

Move, pause, or pivot. Then repeat with the next risk.