Product Discovery & Decision Making
My approach to understanding complex product problems through customer discovery, structured thinking and evidence-based decision making.
I spend most of my time understanding the problem before defining the solution. Discovery is not a phase — it is a habit. I talk to users until the patterns repeat, map the current workflow in detail, and look for the gap between what people say and what they do. The best product ideas usually come from watching someone work around a broken system, not from asking what they want.
Research is only useful when it changes a decision. I design research to answer specific questions, not to collect general insights. I mix methods — interviews, diary studies, funnel analysis, shadowing — depending on what I need to validate. I share raw quotes and video clips with the team because nothing builds empathy faster than hearing the actual words.
I treat engineers as creative partners, not implementers. I bring them into discovery early, share context on constraints and trade-offs, and write requirements that explain the why, not just the what. The best products I have shipped came from teams where engineers felt ownership over the user outcome, not just the technical delivery.
Everything cannot be important. I use frameworks lightly — they are scaffolding, not architecture. The real work is understanding what moves the outcome, what unlocks the team, and what removes risk. I prefer small bets with clear validation criteria over large initiatives with ambiguous success metrics.
Good decisions come from clear thinking under uncertainty, not from having perfect data. I document the assumptions behind every major decision, define what would prove me wrong, and set review points before committing further. Being wrong is fine; staying wrong is expensive.
These are the principles I return to when the path is unclear:
- —Start with the user, not the feature
- —Ship to learn, not to finish
- —Measure what matters, not what is easy
- —Simple is hard; complexity is the default
- —Trust is built through consistency, not promises
I assume I am wrong until evidence says otherwise. Every assumption gets a test — a prototype, a conversation, a data query. The goal is not to prove the idea works; it is to find the failure modes early, when they are cheap to fix.
Across B2B, B2C, marketplaces and AI products, a few patterns keep repeating:
- —The problem is rarely what users first describe
- —The best teams argue about the right things
- —Speed comes from clarity, not from rushing
- —AI products need evaluation infrastructure before they need more features
- —Internal products need real product management too