LEAN · Finding the Right Problem

1. The Target-Problem-Solution Pyramid

Before he wrote The Lean Startup, Eric Ries burned 300,000 dollars and six months on a product nobody wanted. He was a developer in Silicon Valley, so the code was never the issue. The issue was that he had no idea who he was building for.

If you're launching something right now, you're in exactly the same position he was at the start. That's not a flaw. It's the starting condition.

What nobody tells you at the very beginning

A startup, by definition, is a company that doesn't know three things: who it's talking to, what problem it solves, and with what. A traditional entrepreneur knows all three. She opens a bakery in a neighborhood with no bakery, and she knows who it's for, what it's for, and how. A startup doesn't. It discovers. That's the difference.

The normal instinct when you start is to say everything, just to reassure yourself. You aim wide, because you're afraid of cutting yourself off from the world. You list several problems, because you're not sure which one is real. You pile on features, because you confuse "complete product" with "finished product." The result fits in one sentence: a message nobody understands, so nobody reacts, so you get no signal on whether the idea has any value. Six months later, you're at the same point as day one, but with less money and more exhaustion.

The Target-Problem-Solution pyramid is how you get out of that. Not by being right on the first try. Just by having a hypothesis sharp enough that a human can tell you yes or no, without hesitating.

Three lines, three rules

Target. One only, and as precise as possible. "SMBs" doesn't exist, because nobody wakes up in the morning thinking "I am an SMB." Aim instead for "recruitment agencies of fewer than 10 people in the Paris region that bill on a success-fee basis." If someone in that segment reads your sentence, they should recognize themselves at first glance.

Problem. One sentence, the main problem. "They don't have tools" says nothing. "They retype their candidates by hand from one ATS to another, every day" says something. If you can describe the concrete action that wears them down, that's a good sign.

Solution. One feature. The smallest thing that answers the main problem. "An all-in-one platform" is a polite way of saying "I haven't chosen." "A button that pushes a candidate profile from LinkedIn into their ATS in one click" is a real pyramid.

A pyramid is a concept to test, which means a message to hammer home. If you launch two in parallel, you launch neither. You get noise, not a signal.

The exercise, right now

Grab a sheet of paper. Write:

Target   : ...
Problem  : ...
Solution : ...

Three forces will try to pull you back toward vagueness.

The first is the urge to broaden. "And also freelancers, and also the self-employed, and also…" No. You can always broaden later. For now, you want to know if your message speaks to one specific human. And when a target doesn't work, you don't broaden, you switch.

The second is the urge to stack problems. Pick one. The one that comes up most when you listen to future customers. The others don't vanish, they wait their turn.

The third is the urge to list everything on the solution side. One feature only. The smallest one that solves the main problem. Everything else is a v2.

If you can't manage to choose, it isn't an intellectual block. It's that you haven't talked to enough people yet. We'll get to that in the next chapter.

The explicit plan B

You can keep a second pyramid in reserve, with a different target. If the first doesn't hold up after a few tests, you switch to it without starting from scratch. That's your explicit plan B, not an emotional safety net.

The difference isn't a subtlety. A safety net is something you keep so you don't have to choose. A plan B is something you write so you can choose fast, the day the data says the first one isn't the right one.

What should be left on your sheet at the end

A pyramid you can read aloud, without pausing, without any "and also." If it takes you longer than a single breath, there's too much in it.

You don't need it to be right. You need it to be precise. The rest is what happens next, when you take this pyramid and confront it with real people.

2. Finding a problem worth your time

You have a pyramid. Well done, that's already rare. The trouble is you don't yet know whether the middle line, the one where you wrote "Problem," is worth the time of your life.

This is the section where we filter.

The trap of polite validation

When you talk about your idea to friends, to colleagues, to strangers on LinkedIn, the vast majority will say it's a good idea. They're not wrong out of malice. They're wrong because you asked them the wrong question.

"Would you use a thing that does X?" Answer: "Oh yeah, that'd be cool." That "cool" is worth nothing. It's politeness talking, not the wallet. Rob Fitzpatrick wrote an entire book about this, The Mom Test, and the title says it all: if you phrase your question in a way where even your mother could lie to you without meaning any harm, you learn nothing.

The real question is never about your product. It's about the person's life, before you existed.

Three questions that work

To find out whether the problem on your second line deserves your year, you only need three angles. You can put them to anyone in your target, without ever pitching your idea.

Frequency. How often do they hit the problem? Once a year, once a month, once a week, every day? A monthly problem rarely mobilizes a budget. A daily one does.

Intensity. What does it cost them when the problem shows up? Time, money, morale, customers, sleep? If you can't put the cost into one sentence, it's probably not a problem, it's a mild annoyance.

The workaround. How do they cope today? An Excel file? An intern? A tool they hate but keep paying for? Their current hack is your best indicator. Someone who has already built a homemade system around a problem has told you, without realizing it, that they'd pay for something better.

Three angles, a few minutes per person. That's enough to start seeing a pattern.

The signals that say "give up"

There are also things you'll hear that you must not over-read. The human instinct is to hold on to what validates and forget what invalidates. That's an ego trap, not a reasoning one.

"That'd be nice to have." Translation: it's not a problem, it's a comfort.

"I'd never thought to look for a solution." Translation: it's not painful enough for the person to have already put themselves in motion.

"We tried a tool two years ago, but we dropped it." Ask the follow-up: why did you drop it? If the answer is "it took too long to set up," you have an opportunity. If the answer is "turns out we didn't need it," you have a stop signal.

A good founder throws ideas in the trash regularly. Clinging on when the market says no is ego, not conviction.

The signals that say "dig"

You know you're onto something when the person across from you shifts their posture. They lean forward. They cut you off to describe their own case before you finish your question. They tell you what they've tried. They end up asking whether you'd like to talk to a colleague who's living the same thing.

At the other end of the spectrum, there's the infallible signal, the one you might meet in a year or two. If one day you find yourself wondering "have I reached product-market fit?", the answer is no. When it's there, you don't have time to ask the question, because you're underwater.

You're not there yet. And that's perfectly fine. For now, you're just trying to see whether your listeners' posture changes when you describe the problem on your second line.

What should be left on your sheet at the end

Next to your pyramid, add three things, observed and not guessed:

Frequency  : ...
Cost       : ...
Workaround : ...

If you can fill in all three for a handful of different people in your target, and the answers resemble each other, you have a problem worth attacking. If you can't fill in a single one, it isn't your idea that has a problem. It's that you haven't had the right conversations yet.

We're getting to that now.

3. Testing the market through interviews

You have a pyramid. You've listed a frequency, a cost, a workaround for a few people. Good. Now you're going to do the thing everyone says they'll do and almost nobody does: you're going to call people.

The goal is neither to sell nor to pitch. You want to understand.

Why this doesn't come naturally

Nobody likes calling strangers. Nobody. Even the founders who do it every day will admit, off camera, that they put off the first message of the day. The normal instinct is to replace the interview with a Tally survey, a LinkedIn poll, or worse, a conviction. "I know my market, I worked in it for five years." That's exactly how you spend six months building a product for the five-years-ago version of a market that has since moved.

An interview, in this context, is not a job interview. It's not a focus group either. It's a fifteen-to-twenty-five-minute conversation, over video or phone, where the person talks about their professional life and you listen. You don't talk about your idea. You don't show a mockup. You don't explain what you want to build. You ask questions about before, about what they're living today, without you.

Rob Fitzpatrick, in The Mom Test, sums it up in one rule: if the person across from you can answer politely without knowing anything about your idea, then you're asking the right questions.

The structure that works

You don't need a twelve-page script. You need three moments.

The context. You start by getting them to describe a typical day, or the last time they hit the problem you suspect. Above all, you speak in the past tense. "The last time you had to retype candidates from one ATS into another, can you walk me through how it went?" The past is lived experience. The future is imagination, and imagination lies.

The pain. You dig into the real impact. How much time did it take them, or their team? What would they have preferred to be doing instead? Have they ever gotten worked up about this internally? If so, in front of whom? You're looking for signals of emotion, because emotions come before purchases. Nobody pulls out a credit card to solve a lukewarm annoyance.

The workaround. You finish with how they do it today. A tool they bought, a homemade file, a dedicated intern, an outside provider? Are they already paying for a solution that does half the job? How much? This is the most important question in the whole interview, because it tells you what they're already paying. Someone who pays for a tool they hate is a customer. Someone who has never looked for a solution is rarely a buyer.

At the end, you ask one last line, always the same: "Is there anyone else in your network who lives the same problem and who I could have this conversation with?" If the person says yes without hesitating and gives you a name, that's a huge signal. If they say "uh, I'll see," then your problem isn't that sharp for them.

How to find people

This is the part where most people get stuck. You don't need a CRM. You need five to ten conversations with people who match your target. Here's where they are, from easiest to hardest.

Your direct network. You already have colleagues, former colleagues, friends who are in the target, or who know someone in it. That's the least awkward pool to activate. Ask privately, never in a LinkedIn post.

LinkedIn, by DM, by hand. You search for your target through Sales Navigator if you have access, or through the standard LinkedIn filters. You send a short message, saying you're doing research on their line of work, that you're looking for fifteen to twenty minutes, and that you're not selling anything. The acceptance ratio is low, and that's normal. Aim for around a hundred DMs sent if you want ten interviews.

The communities where your target talks. Discord, Slack, subreddits, Facebook groups if your target lives there. You observe before you step in. When you do step in, you ask a real question, never your Calendly link as a first message.

A warm intro from someone who vouches for you. This is the most powerful option. It comes naturally after your first three interviews, because you ask the closing question.

You don't pay anyone for these interviews. You offer your time in exchange for theirs. Gratitude shows up as a thank-you message, and in the fact that you come back later to share what you learned.

What you write during and after

During the interview, you take short notes. You don't record, unless you've asked for permission. You note verbatims, meaning the person's exact phrases. Not your interpretations, not your conclusions, their own words.

Right after, give yourself five minutes. You fill in a mini-template, always the same.

Interview : first name / role / company / date
Target matched : yes / no / partial
Problem frequency : ...
Problem cost : ...
Current workaround : ...
Verbatim that struck me : "..."
Pain signal : weak / medium / strong
Referral given : yes / no

After five interviews, you lay the fiches side by side. You look for phrases that resemble each other. Not once, not twice. The same phrasing three times, across three different people, is a pattern. Once is an anecdote.

The "I told you so" trap

Your brain will want to hear what validates your hypothesis. It's mechanical, it's confirmation bias, and even the best founders fall into it. The best protection is to read your notes with a contrary question: "what did I just learn that should make me stop?" Ask yourself that question out loud, with every stack of five fiches.

If you have nothing to answer, that's suspicious.

If you find something, that's precious. You just saved yourself time.

What should be left on your sheet at the end

Five to ten completed interview fiches, and a short synthesis paragraph in plain language, answering three questions:

Do the people you interviewed genuinely live the problem on your middle line, frequently and with real pain?
Are they already paying, or hacking around, to cope?
Does your pyramid hypothesis hold up after these conversations, or does it need to move?

If you answer no to even one of these three, it's not a failure. It's several months saved. You go back to the pyramid, you change what needs changing, and you run five more interviews. That's the work.

If you answer yes to all three, we move to the next step: laying your model out on a single page.

4. Lean Canvas

You have a pyramid. You have five to ten interviews that resemble each other. You're starting to see a pattern.

Now is the moment to lay out the rest on one page.

Why one page, not a business plan

A traditional business plan is thirty pages nobody reads, written to reassure a bank that won't fund you at this stage anyway. You write that when you already know what you're doing. At the start, you don't. You have a series of hypotheses, and you're trying to confront them with reality as fast as possible.

Ash Maurya, an entrepreneur who struggled through several startups before writing Running Lean, started from Alexander Osterwalder's Business Model Canvas, a tool used in large companies, and adapted it for very early-stage startups. His version fits on one page. It forces you to say the essentials and drop what serves no purpose.

You're going to fill in this page. But not in the order the grid suggests. Not by starting with what reassures you, either. You start with what scares you, because that's where the information is.

The nine boxes, in the order you actually fill them

The page is divided into nine zones. The order you fill them in matters far more than the neatness of your handwriting.

1. Customer Segments (top right). You start here. This is the top line of your pyramid. You put your most precise target. If you're aiming at several segments, you pick one for this page, and you make another page for the others later. One page, one segment. No mixing.

2. Problem (top left). The three main problems of this segment, listed. Not ten, three. If you have more, it's because you haven't yet chosen the one that deserves your year. You can also note, just below, the current workarounds you saw in the interviews. This box is the summary of your middle line.

3. Unique Value Proposition (center). One sentence, readable by an outsider, that says what you offer and for whom. No jargon. No "all-in-one platform." No "revolutionize." You can draw on the classic formula: "For [precise target], who [problem], we offer [solution] that [measurable benefit]." This isn't a marketing slogan. It's a clarity test.

4. Solution (top left, under Problem). The three smallest features that answer the three problems. Not everything you want to build someday. Just what it takes to check your hypothesis. This is the bottom line of your pyramid.

5. Channels (right, under Segments). How you'll reach these people. LinkedIn outbound, cold email, Slack communities, events, LinkedIn content, partnerships. Three at most, the ones you can activate tomorrow morning. If you write "SEO" when you have no site and no article, that's not a channel, it's a dream.

6. Revenue Streams (bottom right). How much you'll charge, and how. No "freemium, to be explored." If you don't know, write a price in pencil. Fifty euros a month? A thousand euros a year? Three percent of their sales? That number will move, and that's exactly why you need to write one down. Without a number, you have nothing to confront.

7. Cost Structure (bottom left). What your launch will cost you, in cash and in time. Tools, hosting, lead purchases, providers. You don't need an accounting file. A dozen clear lines.

8. Key Metrics (center, under UVP). Two or three metrics you'll track this week and next. Number of interviews closed, conversion rate on your landing page, number of payments received. If you write "MRR" when you have zero customers, that's fiction. Pick metrics you can move yourself this week.

9. Unfair Advantage (bottom, under UVP). The hardest box, and the one most people leave blank too quickly. What do you have that a competitor can't copy? Access to a niche market, deep expertise, a preexisting community, an obsession that keeps you going when others quit. "First to market" isn't an advantage, it's a temporary situation. If you genuinely find nothing today, write "to be built" and keep the box open. The worst thing is to invent one.

Hypothesis versus fact

On your page, you'll mark each box with a small symbol. A question mark when it's still a hypothesis, meaning something you believe without proof. A checkmark when it's validated by your interviews or by an observable fact.

At this stage, your page will be overwhelmingly filled with question marks. That's normal. The work of the coming weeks is to turn question marks into checkmarks, or to change what's in the box. Not to validate everything at once.

You can give yourself a simple rule: a box only becomes a checkmark once confirmed at least three times, across three different people, or with a verifiable, quantified data point.

The "pretty canvas" trap

There are tools for making very clean Lean Canvases. Canvanizer, Notion templates, Miro, Figma. They're useless as long as the boxes are wrong. A scribbled A4 sheet with the right hypotheses beats a pastel canvas full of platitudes.

You can write your first canvas by hand, in fifteen minutes, on the corner of a desk. You revisit it once a week. You cross out, you rewrite. It's a living document, not a deliverable to print.

What should be left on your sheet at the end

One page, nine boxes, filled in. For each box, a hypothesis or a validated symbol. And at the bottom of the page, a single sentence, written separately:

Riskiest hypothesis right now : ...

That's the one you'll test first with the next step. Because having a canvas full of questions is useless if you don't know where to attack. The riskiest point is the one that, if it's wrong, brings the whole rest crashing down.

For many startups at the start, it's either "does this problem really exist for this segment" or "will they pay the price we imagine." If you're torn, it's probably one of the two.

We're going to go test it with an MVP.

5. MVP: fake before make

You have a page. You have a risky hypothesis. You could now spend six months building your product. You have no reason to.

Instead, you're going to build the smallest thing capable of telling you whether the hypothesis holds.

What an MVP is not

MVP stands for Minimum Viable Product. Three words that have been misused for fifteen years. The trap is believing that MVP means "a stripped-down version of the final product." You take your brilliant idea, you remove the advanced features, you code the rest, you launch. That is not an MVP. It's just a beta that stinks, and that costs just as much to produce.

Eric Ries, who popularized the term in The Lean Startup, defines it differently. The MVP is the smallest thing that lets you check the riskiest hypothesis, with the least effort and the least code possible. It's not a product. It's an experiment.

And in an experiment, what matters isn't that it works technically. It's what you learn.

Three patterns work especially well for founders who are just starting. You pick only one, depending on what you're trying to find out.

Pattern 1: the landing page (to test intent)

You create a standalone web page, with no product behind it. You describe the promise, who it's for, what it solves. You put a button that says "Request access" or "Reserve," followed by a form that captures an email or a number. You send traffic to it: LinkedIn posts, targeted DMs, communities where your target lives, ads if you have a few dozen euros to spend.

You don't measure how many visits. You measure how many people leave their email or click on "I want to pay" if you're ready for that level. The ratio says a lot. A hundred people who see your page, zero who want to know more, that's a signal. A hundred people who see your page, twenty who leave an email to beta test, that's a different signal.

The best-known public case is Dropbox. In 2008, Drew Houston couldn't do a real demo, because the technology he wanted to show wasn't operational. He posted a four-minute video on Hacker News showing the expected experience. His waitlist went from five thousand to seventy-five thousand people overnight. He had validated that there was demand, without having produced the product.

You don't need fifty thousand signups. You're trying to see whether someone, somewhere, says "yes, take my email" with a bit of enthusiasm. Twenty to fifty qualified signups are plenty at this stage.

Pattern 2: the Wizard of Oz (to test value)

The concept is simple. You lead your first users to believe everything is automated, when in fact you're doing the work by hand, behind the scenes. Like in the film, when the curtain is pulled back and you discover the wizard was a guy with levers.

The most cited example is Zappos, which wanted to sell shoes online before that market existed. Nick Swinmurn, the founder, didn't know whether there would be demand. He took photos of shoes in physical stores, put them on a basic site. When someone bought, he went to the store, bought the pair, shipped it by hand. No automated logistics. He ran the experience of an e-commerce site without having built a single one.

You can do the same for just about any SaaS. An analytics tool? You do the analysis yourself in a Google Sheet and send a PDF report. A matching tool? You read the profiles by hand and make the intros over email. An automation tool? You run the automation in your head and send the result. The user pays for the result, not for the technology.

The manual work is unsustainable at ten customers. That's exactly the point. You're not supposed to scale it. You're supposed to learn. And you learn far better by doing each step yourself than you ever will by reading a dashboard six months later.

Pattern 3: the concierge (to test the promise)

A variant of the Wizard of Oz, more openly acknowledged. You don't hide that you're doing it by hand. You tell your first customers explicitly: "I'm going to handle your case personally for the first few weeks, while I figure out what works for you." The customer knows it. Often they appreciate it, because they get direct access to the founder.

The example often cited is Airbnb, in its earliest days. Brian Chesky and his cofounders went personally to hosts in New York, took the photos themselves, redid the listings. They didn't know whether a platform was enough. So they didn't assume it would be. They did the work.

The concierge works well for promises you've never tested on yourself. You learn, in every interaction, what matters, what irritates, what surprises. And you build the first version of your product with a level of precision you could never reach through interviews alone.

The rule that comes with it: you charge from the very first week. Not the final price, not necessarily the right price, but a price. The moment someone pulls out their card is the only real signal. Everything else is intent.

Which tools in 2026

If you decide to go with a landing page, you don't need to code. Several tools let anyone put a clean page online in a few hours:

Framer (framer.com): design-focused, good SEO, ideal if you want a polished look.
Webflow (webflow.com): the market standard on the no-code side, more flexibility.
Carrd (carrd.co): minimalist, perfect for a single page with a capture form.

To generate a first AI-assisted version, v0 (v0.dev) and Lovable (lovable.dev) let you produce a simple site from a prompt. The result isn't magic. You'll have to edit it. But you start in hours, not weeks.

You don't pick the best tool. You pick the one you can put online this week. Loop speed matters more than the neatness of the result at this stage.

The premature-polish trap

You'll be tempted to fine-tune your MVP. Make it clean. Make it pretty. That's understandable, especially if you come from design or engineering. You'll have to hold yourself back.

A well-produced MVP that tells you nothing about your hypothesis is a costly failure. An ugly MVP that gives you a clear signal in five days is a win. The goal isn't for your friends to say "wow, that's beautiful." The goal is for you to make a better-informed decision on Friday than you could before Monday.

If you find yourself retouching the title's typography a third time, you're procrastinating. You stop, you publish, you send it to ten people, you watch what happens.

What should be left on your sheet at the end

An MVP online or a concierge in progress, and an experiment card, always the same, that says:

Hypothesis tested : ...
Pattern chosen    : landing / wizard / concierge
Target metric     : ...
Success threshold : ...
Timeframe         : ...
Observed result   : ...
Decision          : pivot / persist / kill

That last line is what we're going to tackle now.

6. The IMAP loop: pivot, persist, kill

You have an MVP online, or a concierge in progress. You're watching what happens. At some point, you'll have to make a call.

Three options: you pivot, you persist, you kill. Not one more, not one fewer.

Why you feel nothing without a loop

The trap that kills the most projects isn't bad code, or a bad market. It's the absence of a cycle. You launch something, you watch for three months with your fingers crossed, you tell yourself "you have to give it time," you add a feature because someone asked for it, you keep going. Six months later, you've worked enormously, and you haven't made a single considered decision.

Eric Ries popularized a simple idea: to learn anything, you need a loop. Build, measure, learn. You build the smallest thing that answers a question, you measure, you decide what to do with the information, you start over.

In the swanbase framing, we call this cycle IMAP. Four steps, in this order, and the order matters.

Idea → Produce → Measure → Absorb → (Idea)

The addition compared to the original version is the "Idea" step up front. You don't dive into "Produce" because you feel like it. You explicitly decide which question you're attacking, which hypothesis you're testing, and what will validate or invalidate it.

The cadence: one week, ideally 48 hours

At this stage, your loop should spin fast. The target, as framed at swanbase, is one loop per week, ideally forty-eight hours. You won't hold that cadence every week. But it's the horizon you push toward, and every time you fall short of it, you know you're losing time.

A one-month loop is comfortable. Too comfortable. You do one thing, you wait, you do another. After a year, you've learned twelve times. A one-week loop makes you learn fifty times. A fivefold difference in frequency is enormous over the trajectory of a project.

To hold that cadence, there are two hard rules:

One loop = one hypothesis. Not three questions stacked into the same experiment. If you test the acquisition channel, the price, and the promise at the same time, you learn nothing about any of the three. You make sequential changes.

A loop ends with a written decision. Not an intuition kept to yourself. One sentence, in a file, that says what you learned and what you're doing next. Without that, you loop in a vacuum.

The three possible decisions

At the end of a loop, you have exactly three options. Not ten. Three.

Persist. The hypothesis holds. The signal is there, modest or strong, but legible. You double down. You rerun the same experiment, bigger, or you attack the next risky hypothesis on the Lean Canvas. Persistence isn't passivity. It's an active decision to double down on something that works.

Pivot. The hypothesis doesn't hold, but you've learned something that changes what needs testing. The segment was too broad, but a sub-niche reacts. The price was mispriced, but people happily pay for a stripped-down version. A pivot means keeping what works, changing what doesn't. Not throwing everything away, not keeping everything. You update your pyramid, your canvas, and you set off on the next loop.

Kill. No signal. Three consecutive loops that teach you nothing. The market doesn't react, and your instinct tells you it won't react with an nth variation. There, you kill it. It's the rarest decision, and the most mature. Killing a project you've put three months into is hard. It's also what frees up your time for the right project, which is probably the next one.

The traps of the three decisions

Each decision has its trap, and it's rarely the one you'd imagine.

The Persist trap: continuing by default. You don't really have a signal, but you don't feel like stopping, so you rerun the same thing. That's not Persist, it's inertia. Real Persist has a concrete, written signal that justifies doubling down.

The Pivot trap: pivoting because it's trendy. You read a Twitter thread about a fashionable niche, you pivot toward that niche, you pivot again the following week. At that speed, you test nothing, you chase noise. A real Pivot comes from data you observed yourself in your loops, not from a thread.

The Kill trap: killing out of exhaustion. You've had two hard weeks, your experiment didn't work, you decide to stop everything. A Kill deserves a reflection window of at least 48 hours, and ideally a conversation with someone who has watched you work on it. The point isn't for them to talk you into continuing, but for you to check that you're not deciding in the grip of burnout.

The loop journal

From now on, you keep a journal. Not a blog, not a newsletter. A private file where you log every loop. The format can fit in four lines.

Loop no. / dates :
Hypothesis tested :
Observed result :
Decision (P/P/K) + reason :

After five loops, you reread. You'll see what no dashboard would tell you. The patterns in your own decisions. The hypotheses that keep resurfacing. The things you always promise yourself and always put off. The journal is the tool good founders keep and the others forget.

It's not for posterity. It's for you, three months from now, when you need to remember what you'd already tried.

How to know if you're looping too fast or too slow

Too slow is easy to spot. If you haven't made the call within two weeks, you have a cadence problem. Often it's not an idea problem, it's a badly calibrated experiment, too big, that demands weeks of production before you measure anything. Shrink the size of the experiment, not the thinking time.

Too fast is subtler. If you change hypotheses every three days, without giving the data time to arrive, you don't learn anything either. A cold email sent to ten people tells you nothing about the channel's effectiveness. A hundred, yes. The minimum threshold for drawing a conclusion depends on the test, but a healthy rule: ask yourself "how many observations do I need before I'm ready to bet on the result?" If the answer is five, you do at least five.

What should be left on your sheet at the end

A living journal, fed after every cycle. And after each of the first five loops, a short synthesis page answering three questions:

What is the most surprising thing you learned this week?
What confirmed or invalidated your biggest Lean Canvas hypothesis?
What is the next riskiest hypothesis to test?

If you can answer these three questions every week, you're in the right rhythm. If you can't answer any of them, you didn't really run a loop. You worked without direction.

The exit door of this chapter

You know you can move on to CH2 when three things are true:

Your pyramid is stable. You no longer change it with every conversation. It has held across three consecutive loops.
You have a handful of people who pay, or who have committed to paying, even symbolically, for what you do.
You can articulate your proposition in one sentence, and when you say it, the posture across from you changes.

These three conditions are not victories. They're the minimum conditions for earning the right to move on to the next stage, where we'll attack the first ten customers who genuinely pay, by hand, one by one.

That's what we do in the next chapter.

CH1. You have your problem, your MVP, your first signals

You're no longer "thinking about an idea." You have a pyramid, interviews that resemble each other, an MVP online, and an IMAP loop that's spinning. You've done the hardest thing on a founder's journey: you've accepted looking for the problem before looking for the solution.

That's rare. Most of the people who spend six months coding don't have that.

The artifact you should have

By the end of this chapter, you should be able, in five minutes, to show a stranger:

A written CPS pyramid: a precise target, a problem named with frequency-cost-workaround, a solution in one sentence.
Five to ten conversations whose phrases you can quote in the past tense (not what people "think," what they did).
A Lean Canvas filled in, order 1 to 9, with honest "?" marks on the hypothetical boxes.
A testable MVP: landing page, Wizard of Oz, or concierge. Not three patterns in parallel.
At least three completed IMAP loops, each with a written decision (pivot, persist, kill).

If you check these five boxes, you have a problem validated with 5 to 10 real people. That's your starting point for selling.

The trap waiting for you

You'll be tempted to stay in CH1. It's comfortable. You learn. You pivot. You don't risk the rejection of a sale. At some point, learning becomes an excuse to avoid facing the payment wall. If you've been looping for three months without receiving a single euro, you're no longer in Lean, you're in structured procrastination.

The signal that you're ready for CH2: you have an MVP that draws unsolicited "where do I sign?" reactions, or your concierge has already received a first informal payment.

What awaits you in CH2

You'll move from "learning" to "selling." The intent changes: you're no longer testing a hypothesis, you're looking for ten people who pay you, by hand, without hiding behind an automated funnel. You'll sign your first v1 price, test three channels, and set up with your first users as a concierge.

No growth hacks, no industrialization. Your hands, the phone, the DM.