The principles, mental models, and convictions that guide every product decision, platform investment, and team I've led over 14 years.
This is the lens I apply to every product challenge. It has guided me through 12.5 years at Amazon — from a data analyst to a PM II owning a $220M programme — and it underpins the following five core pillars of my leadership philosophy.
The difference between a product leader and a feature manager is time horizon. I design systems that outlast the immediate requirement — built for 10x scale, long-term reuse, and evolutionary growth. Every capability I've built is a foundation, not a ceiling.
This is why I invest heavily in platform governance: clear APIs, documented SOPs, scalable investigator frameworks, and knowledge architectures that grow with the organisation rather than becoming technical debt.
I don't build solutions to problems I haven't validated. Every significant product decision is preceded by a hypothesis, an experiment design, and a measurement framework. Data is not a post-hoc justification — it is the basis of the decision itself.
This means being comfortable with ambiguity early, rigorous in test design, and intellectually honest about what the data actually says — even when it challenges the initial assumption.
Customer obsession is not a value statement — it's a design constraint. I build Voice of Customer measurement into every programme, treat false-positive enforcement as a critical defect, and consistently ask: "What does this decision cost the customer, and is that the right trade?"
At Amazon, I've learned that the best customer outcomes and the best business outcomes are almost always aligned — you just have to measure both, not assume it.
The most valuable thing a product leader can do in a complex organisation is reduce ambiguity. I do this through structured artefacts: detailed BRDs, monthly programme review cadences, 12-milestone roadmaps, documented decision logs, and clear RACI frameworks for 25+ team initiatives.
Complexity doesn't disappear — but it can be made navigable. When teams know their role, the timeline, and the success metric, they move faster and with greater confidence.
Manual processes are a ceiling on scale. Every significant manual workflow in a product I own is a target for intelligent automation — not because technology is inherently better, but because automation done right creates faster decisions, lower costs, and better consistency at scale.
The key is identifying which workflows are truly automatable (rule-bound, repetitive, data-rich) versus which require human judgment — and being honest about that distinction.
Every strategic initiative I lead has a clearly defined success metric before a single line of code is written. If you can't measure it, you can't manage it — and you can't learn from it.
Elegant product decisions look obvious in retrospect because they followed the data, listened to the customer, and resisted the temptation of clever over correct.
I've seen too many platforms rebuilt from scratch because scalability was an afterthought. Building for 10x from day one is not a luxury — it is the only sustainable approach.
No significant product is built by one team. The ability to align engineering, legal, finance, data science, and operations is not a soft skill — it is a core product competency.
Features shipped, teams managed, and roadmaps planned are means, not ends. The end is measurable business impact — in dollars, in customers served, in processes transformed.
The goal of intelligent automation is not to eliminate human judgment — it is to focus human judgment where it is most valuable, by eliminating the repetitive and rule-bound.
My product strategy process is built on a repeatable framework refined across 14 years of product and programme work at Amazon — from knowledge management platforms to global enforcement systems.
I invest disproportionate time in problem definition. A precisely defined problem generates its own solution space. A vague problem generates endlessly competing features.
Measurement frameworks, baseline metrics, and hypothesis designs come before engineering investment. This is the difference between a validated build and an expensive guess.
Legal, finance, engineering, data science, and operations all have legitimate interests in any significant platform decision. Align them early — they become accelerators, not blockers.
Every architecture decision, SOP, and governance model is designed for 10x the current scope. If it can't scale, it's a prototype — not a product.
Quantitative impact metrics tell you what happened. Voice of Customer tells you why. Both are required. Neither alone is sufficient.
I give teams clear direction, defined success metrics, and genuine ownership. I seek input widely and decide decisively — consensus at scale is a path to mediocrity.
Team members get genuine ownership — but with clear accountability frameworks. The Monthly Programme Review I built for ME holds every team to their commitments, visibly.
Status meetings without metrics are social events. I build dashboards, define KPIs, and lead every programme review from the data — which keeps conversations grounded in facts.
I build SOPs, knowledge bases, and runbooks because great products are also great processes. An investigator team that scaled from 15 to 433 required documented, repeatable operational excellence.