For most of my career, I never had a clean answer to the question:
“What’s your product process?”
Not because I didn’t have one — but because every situation felt different.
Different stakeholders.
Different systems.
Different constraints.
So my honest answer was always… “it depends.”
Recently, I forced myself to actually map how I really operate.
What came out wasn’t a linear process — it was a set of overlapping loops:
• Identify real problems (not just requests)
• Frame and pressure-test them from multiple angles
• Architect solutions that actually hold up technically
• Orchestrate delivery in a way that can ship incrementally
• Validate based on real-world impact, not assumptions
And the key realization:
I’m not moving step-by-step — I’m constantly working across all of these at once.
The biggest thing I’ve learned is that 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.
Still refining how to visualize this (turns out translating your own thinking is harder than building systems 😄), but this exercise alone helped me clarify where I actually add value.
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
- behavior becomes unpredictable
That’s when you’re no longer building features — you’re designing a system.
One of the biggest shifts in how I work: 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 will actually be built
- how it integrates into existing systems
- how it can be sequenced and shipped incrementally
…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 I’m constantly asking:
“Could we actually ship this?”
“What breaks when this hits production?”
“What’s the smallest version of this that creates value?”
That shift alone has probably saved more time than any process improvement I’ve made.