When do you need extra experiments or product discovery, and when can you just build the thing?

I get this question in almost every team coaching session. And a while back I recorded a Loom walking through Itamar Gilad's GIST framework to answer exactly that.

I shared that Loom in a recent team coaching session, and Kristian Rabe, Product Consultant and Managing Partner at Dynamo Partners, took it and did something I love: he turned it into a table. Kristian has a genuine gift for taking complicated input and making it simple, and this is a great example of it. Thanks, Kristian, I'll be using this a lot.

Copy it, stick it on a wall, share it with your team.

The Gist (pun intended) of Testing Ideas

1. The release is the test

When the idea is already based on learnings, you don't need to test anything extra. Same for ideas that are not complex, easy to build, easy to revert. The release is the experiment. You set success metrics upfront, wait a defined amount of time, and then check whether the released increment did what you wanted. If it didn't, you decide whether (and how) to iterate, or whether to kill it.

Example: When I was building Doodle 1:1, we noticed people kept sharing invite links outside the system instead of inviting through the platform. Not a priority, but a couple of users had asked for a text field to customise the invite message, easy to build, easy to remove. The goal: improve the "invite by email" vs. "copy link" ratio. Nobody knew why people preferred the link, and with an idea this small and reversible, that didn't matter. No assumption testing, straight to shipping it and measuring.

Four weeks later, email invitations were performing 100% better. We kept the feature. Same rigour about measuring before declaring victory, just none of the upfront testing, because the risk profile didn't call for it.

Disclaimer: This only works if you actually do the second half. If you define success metrics but then keep the feature regardless of what the numbers say, or quietly avoid pivoting or taking it down when it doesn't work, you haven't skipped discovery, you've skipped accountability. The willingness to kill or change what you ship is the whole deal, not an optional extra.

2. Experiments to test assumptions

Sometimes you do need a handful of experiments to check whether there's actually something worth building behind the idea. Especially when the idea is risky, meaning: It's either very complex and therefore expensive to build, there is risk of damaging your image longterm (Starbucks in South Korea anyone?), it's difficult to revert, or any other risk that cannot be fixed with one or a few releases following the launch.

Two examples from my own experiments bin: one that didn't survive, one that did.

Example 1: I once tested a paid newsletter for expecting dads, explaining what the mum goes through in pregnancy and what the baby goes through in its first year. I interviewed the target audience, then tested my own writing with a signup link dropped into a no-code community. I pulled the link down again almost immediately, not because the idea failed, but because I realised I didn't want to build or run this business.

Example 2: Compare that to the cohort-based metrics course I ran with Henry Latham, who'd already validated demand. We built the curriculum and put up a landing page with a CTA. The first cohort, at a fairly high price, got 16 people. The second, at a much higher price, got 6, which told us the first price point had actually been right.

Same territory both times: small, cheap experiments to find out if there's something real behind an idea before anyone commits to building it properly. In the first case, the risk was that I'd commit to a business that I don't want to run. In the second case, the risk was failing pricing long-term.

Keep in mind: When it's a completely new territory, the idea is super risky, very complex and you're not sure about its impact, then you should gradually test your assumptions from cheap-fast-low evidence strength up to expensive-slow-high evidence strength.

3. The evidence base to make a decision

And sometimes you need experiments to build an evidence base, so you can decide for or against a direction with more than a gut feeling.

Example: At a marketplace startup, we had to introduce shipping fees and nobody knew how much to charge. Full cost recovery would keep merchants happy but tank conversion, a token fee would keep conversion high but merchants would hate it, and "something in between" isn't a number you can take into a merchant negotiation.

Management leaned towards a low fee but didn't know the actual consequences, so we ran a split test: CHF 0 shipping against a low, mid and high variant. It showed exactly how much conversion dropped at each price point, so management walked into merchant negotiations with real numbers instead of a preference, and settled on the mid-level fee. That's case 3: the experiment wasn't there to validate an idea, it was there to produce the evidence needed for a decision nobody could otherwise make with confidence.

This is also the case to reach for when you need a realistic business case for a feature. Instead of filling in the assumptions with best guesses, run the tests that get you the numbers, and build the case on evidence instead of hope.

Disclaimer: You might not work in an environment in which it's seen as good practice to run tests to get your numbers. This is okay. The majority of companies rather wants you to "quickly" make assumptions and guess the numbers. It is what it is, don't fight the system, rather play it the way you can make it work for you.

Let's make it practical

That's it. Three buckets. Most ideas fall into the first one, and teams still treat every idea like it needs a discovery phase before anyone's allowed near the backlog.

Next time an idea lands on your desk, run it through the questions in the table before you do anything else: is it risky, is it complex, is the potential impact big enough to bother with at all. If the answer is "no, no, yes", stop overthinking it, define your success metrics and ship it. Save discovery and experiments for the ideas that are genuinely risky and complex, where a wrong bet is expensive. Most of your backlog doesn't need a research phase. It needs a release date and a metric you'll actually look at afterwards.

What bucket is your last "must-have" idea actually in?

Reach out - I'm curious as hell ;)