Learning Velocity

Last month, a founder I'm mentoring killed a feature 72 hours after shipping it.

He's building a workflow tool for small logistics companies - the kind of niche that sounds boring until you realize how badly they're underserved. By Tuesday, he'd pushed a rough version of a new scheduling feature to a handful of users. By Thursday, the data was clear - nobody cared. By Friday, it was gone. No postmortem, no "let's give it more time." Just done.

He does this constantly. Ships minimal versions. Watches what happens. Kills what doesn't work without hesitation. Moves on. It's slightly maddening to watch. Also, he's right.

He's not optimizing for building speed. He's optimizing for learning speed.

That distinction - between building fast and learning fast - is the most important shift in how startups work today. And most founders haven't made it yet.

The bottleneck moved

Everyone talks about how AI changed building. Ship an MVP in days instead of months. Generate working code in hours. Test ideas that would have been too expensive to prototype before.

All true. But it misses the deeper shift.

When building is cheap, building is no longer the constraint. Anyone can ship fast now. The bottleneck moved upstream - to knowing what's worth building in the first place.

Here's what I keep seeing: a team that ships the wrong product in two weeks has merely confirmed its mistakes faster than a team that took three months. Speed of building, by itself, gets you nowhere. A team completing ten learning cycles while competitors complete one gains roughly a 10x information advantage - and that compounds. Each cycle informs the next. The gap widens with every iteration.

AI gave founders the capacity to run more experiments. But capacity isn't the same as capability. The founders pulling ahead are the ones using that capacity deliberately - to learn faster, not just to ship faster.

What learning velocity actually looks like

I've noticed that high-velocity learners share a few patterns.

They test hypotheses, not features. The difference sounds subtle. It's not. "Let's add notifications" is a feature. "Let's test whether reminders increase return visits" is a hypothesis. One leads to code. The other leads to insight - and only then, maybe, to code.

There's a distinction I've started using with founders: MVT instead of MVP - minimum viable testing. An MVP simulates your entire solution in minimal form. An MVT isolates a single critical hypothesis and tests only that. Founders building MVPs often overbuild because they're thinking about the product. Founders running MVTs build only what's needed to validate or kill a specific assumption. A rough prototype with placeholder design is fine - the goal isn't to impress users, it's to answer a question.

They define kill criteria before they start. "If we don't see X behavior in two weeks, we're done with this." The discipline isn't just setting the criteria - it's actually checking them. And actually killing things when the criteria aren't met.

Most founders don't do this. They set vague goals, miss them, then rationalize why they should keep going. "Just three more months" becomes a recurring theme. I've done this. You've probably done this. Everyone does. I wrote about this pattern in Knowing When to Fold - without pre-defined kill criteria, sunk cost takes over. Every week invested makes it harder to walk away.

They have zero attachment to yesterday's work. When building is cheap, attachment is expensive. Holding onto something that isn't working costs more than rewriting it. The founders I've seen do this well treat code as disposable. The insight it generated is the asset - not the code itself.

They measure learning, not output. At the end of a week, low-velocity teams report what they shipped. High-velocity teams report what they learned. "We invalidated our assumption about X. We discovered users actually care about Y. We're now testing Z." The output isn't code. The output is insight.

The 70% rule

The high-velocity founders I work with tend to operate at around 70% confidence. They don't wait for certainty before acting.

I saw this pattern clearly in mineral exploration - a business built on incomplete information. The geology is always ambiguous. The data always has gaps. Teams that waited for 90% confidence before committing resources consistently lost to teams operating at 70%. The faster teams tested more targets, learned more, and found deposits while the cautious teams were still analyzing.

What does 70% confidence actually feel like? It's the point where you have a clear hypothesis and some supporting evidence, but you're still uncomfortable. You can articulate what you're betting on and why, but you also know there are gaps. If you feel completely certain, you've probably waited too long. If you feel like you're guessing, you're probably not at 70% yet.

The same principle applies to startups. Certainty is expensive. The time spent getting from 70% to 90% confidence is time a competitor spends running three more experiments. And often, those experiments generate more useful information than additional analysis would have.

The 70% rule isn't about being reckless. It's about recognizing that action generates information that analysis can't. A live test with real users, even a rough one, teaches you things that customer interviews and market research never will.

The founders who struggle with learning velocity often have the opposite instinct. More data before they build. More validation before they ship. More certainty before they decide. Each delay feels responsible. In aggregate, it's fatal.

Where this breaks down

Some founders have completely internalized this shift. They're disciplined about what they're testing, clear about their hypotheses, quick to kill what isn't working. They compound their advantage with every cycle.

Others are using AI to build faster - but still building the wrong things. They ship more features without learning more. They iterate without direction. They're busy but not getting smarter.

One founder I worked with last year ran into exactly this trap. He'd embraced AI tools enthusiastically - shipping new features weekly, sometimes daily. Impressive velocity. But six months in, he couldn't tell me what he'd learned. The features had accumulated without pattern. Each one was a reaction to the last user complaint rather than a test of a coherent hypothesis. He was iterating, but toward nothing in particular.

There's a version of this worth naming explicitly. A startup running fifty A/B tests on button colors while its core value proposition is misaligned isn't learning faster - it's iterating toward irrelevance. Speed without strategic clarity is expensive. The skill isn't just moving fast. It's focusing your learning on the hypotheses that actually matter.

If you're shipping features but can't articulate what you learned last week, you're probably in this second camp. That's not a character flaw - it's a pattern worth noticing.

What seems to work

The founders I've seen make this shift share a few practices.

Most of them start with hypotheses rather than specs. They write down what they're testing and what would prove them wrong. If they can't articulate the hypothesis, they're not ready to build. In practice, this looks like: "We believe that [specific user segment] will [specific behavior] if we [specific change], and we'll know within [timeframe] by measuring [specific metric]." That's a hypothesis. "Add a reminder feature" is just a task.

They set kill criteria before building starts - and actually enforce them. Define the threshold. Define the timeline. Write it somewhere visible. I've watched founders who set clear criteria at the start quietly move the goalposts when the moment of truth arrived. The discipline of actually killing things is separate from the discipline of setting criteria. Both are necessary.

The first versions they build are truly minimal. Placeholder designs. Hardcoded values. Whatever gets to real user feedback fastest. They can rebuild properly once they know it's worth building.

Some run weekly learning reviews - not standups about what got shipped, but conversations about what got learned. What assumptions were tested? What did the data show? What's the next hypothesis? If the team can't answer these questions, they're measuring output, not learning.

And they obsess over cycle time - how long it takes from "we have an idea" to "we have real user data." Every week saved is another experiment they can run.

The shift that matters

Building is cheap now. Anyone with AI tools can ship fast.

The constraint moved. The advantage now goes to founders who know what's worth building - and who figure that out faster than the competition.

Learning velocity is how you get there. Not just running experiments, but running the right experiments. Not just iterating, but iterating toward something. Not just shipping fast, but learning fast.

The question isn't whether you can build in two weeks instead of two months. It's whether you can learn in two weeks what used to take two months.

I've seen founders who can do this pull ahead remarkably fast. I've also watched others run a hundred experiments and learn nothing. The difference isn't speed - it's discipline. The good news is that the patterns are learnable. The hypothesis framing, the kill criteria, the 70% confidence threshold - these are habits, not personality traits. They feel unnatural at first. With practice, they become instinct.

That's where the real advantage compounds.

I help founders navigate strategy and funding decisions when the path isn't clear. If you're there, let's talk.