I think this is one big reason why Uber won. For ~half of what HQ built, the user was ops, not riders. We built a ton of general purpose tools that they used to hustle and run their business — and how they used these tools often surprised even us
Conversation
The most spectacular example of this is Uber Eats — originally a pilot called Uber Fresh in LA, which required 0 product or engineering work to launch. It was all ops
1
2
31
The vast majority of products we ended up building at HQ started as ops-only experiments — you’d always hear people say things like “the [DC] team is killing it with [experiment X], we need to productize this.”
1
1
37
You wouldn’t believe the things ops could build with sql queries, google sheets, and tools we gave them to trigger things like custom comms or payments. To this day I still think the hustly soul of uber was really alive in its ops teams (picture below from a public conference)
3
10
130
I also think this highlights one return to scale that I haven’t seen explored anywhere: that of spinning up more experimentation threads. With a culture allowing bottom-up experimentation + tooling to cap its downside, you can create a massively parallel experimentation engine
5
5
78
I had the same feeling, and it was even crazier on the marketing / acquisition side than on product. Engineers were even warned in HQ: “any feature you build will be hacked by ops to do something you’d never foreseen.”
1
1
17
You’re unable to view this Tweet because this account owner limits who can view their Tweets. Learn more
I’ve written two essays when I left uber on this that I never published 😞 should find the time to
2
1
17
