My Product Development Framework
How I move from user evidence to shipped work: discover the problem, design and test the answer, build with measurement in place, then use the results to decide what happens next.
The framework, end to end
Discover → Design & Validate → Build & Iterate → Measure. Cross-functional collaboration and data are the connective tissue at every stage.
Insight → value, on a repeatable cadence
Most product orgs don't fail at any single step — they fail at the handoffs. Discovery insights die in the gap between research and design; design intent gets diluted in engineering; experiments ship without instrumentation; learnings never feed the next quarter's plan. This framework is what I use to keep the loop closed.
It is opinionated but not rigid. The four phases stay constant; the tools and tempo change with the team's maturity, the risk profile of the bet, and the velocity you can sustainably hit.
The four phases
Discover — Empathize, Define, Research, Analyze
Deeply understand user needs through research and data. Tools I reach for: interviews and surveys, Google Analytics, Power BI, SQL, Hotjar, FullStory, SurveyMonkey, competitive analysis. The output of this phase is a clearly defined problem — not a feature list.Design & Validate — Ideate, Prototype, Test, Gather Feedback
Build and test solutions quickly to validate assumptions before writing production code. Wireframing and prototyping in Figma / UXPin, qualitative user testing, and A/B testing on Optimizely or in-house experimentation platforms (Launchpad). The point is to learn fast, not to ship pretty.Build & Iterate — Build, Measure, Feedback, Learn, Prioritize
Cross-functional execution on Agile / Scrum or Kanban with Jira or Azure DevOps. Instrumentation is part of the definition of done — if a feature ships without a way to measure it, it didn't ship. The team's job is to learn from what shipped, not just to ship the next thing.Measure — KPIs & OKRs
Conversion rate, engagement, retention, revenue — measured against pre-committed hypotheses, not retrofitted narratives. OKRs at the org level, KPIs at the surface level. Misses are debriefed publicly; that's how the framework gets sharper.
Five operating principles
User-Centered Discovery
Start with user needs, research, and data. The goal is to define the real problem before anyone draws a wireframe.Rapid Prototyping & Iteration
Build and test solutions quickly to validate assumptions and gather real user feedback. This is how we learn at high speed and avoid expensive misses.Cross-Functional Collaboration
Keep product, engineering, design, and marketing close enough that work does not become a relay race.Continuous Feedback & Measurement
Build feedback loops and track the key metrics from the start, so the team can see what changed after launch.Security & Privacy by Design
Build trust by integrating security and privacy from day one. Protecting user data is a non-negotiable part of the process — not a compliance step at the end.
Discovery insights die in the gap between research and design. Design intent gets diluted in engineering. Experiments ship without instrumentation. This framework exists to close those gaps.
Adapting to team and risk
On a small team with low-risk surface area, “Discover” can be a 2-day exercise and “Validate” can be one usability session plus one A/B test. On a $5B platform with payment-flow blast radius, the same loop runs over weeks with multi-arm tests, statistical guardrails, and gradual rollouts.
The discipline is the same; the dosage is what changes. The teams I've led that stuck to the loop — even when leadership wanted to skip Discover and ship — were the teams that compounded learnings quarter over quarter.
Want to talk through this work?
If this maps to a problem you’re hiring for, I’m happy to walk through the decisions behind it — including the ones I’d make differently now.