Mike Hamilton

Founders call me when the product is drifting. The roadmap has too many things on it, nobody owns the product decisions so engineering makes them by default, and momentum stalls. When anyone pushes back, there is no way to tell whether it is technical reality, preference, or a technical experiment.

I run product one to two days a week for companies in that position. I set direction, cut the roadmap down to what matters, and work with the engineers on how it actually gets built. I can read the code, which is not the same as writing it for them. It means I can tell a founder when a build is more complicated than the business needs, and say the same to the engineers in terms they will accept.

I like this work most when the team argues with me and we get somewhere better than where either of us started.

AI can build anything now, so deciding what to build is the bottleneck. A vague spec just gets you the wrong product faster. I've built a set of tools for spec-driven development that slot into an existing team's workflow and codebase: specs and designs go through human review gates, people stay in control, and it works with coding agents. I wrote a course on it called Product Management in the Age of AI.

Why "Hatstep"

A flâneur wanders a city with no particular destination, noticing things, and comes back with connections nobody else made. That's a fair description of how I work: I read widely, across product, engineering and the business, and join the dots. The other reason is simpler. I always wear a hat.