Walks vs Sprints

To build a successful web product, you first need to know what you are building. Whilst that statement is obvious, knowing what to build is not. I spent 6 months building my first Indie web app [1]. And since then, I’ve struggled to start the second. During this period, I noticed two distinct and different modes in building a product as an independent developer.

Most developers will be familiar with the first mode – let’s call it a sprint. A sprint is when you know what you are building. You have some product or feature set in mind. You have tasks broken down. You have a plan. It’s up to you to execute. In a sprint, you write the code, complete feature sets and check off to-dos.

The sprint feels productive, fast-paced and high energy. The app grows and the features are added. You feel a sense of satisfaction as the actual product draws closer to the plan.

But then there is a second mode – let’s call it a walk. The walk is different. During a walk, you don’t know exactly what you’re building. You don’t have a clear product or feature set in mind. Your to-dos seem fuzzy if they exist at all.

Walks feel less productive. They are slower. The direction is not clear. They require introspection, thought and new ideas. It’s hard to measure success of a walk.


When you’re on a sprint, you feel a sense of momentum. Momentum is a powerful tool to keep you focused and positive. It gives you energy. It pushes you forward. When you’re walking you don’t feel that same momentum. Or at least, I don’t.

But the thing is, the walks are important too. The walks answers the question, where to next?

If sprints are execution, then the walks are product strategy. You need to figure out where the next sprint will take you.

I’ve found it useful to understand these differences and to acknowledge these two distinct modes up front. I ask myself, am I in a sprint or a walk? Then you can adjust your expectations. In a sprint phase, the expectation is to do as much as possible; to execute.

But in a walk phase the expectation is different. You need time to let ideas germinate, to figure things out.

It’s not just expectations that change but also behaviours. In a sprint phase, behaviours are narrow. As an indie developer, execution boils down to basically one task, programming. Everything else comes at the opportunity cost of time spent coding.

But during a walk phase, the behaviours are broader. You might research a new market. You might talk to potential users. You may read a book to find inspiration or listen to a podcast to nurture some new trail of thought.

walks vs sprints

The difference between a sprint and a walk is particularly prominent for an Indie developer. As a one-person team, you take care of the full product cycle. This means you’re in charge of both the sprint and the walk. Whereas in larger product teams, the walk is taken care of by others (say a Product Designer or Product Manager).

Perhaps this is why Paul Graham so frequently gives the advice “talk to users”. Talking to users is one method to fast-track the walk. By talking to users, you get a new feature set. You get a new list of to-dos. Talking to users is your route back from a walk to a sprint – with a new destination in sight.

So it’s worth thinking about the walk and how you navigate it. If you plan to build multiple products, knowing how to answer the question ‘where to next’ is important. What are your methods during the walk? How do you generate new ideas? And how to choose between them?

Because once you figure that out, you’ve successfully navigated the walk. And with your direction in hand, you can get back to a sprint – back to the building.

  1. I use ‘Indie’ to mean independently built. I borrow the phrase from IndieHackers, where I first heard it used.