How We Validate an Idea Before We Build It

We validate an idea by trying to prove it wrong as cheaply as possible before we commit real build time to it. That means checking the problem is real, finding out whether the people who have it can be reached, and putting the roughest possible version in front of a handful of them. Only when an idea survives those steps does it earn a place on the shared platform and a share of a small team's attention.

This is the companion to how we choose what to build next. That piece covers the filters an idea has to pass to be considered at all. This one covers what happens after that.

Why validate an idea before building it?

Because building is the expensive part, and not only in effort. Every week spent on a product nobody wants is a week not spent improving the ones people already use. With several live products and a small team, a wrong bet does not just cost its own time; it slows everything else down. We wrote about that trade-off in running several products with a small team.

Validation is how we keep bets small. It will never make an idea certain, but it turns one large, vague risk into a series of small, specific questions that can be answered quickly.

What do we check first?

We check that the problem exists outside our own heads. An idea usually starts with a frustration we have felt ourselves or seen first-hand, but one person's irritation is not a market. So the first questions are plain ones:

• Who exactly has this problem, and can we describe them in a single sentence?
• What do they do about it today, and what does that cost them in time or money?
• Where do they already spend their attention, so that we could actually reach them?

If we cannot answer those, the idea goes back on the list. A problem that people already work around with a spreadsheet, a notebook or a long string of messages is often a good sign. It means they care enough to put up with something clumsy.

How can you test demand without building the product?

The cheapest test is to describe the product before making it. A short, honest explanation of what it does and who it is for, shown to the people you have in mind, tells you more than a long internal discussion. If they read it and shrug, that is worth knowing early. If they ask when they can use it, or ask a question you had not thought of, that is even more useful.

Talking to people directly helps too, as long as you ask the right thing. "Would you use this?" is a question almost everyone answers politely. "How do you handle this today, and what would make you change?" gets a far more honest answer.

What does the first version look like?

The first version is deliberately rough and deliberately small. It does the one job at the centre of the idea and very little else. We would rather a handful of real people use something plain than a large group admire something polished that never gets used.

Because the studio runs on one shared platform for sign-in, billing and hosting, a first version does not need us to rebuild the plumbing every time. That is a large part of why we can afford to test ideas properly. The detail is in shared infrastructure across a studio.

It is also why a product can run an open beta alongside its paid plans. AisleReply, our wedding reply service, has one, because real couples using it teach us more than any amount of planning.

How do we know whether it is working?

We watch what people do rather than what they say. Feedback matters, but behaviour is more honest. The signals we pay most attention to are simple:

• Do people come back and use it again without being prompted?
• Do they use it for the job we built it for, or for something else entirely?
• Where do they get stuck or give up?
• Will anyone pay for it, or ask to?

Shipping is the start of the decision, not the end of it. A first version that teaches us an idea is wrong has still done its job.

When do we stop?

We stop when the evidence keeps pointing the same way and it is not the way we hoped. That is harder than it sounds, because by then it is easy to have grown fond of the idea. The trick is to decide in advance what you would need to see to carry on, so the decision is not made on enthusiasm alone.

Stopping is not failure if it was cheap. The whole point of validating early is that a no costs weeks rather than years, and the shared parts built along the way stay useful for the next idea.

What would we suggest to another small team?

• Write down who the customer is, in one sentence, before writing any code.
• Describe the product honestly to the people you want to serve before you build it, and see how they respond.
• Build the smallest thing that does the central job, and put it in front of real people quickly.
• Judge it on behaviour, not compliments.
• Decide in advance what would make you stop.

You can see the products that made it through on our portfolio page, or browse the rest of the blog.

← Back to the blog