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. It is also the connective tissue between my enterprise platform work, startup work, and creative discipline.
The loop
01 — Identify
What's actually worth solving
Separating real problems from requests and noise. Most things that come in as feature asks are symptoms.
02 — Evaluate
What holds up under pressure
Pressure-testing from multiple angles — business, technical, operational — before committing direction.
03 — Design
What can work as a system
Not just what solves this problem once, but what solves this class of problems repeatedly.
04 — Deliver
What we can actually ship
Sequenced incrementally so value ships before the full system is built. Delivery thinking starts in discovery.
05 — Validate
What proves itself in reality
Based on real-world impact, not assumptions. The loop restarts from what we learn here.
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.
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 usually happens when edge cases pile up, manual work increases, and behavior becomes unpredictable. That's when you're no longer building features — you're designing a system.
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. A solution can look great on paper — clear problem, strong logic, aligned stakeholders — but if you haven't pressure-tested how it ships, it's still fragile.
Now I pull delivery thinking into discovery early. Not to slow things down, but to avoid designing things that can't survive real-world constraints. In practice this means constantly asking:
- Could we actually ship this?
- What breaks when this hits production?
- What's the smallest version of this that creates value?
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, art, 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