Product Manager with a builder's background.
Before product, I built software. Now I use that to ask sharper questions, make faster tradeoffs, and turn ambiguous problems into decisions worth shipping.
What I care about
The product work that gets me excited
Product Strategy
Finding the right problem to solve before building the solution
AI Products
Knowing when AI earns its place in a workflow and when it's the wrong tool for the job.
User Discovery
What people actually do tells you more than what they say they want
Experimentation
Letting data settle arguments opinions can't.
Technical PM
Understanding engineering constraints to make better product decisions
Trust & Responsible AI
Earning autonomy with data, not assuming it.
Product Skills Backed by Technical Execution
I think like a PM and build like an engineer. That combination shows up in how I frame problems, prioritize under constraints, and bridge product vision with technical reality.
Product Strategy & Execution
How I frame problems and ship solutions
Product Analytics & Growth
How I measure what matters
AI & Technical Tools
How I build and understand constraints
Why the technical background matters: I've shipped production code, debugged backend APIs, and optimized build pipelines. That means I know when "it's technically impossible" is real vs. when it's "this will take more effort than planned." I speak both PRD language and engineering constraint language which means I can bridge product vision with what's actually shippable.
Projects & case studies
Product work demonstrating discovery, strategy, prioritization, and execution. Each project shows different PM competencies applied to real problems.
LinkedIn Job Navigator
Early-career job seekers can't filter signal from noise.
Relevance over Volume
Decided to focus on relevance over volume — helping users see fewer, better-fit roles instead of thousands of irrelevant listings.
Notion AI Foresight
Notion AI helps you write about work, but cannot tell if it is on track.
Writing Assistant
Delivery Foresight
Notion's advantage isn't out-integrating competitors—it's reasoning over content it already owns to surface delivery risk before it becomes a crisis.
FeedbackLens
Product teams drown in feedback but can't find patterns.
500+ pieces → 12 themes
Pattern detection at scaleBuilt an NLP-powered tool that groups feedback by theme instead of forcing PMs to read everything manually.
Pricing in the Dark
Replit's AI Agent billed users $1K/week with no way to predict costs before tasks ran.
Diagnosed that Replit didn't lose users because AI is expensive — they lost trust because cost was unknowable in advance and disconnected from whether tasks succeeded.
WHOOP: Users Hacking Their Own Bodies Back
WHOOP's users are reverse-engineering their own hardware to own their data
Data as leverage
Insight as value
Three trust failures in three years isn't bad luck—it's what happens when business model (subscription lock-in) fights brand promise (data ownership). Diagnosed the missing structural checkpoint.
Faster, Not Clearer
Coinbase cut restriction review times by 90% but users still don't know why their accounts are locked
Diagnosed that Coinbase solved the wrong layer: invested in processing speed when the documented failure was communication. Users aren't told which queue they're in, how long it takes, or what's blocking them—but Coinbase already knows all of this internally.
Product management portfolio showcasing user research, product strategy, prioritization frameworks, MVP development, experimentation, and AI product thinking.
My product process
Product management is about making good decisions with incomplete information. Here's how I approach it.
Discovery
Before a solution, I want the real problem not the one that is easiest to assume. That means talking to users directly, checking what the data actually shows, and resisting the urge to skip straight to building.
Define
A vague problem gets you a confident answer to the wrong question. What are we actually solving, for whom, and why now? Get this wrong, and no amount of good execution saves you later.
Prioritize
Prioritization is not picking what to do it is committing to what you wont. The things I chose not to build say as much about my judgment as the things I shipped.
Build
I would rather ship something small and find out I was wrong in a week than spend a quarter building something polished and wrong. Working with engineering means finding the smallest version that actually teaches us something.
Measure
Define success criteria upfront. Track what matters. Use data to inform the next decision, not just to justify what we already did.
Iterate
Use what you learned to improve. Double down on what works, cut what doesn't, and stay open to changing direction when the data says so.
This isn't a rigid framework - it's how I think about moving from ambiguity to action. Real product work is messier, and that's okay.
Why my engineering background matters
I don't outsource my technical judgment. When feasibility comes up, I can usually see the reasoning myself, which means I push back on the right things, and don't waste a fight on the wrong ones.
Understand technical constraints
I can tell the difference between technically hard and technically impossible, and that distinction changes what even makes it onto a roadmap.
Prototype product ideas
I can mock up or build a working prototype myself to test an assumption, instead of waiting on engineering time to find out if an idea holds up.
Evaluate AI capabilities
I've built with AI/ML directly, so I know where it's genuinely useful and where it quietly fails, which keeps roadmaps from overpromising what a model can actually do.
Make realistic MVP decisions
Scoping an MVP isn't just deciding what matters most — it's knowing what each piece actually costs to build, so the cut line is realistic instead of aspirational.
The advantage: The advantage isn't fluency in one language, it's being able to move between product, design, and engineering without losing anything in translation. A designer's proposal the data model can't actually support, an estimate that assumes more complexity than the problem has, I catch these before they cost a sprint.
Experience
Engineering experience that shaped how I think about product
Software Development Engineering Intern
BlackCoffer
- •
Redesigned enterprise onboarding workflows by integrating sequential backend APIs, reducing execution failures by 35% and resolving user drop-offs
- •
Optimized Gradle and Android runtime performance, cutting build times by 20% to accelerate feature release cycles for product teams
→ Backend integration and build optimization directly impact how fast product teams can ship. Technical decisions create or remove bottlenecks for the entire delivery pipeline.
Full Stack Developer Intern
Jabsz Gaming Studio
- •
Identified user needs for an AI smart farming platform and translated them into a prioritized feature set integrating weather data, LLM chatbot, and price forecasting, improving decision efficiency by 35%
- •
Designed a 3-tier difficulty engine across 12+ web games based on user retention patterns, boosting average session duration by 18%
→ User engagement comes from understanding behavior patterns, not just building features. Retention data tells you what to prioritize when intuition does not.
Product Management Intern
Zesframe
- •
Led client discovery to understand business needs and translate them into PRDs, user stories, MVP scope, and delivery plans, giving engineering clear requirements to execute against
- •
Shaped roadmap and scope decisions by weighing client priorities, user impact, technical feasibility, and engineering capacity, keeping delivery focused on the highest-value requirements
- •
Managed client acceptance and post-launch iterations by combining stakeholder feedback with product telemetry to identify UX bottlenecks and drive improvements that increased website load and response performance by approximately 30%
→ Product management is about making trade-offs visible. Understanding both user needs and technical constraints helps you ship the right solution, not just any solution.
What I'm thinking about
Open questions I'm working through right now, in my projects and beyond them.
AI-native workflows
How products should be designed differently when AI is the foundation, not a feature
Human-AI interaction
Designing interfaces where AI augments rather than replaces human judgment
Building for developers
What makes developer tools successful and how to prioritize for technical users
These aren't just buzzwords. They're real questions I'm working through in my projects and thinking
Why I'm moving from
engineering to product
I started as a builder
I studied computer science with AI/ML, and wrote a lot of code. But the more I built, the more I realized the hardest part wasn't the implementation, it was figuring out what to build in the first place.
I discovered product thinking
That question — what's actually worth building, turned out to be the more interesting one. It's what pulled me toward product: understanding a problem well enough to know it's the right one, before writing a single line of code to solve it. My technical background hasn't gone away, it just moved from something I do to something I bring to the decisions I make.
Now I'm seeking opportunity
I'm looking for a product role where I can learn from PMs who've done this longer than I have, ship things that reach real users, and build the instincts that only come from doing the work not just studying it.
Everything here reflects real thinking and honest constraints. Where I don't have data, I say so. Where projects are speculative, they're labeled as such.
On honesty and evidence
Have a product problem worth thinking about?
I'd genuinely like to hear it, whether that's a role, a hard problem you're stuck on, or just a conversation about how you're thinking through something.