Finding the right problem

1. The Target-Problem-Solution Pyramid

You're going to sum up your project in three lines: a target, a problem, a solution. With those three lines made precise, real people can tell you yes or no before you spend any money.

Before writing The Lean Startup, the book that popularized the method in this chapter, Eric Ries burned through $300,000 and six months on a product nobody wanted. He was a Silicon Valley developer, so the code wasn't the problem. The problem was that he didn't know who he was building for.

If you're launching something right now, you're in the same position he was in at the start: you don't yet know who you're building for.

Three unknowns at the start

By definition, a startup is a company that doesn't know three things: who it's talking to, what problem it solves, and with what. A traditional business owner knows all three. Someone opening a bakery in a neighborhood without one knows who it's for, what it's for, and how it will work. A startup has to discover those answers as it goes.

The natural reflex when you're starting out is to say everything, because it feels safer. You aim wide, afraid of shutting anyone out. You list several problems because you don't know which one matters most. And you pile on features, because you confuse "complete product" with "finished product." The result: nobody understands the message, so nobody reacts, and you still don't know whether the idea is worth anything. Six months later, you're where you were on day one, with less money and more fatigue.

The Target-Problem-Solution Pyramid gets you out of that loop. It gives you a hypothesis precise enough that someone in your target can answer yes or no without hesitating, even if that first hypothesis turns out to be wrong.

The rules for the three lines

Target. One only, as precise as possible. "SMBs" doesn't exist, because nobody wakes up in the morning thinking "I'm an SMB." Aim instead for "recruitment agencies with 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. "Every day, they copy candidates by hand from one ATS to another" says something (an ATS is the software an agency uses to track its applicants). If you're describing the concrete action that wears them down, that's a good sign.

Solution. A single 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 testable solution.

A pyramid is a concept to test, which means a message you repeat without changing it. If you run two in parallel, the responses get mixed up and you can no longer tell which one worked.

The sheet-of-paper exercise

Take a sheet of paper. Write:

A filled-in example, for an online store:

• Target: parents who work full time and are organizing a birthday party for a child aged 3 to 6.
• Problem: in the week before the party, they spend their evenings comparing decorations across several websites.
• Solution: a complete decoration kit per theme, ordered on a single page.

You'll feel three temptations pulling you back toward vagueness.

The first is the urge to broaden. "And also freelancers, and also independent contractors, and also…" Resist it. You can broaden later. For now, you want to know whether one specific person recognizes themselves in your message. When a target doesn't react, switch to a different target rather than widening the one you have.

The second is the urge to stack problems. Pick one: the one that comes up most often when you listen to future customers. Write the others down somewhere else. They'll get their turn.

The third is the urge to list everything on the solution side. Keep a single feature, the smallest one that solves the main problem. Everything else goes into a version 2, later.

If you can't choose, it's often a sign you haven't talked to enough people yet. You'll work on that in section 3 of this chapter.

An explicit plan B

You can keep a second pyramid in reserve, with a different target. If the first one doesn't hold up after a few tests, you switch over without starting from scratch.

Write it down in black and white. A backup pyramid kept in your head often becomes an excuse to never commit. Written down, it lets you choose quickly on the day you see the first one isn't holding up.

Your pyramid at the end of this section

You should be able to read your pyramid out loud, in one go, without any "and also." If reading it takes more than one breath, it contains too much.

A precise pyramid can be wrong, and that's useful: you'll find out fast, as soon as you put it in front of people in your target.

---

2. Finding your target's painful problem

You have a pyramid. Now you'll use three simple questions to check that the problem on the middle line deserves a year of your life.

The people close to you will always validate your idea

When you tell friends, family, colleagues or strangers on LinkedIn about your idea, the vast majority will say it's a good one. They aren't misleading you out of malice. They're wrong because you asked them the wrong question.

"Would you use something that does X?" Answer: "Oh yeah, that'd be cool." That "cool" is worth nothing: out of politeness, people say yes when they would never actually open their wallet. Rob Fitzpatrick wrote an entire book about this, The Mom Test, and the title sums up the idea: if you ask your question in a way that even your mom could lie to you without meaning any harm, you learn nothing.

So ask about the person's life as it was before your product existed, and never about your product.

Three questions to ask

To find out whether the problem on your second line deserves your year, three angles are enough. You can explore them with anyone in your target, without ever pitching your idea.

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

Intensity. What does the problem cost them when it happens? Time, money, morale, customers, sleep? If you can't put the cost into one sentence, you're probably looking at a minor annoyance.

The workaround. This is the makeshift fix the person uses today to get by: a spreadsheet, an intern, a tool they hate but still pay for? That workaround is your best indicator. Someone who has already built a homemade system around a problem has already told you, without realizing it, that they'd pay for something better.

With these three angles and a few minutes per person, you'll start to see a pattern, meaning answers that keep coming up across different people.

Signals to walk away

You'll also hear phrases you shouldn't over-interpret. The human reflex is to remember whatever validates the idea and forget whatever undermines it.

"That would be nice to have." Translation: a convenience.

"I'd never thought of looking for a solution." Translation: the problem doesn't hurt enough for the person to have done anything about it yet.

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

Throwing out an idea after these signals is part of a founder's normal work. Clinging to it when people in your target say no costs you months.

Signals worth digging into

You know you're onto something when the person across from you changes posture. They lean forward and cut you off to describe their own situation before you've finished your question. They tell you what they've tried, then end up offering to connect you with a colleague dealing with the same thing.

At the far end of the spectrum, there's one unmistakable signal you may encounter in a year or two: product-market fit, the moment your product fits a market so well that customers show up faster than you can serve them. If you ever find yourself asking "have I reached product-market fit?", the answer is no. When it arrives, you're underwater and have no time to ask the question.

You're not there yet, which is normal at this stage. For now, you're looking to see whether people's posture shifts when you describe the problem on your second line.

Three observations to add to your sheet

Next to your pyramid, add three things, observed rather than guessed:

A filled-in example, for a supplier ordering service aimed at neighborhood restaurants:

• Frequency: every evening, after service.
• Cost: forty minutes spent checking delivery slips, plus ordering mistakes that empty the menu on weekends.
• Workaround: a notebook and photos of delivery slips on the chef's phone.

If you can fill in all three for a handful of different people in your target, and the answers look alike, you've found a problem worth tackling. If you can't fill in any of them, you probably haven't had the right conversations yet. The next section shows you how to get them.

---

3. Testing the market through interviews

You have a pyramid, and for a few people a frequency, a cost and a workaround. Now you'll do what everyone says they'll do and keeps putting off: call people to understand how they experience the problem today.

Your only goal is to understand. You aren't selling anything or pitching your idea.

A normal reluctance

Nobody likes calling strangers, even founders who do it every day. Off camera, they'll admit they put off the first message of the day. The normal reflex is to replace interviews with an online survey (Tally, Google Forms), a LinkedIn poll or, worse, a conviction. "I know my market, I worked in it for five years." With that reasoning, you spend six months building a product for the market as it was five years ago, when it has moved on since.

Here, an interview means a fifteen-to-twenty-five-minute conversation, by video or phone. The person talks about their working life and you listen. You don't talk about your idea or what you want to build, and you don't show any mockups. You ask questions about before, about what they experience today, without you.

In The Mom Test, Rob Fitzpatrick boils it down to one rule: if the person can answer politely without knowing anything about your idea, you're asking the right questions.

A three-part structure

A twelve-page script won't help you. Three moments are enough.

Context. Start by asking them to walk you through a typical day, or the last time they ran into the problem you suspect. Above all, speak in the past tense. "The last time you had to copy candidates from one ATS to another, can you tell me how it went?" In the past tense, the person describes what they actually lived through. In the future tense, they imagine, and when people imagine, they get it wrong.

The pain. Dig into the real impact: how long did it take them, or their team? What would they rather have been doing? Have they ever gotten angry about it internally? If so, in front of whom? You're looking for signs of emotion, because people buy first what annoys them. Nobody pulls out a credit card to fix a lukewarm inconvenience.

The workaround. Finish with how they handle it today. A tool they bought, a homemade file, a dedicated intern, a contractor? Are they already paying for a solution that does half the job? How much? This is the most important question in the interview, because it shows you what the person already pays for. Someone paying for a tool they hate is a potential customer. Someone who has never looked for a solution rarely buys.

A common early mistake is to close with "How much would you pay for this?" The person throws out a random number to please you. Instead, ask how much they spent, in time or money, the last time they had to deal with the problem.

At the end, ask one last question, always the same: "Is there anyone else in your network who has 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 strong signal. If they say "uh, I'll see," your problem isn't that pressing for them.

Channels for finding people to talk to

This is often where people get stuck when starting out. You don't need a CRM, the software used to manage sales contacts. You need five to ten conversations with people who match your target. You'll find them in four places, from easiest to hardest.

Your direct network. You already have colleagues, former colleagues and friends who belong to the target or know people who do. It's the least awkward circle to ask. Ask privately, never in a LinkedIn post.

LinkedIn, by private message, by hand. Search for your target with Sales Navigator (LinkedIn's paid search tool) if you have access, or with LinkedIn's standard filters. Send a short direct message (a DM): you're researching their profession, you're asking for fifteen to twenty minutes, and you're not selling anything. The acceptance rate is low, and that's normal. Plan on sending around a hundred DMs if you want ten interviews.

Communities where your target gathers. Discord, Slack, subreddits, Facebook groups, depending on your future customers' habits. For a local business, the community can also be physical: a neighborhood merchants' association, a trade show. Observe before you jump in. When you do, ask a specific question, and never put your booking link (Calendly or anything else) in your first message.

An introduction from someone who recommends you. This is the most effective 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. Thank each person with a message, then come back later to share what you learned.

Taking notes

During the interview, take short notes. Don't record without asking permission. Write down verbatims, meaning the person's exact phrases: their own words, without your interpretations or conclusions.

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

A filled-in example, for an invoice follow-up app aimed at freelance graphic designers:

Camille, a self-employed freelance graphic designer, matches the target. At the end of every month, she chases several unpaid invoices, which takes her half a day and strains her cash flow. She gets by with a spreadsheet and calendar reminders. Verbatim: "I hate chasing payments, I feel like I'm begging." Strong pain signal, and a referral given: an illustrator friend.

After five interviews, lay the five sheets side by side and look for phrases that resemble each other. Once is an anecdote. The same wording three times, from three different people, is a pattern.

Reading against the grain

You'll want to hear whatever validates your hypothesis and forget the rest. Everyone has this reflex, experienced founders included. To protect yourself, reread your notes with the opposite question: "What did I just learn that should make me stop?" Ask yourself this out loud, for every stack of five sheets.

If you have nothing to answer, be wary: you've probably set aside whatever bothered you. If you do find something, you've just saved yourself time.

Your sheets and your summary

You finish with five to ten completed interview sheets and a short summary paragraph in plain language that answers three questions:

1. Do the people you interviewed experience the problem on your middle line often, with measurable pain?
2. Are they already paying, or improvising, to get by?
3. Does your pyramid still stand after these conversations, or does it need to change?

If you answer no to even one of these three questions, you've just saved several months. Go back to the pyramid, change what needs changing, and do five more interviews. This back-and-forth between pyramid and interviews can take several rounds before the answers converge.

If you answer yes to all three, the next step is to lay out your model on a single page.

---

4. Lean Canvas

In this section, you lay out your whole project on a single page, so you can tell at a glance what you know from what you're assuming. With your pyramid and your five to ten similar-sounding interviews, you already have enough to fill in most of the boxes.

This page is called the Lean Canvas: a nine-box grid that summarizes your business model, meaning who you sell to, what, how and at what price.

The Lean Canvas on one page

A traditional business plan runs thirty pages that nobody reads. You write it to reassure a bank that, at this stage, won't fund you anyway. That document makes sense 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 test them against 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 corporations. He adapted it for startups that are just getting going. His version fits on one page and forces you to state what matters while leaving the rest aside.

You'll fill in this page in a specific order, different from the one the grid suggests visually. Start with the boxes that scare you, because they hold the most information.

The nine boxes, in the order you fill them in

The page is divided into nine areas. The order in which you fill them in matters far more than how neat your handwriting is.

1. Customer segments (top right). Start here, with the top line of your pyramid. A segment is a group of customers who experience the same problem in the same situation. Write down your target as precisely as possible. If you're targeting several segments, pick one for this page and keep the others for later pages: one page per segment, never mixed.

2. Problem (top left). List at most three main problems for this segment. If you have more, you haven't yet chosen the one that deserves your year. Just below, note the current workarounds you spotted in interviews, like the improvised spreadsheet or the Monday call to double-check everything. This box summarizes the middle line of your pyramid.

3. Unique value proposition (center). This is often shortened to UVP. Write one sentence, readable by someone outside your industry, that says what you offer and to whom. Avoid jargon, the "all-in-one platform" and grandiose promises. You can start from the classic formula: "For [precise target], who [problem], we offer [solution] that [measurable benefit]." This sentence is first and foremost a clarity test.

Example for an online grocery store: "For parents of children with allergies, who read every label at the supermarket, we offer an online grocery store where we check each product before putting it on sale, so they no longer have to decode labels."

4. Solution (top left, under Problem). Write down the three smallest features that answer the three problems, just enough to test your hypothesis. Everything else you want to build someday can wait. This box picks up the bottom line of your pyramid.

5. Channels (right, under Segments). Write down how you'll reach these people: LinkedIn direct messages, cold emails (sent to strangers who aren't expecting you), Slack groups, events, LinkedIn posts, partnerships. Keep three at most, ones you can launch tomorrow morning. For a local business, it will more likely be neighborhood word of mouth or a poster in nearby shops. If you write "SEO" (organic search ranking on Google) with no website and no articles, you're writing down a dream.

6. Revenue streams (bottom right). State how much you'll charge, and how. Avoid "freemium, to be decided" (a free version with a paid option, where the decision keeps getting pushed back). If you don't know, pencil in a price: fifty euros a month, a thousand euros a year, three percent of your customers' sales. That number will change, which is exactly why you need to write one down: without a number, you have nothing to test against reality.

7. Cost structure (bottom left). List what your launch will cost you, in money and time: tools, hosting, purchased contact lists, contractors. About ten clear lines is enough, no accounting file needed.

8. Key metrics (center, under the value proposition). Choose two or three metrics to track this week and next. For example: number of interviews completed, conversion rate of your landing page (a web page that presents your offer and collects contacts; the conversion rate measures the share of visitors who leave their email), number of payments received. Writing "MRR" (monthly recurring revenue, what your subscribers pay each month) with zero customers is fiction. Stick to metrics you can move yourself within the week.

9. Unfair advantage (bottom, under the value proposition). This box is the hardest, and people often leave it empty too quickly. Ask yourself: what do you have that a competitor can't copy? Access to a niche market, deep expertise, a community you already run, an obsession that keeps you going when others quit. "First to market" describes a temporary situation. If you can't find anything today, write "to be built" and keep the box open. Inventing an advantage would be the worst option.

Hypothesis versus fact

On your page, mark each box with a small symbol. A question mark signals a hypothesis, meaning something you believe without proof. A check mark signals a fact, confirmed by your interviews or by an observation anyone could repeat.

At this stage, your page mostly carries question marks, and that's normal. The coming weeks are about turning those question marks into check marks, or changing the box's content, one box at a time.

Give yourself a simple rule: a box gets a check mark when at least three different people have confirmed it, or when verifiable numbers back it up.

A common early mistake: checking a box because someone close to you found the idea "great." A friend cheering you on teaches you nothing about your customer. To check a box, rely on what people in your segment have done, paid for or improvised.

The "pretty canvas" trap

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

Write your first canvas by hand, in fifteen minutes, on the corner of your desk. Come back to it once a week to cross things out and rewrite them. It will evolve with your project, and nobody needs to print it.

The deliverable: your nine-box page

At the end of this section, you have a page with nine filled-in boxes, each marked with a hypothesis or fact symbol. At the bottom of the page, write a single sentence separately:

This hypothesis goes first in your next test: a canvas full of questions is useless if you don't know where to start. The riskiest hypothesis is the one whose failure brings everything else down.

A filled-in example, for a caterer who delivers lunch trays to offices in her neighborhood: "Office managers at small and midsize companies will order every week, not just for occasional meetings." If that's wrong, her delivery round will never be profitable, whatever the rest of the canvas says.

At the start, it's usually one of these two questions: "Does this segment have this problem?" or "Will these customers pay the price we have in mind?" If you're unsure, it's probably one of the two.

The next section shows you how to test this hypothesis with an MVP.

---

5. MVP: fake before make

In this section, you build the smallest test that can tell you whether your riskiest hypothesis holds up, before writing a line of code. Six months spent building a product on a wrong hypothesis are six months lost, while a well-chosen test gives you an answer in a few days.

The phrase "fake before make" sums up the idea: simulate the product before you build it.

The misused definition of MVP

MVP stands for Minimum Viable Product. Those three words have been misused for fifteen years. The trap is believing an MVP is a stripped-down version of the final product: you take your brilliant idea, remove the advanced features, code the rest and launch. What you get is a shaky beta 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 test your riskiest hypothesis, with the least effort and as little code as possible. Think of it as an experiment: you judge it by what you learn, even if the tech isn't there yet.

Three experiment formats, called patterns, work well when you're starting out. Pick just one, based 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. On this page, you describe the promise, who it's for and what it solves, then add a "Request access" or "Book now" button followed by a form that collects an email address or phone number. Next, you send visitors to it: LinkedIn posts, targeted private messages, communities where your target spends time, ads if you can put a few dozen euros into them.

The number of visits matters little. Measure how many people leave their email, or click "I want to pay" if you're willing to go that far. Look at the ratio: if a hundred people see your page and none want to know more, that's a signal. If a hundred people see the page and twenty leave their email to try the beta, that's a different signal.

The test also works outside software. A florist considering a weekly bouquet delivery subscription can open a pre-order page before buying a single flower.

The best-known public case is Dropbox. In 2008, Drew Houston couldn't give a real demo, because the technology he wanted to show didn't work yet. He posted a four-minute video on Hacker News, a forum widely followed by developers, showing the intended experience. His waiting list jumped from five thousand to seventy-five thousand people overnight. He had validated demand without building the product.

You don't need fifty thousand sign-ups. You're looking to see whether someone, somewhere, trusts you with their email with a bit of enthusiasm. At this stage, twenty to fifty sign-ups from people who match your target are plenty.

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

The principle is simple: your first users believe everything runs automatically, while you do the work by hand, behind the scenes. The name comes from the film The Wizard of Oz: when the curtain is pulled back, the wizard turns out to be a man pulling levers.

The most cited example is Zappos, which wanted to sell shoes online before that market existed. Founder Nick Swinmurn didn't know whether there would be demand. He photographed shoes in physical stores and put them on a basic website. When someone placed an order, he went to the store, bought the pair and shipped it himself. With no automated logistics at all, he offered the experience of an online store without having built one.

The method applies to almost any SaaS (online software sold by subscription). An analytics tool? Run the analysis yourself in a Google Sheet and send a PDF report. A matchmaking tool? Read the profiles by hand and make the introductions by email. An automation tool? Run the steps yourself and send the result. A marketplace connecting parents and babysitters? Take requests through a form and call available babysitters yourself. The user pays for the result, and how you produce it isn't their concern yet.

This manual work becomes unsustainable at ten customers, and that's the point: at this stage, you're trying to learn, and growth will come later. By doing every step yourself, you learn far more than you would reading a dashboard six months from now.

Pattern 3: the concierge (to test the promise)

The concierge is an open variant of the Wizard of Oz: you don't hide the fact that you do everything by hand. You tell your first customers: "I'll handle your case personally for the first few weeks, while I figure out what works for you." The customer knows, and often appreciates having direct access to the founder.

The example often cited is Airbnb in its very early days. Brian Chesky and his cofounders went to hosts' homes in New York themselves, took the photos and redid the listings. They didn't know whether a platform alone would be enough, so they did the work instead of assuming.

The concierge works well for a promise you've never tested yourself. In every exchange, you learn what matters to the customer, what annoys them, what surprises them. You then build the first version of your product with a precision that no interview alone would give you.

A fitness coach imagining an app for personalized training programs could start this way: she writes each program by hand and sends it over WhatsApp to her first paying clients, before coding anything.

The rule that goes with it: charge from the first week. The final price and the right price will come later, but you need a price. The moment someone pulls out their credit card remains the only reliable signal; everything else is intent.

Landing page tools in 2026

If you go with a landing page, you don't need to code. With a no-code tool (a service that lets you build a website without programming), anyone can 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 no-code benchmark, with more flexibility.
• Carrd (carrd.co): minimalist, perfect for a single page with a contact form.

To generate a first version with AI, v0 (v0.dev) and Lovable (lovable.dev) let you produce a simple site from a prompt, meaning an instruction written in everyday language. The result is still imperfect and you'll have touch-ups to do, but you get started in a few hours instead of several weeks.

Choose the tool you can put online this week, even if it isn't the best one. At this stage, the speed of the loop matters more than how clean the result looks.

Premature polish

You'll want to polish your MVP and make it clean and pretty. That's understandable, especially if you come from design or engineering, but you'll need to hold back.

A polished MVP that teaches you nothing about your hypothesis is an expensive failure. An ugly MVP that gives you a clear signal in five days is a win. Your goal: make a better-informed decision on Friday than you could on Monday.

If you're adjusting the headline font for the third time, you're procrastinating. Stop, publish, send the link to ten people and watch what happens.

Your MVP and your experiment sheet

At the end of this section, you have an MVP online or a concierge underway, with an experiment sheet, always the same one, that contains:

A filled-in sheet, for a freelancer who wants to manage restaurants' Google reviews:

• Hypothesis tested: independent restaurants would pay monthly for him to reply to their Google reviews.
• Pattern chosen: concierge. Target metric: number of restaurants that agree to a first paid month.
• Success threshold: three restaurants out of fifteen approached. Deadline: two weeks.
• Result and decision: two yeses, both pizzerias that deliver; pivot toward that segment in the next loop.

You'll settle the last line, the decision, in the next section.

---

6. The IMAP loop: pivot, persist, kill

In this section, you set up a rhythm: one experiment per week, one measurement, then a written decision. Without that rhythm, you work hard for months without ever making a call.

Your MVP is running, or your concierge has started, and you're watching what happens. At some point, you'll have to choose between three options: persist (keep going in the same direction), pivot (change part of the project) or stop. The guide uses the English terms persist, pivot and kill.

The danger of moving forward without a loop

The deadliest trap for a project is having no cycle at all, worse even than bad code or a bad market. You launch something, watch it for three months with your fingers crossed, tell yourself you "need to give it time," add a feature because one user asked for it, and keep going. Six months later, you've worked enormously hard without making a single deliberate decision.

Eric Ries popularized a simple idea: to learn anything, you need a three-step loop, build, measure, learn. You build the smallest test that answers a question, you measure, you decide what to do with the information, then you start again.

At swanbase, we call this cycle IMAP, and its four steps follow each other in this exact order.

Idea → Produce → Measure → Learn → (Idea)

The swanbase version adds the "Idea" step up front. Before you "Produce," you decide in writing which question you're tackling, which hypothesis you're testing and which result will validate or invalidate it. Wanting to build isn't enough to start a loop.

The cadence: one week, ideally 48 hours

At this stage, your loop needs to spin fast. The target, as swanbase frames it, is one loop per week, ideally forty-eight hours. You won't hold that pace every week, but aim for it: every slip costs you learning 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. With one loop a week, you learn fifty times, and that gap weighs heavily on a project's trajectory.

This cadence rests on two hard rules:

One loop = one hypothesis. If you test the acquisition channel, the price and the promise at the same time, you learn nothing about any of them. Change one thing at a time, one after another.

A loop ends with a written decision. Write one sentence, in a file, stating what you learned and what you'll do next. A gut feeling kept to yourself doesn't count: without a written record, you're spinning your wheels.

The three possible decisions

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

Persist. The hypothesis holds: the signal is there, modest or strong, but readable. You double down by running the same experiment at a larger scale, or you tackle the next risky hypothesis on your Lean Canvas. Persisting takes an active decision: you bet more on what's working. To see where that signal stands relative to product market fit, take Sean Ellis's 40% test.

Pivot. The hypothesis doesn't hold, but you've learned something that changes what you should test. The segment was too broad, but a sub-niche is responding. The price was off, but people happily pay for a simpler version. Pivoting means keeping what works and changing what doesn't. You update your pyramid and your canvas, then head into the next loop.

A pivot example: a quick-recipe app designed for students attracts almost no students, but the messages that do come in are from busy young parents. The next loop tests the same app with those parents.

Kill. No signal, three loops in a row without learning anything. The market isn't responding, and your gut tells you yet another variation won't change that. So you stop, and this decision, the rarest, is also the most mature. Shutting down a project after three months of work hurts, but you get time back for the right project, which will probably be the next one.

The traps behind each decision

Each decision has its own trap, often different from the one you'd expect.

Persisting by default. You don't have a clear signal, but you don't want to stop, so you do the same thing again. That's called inertia. A solid Persist rests on a concrete, written signal that justifies doubling down.

Pivoting to follow trends. You read a Twitter thread about a trendy niche, pivot toward it, then pivot again the following week. At that speed, you're testing nothing and chasing noise. A solid Pivot starts from data you observed yourself in your loops.

Killing out of fatigue. After two rough weeks and one failed experiment, you decide to shut everything down. Give a Kill at least 48 hours of reflection, and if possible a conversation with someone who has watched you work on the project. That conversation is there to check that you aren't deciding out of exhaustion, and you remain free to stop afterward.

The loop log

From now on, keep a log: a private file where you record every loop. The format fits in four lines.

A filled-in example for a flashcard app aimed at high school students:

• Loop no. 3, October 5 to 9.
• Hypothesis tested: parents will pay for the subscription if the app sends them a weekly progress report.
• Observed result: out of thirty parents contacted, only one asked about the price, while several students wrote in on their own.
• Decision and reason: pivot, loop 4 tests an offer paid for by the student.

After five loops, reread your entries. You'll see what no dashboard would show you: the recurring patterns in your own decisions, the hypotheses that keep resurfacing, the things you keep promising yourself and keep putting off. Good founders keep this log going over time, where others forget about it.

This log will be useful in three months, on the day you need to remember what you've already tried.

The right loop pace

A loop that's too slow is easy to spot: if you haven't made a call in two weeks, you have a cadence problem. Often, you've designed an experiment that's too big and requires weeks of production before you can measure anything. Shrink the experiment and keep the thinking time.

A loop that's too fast is harder to see. If you change hypotheses every three days without giving the data time to arrive, you don't learn anything either. With ten cold emails, you know nothing about the channel's effectiveness; with a hundred, you start to see a trend. The minimum threshold depends on the test, but one question helps set it: "How many observations do I need before I'm ready to bet on the result?" If the answer is five, run at least five.

A common mistake: changing the success threshold after seeing the result, telling yourself "four out of fifteen is fine, actually." Set the threshold on your sheet before launching, and stick to it.

Your log and your summaries

At the end of this section, you have a living log that you update with every cycle. After each of your first five loops, add a short summary page that answers three questions:

1. What's the most surprising thing you learned this week?
2. Which result confirmed or invalidated the biggest hypothesis on your Lean Canvas?
3. What's the next riskiest hypothesis to test?

If you answer these three questions every week, you have the right rhythm. If you can't answer any of the three, you haven't run a loop: you've worked without direction.

The exit door for this chapter

Three conditions unlock chapter 2 (CH2):

• Your pyramid is stable: you no longer change it after every conversation, and it has held up across three consecutive loops.
• A handful of people pay for what you do, or have promised to pay, even symbolically.
• You can state your proposition in one sentence, and when you say it, the other person's attitude changes.

These three conditions are the minimum to earn the next step: going out to find your first ten paying customers, by hand, one at a time. The next chapter walks you through it.

---

CH1 . Your problem, your MVP, your first signals

You're no longer "thinking about an idea." Your folder holds a pyramid, interviews that echo each other, an MVP online and an IMAP loop that's running. The hardest part of a founder's journey is behind you: accepting that you look for the problem before the solution.

You avoided the reflex of coding for six months before talking to a single customer.

The end-of-chapter artifact

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

• A written Target-Problem-Solution pyramid: a precise target, a named problem with its frequency, its cost and the current workaround, and a one-sentence solution.
• Five to ten conversations you can quote in the past tense: what people did, in their own words.
• A Lean Canvas filled in from 1 to 9, with honest "?" marks on the boxes that are still hypotheses.
• A testable MVP: landing page, Wizard of Oz or concierge, one pattern at a time.
• At least three completed IMAP loops, each with a written decision (pivot, persist, kill).

If you can check these five boxes, you have a problem confirmed by 5 to 10 real people, and your starting point for selling.

The comfort of staying in CH1

Staying in CH1 is tempting because it's comfortable: you learn, you pivot, and you never risk a buyer saying no. At some point, learning becomes an excuse to avoid the payment wall. If you've been looping for three months without receiving a single euro, you've left Lean behind for structured procrastination.

You're ready for CH2 when visitors to your MVP ask you "where do I sign?" without any follow-up from you, or when a concierge customer has already paid you, even informally.

On to CH2

In chapter 2, you move from "learning" to "selling." The goal changes: instead of testing a hypothesis, you're looking for ten people who pay you, by hand, without hiding behind an automated funnel (a sales funnel, the sequence of steps that takes a stranger all the way to a purchase with no human involvement). You'll set your first price, the v1, test three channels, and onboard your first users in concierge mode.

You'll work by hand, over the phone and by private message, without scaling or automating anything.