My product process
Nested, non-linear loops driven by business impact
This isn't a framework I read somewhere. It's how I actually work — mapped after years of noticing what held up under real constraints and what didn't.
The loop
Product isn't just about getting to delivery — it's about making sure what you're building can survive contact with reality, both technically and operationally.
Writing
Short write-ups on how I think about product, systems, and delivery. I share summaries on LinkedIn; the full versions live here.
-
Nov 2, 2026
The Box Is Home
If we want agents to take risks, the box can't be a cage — it has to be a home they'll come back to.
-
Oct 27, 2026
Don't Let Your AI Think It's in Squid Game
Nearly 700 AI agents broke out of a test and hacked a real company. The problem isn't the agents — it's the game we put them in.
-
Why Delivery Has to Start in Discovery
Good ideas usually fall apart where discovery hands off to delivery. Pulling delivery thinking forward is the fix.
-
The Moment Product Stops Being Features
A feature solves a problem once. A system solves a class of problems repeatedly. Here is how to tell when you've crossed that line.
-
Why I Never Had a Clean "Product Process" Answer
For most of my career my honest answer was "it depends." Mapping how I actually work turned out to be a set of overlapping loops.
How I think
Where most product work breaks
The gap between a good idea and a real system. That's where constraints show up, edge cases multiply, and delivery gets messy. That gap is where I spend most of my time.
A feature solves a problem once. A system solves a class of problems repeatedly.
The shift happens when edge cases pile up, manual work increases, and behavior becomes unpredictable — the point where you're no longer building features, you're designing a system.
Read the full post →Delivery has to start in discovery
I stopped treating delivery as something that happens after discovery, because that's usually where good ideas fall apart. Pulling delivery thinking forward keeps you from designing things that can't survive real-world constraints.
Read the full post →I don't memorize — I map
From early math to relational database design, I kept noticing the same thing: everything connects if you're looking for structure. I'm almost always running a parallel thread asking how things connect, where they break, and whether they're efficient. That applies to systems, workflows, and everyday decisions.
Product has no single truth
Product isn't an objective discipline — it's a collection of perspectives. Most people are reacting to one slice — discovery, delivery, growth, UX — and presenting it as the whole. That realization changed how I work: I don't follow a single approach, I connect multiple perspectives at once.
Product is like the sun. Everyone is reacting to it, but most people only see one ray.
How this thinking has evolved