What product leadership is and how it differs from product management
Product leadership is the transition from making product decisions to enabling others to make good product decisions. An IC PM owns a product area, makes trade-offs, and ships features. A product leader (Director, VP, CPO) owns the product organization: hiring PMs, coaching them, designing the org structure, setting the strategic direction, and building the culture that produces great products. The skills that make a great IC PM (detailed analysis, hands-on customer research, feature-level decision-making) are necessary but insufficient for leadership. Leadership adds: hiring judgment, coaching patience, organizational design, and the ability to set context without prescribing solutions.
The hardest transition is letting go of the product decisions you used to make. A PM who becomes a leader and continues making all the product decisions has not transitioned — they've just gotten a bigger title while doing the same job, with the added burden of denying their reports the opportunity to develop. The leader's job is to set the strategy, hire people who can execute it, give them enough context to make good decisions, and step in only when decisions are off-strategy or when a PM is stuck.
Hiring PMs
PM Hiring Rubric Core Method
Use when: defining what "good" looks like for a PM hire at your company.
Evaluate across five dimensions:
- Product sense — can they identify the right problem to solve and design a compelling solution? Test with a product critique exercise or a "design a solution for X" case.
- Analytical ability — can they use data to inform decisions? Test with a metrics case ("this metric dropped 15%, what would you investigate?").
- Execution — can they turn ambiguity into action? Test with a prioritization exercise or a past experience deep-dive.
- Communication — can they explain complex trade-offs clearly? Observe throughout the interview.
- Leadership & influence — can they align people without authority? Test with a stakeholder conflict scenario.
Weight the dimensions based on the role: junior PMs need stronger analytical and execution skills. Senior PMs need stronger product sense and leadership. Platform PMs need stronger technical depth. Growth PMs need stronger analytical and experimentation skills.
PM Onboarding 30/60/90 Template
Use when: a new PM joins and needs structured ramp-up.
First 30 days (Learn): Read every product doc, attend every meeting, talk to 10+ customers, shadow support for a day, review the last 3 months of metrics, and understand the competitive landscape. No decisions — only questions. Days 31-60 (Contribute): Own a small, well-scoped project. Run a sprint planning session. Write a spec and get feedback. Conduct a user research session. Start forming a point of view on priorities. Days 61-90 (Own): Take full ownership of a product area. Propose a roadmap for the next quarter. Identify one thing that should change about how the team works. By day 90, the PM should be operating independently with your coaching, not your direction.
Coaching and developing PMs
PM Coaching Framework Core Method
Use when: developing PMs on your team through structured feedback.
Coaching PMs is different from coaching engineers or designers because PM skills are harder to observe directly. You don't see a PM "working" the way you see code or designs. Coach through three mechanisms:
- Decision review — after a PM makes a significant decision, review the reasoning: what data did they consider, what trade-offs did they weigh, what did they miss? The review is about the thinking process, not just the outcome.
- Spec/artifact review — review PRDs, strategy docs, and presentations. Focus on clarity of thinking, not formatting.
- Stakeholder feedback — regularly ask engineers, designers, and cross-functional partners how the PM is performing. PMs often have blind spots about how they're perceived.
The coaching stance: ask questions more than give answers. "What other options did you consider?" builds more PM judgment than "You should do X." Reserve direct instruction for cases where the PM is about to make a consequential mistake.
Career Ladder Design Framework
Use when: building or refining the PM career progression at your company.
A PM career ladder defines expectations at each level across 4-5 dimensions: Scope (feature → product area → product line → portfolio). Autonomy (supervised → guided → independent → defining direction for others). Impact (feature-level metrics → product-level outcomes → business-level results). Leadership (individual contributor → mentoring → managing PMs → setting product culture). Craft (executing established practices → adapting practices to context → creating new frameworks).
Common levels: APM/PM I (executing with guidance), PM II (independent ownership of a product area), Senior PM (cross-functional influence, mentoring), Staff/Principal PM (company-level impact, thought leadership), Director (managing PMs, organizational design), VP/CPO (setting product strategy for the company). Not every company needs all levels — a startup might have PM, Senior PM, and Head of Product.
Product org design
Org Model Comparison Framework
Use when: designing or restructuring how product teams are organized.
Common models:
- Feature teams — each team owns a product area (search, payments, onboarding). High autonomy, risk of local optimization.
- Platform + product teams — platform teams provide shared infrastructure, product teams build user-facing features on top. Clear separation, risk of coordination overhead.
- Customer-journey teams — teams organized around lifecycle stages (acquisition, activation, retention). Good alignment with metrics, harder to own a coherent product area.
- Dual-track teams — each team has a discovery track (PM + designer researching) and a delivery track (engineers building). Good for continuous discovery, requires discipline to keep tracks connected.
The right model depends on your product's architecture, your team's size, and your strategic priorities. Feature teams work well under 20 engineers. Platform + product works well at 50-200 engineers. Journey teams work well for growth-stage companies optimizing funnels.
Product Culture Assessment Tool
Use when: joining a company or team where product culture is weak or undefined.
Assess five indicators:
- Decision authority — do PMs make product decisions, or do executives?
- Customer proximity — do PMs talk to customers regularly, or rely on secondhand reports?
- Outcome orientation — is success measured by impact or by output (features shipped)?
- Experimentation safety — can teams run experiments that might fail without political consequences?
- Cross-functional health — do PM, design, and engineering operate as partners or in a handoff chain? Score each 1-5. A score below 3 on any indicator reveals where to invest first.
Real-world examples
Case study
Stripe: Product culture as competitive advantage
Stripe's product culture is built around two principles: "move thoughtfully" (not "move fast") and "craft." PMs are expected to deeply understand the domain (payments, financial infrastructure) before making product decisions. Their hiring bar is extremely high — they famously ask PM candidates to explain a recent Stripe product decision and what they'd do differently. The culture produces PMs who are technically fluent, domain-expert, and quality-obsessed.
Why it works: Product culture at Stripe isn't a poster on the wall — it's embedded in hiring (the questions filter for domain depth), in rituals (regular product reviews with Patrick Collison), and in standards (products ship when they meet a quality bar, not a deadline).
Journey-centric organizational design
Journey-Centric Org Design Technique
Use when: your product organization is structured around features or platforms, and the end-to-end customer experience suffers as a result.
Most product orgs structure teams around product surfaces (the checkout team, the dashboard team, the onboarding team). This creates locally optimized features and globally incoherent journeys. Journey-centric design restructures accountability around customer journeys. A "new customer journey" owner has authority across onboarding, first-use, activation, and early retention — regardless of which product surfaces are involved. This doesn't require a full reorg. Start by adding a journey coordination layer: Journey owners work across feature teams with authority to prioritize cross-team work. Journey health metrics span team boundaries — end-to-end completion time, cross-team handoff quality, journey-level satisfaction. Journey reviews evaluate the complete experience rather than individual features. The PM leadership challenge: giving journey owners enough authority to coordinate without creating a matrix organization that slows everyone down.
Common pitfalls
Promoting your best PM to manage PMs
The best IC PM isn't necessarily the best PM manager. IC excellence is about product judgment and execution. Management excellence is about coaching, hiring, and organizational design. Some great ICs are terrible managers (they micromanage product decisions). Some average ICs become great managers (they excel at developing others). Evaluate management potential separately from IC performance.
Building a career ladder nobody uses
A beautiful career ladder document that sits in Notion and is never referenced in promotion discussions is theater. The ladder must be used: in hiring (mapping candidates to levels), in performance reviews (measuring against level expectations), in promotion discussions (demonstrating readiness for the next level), and in coaching (identifying specific growth areas).