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
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 techcrunch.com/2014/08/26/ube…
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.”
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) 
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
