Writing
I write to think — about product decisions, what makes teams work, and where AI is genuinely useful versus just impressive. Published when a thought is complete enough to share.
Most prioritization frameworks answer the wrong question. They help you rank work — but prioritization is actually about choosing what you are willing not to do. When you see a backlog debate go in circles, it's usually because no one has named the real tradeoff out loud.
There's a gap between how AI is talked about in product circles and how it actually gets used in day-to-day work. I've found it most useful in three places: synthesising research faster, drafting specs that don't yet exist, and catching gaps in my own thinking.
The spec is not the product, but a bad spec produces a bad product. I've noticed that the PMs who ship well tend to write for the person who will implement at 11pm, not the executive who will review at 9am. That distinction changes everything about how you write.
Every product problem starts fuzzy. The job is not to wait for clarity — it's to generate just enough clarity to move. I use a simple three-step frame: name the best version of the problem, surface the assumptions underneath it, then choose the smallest test that could invalidate the biggest assumption.