Product principles
Start from the decision, not the feature
A roadmap item phrased as "build a comments system" is an order taken. Phrased as "increase weekly return visits among firms with more than five active matters," it's a problem with more than one possible answer — and the team gets to find the cheapest one. I push every intake through that translation before it reaches a backlog.
The bets you decline are the strategy
Anyone can produce a list of shipped features. What tells you whether a product org is being led is the list of things it deliberately did not build, and whether the reasoning survives contact with the person who asked for them. I keep that list explicit and I keep it visible to executives, because a stakeholder who understands why their request lost is a stakeholder you can go back to.
Ambiguity is the job, not an obstacle to it
The most valuable work I've done arrived with no BRD, no infrastructure, and no agreement on what success meant. The pattern that works: get to a written problem statement within days, get to something running within weeks, and let the artefact — not the document — settle the disagreement.
Ship, then earn the right to scale
Every one of the four products I've taken to production started narrower than the ambition. Multi-tenancy, pricing tiers, and reporting all came after someone was using the thing daily. Building the general case first is the most expensive way to learn you were wrong about the specific one.
AI principles
Adoption is a product problem, not a training problem
Leading a company-wide AI transformation taught me that the constraint is almost never model capability. It's that people don't know which of their tasks is a fit, don't trust the output, and have no safe place to fail. So the work is: pick the workflows where the failure mode is cheap, instrument them, publish the results honestly including the misses, and let adoption follow evidence.
Human-in-the-loop is a design decision with a price tag
Every automation I've put into production has an explicit answer to: what does a wrong output cost, who catches it, and how long does catching it take? When the cost is low and reversible, automate fully. When it isn't, the review step is part of the product, not a temporary scaffold to remove later.
Reusable patterns beat individual wins
A single team using AI well is a story. A reusable agent template that four teams adopt is infrastructure. I bias toward building the second — the Business Analyst agent (Claude Code + Atlassian MCP) that automated Jira story creation and backlog grooming mattered far more as a template other teams forked than as a tool I used.
Evaluate before you evangelise
Guardrails, evaluation sets, and a written definition of "good enough for this use case" go in before rollout, not after the first incident. This is the least glamorous part of AI product work and the part that decides whether leadership trusts the next thing you propose.
How I build teams
Hire for the gap, not for the resemblance
The strongest teams I've run were uncomfortable to assemble — people whose instincts corrected mine rather than confirmed them. The tell for a healthy product org is that engineering pushes back on scope and research pushes back on certainty, and nobody has to be brave to do it.
Scope grows through delegation, not through hours
Running three concurrent SaaS lines with one team only works if decisions happen without me. That means written context over verbal context, a clear standard for what needs escalation, and a genuine tolerance for a good-enough decision made by someone else rather than a slightly better one made late.
Stay close enough to the work to be useful
I still build. Not because a Director should be writing production code, but because reviewing an architecture, prototyping the disputed screen, or shipping the internal tool nobody has time for is often the fastest way to unblock a decision — and because a product leader who can't read the system is negotiating blind.