Customer Discovery & Product-Market Fit

A Kaern Schools course for founders building real companies.

Tutor: Iris

Welcome to the course

Hello, founders. I'm Iris, and I'll be your tutor for the next six modules. For fifteen years I've sat beside teams who were certain they knew what their customers wanted — and watched most of them learn, the hard way, that certainty is not evidence. The ones who succeeded weren't smarter. They were better at listening, faster at testing, and more honest with themselves about what the data actually said.

I'll teach this course the way I'd teach it in a real classroom: I'll talk you through ideas in my own voice, show you how real cycleX products clawed their way to a market, hand you exercises you do this week with real humans, and then ask you questions you have to answer out loud. This is not theory you file away. It's a craft you practice.

Who this is for

You are a founder at a Kaern startup. You have an idea, maybe a prototype, maybe early revenue — and a nagging fear that you might be building something nobody truly needs. Good. That fear is the beginning of wisdom. This course is for any founder pre-fit: zero customers up to "we have traction but we're not sure why."

What you'll be able to do by the end

• Frame a falsifiable hypothesis about a problem worth solving — and kill it fast if it's wrong.
• Run customer interviews that surface truth instead of flattery, using jobs-to-be-done.
• Design MVPs and rapid experiments that buy the most learning for the least build.
• Measure product-market fit with leading and lagging signals, not vibes.
• Write a value proposition that makes the right customer say "finally."
• Iterate toward fit — and recognize the honest moment when you must pivot.

How cycleX runs through this course

Every module is anchored to how real cycleX products found their market — the wins, and more usefully, the expensive mistakes. cycleX is our running case study: a portfolio of products that each had to discover a real customer before they earned the right to scale. You'll see the same patterns repeat. That repetition is the lesson.

Let's begin.

Module 1 — Problems Worth Solving & the Founder's Hypothesis

Learning objectives

By the end of this module you will be able to:

1. Distinguish a problem worth solving from a merely interesting idea.
2. Write a falsifiable founder's hypothesis with a named customer, problem, and assumption.
3. Identify your riskiest assumption and order your learning around it.
4. Separate your enthusiasm from the customer's pain.

Lessons

Lesson 1.1 — Fall in love with the problem, not the solution

Teaching script. Founders, let me start with the most expensive mistake I see, again and again. You fall in love with your solution. You can picture the app, the dashboard, the slick onboarding — and that picture is so vivid it feels like proof. It isn't. It's a daydream wearing a lab coat.

Here's the cycleX story I tell every cohort. The first cycleX product was conceived as a beautiful piece of hardware. The team spent eight months perfecting it. When they finally showed customers, people nodded politely and didn't buy. The hardware was gorgeous. The problem it solved was minor — a mild annoyance, not a burning pain. They'd fallen in love with the solution.

Think of a problem like a fire. A solution is a fire extinguisher. Nobody buys an extinguisher because it's elegant; they buy it because something is burning right now. Your job in discovery is to find the fire — the recurring, costly, emotionally charged problem someone is already spending time, money, or worry trying to solve.

When you fall in love with the problem instead, the solution becomes negotiable. You can change the product ten times and still be on a mission. That flexibility is what survival looks like.

So before you write a line of code, ask yourself: what is actually on fire for my customer — and how do I know it's burning, rather than just smoldering in my imagination?

Lesson 1.2 — Writing a falsifiable hypothesis

Teaching script. A hypothesis is not a vision statement. A vision statement is designed to inspire; a hypothesis is designed to be killed. That difference matters more than almost anything else I'll teach you.

Here's the template I want stuck in your head: "We believe that [specific customer] experiences [specific problem] when [situation], and currently solves it by [current workaround]. We will know we're right if [observable evidence]." Every blank must be concrete enough that a stranger could check it.

The magic word is falsifiable. "People want to be healthier" cannot be falsified — it's true and useless. "Indoor cyclists in cold climates skip winter training because their setup takes more than ten minutes to start" — that can be tested. You can find those people. You can time their setup. You can be wrong by Friday.

When the second cycleX product launched, the team wrote down their hypothesis in one sentence and pinned it to the wall. Within two weeks of interviews they discovered the "situation" was wrong — the pain wasn't setup time, it was boredom. Because the hypothesis was specific, they could see exactly which clause had failed and rewrite it. A vague vision would have hidden that failure for months.

A good hypothesis is a bet you're willing to lose, written clearly enough that you'll notice when you lose it.

So: can you state your core belief in one sentence that a customer could prove false this week?

Lesson 1.3 — Finding and ranking your riskiest assumption

Teaching script. Every business plan is a stack of assumptions wearing a trench coat, pretending to be a single confident decision. Your job is to unbutton the coat and look at each assumption underneath.

Try this: list everything that must be true for your startup to work. Customers have this problem. They'll pay to solve it. We can reach them affordably. They'll switch from their current habit. We can build it. Now ask of each one: "If this is false, is the whole company dead?" and "How sure am I, really?" The assumption that is both fatal-if-wrong and least-proven is your riskiest assumption. Test that one first. Always.

Founders love testing the assumptions they're already confident about, because it feels good to be right. Resist that. The cheap, comforting experiment that confirms what you knew teaches you nothing.

When cycleX built its third product, the riskiest assumption wasn't "can we build it" — engineering was solid. It was "will gyms pay a subscription, or do they expect to own equipment outright?" That one assumption could kill the business model. They tested it in nine days with a fake pricing page and twelve sales calls, before writing a single feature. The answer reshaped everything.

So look at your stack honestly: which assumption, if false, ends your company — and how little do you actually know about it?

Worked example

Kaern startup: "Wrenchwise" — a founder believes independent bicycle mechanics waste hours on phone-tag scheduling.

• Idea (weak): "An app for bike shops."
• Problem reframed: "Solo bike mechanics lose paying jobs because customers can't book without calling during work hours."
• Hypothesis: "We believe solo bike mechanics in cities lose 2–4 jobs a week because customers call while the mechanic is hands-deep in a repair and can't pick up, and they currently cope by a paper notebook and missed-call callbacks. We'll know we're right if at least 6 of 10 mechanics can name a specific job they lost last month to this."
• Assumption stack: (a) the problem is real and frequent; (b) lost jobs are attributed to scheduling, not price; (c) mechanics will adopt new software; (d) we can reach them.
• Riskiest: (b) — if mechanics lose jobs to price, not scheduling, the whole premise collapses. Test (b) first.

Hands-on exercise

1. Write your idea as one sentence.
2. Rewrite it as a problem statement that names a customer, a situation, and a current workaround.
3. Convert it into the falsifiable hypothesis template from Lesson 1.2.
4. List 5–7 assumptions your startup depends on. Score each 1–5 on "fatal if false" and 1–5 on "how proven."
5. Circle the highest fatal × least-proven assumption. Write one sentence: "Next week I will test this by ___."

Common mistakes

1. Solution-first framing. Describing what you'll build instead of what's broken. If your hypothesis names a feature, it's not a hypothesis yet.
2. Unfalsifiable claims. "People want convenience." You can never be wrong, so you can never learn.
3. Testing the safe assumption. Validating what you already believe because disconfirmation is uncomfortable.

Check for understanding

1. What single property turns a "vision" into a "hypothesis," and why does it matter?
2. Two assumptions: one is very likely true but fatal if false, the other is uncertain but survivable if false. Which do you test first, and why?
3. Rewrite this into a falsifiable hypothesis: "We think busy parents would love a meal-planning tool."