Product Operations Function

A dedicated function bridging centralized product teams and distributed operations

Brian Tolkin
Lessons from scaling Uber and Opendoor

Product Operations Function

"Product operations... had accountability and reported into operations but physically sat with and operated much like a member of the product team to help solve that [feedback loop problem]." - Brian Tolkin

What It Is

Product Operations is an organizational function designed to solve the bidirectional communication problem between centralized product/engineering teams and globally distributed operations teams. It creates a formal bridge where insights from the field reach product builders, and new product features effectively reach global markets.

The function emerged from the recognition that as companies scale, a natural gap develops between product teams (often centralized in headquarters) and operations teams (distributed across cities, countries, and markets). This gap causes two problems: product teams build features without understanding local realities, and operations teams don't effectively adopt or provide feedback on new products.

Brian Tolkin helped formalize this function at Uber, though similar roles existed at Google and other companies. The key innovation is having people who report into operations (maintaining field credibility) but physically sit with and operate like product team members (enabling influence on product decisions).

How It Works

The Core Problem:

  • Centralized EPD (Engineering, Product, Design) teams build features in San Francisco
  • Globally distributed operations teams deploy and use these features
  • Bidirectional feedback loop is weak:
    • New features don't effectively reach global markets
    • Local insights don't effectively inform feature development

The Solution:

  • Create a dedicated Product Operations function
  • Team members report into Operations (maintaining operational credibility)
  • Team members physically sit with Product teams (enabling product influence)
  • Team members operate like PMs (speaking both languages)

What Product Ops Does:

  1. Outbound: When EPD builds new features, helps effectively deploy them in global markets
  2. Inbound: Synthesizes insights from global markets to inform what EPD should build
  3. Translation: Bridges the cultural and communication gaps between both worlds
  4. Credibility: Can advocate for field needs in product meetings and product priorities in ops meetings

How to Apply It

  1. Identify the gap - You likely need Product Ops when:

    • Field teams complain product doesn't understand their reality
    • Product teams complain ops doesn't adopt their features
    • Local innovations don't spread to other markets
    • Product roadmaps don't reflect operational insights

  2. Hire the right profile - Look for people who:

    • Have operational experience (credibility with field)
    • Think like PMs (can structure problems, prioritize)
    • Communicate effectively across cultures
    • Can translate between technical and operational language

  3. Set up the right reporting structure - Report into Operations but:

    • Sit physically with Product teams
    • Attend product reviews and planning sessions
    • Have formal input into roadmap prioritization
    • Are accountable to both organizations

  4. Define clear responsibilities:

    • Outbound: Feature rollout and adoption
    • Inbound: Market insights and prioritization input
    • Internal: Best practice sharing across markets
    • External: Voice of the field in product decisions

  5. Measure effectiveness by:

    • Feature adoption rates across markets
    • Time from launch to global availability
    • Field-originated insights in product roadmap
    • Reduction in product-ops friction

When to Use It

  • Centralized product teams building for distributed operations
  • Global companies with significant local variation
  • Products with heavy operational components (marketplaces, logistics, etc.)
  • Organizations where product-ops communication has broken down
  • Companies scaling beyond the point where informal communication suffices

Source

  • Guest: Brian Tolkin
  • Episode: "Lessons from scaling Uber and Opendoor"
  • Key Discussion: (00:08:22) - The birth and structure of Product Operations at Uber
  • YouTube: Watch on YouTube

Related Frameworks

Back to Team Building