How I work as a PM
I bring structure to ambiguous problems through clear requirements, visual communication, documentation and cross-functional alignment.
From ambiguity to execution
I create clarity before execution so teams understand the problem, solution, dependencies and expected outcome.
Understand the problem
Explore stakeholder needs, user problems, workflows and business context before defining scope.
Structure the solution
Translate discovery into roadmaps, requirements, user stories and clear functional specifications.
Align & execute
Coordinate product, design and engineering while keeping priorities, dependencies and decisions visible.
Test & iterate
Lead UAT, identify gaps and use feedback to improve the product and validate outcomes.
My goal: reduce ambiguity before it becomes rework, unnecessary bugs or delivery delays.
I make complexity visible.
I use visuals alongside written requirements to make complex products easier for teams to understand and execute.
Flowcharts & flows
Map user journeys, business processes, system behaviour, decision points and dependencies.
Visual explanations
Use diagrams, screenshots and annotated visuals to simplify requirements and interactions.
Presentations & walkthroughs
Turn complex concepts into structured walkthroughs that stakeholders and technical teams can quickly understand.
One product. One shared understanding.
I make logic, interactions, dependencies and expected outcomes explicit so business, design, engineering and technical teams work from the same understanding.
How I approach product delivery
The principles that guide how I think, communicate and collaborate.
Clarity before execution
I clarify the problem, user need, scope, outcome and dependencies before delivery begins.
Visualise complexity
I use flowcharts, diagrams and visual references when written requirements alone aren't enough.
Document from day one
I document requirements, decisions and flows from the start so context is preserved through changes, handoffs and future improvements.
Cross-functional alignment
I bridge business, design and engineering so decisions and requirements are understood consistently.
Prevent problems upstream
I surface ambiguity, edge cases and dependencies early to reduce avoidable rework and delivery friction.
Design-informed thinking
My UI/UX background helps me think through user flows, usability and product experiences with designers.
AI-augmented workflows
I use AI tools to accelerate research, requirements, exploration and documentation while keeping judgement human-led.
Documentation is part of the process, not the handoff.
Products change. People change. Requirements evolve. I therefore treat documentation as a living part of product development rather than something created at the end.
Preserve context as the product evolves.
I maintain detailed documentation around requirements, decisions, flows, assumptions and product logic so teams can pick up work with context intact — even when ownership changes or new improvements are introduced.
I adapt communication to the audience.
Different teams need different levels of detail. I keep the product intent consistent while adapting how I communicate it.
Business & stakeholders
Objectives, value, priorities, scope, risks and outcomes.
Designers
User journeys, interactions, requirements and edge cases.
Engineers & backend teams
Functional requirements, business rules, dependencies, data needs and acceptance criteria.
System architects
System interactions, integrations, dependencies and process flows.
Make the product understandable before making it buildable.
When teams understand the same problem, flow and expected outcome, they can make better decisions without repeatedly returning for clarification.