Across consumer apps, SMB workflows, marketplaces, payments, and AI-enabled products, I combine design-trained product sense, complex-category experience, and end-to-end ownership to shape products users understand, trust, adopt, and buy.
See my latest AI prototype →By the numbers — 13+ years in product · $500M+ cumulative product and venture revenue · products shipped across US, EU, and APAC · teams of 8–40 across PM, design, engineering, data, and GTM · 4 ventures incubated 0→1
Palo Alto Networks · BCG Digital Ventures · HP · ADP · Bunnings · PepsiCo · Blue Cross Blue Shield · SC Johnson · Polycom
Palo Alto Networks had world-class enterprise security, but no obvious consumer category to enter. Okyo Garde was a 0→1 bet to turn enterprise-grade protection into a household product — built inside a company learning B2C for the first time.
Reframed a stalled B2B SaaS sales motion at ADP into a commercialization pivot — turning a complex, sales-dependent HR product into a digital self-serve experience SMBs could evaluate and buy on their own.
Bunnings wanted to extend its trade ecosystem into home services. Contractor workflow SaaS — not demand aggregation — became the stronger and more scalable wedge.
HP saw a higher-margin growth opportunity beyond hardware: SMB IT services. The challenge was turning messy break/fix support into a trusted digital service product small businesses could understand, buy, and rely on.
When the customer problem is real but the product hasn't found its shape, I figure out what to actually build. Sometimes that's a SaaS workflow, sometimes a marketplace, sometimes a productized service, sometimes none of the above. The work is in not assuming the answer.
I trained as a designer before I became a PM. That shows up as observing users in their real context, building around behavior rather than features, and treating craft as a strategic asset, not a downstream execution detail.
From cybersecurity to PEO benefits to SMB IT services, I work in high-trust, high-consideration categories where adoption depends on whether users can understand and believe the product before they fully use it.
I think in unit economics, pricing, and GTM motion alongside product specs. That's how 0→1 work actually ships, scales, and compounds revenue — rather than getting stuck as a proof of concept.
Technical feasibility is almost never the assumption most likely to kill adoption. Whether the user who matters most actually has the problem you think they have — usually is. I design the first weeks of any new product around stress-testing that assumption, not building the most demoable version.
In complex categories — cybersecurity, AI, B2B platforms — a product can work perfectly and still feel like nothing is happening. The product job isn't done until value is legible: visible enough to trust, specific enough to recommend, real enough to renew.
The most important design decisions aren't about color or polish. They're structural: what appears first, what's hidden, what's the default, what the system implies about how users should behave. These choices shape behavior before anyone reads a single word — and they're product strategy, not styling.
In early products, love is a more reliable signal than completeness. It tells you whether you've found something worth scaling — or just something that technically works. Minimum lovable, not minimum viable.
I build small AI prototypes to develop sharper product intuition — about where intelligence belongs in a workflow, how much autonomy a system should have, and what trust cues make AI products actually adopted instead of ignored.
Problem. Busy households cycle through the same few meals. Finding something new means hopping across Google, YouTube, Instagram, and ChatGPT — and none of them hold taste, mood, and constraints in one place.
Product bet. Search and video help once users know what to cook; chat can suggest ideas but is not visual, persistent, or personal enough to plan around. The opportunity is not a better recommender — it is collapsing recommendations, recipes, images, and video into one flow, so the idea and the means to act on it live together.
Built. Live app in ~20 hours using Cursor, Supabase, YouTube, Pixabay APIs, and Vercel.
Problem. Preparing for the day as a PM meant checking too many disconnected sources — news, blogs, competitor updates, email, Slack, and calendar — then manually deciding what mattered and how it connected to my weekly goals, personal priorities, and professional learning.
Product bet. The opportunity was not another summary tool or feed aggregator. It was a “so what” layer: an agent that could connect external signals, personal context, and daily commitments into a brief that explains what matters, why it matters, and how to make time for it.
Built. Built with Claude Code and run locally through LM Studio using Hugging Face / Qwen 9B.
Problem. [One-line problem statement.]
Product bet. [The product bet or reframe that came out of building it.]
Built. [What you built, how quickly, and with which tools.]
I write about product leadership and AI product building — particularly the parts the model-centric conversation misses: autonomy calibration, trust signals, stakeholder influence, and why technically accurate AI products still get ignored.
Based in Los Angeles. Open to Principal PM roles in large tech and Head of Product or Founding PM roles in startups.
Consumer · SaaS · Marketplaces · AI 0→1 · Onboarding · Monetization · Behavioral Product Design Master of Design, IIT Institute of Design
I've spent 13+ years building 0→1 products at the intersection of behavior, design, and commercial strategy. My work tends to live in categories where the right product form isn't obvious from the start — cybersecurity, SMB services, payments, marketplaces, AI — and where adoption depends on whether the product earns trust before it earns habit.
I think with a designer's instinct for how people actually behave, a GM's attention to unit economics and GTM, and a 0→1 PM's bias toward action under ambiguity. The combination is what's most useful when a team has the customer signal but hasn't figured out the product.
Outside of work I build furniture, ride motorcycles, and am slowly learning to make shoes.
Making things outside software has kept my product instincts honest. Each of these influences how I think about real product work.
I build furniture and shop infrastructure for my own garage — most recently a mobile tool cart that solved my own workflow friction. Working in wood teaches a different kind of product discipline: you can't hide behind abstraction. Sequencing, tolerance, ergonomics, and the actual repeated use of the object all show up immediately.
I'm slowly learning the craft of making shoes — a category where function, fit, identity, comfort, and feeling all sit on top of each other in a single object. It's a reminder that great products don't ask users to contort themselves into the product; they adapt to the human.
Riding shapes my taste for products that involve controlled complexity — where power is high, feedback matters, and trust is earned through small, predictable, repeated signals. Most of how I think about AI product design borrows from this.
A space held open for the next thing.