Product Philosophy
How I Think
About Product
These are not abstract principles. They reflect how I actually approach product problems, make decisions under ambiguity, and work with teams building complex financial infrastructure.
Think in systems, not features.
Individual features are rarely the real product. The system around them — the data flows, operational dependencies, partner constraints, and customer mental models — is what determines whether something actually works at scale.
Product must balance four things simultaneously.
Customer value, business viability, operational reality, and technical feasibility. Optimising for one at the expense of the others creates products that look good on paper but fail in practice. The PM's job is to hold all four in tension and find the viable design space.
Financial infrastructure should hide complexity without ignoring risk.
The best financial products feel simple from the outside. But simplicity is earned through deliberate design — not by pretending the complexity doesn't exist. Compliance, treasury, and operational risk are not edge cases. They are product constraints.
Strong product leadership means making trade-offs explicit.
Ambiguity in product decisions is often a sign that the trade-offs haven't been surfaced clearly enough. My role is to frame decisions honestly, name what we are giving up, and help the organisation make confident choices rather than deferring them indefinitely.
Commercial outcomes matter as much as delivery.
Shipping is not the end of the job. Whether the product creates real commercial value — for customers and for the business — is what determines whether the work mattered. Product leaders need to stay connected to the commercial reality of their decisions.
Compliance, treasury, and operations are product inputs.
Treating these functions as blockers or reviewers is a structural mistake. The most effective product work I have done has been built around close collaboration with compliance, treasury, and operations from day one — treating their constraints as design inputs, not approval gates.