Experiments, MVPs and no-code/AI prototypes

0:00 Experiments, MVPs and AI prototypes

In 2026, you can build an app over a weekend. You describe it in plain English to an AI builder, and out comes a working prototype. So here's the uncomfortable question. If building is now that easy, why do most new products still fail? Because the hard part was never building. It was learning what people will actually do. In this lecture, you'll learn to design experiments that answer one risky question at a time, choose the right kind of MVP, set success criteria before you look at the results, and use no-code and AI tools to learn faster, without fooling yourself.

0:44 Why it matters

Why does this matter? Because every week you build without learning, you're spending your most limited resource: runway and energy. A minimum viable product, an idea associated with Eric Ries and The Lean Startup, isn't a smaller version of your dream product. It's the smallest thing that lets you observe real customer behaviour and test a specific assumption. Build, measure, learn. And here's the key idea for today. Build the least that produces the behaviour you need to observe. If you want to know whether people will pay, you don't need an app. You need a price and a way to pay.

1:28 MVP types

Here's an analogy. A film studio doesn't shoot a whole film to find out whether audiences like the story. They test a script reading, then a trailer, then a rough cut with a test audience. Each step is cheap compared with the next, and each answers a different question. MVPs work the same way. A landing page with a price tests whether anyone clicks buy. A concierge MVP, where you deliver the service by hand, tests whether people value the outcome. A Wizard of Oz test, where the front end looks automated but a human does the work, tests whether people use the experience. And a clickable or AI-built prototype tests whether a workflow makes sense to them.

2:19 Experiment card

Now the method, step by step. First, pick your riskiest assumption from your assumption map. Next, write a hypothesis: we believe this segment will do this behaviour because of this reason. Then choose the test and one metric. And here's the step most founders skip. Set your success threshold before you run it. For example, at least six of thirty will pay a deposit within two weeks. Write it down. Why? Because once results arrive, you'll be tempted to reinterpret them. Four out of thirty will suddenly feel promising. Finally, run it fast, then decide: persevere, pivot, or stop.

3:02 Worked example 1: dog walking

A simple worked example. Sam in Bristol thinks dog owners will pay for a weekend dog-walking subscription. Instead of an app, he makes a one-page site with a price, twenty-five pounds a weekend, and a button saying reserve your first weekend. He puts up posters in two parks and shares it in a local community group. His threshold, set in advance, is ten reservations in two weeks. He gets four. So what does he learn? At that price, in that channel, demand is weak. He hasn't wasted months on an app. He can now test a different price, a different segment, like busy couples in flats, or a different channel.

3:50 Worked example 2: Wizard of Oz with AI (illustrative)

Now a realistic business scenario, with illustrative numbers. Noura, in Riyadh, believes small online stores will pay for weekly product descriptions in Arabic and English. Instead of building software, she runs a Wizard of Oz pilot. Stores submit photos and notes through a simple form. An AI model drafts descriptions using a prompt she's tested. Then she edits every one, checks claims against the notes, and sends them back within twenty-four hours. Her threshold, written in advance: six of twenty pilot stores pay for a second month. Result? Nine pay. And there's a bonus. Her edit log shows which product types need the most human correction. That becomes the spec for the real product, and the basis for its cost model.

4:43 Watch me: a pilot in an hour

Watch me do it. I'll set up Noura's pilot in under an hour. Step one, I write the experiment card. Step two, I ask an AI builder for a landing page, then rewrite the headline myself using real customer words, like, stop writing product descriptions at midnight. I add a real price and a join the pilot button. Step three, I create a form that feeds a spreadsheet, and an automation in a tool like Zapier, Make or n8n that alerts me when a store submits. Step four, and this is non-negotiable, I add a review column. Nothing reaches a customer until a human marks it approved. For payments, I use a hosted payment link from a regulated provider, never a homemade card form.

5:37 Ethics and metrics

What about ethics and compliance? Keep it simple. Tell people they're joining a pilot. Don't take money for things you won't deliver, and make pre-orders refundable. Don't collect personal data you don't need, and follow the data protection rules where your customers live. Check your no-code or AI builder's data and hosting terms. And in health, finance, legal or anything safety-related, a human must check AI output before it reaches anyone. Now, what about metrics? Avoid vanity numbers like page views or likes. Measure behaviour that costs the customer something: time, data, money or reputation, like a referral.

6:20 Deciding after a test

Once the results are in, how do you decide? Look at three things together. First, the headline number against your threshold. Did you hit it, miss it narrowly, or miss it badly? Second, the quality of the behaviour. Nine people paying once is different from nine people paying, using it weekly and telling a friend. Third, what surprised you. Often the most valuable result isn't the metric at all. It's the unexpected segment that responded, or the objection you heard five times. Then choose. Persevere if the numbers are near or above target and improving. Pivot if the evidence keeps contradicting a core assumption. And stop if, after honest testing, no path looks viable. Stopping early is a success. It frees you for the next idea.

7:15 Common mistakes

Now, the common mistakes. Building the full product and calling it an MVP. With AI builders, this is more tempting than ever. No threshold set in advance. Measuring vanity metrics. Running a test for months without deciding. Testing with the wrong segment, usually people who are easy to reach rather than people with the problem. And letting AI output reach customers unchecked, then blaming the customer when they don't return. One more. Don't confuse a pivot with giving up. A pivot keeps what you've learned and changes one big thing: the segment, the problem, the solution, the channel or the revenue model.

7:59 Recap and try this now

Let's recap. An MVP is an experiment, not a small product. Pick the riskiest assumption, write a hypothesis, choose one metric, and set the threshold before you look. Choose the cheapest test that shows the behaviour: a landing page, a concierge service, a Wizard of Oz pilot or a prototype. Use AI and no-code tools to build less and learn faster, with a human checking anything that matters. Your try this now: write one experiment card today, and use the one-week plan in the lesson to run it. In the next module, we'll turn what you've learned into a business model.