Run Laps, Not Sprints

The model

At Mindlap, we don’t run sprints. We run laps.

Not because we needed a new word for an old idea but because the underlying unit of work has genuinely changed, and the old word no longer fits what we’re doing.

The model is simple. Two levels. No more.

Track. A directional bet. A goal worth orienting around. Something you’d defend in a board meeting, not a ticket in a backlog. Tracks are prioritised against market feedback and held until you’ve learned enough to move on.

Lap. The highest-ROI thing you can specify and execute today to advance your track. A lap is a full circuit. You open it, run it, and close it with a result: working code, a validated prototype, or a clear dead end. All three count.

That’s it. No epics. No story points. No sprint ceremonies. A track tells you where you’re going. A lap tells you what you’re doing today to get there.

Laps can run in parallel. You can open three laps against the same track simultaneously, with different approaches and different bets, and demo them at the end of the day and keep the ones worth keeping. The ones that aren’t? You killed them in hours, not weeks.

This is the sharpest contrast with sprint-based development, and it matters more than it looks. A sprint is a time box. A lap is a feedback loop. These are not the same thing dressed up differently. They produce fundamentally different teams.

Five assumptions AI just broke

Sprints weren’t a philosophy. They were a pragmatic solution to real constraints. Constraints that defined software development for two decades. Those constraints are gone. And when the constraints go, the system built around them has to go too.

Here’s what changed.

“We can estimate this.”

You can’t. Not anymore. A coding agent can rewrite a module in 40 minutes that your senior engineer estimated at two weeks. The entire practice of sprint planning, with sizing tickets, running poker, and debating story points, is now theater. Estimation assumed coding time was the primary variable. It isn’t. The variable now is how clearly you can think and specify. That can’t be pointed-scored in a planning meeting.

“Coding is the work.”

It isn’t. Thinking, deciding, and specifying are the work. Coding is now closer to compilation. Something that happens after the real work is done. When coding is instant, the bottleneck moves upstream: to the quality of your judgment, the clarity of your brief, the sharpness of your bet. Teams that don’t reorganize around this will stay busy while their output stays slow.

“We validate after we build.”

Why? A working prototype costs an afternoon. The entire build-then-validate sequence of design, develop, QA, release, and measure assumed that building was expensive enough to justify front-loading it. It isn’t anymore. The prototype comes first. The decision to build properly comes after you’ve seen it work in the real world.

“Roles are stable.”

They’re not. The boundaries between PM, designer, and engineer are dissolving. Not because people are being replaced, but because the altitude of the work has risen. When coding is fast, the most valuable person on a team isn’t the one who codes fastest. It’s the one who decides best, specifies most clearly, and knows which lap to run next. Those skills don’t map onto the old org chart.

“Two weeks is the right rhythm.”

For what? If you can run a meaningful experiment in a day, a two-week box isn’t discipline. It’s drag. The sprint cadence made sense when work was slow enough to justify periodic planning. When work is daily, planning needs to be daily too. Waiting for the next sprint to start something you could start right now is a choice to move slower than you have to.

None of these assumptions are controversial anymore. Most engineering leaders will nod along to all five. The problem is: they’re nodding inside organizations still running sprints. Agreeing the map is wrong but refusing to change the route.

What this looks like in practice

Let’s make this concrete. Here’s how a real product track plays out under the lap model.

The track: Reduce activation drop-off in onboarding.

Under the old model, this is a sprint epic. It goes into discovery. Design does research. A spec gets written. Dev picks it up in the next sprint, or the one after, depending on capacity. QA runs a cycle. Six to eight weeks from insight to shipped. If it doesn’t work, you find out in week nine.

Here’s what actually happens with laps.

Day 1. Two laps open simultaneously against the same track. Lap one specifies a copy and flow change. Low-risk, high-confidence, testable in a day. Lap two specifies a more ambitious personalization approach, designed to adapt onboarding based on what the user said they came to do. Both laps are fully written before any code is touched. The specification is the work.

Day 2. Both laps close. The copy and flow prototype is done and validated with five real users in a hallway test. The conversion path is clearly better. The personalization build is 70% complete, promising but not ready to ship.

Day 3. A third lap opens. It takes the winning copy direction from Lap 1 and integrates it with the personalization layer from Lap 2. One person runs it.

Day 5. Something shippable exists. Not perfect. Validated. Data-backed. Ready to put in front of customers while the next lap on this track is already opening.

The point isn’t the speed, though the speed is real. The point is the shape of the work. The team was never blocked waiting for a sprint to end. There was no estimation meeting. No “we’ll pick that up next cycle.” Every single day, someone opened a lap, specified it, ran it, and closed it with a result. The track advanced. The learning compounded.

One lap is fast. Thirty laps a month, across three tracks, with parallel bets being kept or killed daily. That’s a compounding machine. That’s what sprint teams are competing against without knowing it.

Start running laps

We’ve been running laps at Mindlap for six months. Not as an experiment. As the way we work. Every track has a sponsor. Every day produces laps. Last week, our three member team ran 22 laps. Every lap closes with something: a result, a decision, a dead end that saves us from a longer one. The rhythm is daily. The compounding is real.

The move isn’t to throw away everything you know about product development. The move is to change one thing: the unit of work.

Stop asking “what’s in this sprint?” Start asking “what lap are you running today?”

If you can specify it, you can run it. If you can run it, you get a result. If you get a result, you learn. Do that every day, across your whole team, on the bets that matter most, and you’re not sprinting.

You’re compounding.