Someone on your team says "let's build X." Your job isn't to decide yes or no straight away. It's to figure out what kind of unknown you're actually dealing with, because that determines what you test, and how much effort that testing deserves.

To make it easy to remember, I split "solution" into two layers:

• The solution: the general idea, the concept of a feature.

• The solution of the solution: the exact implementation of that idea.

Mixing these two up is where most teams waste time. They either assumption-test something that's genuinely low-risk (overkill), or they solution-test something built on a shaky assumption nobody's checked yet (expensive mistake, just a slower one).

What each one actually tests

Assumption testing checks whether the general idea deserves to exist at all, before you build anything:

• Is it valuable to the people you'd build it for?

• Is it viable for the business?

• Is it usable?

• Is it ethical?

• Is it feasible to build?

You're checking whether the problem is real and worth solving, and whether your idea even points in the right direction. Not yet how exactly you'd build it.

Solution testing checks something narrower: whether one specific implementation works. You already believe in the general idea; now you're checking whether the actual thing you built or plan to build is:

• Accessible

• Easy to understand

• Easy to use

• Useful

• Viable

• Ethical

• Actually moving the outcome metric you care about

Same rigour, different question. Assumption testing asks whether you should build this at all. Solution testing asks whether this particular version works.

Two real examples show what that looks like in practice, one where a solution test doubles as an indirect assumption test, and one where you need both, in sequence, with a wrong turn along the way.

Example 1: when the solution test validates the assumption indirectly

Outcome: Increase signups to a new service.

Problem: The service is new. Visitors need to trust it before they'll sign up.

The team wasn't allowed to reach out to actual users on this one, so a direct assumption test was off the table. They weren't flying blind either: they'd seen the same pattern on other platforms handling similarly sensitive data, trust standing between a visitor and signing up. Not proof, but decent enough signal to act on.

So there was no separate assumption-testing phase here. The assumption behind "let's build a demo" would get tested indirectly, through whichever solution they picked. If a demo moved signups, trust was probably the blocker. If it didn't, they'd learn that too.

The real open question was the "solution of the solution": which exact version of "show them what's inside" to build.

• A screenshot of the dashboard

• A GIF showing the logged-in area

• An explainer video

• A full demo experience with mock data

The experiment: a gradual A/B test across these, from the cheapest to the most expensive, stopping once they stopped seeing further uplift. Notice how much cheaper this got once you separated "is trust the problem" from "which format solves it." and if none of it solves it, then trust wasn't the problem.

Example 2: assumption testing first, then a false start, then the real test

This one's from when I was building Doodle 1:1.

Outcome: Increase the proportion of shared calendars out of all created calendars.

Feature request, straight from users: "I want to see what the person sees before I send it to them."

That sentence hides more assumptions than it looks like: do they want the whole email sequence the invitee goes through, just the calendar itself, and why do they want this at all? Instead of guessing, we exchanged with a few users.

Turns out there were two jobs behind the request: a functional one (organisers wanted to make sure the times were correct and showing up correctly on the calendar) and a social one (they wanted to look professional to the person they were inviting).

That answered why, but not which version to build. We still didn't know whether the full email sequence preview or the in-app calendar preview would serve both jobs better, so we shipped the easier one, the email sequence, first. It turned out not to be the right solution.

The calendar preview was technically complicated, so before committing the engineering time, we ran a fake door test instead: a preview button that didn't do anything yet, it just opened a layover and counted clicks.

Result: one in three visitors clicked. That was enough signal to build it properly.

This is what the two testing types look like end to end: assumption testing to find out why people actually want something, and solution testing to find out which version is worth the build cost, sometimes with a wrong turn in between.

The question that decides which path you're on

Before you reach for either kind of test, run a quick confidence check on the idea:

• Where does this idea come from?

• Do we have evidence about the problem being worth solving?

• Do we have evidence about the feature or product actually being the right value proposition?

• Do we have evidence that the target group for this idea is really willing and able to pay (with money or their time) for this feature or product that solves that problem?

If the answer to any of those is "not really", you're in assumption-testing territory. Map the assumptions (valuable, viable, usable, ethical, feasible), pick the riskiest ones, and design experiments before you build anything. If the idea is small, low-risk, and you already have reasonable confidence in the problem and the value it delivers, skip straight to solution testing: is it accessible, easy to understand, easy to use, useful, viable, ethical, and does it actually move the outcome metric. A usability test, fake door test, A/B test, concierge test, or even a plain survey will tell you that fast.

And sometimes solution testing isn't even a separate step. If the idea is unrisky enough, the production release itself becomes the experiment: define the success metric upfront, decide when you'll check it, and agree what happens if it fails. Then ship it, measure, learn, iterate, measure, learn, and so on.

How to apply this tomorrow

Next time a feature idea lands on your desk, ask the four confidence-check questions out loud, in front of whoever proposed it. It takes less than five minutes and it tells you immediately whether you're about to build on sand (go test the assumption) or whether you're just picking between a few reasonable implementations (go test the solution). Skipping this step is exactly how teams end up either over-engineering a validation process for a harmless tweak, or shipping a fully-built feature on top of a problem nobody actually confirmed exists.

Now that AI lets us build almost anything quickly, you could ask whether any of this still matters. Why not just build what you think is right, whenever you think it, and see if it works? I'm not against that as a way of working. It depends entirely on the product creation culture you're in. If you're already working in a culture with tight feedback loops and a genuine habit of killing what doesn't work, then AI-assisted building becomes a new flavour of solution testing: you build with AI, wire it into that existing feedback loop, and let it tell you whether the specific solution holds up. That's solution testing, just with a faster tool for the "solution of the solution" step.

What AI doesn't let you skip is assumption testing. If you haven't confirmed that the idea has the right value proposition for a problem genuinely worth solving, for an audience that actually has the pain and is willing to pay for the fix, whether with money or with their time, then building fast just gets you to the wrong answer faster. De-risk the assumption first. Then use AI to speed up whichever solution you decide to test.

You don't need to test everything, and you don't always need to test it full-fledged. You need to know which kind of unknown you're looking at.

What does your team currently do when someone says "let's build X"? Do you check the assumption, or do you go straight to building and hope for the best?

Get in touch if you're looking for an experienced guide to introduce or improve continuous experimentation for your product trio or team.