Problem First. Always.
I do not start with solutions. I start by interrogating the problem statement until I am certain we are solving the right thing. Most product failures I have seen were caused by teams solving the wrong problem very efficiently.
Global tier-1 asset managers asked for standalone AI plugins. I identified data fragmentation as the real problem and delivered a unified data architecture instead. A major European wealth platform asked for a manual rebalancing dashboard. User research revealed it was causing cognitive paralysis. I killed the feature mid-sprint and rebuilt around automated risk profiling.
Before writing a single user story, I run a 5 Whys analysis mapped against three lenses — user pain (what are users actually doing?), organisational pain (what metric is this blocking?), and technical constraint (what in the system makes this hard?). If the stated solution does not address all three, I go back to the problem.
I use Amplitude, Mixpanel, and raw SQL cohort analysis to find problems hiding behind green dashboards. At Deloitte, I found D7/D30 retention collapsing while surface metrics looked completely healthy — a failure nobody else had flagged.
Platform Before Features
I do not build point solutions. I build the shared foundation that makes every downstream experience possible — governed, observable, and designed to scale across teams without re-engineering.
A feature that cannot be replicated across the platform is not a product win. It is technical debt wearing a product hat. At Deloitte, this meant delaying multi-agent wealth optimization features that stakeholders were demanding — because the data layer was not ready.
Before any feature goes on the roadmap, I ask: can this be extended to three other teams within 90 days without re-engineering? If no, it goes on the platform backlog first.
I use RICE and Kano prioritisation to present data-driven trade-off maps when pushing back on scope. Winning a scope argument is not about being right — it is about making the cost of the wrong decision visible to the people with the authority to change course.
Compliance Is a Design Input, Not a Checklist
In regulated FinTech — wealth management, KYC/AML, payments — compliance embedded after the fact is not compliance. It is a liability. I treat regulatory requirements as first-class product constraints from day one of every sprint.
Every retrieval pipeline I have built has compliance logic at the data layer, not the application layer. At Deloitte, this approach cut legal review cycles from six weeks to ten days — because compliance teams move faster when they helped design the system rather than audit it.
Before any sprint begins on a regulated feature, I map four things: which data fields are PII, which workflows trigger audit events, which decisions require human sign-off by law, and which third-party API calls could cascade under high-volume conditions.
This is how I caught the KYC/AML API edge case at Deloitte — synchronous compliance calls that would have cascaded to server failure during high-volatility trading. The async queue requirement went into the acceptance criteria before a line of code was written.
Technical Depth Is Non-Negotiable
I started in electronics engineering. I write PRDs that engineering teams respect because I understand system architecture, API design, event pipelines, and cloud infrastructure — not just wireframes and user stories.
Hands-on with AWS Lambda, CloudWatch, DynamoDB, S3, Athena, GCP, and Azure. Architected REST API pipelines, webhook event systems, async queue architectures, and RAG pipelines using OpenAI APIs. I use this fluency to write acceptance criteria that catch what engineers miss, and to make the right architectural trade-offs in PRDs before they become production problems.
My PRDs include API contract specifications, event flow diagrams, edge case matrices, graceful degradation states, data schema requirements, compliance surface maps, and acceptance criteria written at the level of system behaviour — not just user behaviour.
I bridge the gap between business requirements and engineering reality so nothing gets lost in translation. Engineers do not push back on requirements they helped shape and that they can see were written by someone who understands the system.