Oso’s Graham Neray: ‘I Can't Tell You How Much We've Drawn From Listening To Customers’

Oso CEO and Cofounder Graham Neray is passionate about his customers. Three-plus years into the creation of the company—a batteries included system that helps developers build authorization in their applications—Graham still joins every first customer call and interview loop and he requires every engineer at the company to spend 20% of their time with customers and takes rotations on sales and customer support calls.

We're not investors in Oso, but I asked Graham if he'd be open to sharing some insights with our community. We chatted about everything Oso, its new cloud product—which becomes Generally Available today, October 4—how he envisions big migrations, and his oals for the relatively young company’s projected ‘long and soon-to-be illustrious journey.’

Who is Oso for?

The core use case is b2b companies adding authorization to their apps. Authentication is for logging in—it’s the front door to every app. Authorization controls what you can do once you’re inside—what pages you can see, what buttons you can click, what data you can pull.

For example, Intercom runs on Oso—all requests at app.intercom.com flow through Oso, which then decides whether or not the user trying to do whatever it is they’re trying to do is allowed to do it. Every app needs authorization. With Oso, companies typically spend about 1/10 of the time building these capabilities.

That's exciting. How's it going?

It's awesome. A good off-the-shelf solution has never existed until now.

The majority of the companies I talk to are deciding between building on their own or using Oso, which is a great place for us to be in. But we’re creating a $25 billion market, and big markets attract competition. We’ve known that would happen for a while, and sure enough, others are wising up to what we’re doing. Since Oso launched, 10 companies have either launched a competitive product or come out of stealth with a competing product. I saw the same thing happen at my last company, MongoDB.

Are you competing directly with Auth0?

Auth0 has for the last 10 years focused on authentication—user logins, password resets, things like that. They’re starting to explore this domain, but it’s early days for them as they need to start completely from scratch. They focus on authentication, which checks users’ identities.

What are you launching today?

We’re launching Oso Cloud, an authorization as a service product we’ve been building for almost a year (and thinking about more or less since we started the company). This launch is part of our vision to make programming authorization fun and give developers a feeling of being supercharged (a few words that I’m sure have never been used in the same sentence before).

Who's your main competitor?

Do It Yourself.

The good news is that most people’s experience writing authorization code is a slog. We make it fun.

When did you start Oso and how much have you raised so far?

Oso was started in 2019 and the first version launched in 2020. We raised just under $11 million in Series A.

What do you feel like you have to do to get to your Series B?

Today we’re GAing Oso Cloud, our authorization as a service product. Nearly 1,000 companies have signed up already. I hear Series B investors care about revenue.

Oso’s first product was an open source library. How did you decide to build something from scratch as opposed to commercializing an existing project with traction?

Monetizing someone else’s project is always a risky proposition. You get some time-to-market benefits, but you’re not in control of your own destiny.

But even if we’d wanted to do that, it wasn’t a viable option for us. We started from the customer: What do we think will be the best experience for them? We decided that we needed a policy language for writing authorization logic and a library for integrating it into your app. Those two things—languages and libraries—kind of want to be open source. Plus we knew we wanted to have a free version to drive developer mindshare. So that’s how we arrived at an initial open source version of the product.

Talk to me about your decision to turn on paid. What are people paying for?

The decision to turn on paid was driven by problems we wanted to solve with the paid product. One complex authorization problem is how to execute authorization in a microservices architecture or an architecture beyond a monolithic app. Our open-source library doesn't help you solve that as a developer. So we started working on Oso Cloud because of customer demand.

Oso Cloud also solves other problems, like logging and debugging.

Can you talk about your business model?

It's a usage-driven model. We charge per API request. Our customers love this because they pay for value.

Was that obvious to you?

Sort of. We spent time thinking through other options. We considered pricing based on the number of end users our customers have, but we decided not to do that because it doesn’t fully align with the value they get. There are advantages to the per-instance model (it’s very clear what you’re paying for), but then the customer has to think about things like sizing, etc. Every option has its pros and cons.

What do you do as CEO to stay close to customers?

I talk to customers all the time.

How do you make that your mission?

I'm on every first customer call and interview loop. I can't tell you how much we've drawn from listening to customers. Every engineer also spends 20% of their time with customers. We have a customer call rotation for sales and support calls.

How do you preach the gospel of customer centricity to your company?

It starts in the hiring process. We have four values, one of which is to be for the makers. We do whatever it takes to make our customers become card-carrying members of the Oso fan club for life. We look for engineers who find it more fulfilling to get a customer to their end goal than to prioritize a specific design or solution.

One of our team members, Vijay, was debating starting his own company or joining Oso. When I told him he would learn everything he wants to know about starting a company by working with us, he decided to join. On his first day on the job, he said, “Cool. When can I join my first customer call?”

I tell my team that it's good for our customers and it's good for our team. It's good for customers because they get direct access to an extremely smart and knowledgeable group of engineers in a domain that is very poorly understood. The customers get fast, high-quality information—which is part of how we bootstrap our credibility with the outside world. And startups are in a race for credibility.

What are your thoughts on product-led growth?

According to the Head of Growth at HubSpot, a core metric is the number of weekly active teams. A person's likelihood of becoming a customer skyrockets when they reach this threshold, which they measure as something along the lines of completing a few important steps in the product.

That was always how I internalized what product-led growth meant. You set metrics inside the product. The term is getting thrown around A LOT today, but I think this is what people have traditionally meant when talking about product-led growth.

How about at Oso?

I consider our efforts to be relatively amateur, because we're still early in our long and illustrious journey, but I can't imagine how many startups have these massive product-led growth machines going. We've gone above and beyond in content strategy. At this point, we are the definitive experts on authorization. There is no other team that has written or spoken more on the topic, in particular in a vendor-agnostic way. To that end, our content drives upwards of 100,000 website visits a month.

Beyond that, open source is undergoing tons of change and no one's talking about that.

Give me your perspective on that.

There's never been a standard approach to open source. I once worked with a Product Leader who said to me, “Graham, this is the standard open source playbook.” Baloney. There is no playbook.

You have one big company (Red Hat) that managed to make one model (support) work; no one else has done that. You have a small number of other companies, which I could count on one or two hands, that have managed to make money on open core. All of their models were originally on-prem open-source products with a funnel to a paid, also on-prem product. They are all now transitioning completely to cloud models. Off to the side, you have AWS.

So, the world has woken up to the idea that the cloud as a service seems like a good monetization model, ostensibly for open-source products. But it’s broken as a funnel strategy. It’s not based on the same principles as the open source companies that people founded in 2008, 2009, 2010. The user journey for someone who downloads something open source and then migrates to a hosted version of that product is disjointed. Who wants to get something working in their own prod environment, then someday later, do a big migration to a hosted cloud service? I can tell you from experience—it’s no one’s top priority.

There's an unspoken idea in the market that cloud-hosted is a panacea for open-source monetization. But that’s only if your user journey makes it work. Otherwise, you're going to have a huge base of users running your open source product who don’t want to migrate to your hosted product.

The question is, what is your open-source product really for? And what does the ideal version of that journey look like?