Some came from books, some from being wrong in production. Each one is here because it changed how I work.
A plan is a bet on a future you can’t see. Capacity is what lets you place another bet next week, cheaply.
So I stopped optimising the artefact and started optimising the loop: how fast can this team go from question to shipped answer? Roadmaps got shorter. Prototypes got earlier. Meetings got fewer.
The interesting shift isn’t velocity, it’s eligibility. People who could previously only describe a product can now produce one that runs.
That changes the product manager’s job. If you can build the thing you’re asking for, "is this feasible?" stops being a question you outsource — and "is this worth existing?" becomes the only hard one left.
Almost every reporting product I’ve seen confuses completeness with usefulness. It ships everything it knows and quietly moves the hard work onto the reader.
The useful version throws information away on purpose. It commits to a verdict, and keeps the evidence one layer underneath for whoever wants to argue with it.
Missed dates are usually a symptom of a queue nobody owns, a dependency nobody sees, or a decision that has no home.
I’ve never fixed that with more accountability. I’ve fixed it by changing where decisions get made and how work enters the system.
Ten years of writing and leading systems work left me with a physical sense of what a schema change costs, what an integration really costs, what "just add a flag" costs.
What it didn’t teach me is that ambiguity compounds faster than technical debt. A decision deferred for a quarter is more expensive than a decision made imperfectly today.
The moment a roadmap becomes a promise, discovery becomes a threat. Everyone starts defending the plan instead of testing it.
Naming things as bets — with a size, a hypothesis and a date we’ll look at it again — made it socially acceptable to be wrong on purpose. That single vocabulary change did more for our alignment than any tool.