How I run product, from friction to measured outcome

The working method behind the delivery history: how problems get found, how the backlog is shaped and ranked, what “ready” and “done” mean, and how results are proven after release.

Start from the friction, not the feature

• Pull the evidence first: support ticket categories, ops handling time, funnel drop-offs and partner escalations.
• Interview the people doing the manual work — they already know where the product leaks.
• Write the problem statement and the success metric before any solution is discussed.

Turn the problem into a shaped backlog

• Use cases and functional flows drawn end-to-end across every team that touches the process.
• Slice into epics and stories with explicit acceptance criteria and non-goals.
• Rank by expected value: revenue unlocked, loss avoided, hours returned, risk removed.

Keep the cadence honest

• Two-week increments with a visible commitment; scope traded openly, never silently.
• Refinement, planning, stand-ups, review and retro — with engineering in the room from day one.
• Blockers escalated same day; dependencies tracked as first-class backlog items.

Ship, then prove it worked

• Baseline captured before release, re-read 30 days after.
• If the metric did not move, the story is not done — it goes back into the backlog.
• Results reported to leadership in the same language as the business case.