The Lean Startup: Test the Lesson Before You Build the Course

Eric Ries says the worst failure isn't a bad product. It's a good product that nobody wanted, built carefully, on time, and on budget. Experts are especially good at that kind of failure, because we're good at building.

The book in brief

Ries learned this the hard way at IMVU, a startup where his team spent months building features customers never used. He treats a new venture as an experiment, not a plan. You don't know yet whether customers want the thing. So the job isn't to execute the plan perfectly. The job is to find out, as fast and as cheaply as you can, which of your guesses are wrong.

The engine is a loop: Build, Measure, Learn. Build the smallest thing that can test your riskiest guess, which he calls a minimum viable product. Measure what real people actually do with it. Learn whether the guess held. Then go around again. The faster the loop, the faster guesses turn into knowledge.

His most famous example is Zappos. In 1999, before building warehouses and inventory, founder Nick Swinmurn tested one question: will people buy shoes online? He photographed shoes at local stores, posted the pictures, and when an order came in, he went to the store, bought the pair, and mailed it. No system. Just an answer.

Ries calls real progress validated learning, meaning what you've proven about customers, not features shipped or hours worked. He warns against vanity metrics, numbers that feel good and prove nothing. And he makes the pivot respectable: when the evidence says the current approach isn't working, change direction on purpose instead of grinding harder.

The method fits software better than ventures with big upfront costs, and "MVP" has become an excuse for shipping half-finished work. The core discipline still holds. Test early. Let evidence decide.

The Rhynowerks angle

Here's the guess almost every expert gets wrong: "People will want to learn this from me in a course."

Maybe. But the usual way to test it is to build the whole course first. Twelve modules, sixty videos, a workbook, a platform. Six months later the market answers, and if the answer is no, the most expensive part of the lesson is already paid for.

The Navy would never field a training program that way. You pilot it. A small class goes through it, an instructor watches where people get lost, and the course gets fixed before it goes to the fleet. That's Build, Measure, Learn, and the Navy was doing it long before Ries gave it a name.

So shrink your MVP down to one lesson.

Pick the single most useful thing you teach, the one that solves a real problem in under an hour. Teach it live, for free, to three people who have that problem. Not friends being nice. Real people with the real problem. A video call is fine.

Then measure the right things. Did they use it in the next week? Did any of them ask what comes next? Did anyone ask if they could bring a coworker? Those are validated learning. "That was great, thanks" is a vanity metric. It feels good and proves nothing.

If they used it and asked for more, you've learned something no outline could tell you. Build lesson two.

If they didn't, you've lost one afternoon instead of six months. Ask them what got in the way. Maybe the topic is right and the format is wrong. Maybe the audience is wrong. That's your pivot, and it's cheap.

One more point Ries makes that experts should hear. Testing early feels exposed. You're showing something unfinished to strangers. Do it anyway. The rough version in front of three real people beats the polished version in front of nobody.

The Bottom Line

Don't build the course to find out if people want it. Teach one lesson to three people who have the problem, watch what they do next, and let that decide what you build.

New posts go up here every two days. Bookmark https://blog.rhynowerks.ai and come back.