Data as a tool, not a crutch
Data tells you what is happening. It rarely tells you why. I use quantitative data to identify the problem and prioritize urgency, and qualitative data (interviews, usability tests, support tickets) to understand the cause. The best product decisions combine both.
North Star and supporting metrics
Every product I work on has one North Star metric that captures the core value exchange. Around it I build a metrics tree: 2-3 input metrics per level that drive the North Star, down to team-level leading indicators. This prevents metric proliferation and keeps every team connected to outcomes.
Growth loops, not funnels
I think in growth loops: acquisition → activation → retention → referral → revenue, each feeding the next. For each loop I identify the weakest link and concentrate experimentation there. A 10% improvement in retention typically has 5× the impact of a 10% improvement in acquisition.
Instrumenting for insight
I write the analytics spec before features go to engineering. Every event has a name, properties, trigger, and business question it answers. Without this, teams ship features they can't measure - which means they can't learn from them.
Real example
At Hakuhodo I-Studio, I defined KPIs and a measurement framework for the Pechat IoT product from day one. By tracking activation rate (pairing within 24h), engagement (sessions per week), and retention (D7/D30), we identified that users who completed a specific onboarding step had 3× better D30 retention - which became a core focus of the next product cycle.