Ravi Mehta on the Product Strategy Stack, Twelve PM Competencies, and Selective Micromanagement

Key ideas

1. The Product Strategy Stack orders five layers from mission to goals. Mission → company strategy → product strategy → roadmap → goals. Each layer constrains the one below. Most product teams build the stack in the wrong order — setting goals before a roadmap makes goals meaningless.

2. Goals go after the roadmap, not before. The conventional wisdom is to start with goals and derive work from them. Mehta inverts this: you must know what you are going to build (roadmap) before you can set honest goals. Goals set without a roadmap are guesses.

3. Velocity and latency are different productivity axes. Velocity is quantity of work shipped per unit time; latency is the time from idea to first test. Startups have low latency (days to validate an idea) but low velocity. Large companies have high velocity but high latency (months from idea to test). The distinction matters when diagnosing why a team feels stuck.

4. Twelve PM competencies span four quadrants: product execution, customer insight, product strategy, and leadership. Each quadrant contains three competencies. Knowing where you are strong and weak lets a PM choose roles that fit their profile and develop deliberately in weak areas.

5. Selective micromanagement is a legitimate tool when used intentionally. Three stances exist: micro-mismanagement (low trust, high interference), scalable leadership (high trust, high delegation), and selective micromanagement (context-dependent, temporary deep involvement). The third is appropriate when a project is high-stakes, when the team is new, or when something is going wrong.

Summary

Ravi Mehta was CPO at Tinder, Product Director at Facebook, and VP Product at Tripadvisor. He is now co-founder and CEO of Outpace, a coaching and career development platform for product managers.

This conversation centres on the frameworks Mehta uses and teaches: the Product Strategy Stack, the twelve PM competency model, and the distinction between velocity and latency. He also discusses goal-setting, feedback delivery, and when a manager should override delegation with hands-on involvement.

See also: Product Strategy Stack, Ravi Mehta

The Product Strategy Stack

See Product Strategy Stack for the full framework.

The five layers:

1. Mission — why the company exists; changes rarely.
2. Company strategy — how the company wins in its market; directional.
3. Product strategy — the bets the product team is making to advance company strategy; where the PM has the most leverage.
4. Roadmap — the concrete plan of work over a defined horizon.
5. Goals — the measurable outcomes the roadmap is intended to produce.

The key insight is the ordering: goals are derived from the roadmap, not the other way round. Setting OKRs before defining the roadmap produces goals that are either trivially achievable or untethered from the work actually being done.

Velocity vs latency

Two dimensions of team productivity that are often conflated:

• Velocity: how much the team ships per sprint or quarter. Large teams with mature tooling have high velocity.
• Latency: how long it takes from forming a hypothesis to getting data on whether it is right. Startups can validate in days; enterprises often take months.

A team with high velocity but high latency ships a lot but learns slowly. A team with low velocity but low latency ships little but learns fast. The ideal depends on the company stage. The diagnostic question: when was the last time we ran an experiment that surprised us?

The twelve PM competencies

Four quadrants, each with three competencies:

Product execution

• Specification writing
• Delivery (shipping on time, managing scope)
• Quality (bugs, polish, reliability)

Customer insight

• Data fluency (reading metrics, running analysis)
• Voice of customer (qualitative research, interviews)
• UX design intuition (working with designers, visual and interaction judgement)

Product strategy

• Business outcomes (connecting product to revenue, growth, or market position)
• Vision and roadmap (articulating a long horizon and sequencing toward it)
• Strategic impact (influence beyond your team — org-wide bets, cross-functional leadership)

Leadership

• Stakeholder inclusion (keeping executives and partners informed and aligned)
• Team leadership (managing down; developing the team around you)
• Managing up (influencing without authority; working effectively with executives)

Mehta argues that most PMs are uneven across these twelve and that self-assessment against the grid is a useful diagnostic for career development. Outpace operationalises this model.

Selective micromanagement

Mehta describes three management modes:

• Micro-mismanagement: chronic interference driven by distrust. Demoralises the team and slows delivery.
• Scalable leadership: deliberate delegation to capable people with clear goals. The standard aspiration.
• Selective micromanagement: intentional, temporary deep involvement in a specific area. Appropriate when the project is unusually high-stakes, when the team is newly formed, or when something has gone off-track.

The distinction between micro-mismanagement and selective micromanagement is intent and transparency. Selective micromanagement is announced: ‘I’m going to be very hands-on with this project for the next six weeks.’ It is time-bounded and exit-planned.

Frontier-of-understanding goal types

Mehta categorises goals by the primary risk they are managing:

• Understanding risk: we do not yet know if this is the right problem or the right solution.
• Dependency risk: we know what to build but cannot build it without something external.
• Execution risk: we know what to build and can build it; the question is whether we will deliver.
• Strategic risk: we are building the right thing, but we may be outmanoeuvred by competitors or market shifts.

Setting goals well requires identifying which risk is live for a given initiative. A metric that resolves execution risk does not resolve understanding risk.

Exponential feedback

Mehta’s principle: give feedback at the root cause rather than at the symptom. If a PM consistently ships late, the surface feedback is ‘ship on time.’ The root-cause feedback — on prioritisation behaviour, estimation calibration, or stakeholder management — compounds over time. Symptom-level feedback produces local fixes; root-cause feedback produces improvement curves.