How to Know Your AI Feature Actually Works (n8n's Founder's Metric) | Jan Oberhauser, CEO n8n

n8n's founder puts the company's GitHub repo, nearly 200,000 stars, right next to the paid signup button, and he's genuinely fine if you never pay. In this episode of The Product Podcast, Carlos (CEO at Product School) sits down with Jan Oberhauser, CEO of n8n, the open-source automation platform that's crossed $100 million in ARR at a $5.2 billion valuation. Jan breaks down the "fair-code" license bet that let him give the product away and still build a business, how that free version became the on-ramp into enterprises like Meta, Nvidia, Dell, Accenture, Vodafone, Deutsche Telekom, and Mercedes, and why he believes the people with the problem should build the automation themselves, not a centralized team or an outside agency.

He also walks through a live build of a personal AI agent (email and calendar), shows how n8n falls back from Claude to GPT via OpenRouter when a model isn't available, and explains how enterprises get automations into production faster because each agent can only do exactly what it's been permitted to do.

What you'll learn:

• Why n8n rejected traditional open source for a "fair-code" license, and how it avoided the community backlash that burned other companies
• Why trust and consistency, not features, are the real center of a community
• How the free, self-hosted version drives bottom-up adoption inside major enterprises
• Why "sprinkling AI on top" kills products, and what to build instead
• How to chain agents so one agent's output becomes the next agent's input
• Why n8n is the "connective tissue" between models, tools, and business systems
• How guardrails (an agent can only do what it's explicitly allowed) speed up enterprise procurement and production
• Why the people with the problem should own the building, not a centralized AI team
• How 10,000+ community templates and 500+ integrations expand what non-technical builders can ship
• How one company routes 75% of support through an n8n agent, with customers happier than with humans

Connect with Guest (Jan Oberhauser):
LinkedIn: https://www.linkedin.com/in/janoberhauser
X: https://x.com/JanOberhauser

Host: Carlos, CEO at Product School
LinkedIn: https://www.linkedin.com/in/villaumbrosia/

About Jan Oberholzer: Jan is the CEO of n8n, an open-source (fair-code) workflow automation and orchestration platform for building AI agents. He started the company over seven years ago, before LLMs went mainstream, and has grown it past $100M ARR at a $5.2B valuation.

About the Product Podcast: Product School's podcast brings you candid conversations with the founders and product leaders shaping tech.

Social Links:

• Find out more about Product School here
• Follow our Podcast on TikTok here
• Follow Product School on LinkedIn here

Transcript

Jan Oberhauser | n8n 00:00:00

I just went to your website, and you have this big button showing your GitHub repo with almost 200,000 stars, right next to the sign-up. Obviously, we prefer if people use our hosted solution and actually pay us, because it lets us reinvest their money. But at the same time, if people use us for free, that's totally fine as well. They're just two different ways of using n8n.

What made us special is that early on we focused very heavily on the community. We created an amazing platform, but we also made sure those people had a great experience, that they supported each other. And it's very powerful: you can build very complex systems, where something happens here, then it does something with the output, sends it to another agent, and that becomes an input again. People can build really, really complex use cases.

The AI cannot do anything it's not supposed to be doing. That's why large organizations choose us for business-critical use cases, not just a nice demo.

Introduction

Carlos González de Villaumbrosia | Product School 00:00:59

Hey, this is Carlos, CEO at Product School and your host on The Product Podcast. My guest today is Jan Oberhauser, the founder of n8n, the open-source automation platform that's crossed one hundred million in ARR at a five-point-two-billion-dollar valuation, with nearly 200,000 GitHub stars.

In this episode, here's what we cover: the "fair-code" license, why he rejected traditional open source and still won. Why sprinkling AI on top kills products, and what to do instead. How n8n beat Zapier and Make by giving the code away. Who should actually build automations, hint, not the product team. The metric he uses to know if an AI feature actually works. And how one company routed 75% of support through an agent, with happier customers.

Let's get into it. Welcome to The Product Podcast, Jan.

The Name Behind n8n

Jan Oberhauser | n8n 00:01:41

Thank you for having me. Great to be here.

Carlos González de Villaumbrosia | Product School 00:01:45

I had to start with this. Why did you call your company n8n?

Jan Oberhauser | n8n 00:01:50

Because there's a lot of confusion out there. The simple reason is I was a solo founder. Before I launched, I needed a name for the product, and the name also helps make or break the company. So I time-boxed it to about an hour. I wrote down all the names I liked, and every one I liked was already taken. As you know, a lot of domains are always gone.

One name was left: "nodemation." It's a node-based system combined with automation. But the name was quite long. It didn't really look nice or exciting, so I thought, maybe I can make it shorter. I did the same thing as Kubernetes, which becomes K8s: eight letters between the first and last. "Nodemation" becomes n8n. The .io domain was available, and after the seed round I could buy the .com for about five K as well. We don't really use the .com right now, but at least we own it so it doesn't get more expensive.

Now everybody has to figure out how to say it, which is a bit of a tongue-breaker. There are so many different ways people pronounce it that I didn't even anticipate. In Germany especially, there are a million different ways to say it. It's quite fun to watch.

Carlos González de Villaumbrosia | Product School 00:03:00

But you made it work. People recognize the name. It's obviously not very common, but the product works, so people find a way to remember it. You started this journey over seven years ago, way before LLMs became mainstream. I only started hearing about you maybe two or three years ago, so I'm curious: how did you see the opportunity in LLMs and decide to pivot into that?

Jan Oberhauser | n8n 00:03:21

As I said, we started pre-AI, and honestly I didn't imagine we would ever do anything with AI at all. But then ChatGPT came along. We saw large language models getting stronger and better, and we started wondering how to make sure AI wasn't just a feature we bolted on, but that we actually participated in this wave, which we realized would be the future.

So we took a step back and looked at what we were doing, and what our competitors were doing. All of us, including ourselves, honestly, were just sprinkling some AI on top. Then we thought: to really make use of it, we need to be part of the value chain. Not people using AI for anything, but people building AI-powered applications and agents inside n8n.

That's when we realized n8n fits in perfectly. What do these large language models actually need? They need a lot of data from different sources, whether it's Google Drive, your local files, Salesforce, or whatever. The model does something with that data, it transforms it, it makes a decision, and then it outputs the data again into a system or a file. We already had all of those pieces in place. The pieces in between used to be done externally, or in a very limited way through HTTP request nodes. By adding these AI capabilities front and center, we were able to create something really powerful: not just simple automations, but genuinely powerful agents.

The Secret Sauce Behind n8n's Traction

Carlos González de Villaumbrosia | Product School 00:04:52

That vision makes sense in retrospect, because we're all using agents now and we understand agent workflows. But back then it wasn't obvious at all, and there was a lot of competition: platforms that were more well known, at least in the US. And you crossed over one hundred million dollars in annual recurring revenue and raised massive rounds, most recently at a five-point-two-billion-dollar valuation with participation from Nvidia. So there's clearly something unique here. What was the unique thing, the secret sauce, that put you on the map with this traction?

Jan Oberhauser | n8n 00:05:30

First, to clarify: we crossed over one hundred million euros in ARR a while ago, and we're at a five-point-two-billion-dollar valuation now with our SAP partnership. We're growing nicely. We don't announce exact revenue numbers, but yes, we crossed one hundred million in ARR some time ago. So the question is: what enabled that global growth?

Carlos González de Villaumbrosia | Product School 00:05:53

By the way, I love being wrong about those things. "Oh my God, now it's over one hundred million." There are so many tools out there trying to do something similar, and you weren't the first mover. Platforms like Zapier and Make had more market share. But you came out of nowhere in the last two or three years and achieved incredible traction. In the early days, what helped you get that initial tailwind?

Jan Oberhauser | n8n 00:06:18

From the very beginning, it was all about power and flexibility. That's what we felt was missing from a lot of the existing platforms. With many of them you could build something very fast, but if you actually wanted to bring it into production or scale it, the platform maxed out. So we decided to really focus on power and flexibility, and to make sure people don't outgrow our solution.

The other thing was our focus on the community, very early on. We created a great platform, but we also made sure people had a great experience: they support each other, we support them, we provided great support, we ran online events, and now we do offline events too. We put builders at the center. It's about empowering people. One of our core company values is literally "we are builders." We are builders, our community are builders, our users are builders. Having that alignment across everything attracts the right people and creates real value.

We grew nicely in the first years, but it really took off when we focused on AI. There were a lot of other platforms out there, but none of them had the deep, powerful AI capabilities we built. They all had some AI integrations, so you could call out to OpenAI or something similar. But from the very beginning we made sure it wasn't just calling an API somewhere. You actually build proper agents: memory, multiple models, different tools you can configure easily, scripts you can add. That power and flexibility wasn't available anywhere else. That's what people really craved.

Combine that with our other advantages, like the ability to self-host. People really appreciate knowing where their data lives, knowing they can run it behind their firewall, and knowing they can scale it. We have a big focus on reliability, scalability, and auditability, so you can easily understand what's actually happening, even in complex flows.

Why n8n Let Everyone Self-Host for Free

Carlos González de Villaumbrosia | Product School 00:08:40

I want to unpack some of the concepts you mentioned. You built a visual layer that makes it easier for people, what you call "AI builders," to create these agent workflows. I think that expanded the market, because this isn't just a technical audience anymore; technically, anyone can be a builder. You also mentioned something unique compared to other platforms: you let people self-host your product. What was the rationale behind that decision?

Jan Oberhauser | n8n 00:09:07

The core incentive is simple. When I started, I wanted a few things. First, I wanted to make sure we could become the default tool. And if you want to become the default tool, you have to make sure a lot of people can access it, and access it for free. That's really a requirement.

The other thing is that I saw a lot of open-source tools out there building amazing communities that made their success possible in the first place. So it was very clear: I wanted to make n8n available for free, and open source was one of the directions I could take. But I went down a slightly different path, because I saw that a lot of open-source companies later changed their license to something more restrictive, and the community got very angry. Less because of the license they chose, and more because the company suddenly changed the rules: "first you could do all of this," and then they took some rights away. That really upset people.

I thought, I can't afford that. Building a successful community is very hard, and it's also very easy to lose. So I decided to be upfront from the very beginning. I wanted to make it available for free for everybody, but I also wanted to build a business, pay my own salary at some point, hire a lot of people, and provide value. I wanted to make sure the money actually goes back into the company, because we reinvest it into support, docs, the product, and great events. Only by doing that can we keep growing and build a successful company.

So from the very beginning I chose a slightly different license, which we now call the "fair-code" license. You can do more or less the same things you can do with open source. The only limitation is that you cannot commercialize the code itself. You can use it commercially inside your company at any scale you want, but you cannot build a hosted version of n8n and charge other people for it. I think that's a fair ask, which is why it's called fair-code. We did that from the beginning.

We thought hard about how to enable scale, build a great community, and build trust, because trust is really the center of a community. People can say a lot of things, and they can change their mind tomorrow. But if you're consistent from the very beginning, so people see that what you say is what you actually do, you build a very strong community. It was very important to show that from the start, and over the last seven or eight years, people can definitely see it.

The Free Tier as an Enterprise Growth Engine

Carlos González de Villaumbrosia | Product School 00:11:52

I just went to your website, and you have this big button showing your GitHub repo with almost 200,000 stars, right next to the sign-up. It's a unique approach: you pursue this open-source path with a self-hosting option, and still find a business model that lets you run a business while making the product widely accessible. I've seen that approach in other companies, but not in your specific space. We hosted the SVP of Product from a database company that just acquired dbt, and MongoDB is often the lead example. But I think you're the first mover in automation. And by the way, how do you define your industry? I've seen terms floating around: automation, orchestration, now "loop engineering."

Jan Oberhauser | n8n 00:12:42

We're more like the orchestration layer, so "orchestration platform" is how I'd define it. But back to the previous point: a lot of open-source products start as open source and are very proud of it, and at some point they start to hide it. The source code is still there, but they try to hide it more and more and push people down the paid path. We very deliberately say the opposite. We obviously prefer if people use our hosted solution and pay us, because that lets us reinvest their money. But if people use us for free, that's totally fine as well. They're just two different ways of using n8n.

The free option is super important for us. It's how we got adoption in large organizations: Meta, Nvidia, Dell, Accenture, and in Germany, Vodafone, Deutsche Telekom, Mercedes. We got into all of those companies the same way: someone had a problem, started with our free version, and brought it into their enterprise organization. That's what people underestimate. They think short-term: "How do I make sure this person pays me tomorrow for my hosted offering?" instead of thinking long-term: making sure people have a great experience and get a lot of value out of the product. When they get a lot of value, at some point they become a paying customer. And even if they don't, most eventually will.

Bring Your Own Key and Switching Models

Carlos González de Villaumbrosia | Product School 00:14:05

Even if someone chooses the free option, I imagine they start connecting different LLMs, and I know you let people switch between them. Some are open source, some aren't. How do you enable that optionality and still let people pay once they reach a certain level of usage?

Jan Oberhauser | n8n 00:14:25

What makes n8n different from most other tools is that people bring their own key. We have some functionality where you can get test credits, and we're working on a feature where you can use LLMs and pay through us. But up to this point, people bring their own key. They say, "I want to use an Anthropic model, or an OpenAI model, or Hugging Face," and they connect it. Depending on their use case and their budget, they decide for themselves which one to use.

An important part of n8n's power is that you can switch later. It's theoretically a one-second switch: just delete one node and put in another. But you'll usually have to make some adjustments too, so we also have functionality where people can create evaluations inside n8n to test what a change does and how they need to adjust, for example, their prompts. This is much simpler than changing your model provider on other platforms, especially if you switch from, say, an OpenAI model to the same model hosted by Microsoft. That's a switch of a few seconds.

Market Positioning and the "X Killed Y" Cycle

Carlos González de Villaumbrosia | Product School 00:15:37

Right now, some Chinese open-source models are apparently performing better than some US-based models. Having optionality is an advantage: you're not locked into any provider. And you see in the news that when Anthropic or OpenAI releases a new model, the headlines say "this company just killed ten other startups." So I'm curious about your market positioning, your moat, and your relationship with these different providers.

Jan Oberhauser | n8n 00:16:13

There's definitely a lot of "killing" going on. "X killed Y" gets a lot of clicks, so it happens literally daily that something kills something else. I'd probably not take it too seriously. Most of the "killed" startups are still doing very well; obviously not all of them, so there's something true there. But what makes us special is our focus on auditability, flexibility, stability, and security, and really giving people control.

The way I see it: the LLM is the engine, and we're the car, the roads, and the whole system. We connect everything and build the connective tissue between all these different models, agents, and business systems, and turn it into an actual process you can use. We all need each other. We need the model providers, and the good thing is you can replace them. You have a lot of models and a lot of systems you connect to, and we bring it all together. That lets you build not just a nice demo, but reliable, secure systems where you can actually understand what's happening.

If you build an automation with n8n, you know exactly how your data flows, which tools it uses, and that it's not going to do anything else. When something goes wrong, you see exactly what went wrong. That's why large organizations choose us for business-critical use cases: they can get real ROI and deploy in production, not just build a nice demo.

Live Demo: Building an Agent by Describing It

Carlos González de Villaumbrosia | Product School 00:17:51

I think we've talked about the product enough. Now it's time to show it. I love that you volunteered to share your screen and demo. I'd love to see the product in action.

Jan Oberhauser | n8n 00:18:03

In the past, people built workflows manually. But with things like Claude Code, people realized building can be much simpler, and we realized it too. We want to give people that same great experience inside n8n, and let literally anybody build. A lot of the feedback we received was that n8n was a more complex system focused on technical users, and the goal was always to lower the bar. Thanks to AI, we're finally able to empower everybody to build.

What you see here is our newest assistant, which we released about a week and a half ago. You just describe what you want to do. We give you some examples: say you have a marketing or SEO use case, you define what it should build for you. I prepared something in advance because it takes a few minutes to build. Here I asked it to build a personal workflow agent that works with my emails and my calendar.

It starts with a chat trigger so I can talk to it. I told it my email address and everything it should be able to do. I also made sure to include human-in-the-loop: certain actions I don't want the AI to just do by itself. For example, I don't want it to send an email in my name without me confirming it. So I told it to make sure certain steps can't happen unless I approve them first.

It started building, confirmed it understood what was going on, and then asked a first question, about which model to use, since there are a lot of models out there. I said, for example, use Claude via OpenRouter. It asked a few other questions too, and you can see its reasoning here. Then it kept building. Normally you don't have to care about most of this, but more technical users who want to understand what's happening can open it up and see exactly what the AI is doing as it builds the workflow.

It built for a while, and then said it was done. I also said, "Actually, I want to change the way you built this slightly," and it went back in and made changes. In the end, you can see one of the artifacts here: the workflow it built. Let me make it larger so you can see it better.

It's quite easy to understand. You start with a chat node where the conversation begins; you input the data, and it flows into this agent. By default this agent uses Claude, but we also configured a fallback model, because even Anthropic isn't always 100% reliable. You can say, "If this model is currently unavailable, fall back to GPT via OpenRouter." Then you see all the different tools we defined: get recent emails, get emails, create a draft, and so on. And here you see the human-in-the-loop steps: it can send an email, but only after I approve it.

We can see the configuration of each node. Here, before approval, it shows a message: "Send this email, please confirm." It gives you an overview of who it's going to, the subject, and the body, and before it actually does anything it always asks for confirmation. Same thing for sending a reply, or for creating calendar events.

Carlos González de Villaumbrosia | Product School 00:22:04

In this case I see two different types of workflows: ones that can be fully automated, and ones that require human approval before they execute.

Jan Oberhauser | n8n 00:22:12

Exactly. It can run in the background: "Every time a new lead is created, create something in Salesforce for me," and it just does it automatically. Or you can have an internal chat system like this one, where I created a personal assistant for myself that works through chat. You can test it here, or use it via Slack or Telegram. Or you can expose it to your users. For example, a large online travel agency automated a lot of its support through an AI assistant built in n8n: 75% of customer requests go through that agent, where people change hotel rooms, change bookings, ask questions, and so on.

The nice thing about that example is that people are actually happier with the AI customer representative than with a human one. That's amazing, because it shows AI isn't just about lowering cost; it can provide real value for users. So you can build anything from fully automated to "everything needs approval."

Carlos González de Villaumbrosia | Product School 00:23:31

Got it. And just to clarify: this visual graph was created automatically based on the configuration you did before, right?

Jan Oberhauser | n8n 00:23:39

Exactly, automatically. Normally you sometimes have to select which credentials to use. For example, for Claude you can use built-in credits, or use your own API key. You can do this with literally any tool: "This is connected to my Gmail account," and so on. So it builds automatically, and then you can go through and understand what was built. The problem with writing code is that you might have 10,000 lines you hope are right, but actually reading and understanding them is almost impossible; it can take more time to understand the code than to write it. Here it's simple. You have a chat node, you get a message, the data flows through, and here's the AI agent. You can see the system message that tells it "I'm an assistant, I have these tools, I have these rules," it gets the chat message, and it has access to these tools. You can easily add more tools, even code tools, actions in different apps. Anything your heart is asking for.

500+ Integrations, and Connecting to Anything

Carlos González de Villaumbrosia | Product School 00:25:05

A question about those tools. I saw on your website you have over 500 integrations. How do you handle that? Do you set each one up one-to-one, or is there a more automatic way to create integrations?

Jan Oberhauser | n8n 00:25:20

There are multiple levels. There are built-in integrations that we create and maintain ourselves, the most important ones, like anything Google, or Salesforce. Then there are community integrations: the community builds them, we check them and make sure they're secure, and people can access them on the cloud solution or install them. There are actually a lot more than 500 out there. And even if there's no integration built by us or the community, you can still connect manually via an HTTP request node: make a GET or POST request to an endpoint. You can even ask the AI to configure the nodes for you. In the end, you should be able to connect to literally any API-based system.

Carlos González de Villaumbrosia | Product School 00:26:12

I remember the first time I set up my own agent. It was quite an ordeal, and I'm relatively technical, but there was no visual layer. Here I imagine you can drag and drop and set it up, and you don't need to buy a MacBook or a Mac mini to run it, right?

Jan Oberhauser | n8n 00:26:29

Right, it runs entirely in the cloud, and you can test it easily. Let's say you tell it, "Send an email to James saying hello." I can literally watch the data flow through. The message is received, the agent starts, it adds data to memory, it calls the model, it figures out what to do next, and then it calls one of the tools. In this case it says, "Send out this email. Do you want to review it before I send it?" Because we set up human-in-the-loop, it stops and waits until I say to send it. I can say send or cancel. If something went wrong, you'd see the node marked in red and you could debug it easily. You can go in and see the logs, look at the inputs, see what was sent to the model, how it called a tool, and how it asked for approval. You can go through everything that happened and debug it, for literally any execution.

Training Agents, Templates, and the Blank-Slate Problem

Carlos González de Villaumbrosia | Product School 00:27:53

Loops are hot right now: this concept of training your own agents, setting a goal, and having them improve. How do you think about that, and how can people train their own agents as they run these workflows?

Jan Oberhauser | n8n 00:28:07

There's a loop happening already: you call the agent, it calls a tool, it goes back to the model, it calls another tool, it responds to the user, and it can go back again. You can also make it literally loop, telling it to talk to itself just by adding a connection here. It's very powerful; you can build very complex systems. Something happens here, it does something with the output, sends it to another agent, and that becomes an input again. People can build really complex use cases.

Let me also show our website. Here are templates: over 10,000 templates created by our community. You can search "sales," or "Google Sheets," and see nice examples, like how to create TikTok videos. You click on one and see the actual automation that was built. You can explore exactly what's happening and how it was set up, and then just say "I want to use it," copy it, and paste it into a new workflow. The whole thing is right there. Now I can configure it with my own settings. In this case it has an OpenAI model, so I can use my own credentials or...

Oh, sorry, I forgot the...

Carlos González de Villaumbrosia | Product School 00:29:50

I get it. This is a very important problem: starting with a blank slate is sometimes hard.

Jan Oberhauser | n8n 00:29:56

Exactly.

Carlos González de Villaumbrosia | Product School 00:29:56

So having a recipe that lets you validate what you need, while still being able to edit it based on your own tool stack and use case.

Jan Oberhauser | n8n 00:30:07

Exactly. And to finish the earlier example: I had the assistant build this workflow, but I can also extend it. I can say, "That's great, but now add a calendar tool where I want to book my one-on-ones with a consistent format, 30 minutes, and so on." I send that to the agent, and I can watch how it works. It goes off, does some thinking, and starts extending the existing workflow.

So you can start simple. You don't have to build the whole solution from the beginning; you can do it iteratively. Start with the most basic version, then add other things over time. Now it's working, reasoning about what it should do. It'll take a few minutes. It figures out the different nodes it needs, checks whether credentials already exist, and says, "I need Google Contacts credentials. I already have an existing one," so it can connect to Google. In less than a minute it's done, and you can see it extended the existing workflow.

That's the amazing thing: literally everybody can do that. You just have to know what you want to build. If you know what you want, you describe it, and it goes out and does it for you. Then you test it yourself, confirm it works the right way, and deploy it in production for daily use.

The Multiplayer Bottleneck

Carlos González de Villaumbrosia | Product School 00:32:07

I want to ask about the main bottleneck I see with these assistants. People can now create their own second brains or AI staff, and that works well for their own productivity. But the multiplayer bottleneck is real. How do you create a shared environment where people benefit from each other's work and collaborate, instead of everyone building their own version of their own assistant?

Jan Oberhauser | n8n 00:32:36

We're releasing something shortly, if it isn't out already, where instead of connecting your own credentials, you can assign credentials dynamically. So if I interact with it, it uses my credentials and accesses my Gmail and my calendar. If you chat with it, you give it access to your calendar, and it works for you. That's very important. Instead of 10,000 people in an organization each building something separately, you can have literally anybody deploy one thing, and the whole organization gets access to the same thing.

Carlos González de Villaumbrosia | Product School 00:33:26

Because ultimately we become super-agent managers, right? You have all these different agents doing different things. Sometimes they're yours, sometimes your teammates'. So what becomes the control panel, the surface for a product leader to understand what's going on and make modifications?

Jan Oberhauser | n8n 00:33:45

I agree it's so important. By the way, you may have seen it go by fast: it's not just building the workflow, it's already testing it for you, so you can be sure that when it builds something, it's already in a working state.

Getting Enterprises to Trust AI in Production

Carlos González de Villaumbrosia | Product School 00:33:59

Really cool. The other thing that's becoming challenging, especially for large organizations, is deployment. These demos work well when you have full control over the tools you're connecting. But as more people join, you have more controls and checks. For large enterprises already using n8n, how did you get over the procurement and guardrail problems so they trust your solution?

Jan Oberhauser | n8n 00:34:32

Like we talked about, stability matters: people know where it's running, and they can often use their own local models to deploy. The other piece is that when you build with AI, it can go rogue easily. It deletes state it shouldn't, or sends emails it shouldn't. But because we make it simple, this agent can only do the specific things you've defined. It can't go rogue. You've specified exactly what it can do, including which things require human approval.

That means before something goes into production, someone else can easily review it. And they're not reviewing 10,000 lines of code; they're reviewing a workflow they can easily understand and step through, so they know exactly what it will do. That makes it much easier for enterprises to trust it and release it in production faster than with other systems.

Bottom-Up, Top-Down, and Partners

Carlos González de Villaumbrosia | Product School 00:35:32

This is a common challenge for companies that started in the SMB or direct-to-consumer segment, people building something and bringing it into enterprises. Beyond proving you have the right security checks, what does the go-to-market motion look like? Because product-led growth can only take you so far.

Jan Oberhauser | n8n 00:35:56

We got into most organizations via bottom-up growth, but interestingly, not only bottom-up. We also get in top-down, where someone on the board or in the C-suite, a CTO or a CEO, saw content about n8n and asked, "Why don't we do the same thing in our organization?" They bring it in and often find they're already using n8n, just in a more limited way, which makes it much easier.

At some point you also want to accelerate. Partners are a great way to do that, and it works very well for us. A lot of our community consists of people who built agencies around n8n. They go out and say, "I can help you build this workflow, I can maintain it for you, I can help you figure out what can be automated." They're accelerators. A month ago we announced a partnership with Accenture, we're talking with other system integrators, and more partnerships will be announced soon. These accelerators help us reach more of our user base, because we obviously can't have a one-to-one relationship with everybody, so we use all the channels available to us.

Who Should Actually Build the Automations

Carlos González de Villaumbrosia | Product School 00:37:25

As you partner with consulting firms and implementation partners, one challenge, and we do this for a living too, is that you run the initial sprints, the client sees the magic and loves it, but at some point you want them to be more self-sufficient, and they want that too. So thinking about the adoption curve and maintenance: what approaches are you seeing for large enterprises? A center of excellence, a chief AI officer overseeing implementations, functional leaders handling their own automations? What's your vision?

Jan Oberhauser | n8n 00:38:07

We see all of it out there. But success, for us and for our partners, is not just centralizing everything. If you have a centralized team building automations, assistants, or agents for other people, you get a lot of value, but you don't really empower people. You build for them, and at some point it becomes unmaintainable, because that one department has to maintain hundreds or thousands of automations. That doesn't work.

It's also the opposite of why I created n8n. I built it because I saw that the people with the problems were dependent on other people, like me, to build their automations and agents. The idea behind n8n is that the people who have the problem can solve it themselves. That's why we keep making it simpler and simpler.

We have an AI and automation department internally too, but its job is to empower people inside the organization, not to build everything for them. The people who have a problem should be empowered to build it themselves. The department is there if you get stuck: "I don't know how to do this one thing," and they help you, or they help you figure out what's possible in the first place. Teach people to fish. In the beginning, people have no idea what's possible, so you start small and empower them more and more. Then you document what you did and make sure the right tools are in place. The department creates the guardrails and owns education, but the building should be owned by the people who actually have the problem, because nobody can do it better than them. They know the whole process by heart. Explaining it to someone else is super inefficient, and it'll never be quite the same. For any simple change, you'd have to go back to that other person again. It's just inefficient.

Measuring the ROI of AI

Carlos González de Villaumbrosia | Product School 00:40:13

Exactly. And that's why this is so complicated to measure ROI on. First you need to understand what's possible, and once you taste that magic, it's hard to go back. Adoption is a good way to get started, but at some point people ask, "Where does all this productivity go?" At the same time, you can't give a one-size-fits-all answer of "here's how you measure ROI of your AI implementation." So what's your take on how the more advanced companies are taking that AI-adoption metric further?

Jan Oberhauser | n8n 00:40:50

This is something we struggled with too, because there are so many ways to measure impact. Initially we thought the simplest thing was to track how much time it saved. But that's actually not the best measure. You can cheat very easily: an automation might run every minute and "save" ten minutes each time, but that doesn't mean it saves you crazy amounts of time.

So now, internally, we care less about measuring ROI precisely, because we already know it has a lot of impact. What we want to drive forward is making sure change actually happens: that every department thinks about what they can do to drive change, how they can think differently and have more impact. Each department defines its own AI vision and sets specific things to achieve every quarter, and as a company we make sure each department reaches at least 90% of those AI targets.

I don't think it's one-size-fits-all. For some, it makes sense to track time saved or money saved. You have to decide for yourself. But the most important thing right now is that certain things you can take as a given: you know it provides impact, so you just have to make sure you're applying it well.

It becomes problematic when you have an unknown outcome on one side and very high spend on the other, because then it's no longer clear. That's another reason people appreciate n8n: the cost of running an AI system built with n8n is much lower, because we don't say "AI is the solution for everything." AI is one piece. You need AI, but you also want deterministic logic. For example, "approve those emails," or "do X or Y depending on a certain number," that's deterministic logic. It doesn't need an AI, because AI is expensive, less reliable, and slow. Why do it with an AI? And then you still have human-in-the-loop, which again means you can use it for business-critical use cases, not just a nice demo, because you know the AI can't do anything it's not supposed to. So the cost of running an AI system built with n8n is quite low, and the ROI is clear.

In the simplest form, start by tracking time saved, then go further and track your own metrics. You can even do it dynamically: define an arbitrary metric and save that number on each execution. It might get saved as "time saved," but you can use it for whatever impact your organization is aiming for.

One last thing: remember the example of the AI assistant for the online travel agency. This ROI thinking is important, but very often the value isn't just money saved. It's a better customer experience. People preferred the AI assistant because it never gets tired, it speaks any language, it works 24/7, and it has perfect context. So it's not always a single value. Some things you can drive forward without it being about saving money at all. It might be about a better customer experience. Whatever your company is striving for, that's the thing you should measure.

Carlos González de Villaumbrosia | Product School 00:44:46

I like that, because sometimes when we introduce a new tool, we feel forced to come up with ten new metrics to measure that specific tool's impact, when in reality it's all entangled and hard to isolate. Using the same business metrics you already use to measure productivity, outcomes, and performance is the easiest and most reliable way to see whether it's helping. That's how I try to measure the impact of our own AI implementations: are we seeing customer NPS go up? Is revenue growing faster? If so, great, what we're doing seems to work. It's like going to a restaurant and ordering chicken: if you like the taste, who cares where the olive oil comes from, or whether it's AI or not?

Jan Oberhauser | n8n 00:45:41

Exactly. And often it may even be the right thing to spend more money because of the AI, because what you care about is, for example, speed. If a human takes 15 seconds and the AI does it in three, maybe that's worth paying five times as much. But it really depends on your business and what matters to you.

Carlos González de Villaumbrosia | Product School 00:46:04

Jan, it's been a pleasure to have you on the podcast, see you demo the product, and hear you explain the product and go-to-market strategy. Thank you so much for your time.

Jan Oberhauser | n8n 00:46:14

Thank you for having me. It was great.