Product
Product leadership for technically complex companies.
As implementation becomes cheaper, judgment, customer understanding, strategic choices, organizational design, and learning speed become more valuable.
I lead product and technology in companies where the product has an operational floor that never pauses — connectivity, provisioning, billing, compliance. These are the positions I hold and the evidence behind them.
También disponible en español.
Product strategy
Strategy is what you refuse. Most roadmaps I inherit are lists of things nobody objected to, which is not the same as a set of choices. I care about naming the customer we are for, the constraint we accept, and the alternatives we are explicitly not pursuing this year — then keeping that legible enough that a team can use it to say no without asking permission.
Product discovery
Discovery is a discipline, not a phase. The part teams skip is defining, before the work starts, what result would change the decision. Without that threshold, every outcome gets read as partial success. Engineering belongs in discovery from the beginning: a feasibility opinion delivered at the end is not input, it is a veto.
Product operating models
An operating model is the answer to a narrow question repeated many times: for this kind of decision, who decides, who must be consulted, and what evidence is required? Written decision rights beat structural change almost every time, because unwritten rights default to whoever escalates hardest.
The operating model I use →AI-native product development
Cheaper implementation moved the constraint toward judgment, context, distribution, trust, and adoption. The practical consequence is an allocation rule: spend new capacity on reversible experiments, and spend the time saved slowing down irreversible decisions. Teams that only get faster at producing will produce more of the wrong thing.
Where the constraint went →Platform product strategy
A platform is a product only when it has reusable capabilities, consumers you can name, governance you actually operate, and leverage you can express per consumer. Fail one test and you have shared infrastructure — which is fine, but is managed differently and should not be sold internally as strategy.
The four tests →Metrics and outcomes
The metric that predicts outcomes is learning speed: how long from starting a bet to holding evidence that changes the decision. Alongside it I track decision latency, continuity adherence, change failure rate, and the share of work traceable to a stated problem. Velocity and feature count measure motion, so I do not report them upward.
The metric set →Arguments in full
- Product leadership CTO and product leadership are converging, but they are not the same job Technical leadership is expanding from controlling implementation toward shaping product direction, organizational capability, and strategic choices. That expansion has limits worth naming.
- Product operations A product-engineering operating model with separate specialties and shared ownership Product and engineering should specialise differently and be accountable for the same outcomes. This is the model I use, including the decision rights, the metrics, and the antipatterns it is designed to prevent.
- AI product systems AI moved the constraint, it did not remove it When implementation gets cheaper, the binding constraints move toward judgment, context, distribution, trust, and organizational adoption. Teams that only get faster at producing will produce more of the wrong thing.
- Platform products A platform is a product only when it has consumers, governance, and measurable leverage Four tests separate a platform product from a pile of shared services. Most internal platforms fail at least one of them, and the honest response is usually to stop calling it a platform.
Questions I am currently working on
- Where is the honest line between generated implementation and code that must be reasoned about line by line? I hold a stricter bar on money movement, provisioning, and identity — but I cannot yet defend the boundary as a principle rather than a preference.
- How do you fund continuity work in a company that has not yet been hurt by neglecting it? Every mechanism I know relies on a scar.
- What replaces the roadmap as a communication artefact when learning speed matters more than delivery dates, without losing the coordination the roadmap was providing?
- How much product discovery can be delegated to an operations team that already talks to customers all day, and what breaks when you do?
Selected work
- AI product systems Building a seven-server MCP ecosystem as a developer product, not a code dump Seven Model Context Protocol servers published on npm, six in Rust and one in TypeScript. The interesting decisions were about credentials, install friction, and tool granularity — not about the protocol.
- Product strategy Five public apps, and what shipping small things in the open actually teaches A resume builder that stores nothing, a VS Code extension that interrupts you, a tax-registry API, an image tool, and a game. Each one is a decision about scope, and one of them I would not build again.