Why this exists

Bill Walsh said, “focus on the inputs and the score takes care of itself.” This is my personal operating manual: what I hold myself to as a Product Leader. It clarifies the mission, the inputs, and how I hold the bar — so teams know exactly what “good” looks like and stakeholders know what to expect. I run both product development and ops teamsfrom tech support to back office—because building great products means nothing if service, processes, and execution don’t keep up.

What I Do (in this order)

1)Build The Right Thing

• Clear POV, not guesswork, reactionary requests or competitor parity: Frame the strategy, spot the big forces reshaping the playground, and identify the 30% that will drive 80% of the impact.
• Two gaps, one roadmap: Close the performance gap (today’s problem) while investing in the opportunity gap (tomorrow’s growth bets & defensibility).
• Direct exposure > second-hand opinions: Live in the product, keep a friction log, and run weekly customer hours (top users, prospects, and “lost deals”).
• Decisions with context: Write a crisp opportunity matrix, success metrics, and “non-negotiables” before we invest.

2)Build It Right

• Taste + evidence: Pair qualitative judgement with the right data (diagnostic > vanity). Be opinionated; A/B tests optimise; vision decides.
• Start scrappy: build rough, hands on solutions — quick, dirty prototypes to test hypotheses and feel the edges of the problem. Pair qualitative judgement with data that diagnoses root causes, not vanity metrics. Vision makes the call, data sharpens it.
• Understand constraints of systems (security, performance, APIs, pipelines) and operational realities (capacity, training, compliance). Make trade-offs that stick across both.

3)Build it Fast — without cutting the soul

• Milestones ≤ 2 weeks; Visible progress, fast feedback, momentum as a team sport.
• Scope with spine, the the core job-to-be-done and customer value must be protected; if we cut, we cut smart.
• Tidy as we go: “Fit & Finish” gets scheduled, not wished for. Bugs triaged by customer impact, revenue risk, and trust.

Holding the Bar (where I’m uncompromising)

• Product jams & Ops Reviews: Are we thinking ambitiously enough? Is the PRD unambiguous? What would make this delightfully inevitable?
• Design reviews: Whole flows, multiple explorations, real copy, hands-on trials. I’ll nit-pick margins and call out conceptual leaps.
• Product reviews: I drive “try it live” demos. I check copy, states, latency, empty states, and instrumentation. Notes become tickets; tickets become shipped fixes.
• Ops playbacks: Weekly reviews of support tickets, SLAs, and exception cases. We don’t just fix symptoms; we close loops at the root cause.
• Speed rituals: Short huddles over long threads, decisions documented once in the project source-of-truth, reminders for every open loop.
• Customer proximity: Minimum exposure hours per quarter for me and my team. If we haven’t watched real users this week, we’re guessing.
• Systems thinking: Standardise processes, automate the repetitive, and build visibility (dashboards, SLAs, alerts) so both product and ops scale cleanly.