Product Leadership Consulting

What we work on

Product leadership isn't slide decks—it's decisions your engineering team can actually ship, with quality and scale built in from the start.

• Roadmap and backlog governance that survives executive pressure
• AI integration strategy—with execution partners like Aarohii AI when you need build capacity
• Technical due diligence for investors and acquirers
• Monthly advisory retainer for founders and product leaders who need a second brain

How the engagement runs

Discovery first, always—because most product problems brought to me as roadmap problems turn out to be unnamed assumptions.

Weeks 1–2 — Risk mapping. We write down the one or two assumptions that, if wrong, mean the initiative doesn't work. Usually distribution, compliance, or unit economics—rarely the UI everyone wants to discuss. Output: a named risk list and the evidence needed to close each one.

Weeks 3–4 — Time-boxed spikes. Each open risk gets a one-week spike with pass/fail criteria written before the spike starts. Spikes without criteria become zombie projects, so this constraint is non-negotiable.

Weeks 5–8 — Roadmap and governance. A sequenced roadmap you can defend to a board, with prioritisation logic your team can re-run without me (RICE or weighted scoring, chosen to fit how you actually decide). Plus the part most roadmaps skip: observability, on-call ownership, and quality gates for what you're about to build.

Ongoing — Advisory. Most teams move onto a monthly retainer here, using me for design reviews, hiring calls, and the decisions that are hard to make alone.

What you actually get

• A written risk register naming the assumptions that could kill the initiative
• Spike results with explicit pass/fail outcomes—including the "we're not building this" decisions
• A sequenced roadmap with prioritisation logic your team can re-run
• Backlog governance that survives executive pressure
• AI integration strategy with QA guardrails and evaluation criteria defined before launch
• Ownership and on-call model agreed with any delivery partners before the contract is signed
• Technical due diligence packs when you're raising or being acquired

Who this is for

Teams integrating AI into existing products, startups preparing for enterprise customers or funding, and leaders who need someone who speaks both product and engineering fluently. Typically founder-led SaaS between seed and Series B, where the founder is still the de facto head of product and the roadmap has quietly become a political document.

Who this isn't for: teams that want slide decks rather than decisions, organisations where the roadmap is already fixed and the engagement is really about validating it, and anyone unwilling to kill a feature the team is attached to.

A recent example

A SaaS team was three weeks from starting build on a feature 38% of surveyed users had asked for. Discovery surfaced the assumption nobody had written down: that the feature would grow usage across the base. Usage data said the opposite—it would pull engineering capacity away from the 15% of power users generating roughly 70% of ARR.

We killed it. The CEO hated the decision for about a month. Two quarters later, that reallocated capacity had moved those power users into enterprise contracts. The most valuable output of that engagement was a feature that never got built.

Engagement model & investment

• Discovery sprint (2–4 weeks). Risk mapping and spikes, ending in a go / no-go you can defend with evidence.
• Full product engagement (8 weeks). Discovery through roadmap and governance handoff.
• Monthly advisory retainer. A second brain for founders and product leaders—design reviews, prioritisation calls, escalations.
• Technical due diligence (fixed scope). For investors and acquirers who need an independent read on a product and its engineering reality.

Fixed scope, fixed fee, agreed before we start. Indicative ranges come on the discovery call once I understand the shape of the problem. Three to four clients at a time, maximum.

Common questions

Do you write the roadmap for us? I write the first one with you, and leave you the prioritisation logic so the second one is yours. A roadmap you can't defend without the consultant in the room isn't a roadmap.

Can you help us evaluate an AI feature before we commit? That's a common starting point. The question is usually whether it's testable and supportable, not whether it's technically possible—see building a test pyramid that survives AI features.

What if discovery says don't build it? That's a successful engagement. It's also the cheapest quarter you'll ever spend. More on that in product discovery for founder-led SaaS.