product manager
I build the thing, then write down why it worked.
six short case studies on real products. the problem they faced, the bet they made, what shipped, and what I'd have pushed back on.
god is in the details
Nobody hires a PM to care about how a cursor looks when you hover a card. That's not on any job description I've ever seen. But it's the kind of thing I genuinely enjoy getting right.
I spent real time on this exact site working through a circle that's 18 pixels instead of 12, whether it should grow on hover or just change color, and whether opening a panel should feel like reading or like adjusting a dial. Not because anyone asked. Because getting that one detail right is what makes the next one easier to get right too, and a few hundred of those decisions later, the whole thing feels inevitable instead of assembled.
That's the part of the job that doesn't show up in a roadmap review. Nobody puts "cursor felt orienting" on a PRD. But it's the same instinct as writing an error message that tells someone what actually broke instead of "something went wrong," or noticing a metric everyone's celebrating doesn't quite match what users are actually doing. It's not about having good taste. It's about paying attention long enough that the small things stack into something that feels finished, not just shipped.
I've worked across ad systems, internal platform tools, and customer-facing flows, in roles that ranged from writing the code to owning the roadmap. The thread through all of it is the same one: the products I'm proudest of got there because somebody kept sweating the parts nobody would've noticed if they'd been wrong.
That's the actual pitch. Not a big swing, just a lot of small ones that all land.
product manager
six short case studies on real products. the problem they faced, the bet they made, what shipped, and what I'd have pushed back on.