Most roadmaps describe what product and engineering plan to deliver. With AI at their fingertips, most organizations are now building far more than that. Sales ops builds enablement tools. The onboarding team prototypes a workflow that multiple new customers are using within a week. An engineer ships an integration, and the data pipeline behind it …
A two-day hackathon looks like a gift to your team. Two days off the roadmap. Two days of building whatever they want. If you’re a CRO wondering when the feature to help close the deal will be deployed, it looks like you just lit a match on a week’s worth of productivity (because you’re also …
SaaS is in a rough stretch. Companies are cutting, consolidating, fighting to keep the lights on. The Saaspocalypse is being felt at varying stages depending on the market. And when organizations are under pressure, something deeply human kicks in: they start hoping for a hero. Not necessarily a specific person. Just someone — from engineering, …
There is plenty of discussion about AI-enabled development, but very little of it deals with what actually happens inside an organization once the tools are in everyone’s hands. I’m interested in the process stuff—the “where the rubber meets the road” issues that show up in daily operations rather than demos. These aren’t hypothetical risks; they …
You can’t memo or force your way to AI adoption. I’ve written before (Strategy Isn’t Strategy Unless Repeated) about why communication alone doesn’t change behavior. Adoption is a behavior change problem. You need mechanisms of change, not just announcements. Two that have worked well for me for AI adoption specifically are: hackathons and local champions. …
Here’s some math that makes this obvious once you see it: you spend dozens, maybe hundreds of hours developing a strategy. You think through the problems, the options, the trade-offs, the execution paths. You live with it. You sleep on it. You iterate on it. You pressure-test it with other senior execs and your leadership …
Engineering leaders spend years learning to build fault-tolerant systems. We design for failure. We instrument everything. We think carefully about what happens when a node goes down, when traffic spikes, when dependencies become unreliable. Then we walk into a meeting about team structure and don’t apply those same lessons. The highest-leverage work for most engineering …
Building software is easier than ever. The AI tools work well enough really well. The low-code/no-code platforms work well enough really well. The vibe coding works well enough really well. That marketing director who shipped an internal tool over the weekend? They’re not wrong to feel empowered. They actually built something, it actually runs, and …
Getting good feedback is one of the hardest parts of product work. You send a doc. You ask for thoughts and it’s usually met with silence or “Looks good to me.” You follow up for more and maybe one person responds or you get, “move the button in the flow to the top right”. Everyone …
The hardest part of an RFC process isn’t designing the template. It’s making sure people actually use it without feeling like they’re filing TPS reports. I’ve written before about When to Write an RFC and When Not To and how it helps in formalizing technical decisions as companies scale. This is the tactical follow-up on …
