Product Operations Feedback Loop
A function that reports to Ops but sits with Product to close the two-way gap between HQ builders and field teams
- Difficulty
- Moderate
- Time to result
- ~months to results
- Steps
- 3
- Confidence
- 85%
An organizational design for companies where a centralized product team (at HQ) builds for a globally distributed operations team. Product Operations is a dedicated function with accountability into Operations but physically embedded with the product team, whose job is to make the bidirectional feedback loop between builders and the field actually work.
Origin
Brian Tolkin formalized and built out Product Operations at Uber; he credits Google with an earlier (differently-named) version and notes others at Uber had dabbled in the model before him.
Core principles
- 01A PM in San Francisco cannot understand the nuances of 50 markets walking houses or safety in South America daily
- 02Local/ops teams have superior qualitative insight and can iterate faster with customers
- 03Treat product and ops as a 'twin turbine jet plane' — a harmony, not a competition
- 04The feedback loop is bidirectional: HQ features must land in global markets, and market input must shape features
How to run it
- 1
Diagnose the weak bidirectional loop
Identify that centralized product (mostly at HQ) and distributed operations have a feedback loop that isn't strong in either direction — features ship poorly into markets, and market insight doesn't reach builders.
- 2
Create a dedicated Product Operations function
Stand up a new function accountable to and reporting into Operations, but that physically sits with and operates like a member of the product team.
Watch out Reporting line matters: keeping accountability in Ops preserves field credibility while proximity to product gives influence.
- 3
Run the loop in both directions
Push HQ-built features effectively into global markets, and pull structured market input back to build better features.
Pro tip Foster a genuine relationship and feedback loop so the people who deeply understand local nuance can give insights the HQ PM lacks.
In the wild
Uber's EPD teams built mostly in San Francisco while operations was globally distributed. The feedback loop between them was weak in both directions, so Tolkin's team formalized Product Operations — accountable to Ops but embedded with Product — to translate features into markets and market insight back into features.
→ Product Operations became a formalized, built-out organization at Uber and a template Tolkin carried into thinking at Opendoor.
Common mistakes
Product looking down on Ops as 'the team asking for one-off things that don't scale'
Tolkin notes this common dynamic (also seen at Airbnb); treating ops as lesser destroys the mutual respect that operationally-heavy businesses require to function.
Is it for you?
Best for
Product leaders at globally-distributed, operationally-heavy companies where HQ builds and the field executes
Not ideal for
Small single-market teams or pure-software companies where builders are also the users and no HQ-to-field gap exists
From the transcript
“a very globally distributed operations team and there's sort of a bidirectional feedback loop that wasn't wasn't super strong”
“start up a new function called Product operations who had accountability and reported into operations but physically sat with and operated much like a member…”
“a PM sitting in San Francisco can't be in in open door's case 50 markets walking houses every single day”
“twin turbine jet jet plane where you can like fly the plane on one engine for a little bit if you need to but it's…”
From the episode
Lessons from scaling Uber and Opendoor
Brian Tolkin (Head of Product at Opendoor, ex-Uber)