Different moments in a product’s life call for different kinds of leadership.
From the outside, it might look like I’m playing the same role throughout a project. In reality, my role as a product strategist changes shape pretty dramatically from the early days of discovery to launch week. That evolution is intentional.
Early weeks: defining the real problem
At the start of a product project, my focus is on problem definition.
Clients often come in with a sense of what they want to build, or at least a rough idea of the deliverable. What’s usually less clear is the underlying problem that product is meant to solve. This phase is about getting clarity there.
I spend time talking with stakeholders across the organization, doing market and desk research, and running early exploratory user interviews. I’m looking for patterns, tensions, and signals that help us sharpen what really matters. The goal isn’t to define every problem, but to identify the ones that are actually worth solving.
Vision: opening up the possibility space
Once we have clarity on the problem, the work shifts into product vision.
This is where we start imagining what the future of the product could be. We explore different concepts, test value propositions, and pressure-test ideas with both users and the business.
On a project with Vogue, for example, we developed multiple product concepts early and put them in front of focus groups. Seeing what people were genuinely drawn to helped us narrow the field and shape a vision that was both ambitious and grounded. In this phase, my role is about helping the team explore without committing too early, while still moving toward a clear direction everyone can align around.
MVP and roadmap: narrowing and committing
Once a product vision is aligned on, the questions become more concrete. What does this actually look like as an MVP? What needs to come first? What is foundational, and what is differentiating?
I usually lead roadmapping and early feature definition here, helping the team translate vision into a sequence of decisions. This is also where we start pressure-testing choices against business goals. What will actually move the needle now? What can wait? The goal isn’t to lock everything down, but to commit to a path that turns vision into something buildable.
Build: where strategy gets exercised
The build phase is my favorite part of a project.
This is where product strategy stops being abstract and starts showing up in daily decisions. Every day, the team is confronted with questions that test the direction we set earlier. What do we stick to? Where do we adapt? How do we balance quality, scope, and speed? A lot of this work is about de-risking decisions before they become expensive to change.
Lightweight user feedback plays a big role here. On McKinsey’s Global Data Explorer, for example, we ran bi-weekly user testing throughout the build. The product was complex, and regular feedback helped us catch issues early and make clearer decisions faster. It never slowed the team down. It helped us focus. During build, my role is less about big presentations and more about constant shaping, prioritizing, and facilitating decisions across the team.
Launch week: pausing before what comes next
By the time launch week arrives, most of the heavy product decision-making has already happened. We’ve QA’d relentlessly. We’ve pressure-tested assumptions. We’ve made tradeoffs consciously. Launch week is the moment when something real finally goes into the world, whether that’s an app or a website. It’s thrilling. It never gets old.
Of course, launch only the beginning of the work. Products evolve once real people start using them. They get iterated on, improved, and sometimes rethought entirely.
But launch is still an important moment. It’s a pause. A chance to reflect on the decisions that shaped the product and the work it took to get there. Before attention shifts to what’s next, it’s worth recognizing what now exists in the world that didn’t before.
From early discovery to launch, my role evolves from problem framer to editor of possibilities to facilitator of decisions. That evolution is what allows product work to move forward with clarity and confidence. Good product leadership isn’t about playing one role well. It’s about knowing which role the moment requires.
