Running
Building the habit, one run at a time.
I started running recently. Not competitively. Not with a race in mind. Just to build a habit that has nothing to do with a screen, a ticket, or a deadline.
01
Why I started running
I spent years building things on a computer — writing code, managing requirements, running meetings. Good work, but almost entirely mental. At some point I noticed that the days I felt clearest were the days I had been on my feet.
Running was the simplest thing I could start without equipment, a coach, or a plan. Just shoes and a direction. There is something honest about that.
I also wanted to build something that was entirely mine — no stakeholders, no sprint review, no definition of done except finishing.
02
Current goal
Build consistency and complete the half marathon journey.
The goal is deliberately about the process, not the number. I have seen enough roadmaps collapse under the weight of ambition with no foundation. Build the foundation first.
03
Training notes
Early mornings, before the day loads up. A short warm-up walk, then 20–30 minutes of easy running. No music sometimes — just the sound of the neighbourhood waking up.
I track nothing yet. That will come later. Right now the only metric is whether I went or did not go.
04
Lessons from running
Consistency beats intensity.
Three easy runs a week build more than one heroic run every fortnight. The same is true for delivery — steady momentum beats sporadic sprints.
Progress is rarely visible in the moment.
You don't feel faster on Tuesday. You notice it six weeks later. Products are the same — good decisions compound quietly.
Rest is not the opposite of training.
Recovery is part of the system. Teams that never slow down to retrospect or refactor tend to slow down for the wrong reasons later.
Show up on the hard days.
The runs you don't want to start are usually the ones that count. The same applies to the requirements document no one wants to own.
05
The connection to product thinking
The more I run, the more the two things rhyme. Both reward consistency over cleverness. Both punish overplanning and under doing. Both are made up of days that seem unremarkable until you look back at a month of them.
A sprint in Agile is named after a short run for a reason — the idea is that you push hard for a bounded time, then you stop, recover, and assess. Most teams forget the recovery part. So did I, until running made me feel what skipping rest actually does.
I think the most useful thing running teaches a product person is how to be a beginner with patience. You will be slow before you are fast. You will ship rough before you ship right. Both are fine. Neither are permanent.