EP105 What happens when your users become the builders?

Okay, let's get into some of the key questions I had for you here, Saurabh.

Now, when building a system, users consume what you ship.

But at u.com, customers build their own workflows on your APIs.

What changes about how you run your product team?

I think it's fundamentally vastly different.

When you're building a consumer product, let's say Google Assistant, you own the job to be done.

What do you want to enable users to be able to do? Play music, set timers, understand the weather.

You are determining the universe of things that can be done, and you're designing the system to incentivize and push people to be able to do those type of things and find the value.

As an infrastructure provider, it is 180.

We are not the builders.

Our customers are the builders.

And we own the primitives that drive the jobs to be done.

And so our goal, when I was at Google, we would think about, does this feature ship? What user problem does it solve? At u.com, what we think about is, is this a primitive that belongs at the platform layer, or is this something that happens at the application layer that developers should drive themselves? It's a fundamentally different way of thinking.

Now, that said, the similarities are that we are thinking about the job to be done that we enable and think about.

The difference is that our users are building those jobs to be done.

We play a supporting role in enabling that broader capability and broader application to be built.

And so a lot of times what we're thinking about is not about can we add a specific feature, but can we add a composable primitive that enables a range of use cases that we see.

As an example, with our web search API, what we noticed was a lot of customers were then bolting on the ability to scrape web pages that we were returning via our web search API.

And so we added the live crawl capability because we saw that as a fundamental primitive to expose as opposed to something that developers should continue to bolt on.

Fantastic.

I've noticed you keep using this word primitive, Saurabh, and that's quite unique.

I've not heard people wrapping that into product management conversation.

Can I ask, what is it around that word as around why is it so important for you internally to look at primitive versus non-primitive from, I assume, a prioritization perspective?

Yeah, what we look to do is we look to build the building blocks that developers need to create their products.

And in a way, it is similar to consumer product management.