Disciplines
Product
Master
With 15 years experience in product management, working with teams from startups to large enterprises. I've learned that shipping fast and learning from real usage beats endless planning every time.
I focus on solving real customer problems rather than building features for their own sake. If something doesn't move metrics or improve user experience, it's not worth building. I've cancelled more projects than I've shipped. Knowing when to stop is as important as knowing when to start.
I've shipped products used by customer bases in the millions, and I've also built things that didn't work. Both experiences were valuable. The key is staying honest about what's working, measuring impact, and being willing to pivot when the data tells you to.
Design
Advanced
I started designing with Photoshop, then transitioned to Figma and now create fully working react prototypes at speed. I've designed entire applications, always thinking about how they'll actually work, not just how they'll look.
When I was the only PM and designer at a startup, I had to think about both sides at once. Every design choice had to make business sense, not just look good. That experience changed how I approach design. I always consider the product and business context, not just the visuals.
Working across both product and design means fewer handoffs and faster iteration. I can consider the entire experience at once, which leads to better solutions and fewer meetings. The result is designs that solve problems, not just look good.
Engineering
Proficient
I code in my spare time. Next.js and Supabase are my preferred stack. I enjoy tinkering with the full stack and building things. Being able to actually code makes me a better product person.
Having technical knowledge changes how I collaborate with engineers. I can read code, understand implementation challenges, and have meaningful conversations about technical trade-offs. We speak the same language, which reduces miscommunication and speeds up delivery.
I understand what's actually difficult to build versus what's straightforward, and I can assess whether something is worth the engineering effort. That context helps me make better product decisions and work more effectively with engineering teams.
Playbook
Customer Focus
Start with the customer. Understand their problems, needs, and what they're trying to achieve. Talk to them, watch them work, figure out what they actually need, not what they say they want. Everything else follows from understanding the customer.
Deep Analysis
Understand the problem before you solve it. Dive into the data, talk to users, examine the details. Good analysis turns information into insights you can actually use. Most product mistakes happen because we didn't understand the problem well enough.
Experimentation
Test your assumptions before you commit. Run experiments, validate ideas, learn fast. Not everything needs to be a full build. Sometimes a prototype or a simple test tells you everything you need to know. Fail cheap, learn expensive.
Objectives & Metrics
Define what success looks like before you start. Set clear objectives and track metrics that matter. This lets you see if you're heading in the right direction and adjust course when needed. Vague goals lead to vague results.
Ruthless Prioritisation
You can't build everything. Even good ideas need to wait. Cut features that don't move the needle. Say no to stakeholders, say no to your own ideas. If it's not the most important thing, it doesn't ship. Deciding what to cut is more important than deciding what to build.
Communication
Be clear, be direct, be honest. Explain the why, not just the what. Keep teams aligned, stakeholders informed, and users in the loop. Good communication prevents most problems. Bad communication creates them.
Stakeholder Journeys
Involve stakeholders from the start. Bring them into the process early so their input actually shapes decisions. Don't just ask for feedback and ignore it. When people feel heard and see their suggestions implemented, they become advocates, not blockers.
Keep it simple, stupid
Simplicity isn't hard. Complex systems should feel simple to use. If users need training to understand your product, you've overcomplicated it. Make sophisticated processes easy. The best products hide complexity, not flaunt it.
Delivery
Waterfall releases suck. Avoid them. Discovery and ideation should happen in small, rapid cycles. Break big initiatives into phases you can actually monitor. If something isn't working, pivot. Don't wait until the end to find out you built the wrong thing.
Strive For Better
Never settle. Even when things are working, push for better. The products that last are the ones that evolve. What works today might not work tomorrow. Keep improving, keep learning, keep moving forward.
Convinced Yet?
Let's build something amazing together
