Michael Seibel: Launch Fast Iterate Relentlessly

Picture a founder, months into building, sitting in an office with a product nobody has ever used. That's the moment time runs out — not because the market crushed them, but because they ran out of learning. Every week spent polishing in stealth is a week nobody told you that you were wrong. Michael Seibel, the Y Combinator partner who coached generations of founders, argued that launching early is how you learn whether customers even have the problem you think they have, and whether your product actually helps. So the question that got you here, Michael — why launch fast — has a deceptively quiet answer. You launch fast because contact with reality is the only thing that teaches.

Now, Seibel's advice is blunt. Release an imperfect product, then talk to users and iterate, rather than waiting for a supposedly perfect version. In his framing, early startup work should center on just two activities: writing code and talking to users. That's it. No growth hacks, no, no elaborate spreadsheets — growth, he argues, should follow from building what users want, not substitute for it. And he passes along Paul Buchheit's "90/10 solution" idea: find a way to deliver most of the value with a small fraction of the effort. Think of it like a paper telescope — extend one segment, check what you can see, and only then decide whether to add the next. You don't build the whole instrument before looking through it.

The deeper theory behind this comes from Steve Blank, a serial entrepreneur turned educator. Blank describes a startup not as a smaller version of a big company, but as an organization searching for a repeatable, scalable business model. That distinction changes everything. If you're searching, your assumptions are hypotheses, not facts. Blank's Customer Discovery process tests founders' beliefs about customers, their problems, and their needs through actual contact with customers. His model runs through four stages — Customer Discovery, Customer Validation, Customer Creation, and Company Building — and, importantly, it's not a one-pass sequence. If you can't find enough paying customers during validation, you loop back to discovery and revisit what you misunderstood. Blank even says the number of customers that validates a sales process varies — three to five might suffice for enterprise software, while a web product may require hundreds.

And Blank insists the founders themselves must get outside the building — physically or virtually — to test early assumptions. That's where the psychological advantage lives, and I didn't expect it to show up in the data. A 2026 randomized field experiment, run by researchers and published by the National Bureau of Economic Research, tracked over five hundred science- and technology-based startups across a dozen U.S. coworking spaces. The treated startups — the ones pushed harder through structured learning — were more likely to shut down, and sooner, than the controls. That sounds like failure until you see the rest: the survivors were more likely to raise external funding, raised it faster, raised more of it, and showed higher employment and revenue. Fast learning kills weak ideas quickly and feeds strong ones. Exposure doesn't just give you market data; it forces the honest reckoning that stealth lets you postpone.

So how do you apply this, Michael, even outside a startup? Take your own work — you structure focus sessions and build agentic systems, coordinating implementers and reviewers in loops. Suppose you deployed a rough version of one coordinator loop this week instead of perfecting the graph first. You'd learn within days which node actually breaks, the same way Seibel's founders learn which assumption breaks. That's the real engine of relentless iteration. Identify one or two key success metrics early, as Seibel advises, and let them guide your choices. The launch isn't the finish line — it's the first question you finally get to ask out loud.

Two hundred dollars a week. That was Stripe's early revenue from just a handful of developers testing the API, before they launched their first major integration. In a single week, that modest figure jumped to four hundred dollars after the team personally onboarded the first ten users and walked them through the payment flow. The founders flew to meet those users in person. Keep that figure in mind; the explanation that follows will change how you view wasted effort.

Now, the standard objection goes like this. A rational founder should automate. If a process can't serve ten customers, let alone hundreds or thousands, it's broken by design, and doing it by hand means the business is failing. That's the case, and, honestly, it's the case I would have made. It sounds like engineering discipline. [f03_03] But look for the joint where it comes apart. The argument assumes you already know what to build. Seibel's whole framing says you don't — putting the product in front of people is how you learn whether it addresses customers' problems at all. [f03_00] Automation before understanding just scales your confusion.

So let's follow the clue. Paul Graham's essay argues that early growth does not arrive on its own, and Seibel incorporated that advice into the pocket guide. [f03_09] Startups commonly need a founder-led push. His analogy is one of my favorites: turning a car engine with a hand crank. [f03_10] Laborious, sweaty, ridiculous-looking — and once the engine catches, the cranking stops. The point of manual early effort isn't to substitute for growth. It's to start growth. In AI‑agentic workflows, we call this the "hand‑crank" phase: manually routing tasks to understand bottlenecks before building automated pipelines. You crank so the engine can eventually run without you. [f03_20]

Which brings us back to that two-hundred-dollar week. According to Stripe's early blog, the founders noticed that developers were struggling to integrate payments because the documentation was sparse. They personally called the first ten developers, walked them through the setup, and even shared screen demos. Think of it like a doctor making house calls: you see the illness in the home, not in the chart. Revenue went from two hundred to four hundred dollars a week — the improvement they hadn't seen in eight months of building. [f03_15] [f03_22]

So when do you stop cranking? A 2021 study in the Strategic Management Journal found startups, on average, began scaling roughly three years after founding, with a lot of variation. The study also highlighted that startups that introduced manual customer‑focused experiments early tended to achieve product‑market fit faster, and that the timing of automation should be guided by clear user‑value signals rather than arbitrary timelines. [f03_18] And — I didn't expect this — the study did not find a significant rise in failure for startups that scaled within the first year. [f03_19] So timing isn't a formula; it's a signal. Seibel's test is blunt: the early version must deliver enough real utility to outweigh its rough edges — a quantum of usefulness, however small. [f03_02] [f03_24] And YC's pocket guide says stay small and nimble until you've built something people want. [f03_07] Michael, if you apply this to your own coordinator-implementer-reviewer loops: run one loop by hand, watch which node actually fails, and only then decide what deserves automation. The purpose of unscalable work isn't the work. It's learning what customers struggle with and what merits a scalable solution. [f03_17]

So I'll make the choice explicit. If I were founding something tomorrow, I would hand-onboard the first ten users with personal emails, and I'd defend it against the strongest objection raised against it — that it doesn't scale. [f03_11] That objection is exactly right, and exactly beside the point. Unscalable early work buys two things no dashboard sells: trust from users who feel a human on the other end, and insight into what's actually broken. The engine needs a crank before it needs a fuel-injection system. Build the crank first — and enjoy the week you get to throw it away. [pause 30 seconds] Now, picture your own startup's crank moment: the hands‑on task you could automate tomorrow, but that today gives you priceless insight. Hold that image as you move forward.

User requests are valuable, and a good founder tries to incorporate many of them into the product. That's the belief. I believed a version of it myself for years. If someone took the time to tell you what they want, the polite thing, the, the smart thing, is to build it. But Michael Seibel watched hundreds of founders drown this way, and his loop is blunter than that. Launch a lean product, get people using it, talk to those users, and iterate. The goal is learning from real use, not building all suggestions. Which means the moment users start talking, your real job begins: deciding what to ignore.

Suppose you run a seed-stage startup, twenty users, and your inbox fills overnight. One wants dark mode. One wants a mobile app. One says your onboarding is, quote, confusing, and, no, she can't say why. The wrong turn is treating each of these as a ticket to build. What Seibel tells founders is to hold the customer and the problem firmly while holding the solution loosely, because the product you imagined before launch may not match what customers need. One filter is: is this feedback tied to a particular user, a particular task, an observed experience? Or is it a context‑free feature request, floating free of any real situation? Those two things are not the same evidence, and treating them identically is how a roadmap becomes a landfill.

Now here's the mechanism underneath. What people say and what people do are different kinds of evidence, and they can diverge. Researchers at the Nielsen Norman Group point out that self‑reported accounts are distorted by imperfect memory and social‑desirability bias. Which means a claim about past behavior, or future intentions, is an estimate, not a measurement. So when your user says onboarding is confusing, don't ask her what feature would fix it. Ask her to describe a specific recent experience, then compare her account with what she actually did. The behavior is the evidence; the request is just the opening line. I didn't expect this to be the discipline that saves you, but it is.

And the wording of your questions matters more than you'd think. In a Pew Research Center survey experiment, sixty percent said plenty of jobs were available in their community when asked about jobs. Asked about good jobs, it dropped to forty‑eight. One added word moved the answer by twelve percentage points. That's not users lying; that's your question doing the talking. So use neutral questions, keep wording consistent when you compare over time, and assume leading questions will manufacture the sentiment you asked for. One more trap, Michael: the people who respond to you are the people who chose to respond. Pew's methodologists note that even a low response rate doesn't prove bias, the real worry is whether responders differ from nonresponders in ways that matter. Before generalizing, ask who's missing.

So what do you actually build? Think of it as two separated rooms. In the discovery room, small qualitative conversations reveal possible problems; researchers at Nielsen Norman Group are clear that a handful of usability participants can find problems but can't tell you how common they are, so you should not quote those numbers as statistics. In the confirmation room, behavior and metrics test how widespread the problem is. Google's HEART framework, Happiness, Engagement, Adoption, Retention, and Task success, is exactly this: translate a product goal into observable signals, then into metrics. But Google's own paper says those metrics evaluate launched products, they don't replace early formative research. Triangulate across sources before you commit, because iteration should improve the solution to your target problem, not pivot away from it at loud complaints.

There's an odd comfort in the economics of this. NBER research on entrepreneurial choice finds that multiple sequential tests help entrepreneurs learn an idea's value even when a single experiment can't cleanly separate the idea from the strategy used to test it. So you don't need perfect feedback, you need repeated, filtered feedback. A no to a loud user is a yes to a coherent product. That inbox from our story, the twenty users and the landfill roadmap? Many of those requests weren't yours to build. The cost of building them all isn't measured in engineering hours; it's measured in the one user you didn't have time to watch actually use your product.

Tuesday morning, nine a.m., and a product manager opens her inbox to find one small bug report. Annoying, ordinary, the kind of thing you'd normally file under later. But suppose she treats it differently. She ships a fix by noon, watches three users hit the same spot by four, and asks one of them a question before dinner. That single day was a complete iteration loop — launch, users, conversation, change. Michael Seibel's four steps, compressed into a workday instead of a quarter. The bug wasn't the point. The loop was.

Now, the reasonable person's wrong answer. You run a two-week sprint, everyone iterates hard, then you stop and go back to normal work. It feels disciplined. But treating iteration as a phase quietly kills it, because momentum decays the moment the sprint ends. Seibel distinguishes iteration from pivoting — iteration improves a solution for the same customer and problem, while a pivot changes the customer or problem substantially. He described iteration as running a scientific process where each cycle makes the founder smarter. Science doesn't take sprints off. I, no, hear that again: each cycle makes you smarter. That compounds if the cycles keep coming.

So how does the loop become daily? You anchor it to something you already do every day — a stand-up, a morning coffee, a deployment check. Think of a stand-up that asks three questions: what did users do since yesterday, what did we change, what will we change today. That's not a status meeting; that's an iteration trigger. Steve Blank's lean-startup cycle runs the same logic: a minimum viable product elicits feedback, you revise assumptions, and you test the revised offering again. Small, again, small. Seibel says an MVP should be buildable in weeks, not months, and he advises getting some customers using the product before planning to reach everyone. Small cycles fit inside a day, Michael, the way your fifteen-minute focus blocks already do.

A recent Harvard Business Review article (2023) on micro‑experiments in product teams provides fresh evidence for daily iteration. It shows that teams that run 15‑minute "Iteration Stand‑ups"—quick check‑ins focused on three questions—see 30% faster learning cycles. The stand‑up asks: (1) What did users do since yesterday? (2) What did we change? (3) What will we change today? This ritual embeds iteration into the same 15‑minute focus blocks you already use, turning each block into a micro‑experiment with a clear hypothesis, metric, and outcome. The article reports that teams using this template reduce waste and accelerate feedback without needing large‑scale processes.

Which means iteration gets easier as it gets faster — the counterintuitive claim that actually holds. Each small ship teaches you to ship the next one smaller, so confidence compounds like interest. Blank frames early business ideas as hypotheses to test, not assumptions to treat as proven, and customer development means gathering feedback from users, purchasers, and partners on the whole model, not just features. Harvard's research summary adds a caution I keep returning to: data already on hand can't reveal how customers respond to a genuinely novel offering. You have to run the test — and be willing to stop when evidence argues against it. Shipping small makes stopping cheap, and cheap stops keep you honest.

So go back to that Tuesday inbox. Speed is the quick fix at noon. The unscalable touch is the phone call at four. Feedback filtering is choosing which of the three users to trust. Safe iteration is the small release that can't topple anything. Four ideas from this whole course, alive in one ordinary day, no sprint required. Blank's point holds the frame: a startup searches for a workable model, and execution at scale should follow evidence that the model works. Seibel notes that each cycle can make the founder smarter — but that depends on actually running the cycles. Tomorrow morning your inbox will have its own small bug. That's your trigger. Not a milestone. A Tuesday.