Thinking in public
Notes on how AI changes operating models, why APIs become business capabilities, and what helps product and engineering organisations move faster.
Most roadmaps fail in one of two ways: They become an annual PowerPoint promise that nobody on the team is willing to touch again for fear of being held to it, or they live inside a product tool that the executive team never opens. Either way, shortly after it's compiled the roadmap stops doing its job - which is to tell people what you're doing and why.
Patrick Lencioni's The Ideal Team Player argues that the best people on a team share three traits: humble, hungry and smart. I've used that model in hiring conversations for years and it still holds up, but I don't think it's complete anymore. than any of the other three. I recently posted a short video on this thought - the fourth trait I look for now is curious, and I think (at least in the world of product and tech) it's becoming more important than any of the other three.
When I was on the Gold Coast for AREC, I shipped a pull request and released it from my phone while sitting on the G. I was, of course, using an AI coding agent to help me get there.
Marathon finishers skew wealthy and educated, but cost does not explain who finishes. A look at the selection effect behind the finisher's medal.
When process stops serving the work and becomes the work, a scaling company slows down. How to spot it, and why velocity is about customer outcomes.
By now even the skeptics reluctantly accept that it's indisputable that vibecoding / AI-assisted coding makes it much faster to ship software. But it's equally true that the speed does not make the value last. I'd argue it makes it easier to chase the wrong goal because "it's so easy to progress"
I keep encountering this conversation. Twice this week... One over coffee, one over teams. If a team can vibe code a working SaaS tool in a short time, why keep paying for the SaaS version. Good question. Nobody in either conversation answered it with a number.
