I got a call last week from Deborah, a lecturer at The University of Westminster.

She was preparing her second-year entrepreneurship students for their first real MVP (Minimum Viable Product) project, and she wanted me to come in and do a session on prototyping.

Simple enough, right? I've done this talk dozens of times.

But as we planned the session, she mentioned something that made me pause: "They keep asking why they should test their ideas. And honestly, I'm not sure how to answer that without confusing them more."

That's when it hit me.

These students weren't confused about prototyping. They were trying to do three completely different things at the same time.

And honestly? Most of us are doing exactly the same thing.

Deborah's students are brilliant. They understand lean startup methodology. They've read the books.

But they're stuck on questions like:

Questions I’ve heard from founders of all ages.

Here's what I realised while sketching out the lecture: We're treating "product development" as one big blob of activity when it's actually three distinct skills that happen in sequence.

No wonder it feels overwhelming.

When you're creating a product, you're actually doing three completely different things:

Build → Test → Adjust

Each one requires different thinking, happens at different times, and uses different parts of your brain.

Trying to do them simultaneously is like trying to cook dinner, set the table, and eat—all at the same time.

Technically possible. Definitely messy. And completely unnecessary.

Let me break down what I put together for the students (and what clicked for them immediately).

The first skill is straightforward: You need something tangible to show people.

But here's where everyone goes wrong—they build too much.

When I walked the students through this, I showed them the Airbnb example. Their first "MVP" was literally just posting their own flat to see if strangers would actually pay to sleep in someone else's home.

No search function. No form for other hosts. No payment processing beyond the basics.

One test. One assumption. That's it.

I watched the students' faces light up: "Wait, so we don't need to build everything first?"

Exactly.

Your build phase has one job: Create something that represents your core idea clearly enough that someone can tell you whether it solves their problem.

That could be:

The goal isn't to impress. It's to have a prop for the next phase.

This is where I saw the students lean forward in their seats.

Because testing isn't what most people think it is.

You're not testing to see if people like your prototype. You're not collecting compliments. You're not asking "What do you think?"

You're observing behaviour to understand whether you're solving a real problem in a way that makes sense.

I told them: "People are polite. They'll tell you your idea is brilliant even when they'd never actually use it. But their behaviour? That's honest."

So you watch:

Testing isn't about the artefact. It's about listening.

One student raised her hand: "So we're not looking for validation, we're looking for confusion?"

Bingo.

Now you've got data. Real behaviour. Actual confusion points.

The question is: What do you do with it?

This is the third skill—and it's surprisingly difficult.

Because not every piece of feedback deserves action. Not every confused user means you need to change something. Not every feature request should make your roadmap.

I had the students practice this: After showing their sketches to classmates, they had to decide:

Then they had to make a call: Pivot? Iterate? Double down on what's working?

This is a different skill than building. And a different skill than testing.

Right now, you're probably doing what these students were doing before the lecture:

Build → Build More → Build Even More → "Okay, NOW I'll test it" → Realize it's wrong → Panic

Here's what should happen:

Build (just enough) → Test (extensively) → Adjust (strategically) → Repeat

The reason your MVP keeps getting delayed? You're conflating these three skills into one giant "product development" blob.

The reason it keeps getting more expensive? You're spending too much time building and not nearly enough time listening.

At the end of the lecture, I gave the students five minutes to sketch three frames:

No fancy tools. Just paper and markers.

Then I had them pair up and test with each other, immediately.

Within ten minutes, they'd completed a full Build→Test→Adjust cycle.

And the questions changed entirely:

They weren't asking when to test anymore. They were asking what to do with what they learned.

That's the difference.

If second-year entrepreneurship students can grasp this in a two-hour lecture, you can implement it this week.

Pick one assumption about your product. Just one.

Then ask yourself:

Then do it.

Because treating these as three separate skills doesn't just make the process clearer.

It makes it faster, cheaper, and significantly more likely that you'll build something people actually want.

Even if you're not a second-year student learning this for the first time, sometimes it helps to go back to basics and remember: These are three different skills. They happen in order. And trying to do them all at once is why everything feels so bloody hard. 😉

PS — If you know a friend who’s stuck on their MVP, please forward this email to them or share your referral link! And if you're facing a similar dilemma, I'd love to hear about it - just hit reply.

😍 Did you like today’s issue? Ring this bell 🔔 so I can celebrate!

🤷‍♀ Did you think it was meh? Hit reply and lay your feedback on me!

🤩 Want more? Check out the video below!

Code explained in plain English for founders who need to work with developers

Quick legal note: This newsletter shares my experience and opinions, but it's not official financial, legal, or business advice. Every situation is different. Make your own decisions, do your own research, and consult professionals when you need them. You're the expert on your business.