Product Roadmap Strategy & Discovery

Product strategy consulting that turns goals into a sequence you can actually deliver.

As a product strategy consultant, I define the outcomes, break them into initiatives, and sequence them against real capacity. A roadmap that ignores what the team can ship is a wish list. I’d rather agree what we’re not doing this quarter.

When you need this

You have more requests than capacity and no defensible way to choose between them. The roadmap is a list of features with quarters attached, written by whoever argued hardest. Sales promises dates engineering hasn't seen. Nobody can say what the next three months are meant to achieve, only what they'll contain. The symptom that matters most: when someone asks why a thing is on the list, the honest answer is that a customer asked for it.

How I run it

I start with the outcome, not the feature. What has to be different for the business in six months, and how would we know. Then I work backwards into initiatives, and only then into things to build.

I audit what's already committed and separate the promises from the plans. Most roadmaps carry a few items that exist purely because they were mentioned once in a board meeting.

Sequencing comes next, against real capacity rather than optimistic capacity. I'd rather agree what we are not doing this quarter than pretend everything fits.

Finally I write down the assumptions each bet rests on, so when one turns out to be wrong the decision can be revisited rather than relitigated from zero.

What you get

  • An outcome-led roadmap, sequenced against actual team capacity
  • A written “not now” list, with the reasoning for each
  • The assumptions behind each major bet, stated plainly
  • A prioritisation method the team can run without me

How the work runs

Usually two to four weeks. It works best as a short intensive rather than a standing commitment — the value is in forcing the decisions, not in attending the meetings afterwards.

Common questions

Is this the same as product management?

It overlaps heavily. Prioritising and designing stop being separate jobs once you're deciding what to build rather than how it looks. If you have a strong PM already, I work alongside them rather than replacing the function.

What if we don't have research to base it on?

Then that's the first finding. I'll say so rather than sequencing a roadmap on guesses, and we'd usually run a short discovery first.

Will you write tickets?

I'll break initiatives into shippable increments. Estimation and sprint mechanics stay with your team, who know their own velocity.

See the work behind this
Tell me what you’re building. I’ll tell you if I can help.
Email me →