Test your riskiest assumption in a week, before you write the code

With Claude Code and Cursor, a founder can go from idea to working prototype over a weekend. I love that. I build that way too.

But it creates a new failure mode. When building is cheap, it's tempting to skip the step where you find out if anyone wants the thing. So teams ship the wrong product faster, then spend the next two months polishing it.

Speed only helps if you're pointed in the right direction. The cheapest way I know to check the direction is a rapid experiment: a one-week test of the single assumption that would kill your idea if it's wrong. It comes from the user research course in my Stanford product management certification, and it's the framework I reach for most with early-stage AI teams.

Short answer: Run a rapid experiment: a one-week test that puts real users in a believable version of your product, built from off-the-shelf tools, and watches what they do. Pick the one assumption that would kill the idea, test that single behavior, and pilot the setup first. For AI products, a person can play the model.

What is a rapid experiment?

A rapid experiment puts a real person in a believable version of your product experience and watches what they do. It has three traits:

• Timeboxed. A day, a week, two weeks at most.
• Built from off-the-shelf parts. Little to no custom code. Slack, Google Sheets, SMS, a Typeform, a Notion page.
• An experience, not a feedback session. You're watching behavior, not collecting opinions.

That last point matters most. People are bad at predicting what they'll do, and not much better at remembering what they did. "Would you use this?" gets you a polite yes. Putting the experience in front of them for a week tells you what actually happens.

A survey is not an experience. Don't let a stack of "I'd definitely use this" answers stand in for a week of real behavior.

How to run a one-week rapid experiment

1. Pick one idea everyone agrees on.

Before you design anything, write the idea down: a storyboard, a bullet list of features, or a rough one-page PRD. If your cofounder and your lead engineer would describe it differently, you're not ready to test it.

2. List every question that could make or break it.

Every idea is a pile of assumptions about what people will do. Write them all down. Will they come back? Will they trust the output? Will they share it? How much control do they want?

3. Pick the most critical question.

This is where most teams go wrong. A good question is about one part of the idea and one specific behavior. Avoid questions that are too broad ("do people like it?"), too technical ("can we build it?"), too logistical ("how will we implement it?"), or already answered ("do sales reps take notes?").

4. Design the experiment.

Build a scenario that's believable, immersive and natural, and that lets you observe the behavior you care about. Decide up front what you'll measure, what you'll ask in follow-up interviews, and what your backup plan is.

5. Build the prototype, and pilot it first.

Use the scrappiest tools that create a realistic experience. Then run the whole thing once with a friend or colleague before real participants touch it. Always run a pilot. It's where you find the broken link, the confusing instruction and the step you forgot to staff.

Why AI products are ideal for Wizard of Oz tests

The best tool here is the Wizard of Oz prototype: the user sees a product, and behind the curtain a person makes the magic happen by hand.

For AI startups, this is a gift. Your riskiest assumption usually isn't "can the model do it?" It's "will people change their behavior because the model did it?" A human can stand in for the model for a week while you find out.

Here's a hypothetical. Say you're building an AI assistant that turns sales calls into follow-up emails. The tempting move is to spend six weeks on transcription, prompting and a CRM integration. The critical question is simpler: will reps actually send the drafted follow-up, or will they rewrite it from scratch?

The one-week version:

• Participants: eight reps from two friendly teams, recruited with a short screener.
• Prototype: reps forward their call recording to a shared inbox. Within an hour, a "wizard" on your team drafts the follow-up (with an LLM's help, edited by hand) and emails it back.
• Measurement: how many drafts get sent, how much they're edited first, and whether usage holds up or fades by Friday.
• Follow-up: a 20-minute interview with each rep. Start open ("How did that go?"), then ask for specific stories ("Tell me about a draft you didn't send").

Total build: an inbox, a spreadsheet and a few hours of a teammate's time. If reps rewrite every draft, you've learned something that would have cost you a quarter. If they send them nearly as-is, you have evidence to prioritize the integration, and you've watched exactly which edits they make.

I see this pattern a lot. When I joined Family Elf, the founder had already vibe-coded a working prototype of the app. Building it hadn't been the hard part. The hard part was deciding what the product needed to do first, and for whom, before a three-person engineering team put sprints behind it. That's exactly the question a one-week experiment answers cheaply.

Where AI tools help, and where they don't

I use AI tools all through this process. They're great for:

• Turning a messy idea into the one-page artifact for step 1.
• Brainstorming the full list of assumptions in step 2, so you don't miss the obvious one.
• Standing up the fake: a landing page, a screener form, a script that sends the SMS reminders.
• Clustering interview notes once the week is done.

They're not a substitute for choosing the right question, or for watching what people do. That part is still judgment, and it's the part that saves the runway.

Don't skip the ethics

Wizard of Oz tests involve a little theater, so be straight with people afterward. Debrief participants on how the experiment actually worked. Get consent before you record or share anything, protect the privacy of anyone who asks, and think through what could go wrong for them before you start.

Frequently asked questions

What is a rapid experiment in product management?

A short, timeboxed test, from a day to two weeks, that puts real people in a believable version of a product experience, built with off-the-shelf tools, so you can observe what they actually do rather than what they say they'd do.

What is a Wizard of Oz prototype?

A prototype where users interact with what looks like a working product while a person behind the scenes performs the function by hand. It suits AI products well, because a teammate can stand in for the model while you test whether people want the outcome.

How long should a startup validation experiment run?

One week is a good default, and two weeks is the ceiling. That's long enough to see whether behavior holds once the novelty wears off, and short enough that the experiment doesn't quietly turn into a build.

Is a customer survey enough to validate an MVP?

No. People are poor at predicting their own behavior, so survey answers skew optimistic. Use surveys to find the right people to talk to, then validate with an experience you can watch.

The takeaway

AI tools collapsed the cost of building. They didn't collapse the cost of building the wrong thing. Before your next sprint, find the one assumption that would sink the idea, and spend a week watching real people run into it.

If you're about to build something and you're not sure which assumption to test first, that's exactly the kind of problem I like. Book a 30-minute call below and we'll design the experiment together.