Person-Product Fit

Match PM skillsets to specific problem types instead of hiring generic product managers

Brian Tolkin
Lessons from scaling Uber and Opendoor

Person-Product Fit

"It's not really about is this person good or bad or whatever, it's is this person's skillset and context to the problem that is really needed... How can we be a little bit more thoughtful about what the actual skillset needs off this type of team?" - Brian Tolkin

What It Is

Person-Product Fit is a framework for hiring and assigning product managers that moves beyond generic "good PM" evaluations to specific skillset matching. Just like products need to fit their market, PMs need to fit their problem space.

Product managers come with different backgrounds and strengths:

  • Technical PMs: Engineering background, strong with systems and architecture
  • Ops PMs: Operations background, strong with process and real-world complexity
  • Design PMs: UX background, strong with user experience and interface decisions

The insight is that different problems require different PM archetypes. A highly technical infrastructure problem needs a PM who speaks engineering. A complex operational process needs a PM who understands real-world messiness. A consumer experience challenge needs a PM with design sensibility.

Rather than posting generic "Product Manager" roles, teams should identify what the actual skillset needs are for specific problems and hire or assign accordingly.

How It Works

PM Archetype Spectrum:

  1. Technical-Background PMs

    • Came from engineering or technical roles
    • Speak the language of systems and architecture
    • Strong with infrastructure, platform, and technical products
    • Best for: Developer tools, platform products, technical infrastructure

  2. Operations-Background PMs

    • Came from ops, business, or operations roles
    • Understand real-world complexity and edge cases
    • Strong with process, scaling, and ops-heavy products
    • Best for: Marketplaces, logistics, products with physical components

  3. Design-Background PMs

    • Came from UX, design, or creative roles
    • Understand user experience and interface decisions
    • Strong with consumer products and experience design
    • Best for: Consumer apps, experience-focused products, brand-driven products

The Matching Process:

  1. Identify the nature of the problem
  2. Determine what skillset is most needed
  3. Hire or assign PMs with matching backgrounds
  4. Don't try to force fit

How to Apply It

  1. Audit your problem space - For each product area, ask:

    • Is this primarily a technical challenge?
    • Is this primarily an operational challenge?
    • Is this primarily an experience challenge?
    • What expertise would be most valuable?

  2. Map your current team - Understand what you have:

    • What backgrounds do current PMs come from?
    • Where are they strongest?
    • Where are there gaps?

  3. Hire for specific fit - When opening new roles:

    • Define the problem first
    • Identify the ideal background
    • Write job descriptions that attract that profile
    • Interview for relevant experience

  4. Assign intentionally - When staffing teams:

    • Match PM strengths to problem types
    • Don't default to availability
    • Move people to better fits when possible

  5. Develop complementary skills - Help PMs grow:

    • Build awareness of their blind spots
    • Pair with complementary team members
    • Encourage cross-functional exposure

When to Use It

  • Building out a product team
  • Assigning PMs to new problem areas
  • Writing job descriptions for PM roles
  • Evaluating PM candidates
  • Restructuring product organizations
  • Identifying team capability gaps

Examples

Opendoor:

  • Problem: Heavy operational complexity, physical homes, real-world logistics
  • Fit: PMs with operations backgrounds who understand real-world messiness
  • Rationale: Building for 50 markets with home inspections requires ops intuition

Uber Early Days:

  • Problem: Technical matching and pricing systems
  • Fit: Technical PMs who could work closely with engineering
  • Rationale: Core value creation was algorithmic, needed technical depth

Consumer App:

  • Problem: User experience and engagement
  • Fit: Design-background PMs with UX sensibility
  • Rationale: Success depends on intuitive, delightful experiences

Pitfalls to Avoid

The generic job posting:

  • "Looking for a PM with 5+ years experience"
  • Attracts broad pool but misses specific fit
  • Better: "Looking for PM with operations background for marketplace product"

Forcing fit:

  • Assigning a technical PM to experience problems
  • Expecting them to develop skills they don't have
  • Better: Match strengths to problems

Ignoring the problem evolution:

  • Problems change over time
  • What starts technical may become operational
  • Reassess fit as products mature

Source

  • Guest: Brian Tolkin
  • Episode: "Lessons from scaling Uber and Opendoor"
  • Key Discussion: (01:04:13) - Different types of PMs for different types of problems
  • YouTube: Watch on YouTube

Related Frameworks

Back to Team Building