Measure before you build
How I approach strategy for early-stage products now: decide what success looks like first, track only what earns its place, and launch one side of the problem at a time.
Where I am
In July 2026 I moved from delivery into strategy. I’m now Product Strategy Manager at a Dublin venture studio, working on several products at very different stages, from pre-launch to live. The work changed from “ship it” to “is this worth shipping, and how will we know?”
How I work now
- KPIs that change with the stage. A product three weeks old shouldn’t be judged on the same numbers as one three years old. I set out what success means in the first months, the next few, and later on, so a week of early data gets compared with early goals.
- Tracking plans built backwards. I start from the one dashboard leadership will actually read, then list only the events that dashboard needs. Each event has to justify its cost. You see the whole journey without paying for noise.
- Talk to people before you instrument. For a very early product, a few good conversations with real users tell you more than tracking on a product with no traffic yet.
- Sequence the launch. When a product serves more than one kind of user, choose who comes first. That one choice shapes the KPIs, the growth ideas worth trying, and what the team builds next.
- Specs a team can build from. I turn a business goal into feature requirements specific enough that engineering can start without a week of questions.
- One page a week for leadership. I write a short weekly performance report that says what moved and what we do next.
What I’m learning
- Decide how you’ll measure success before you decide what to build. It changes the roadmap more than any feature idea.
- Saying no is most of the job. A good plan is mostly the things that didn’t make it in.
- Delivery experience is an unfair advantage. Knowing what’s hard to build keeps strategy honest.
Want the longer version? I’m happy to walk you through it.
Email me