View profile

Walks vs Sprints


Thinking In Public

June 9 · Issue #4 · View online
I appreciate the build in public movement. It allows people to share ideas, get feedback and learn quickly. So why not do the same with our thinking? That’s what I try to do with this monthly newsletter, send on the last Sunday of each month. The current iteration has 3 sections: - Clarify - Something I’ve tried to think through. - Consider - Ideas I’m playing with. Normally with questions. - Collect - Thinking I’ve collected from others. All thinkers welcome.

Hello everyone - I hope you had a good May.
I expected to start a second side-project in May, but I completely stalled. I didn’t settle on an idea I wanted to take through to execution.
In doing so, I did manage to appreciate a second mode of creation for the Indie developer; the mode that focuses on exploring and choosing ideas. That is the topic of this months essay.
As always, please send me any thoughts. You can reply directly to this email.

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.
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.
You can see all of my essays on
Other Thoughts
This tweet from man @samueIw got me thinking back to the Chefs vs Cooks post by @waitbutwhy.

What if entrepreneurs aren’t ‘crazy’ or weirdly confident. What if everyone else is held back by irrational fear?
I’m interested in how people foster thinking time and reflection in their lives.

Is this something you do deliberately?

Do you do it at a regular cadence? Or at random?

Do you ask yourself a set of questions? Or is it something more off cuff?
Finally got around to reading this excellent essay from @andy_matuschak. How can we make books better? Or more generally, what is the best way to pass on the knowledge that has previously been shared via books?
Did you enjoy this issue?
If you don't want these updates anymore, please unsubscribe here.
If you were forwarded this newsletter and you like it, you can subscribe here.
Powered by Revue