n8n CEO: Why we aren’t dead, how to build great AI products, and what I look for in an AI PM

Context

Jan Oberhauser is the founder and CEO of n8n, the workflow and AI orchestration product that many people started treating as obsolete once Claude Code, Cowork, and other agent builders took off. His argument is that those tools did not remove the need for n8n. They made the distinction between a fast prototype and a business-critical system more obvious. For PMs, that matters because the episode is really about what turns an AI demo into a usable product: reliability, auditability, safe handoffs, and product decisions about where AI should sit in the workflow.

The Big Idea

The hard part of AI product building is no longer getting a model to do something impressive once. The hard part is turning that behavior into a system that is reliable, inspectable, safe to operate, and easy for someone else to own.

Jan's core claim is that prototype tools like Claude Code and orchestration tools like n8n are complements, not substitutes. The strategic advantage comes from owning the production layer where models, rules, approvals, data, and teammates all have to work together.

Key Insights

Prototypes and production differ

• Jan draws a clean line between prototype speed and operational readiness.
• Claude Code is where teams can get an agent working in minutes. n8n is where that same workflow should move once it has to run on schedule, survive failure, be reviewed by teammates, and be handed off safely.
• The PM lesson is simple: do not confuse "it worked in a terminal" with "it is now a product." The second job requires ownership, not just output.
• In the live demo, n8n's assistant asked clarifying questions, thought for about eight minutes, then generated a working workflow that could later be extended with more tools and approval logic.

Reliability is product value

Jan treats reliability as a product feature, not an infrastructure afterthought. He gave several concrete layers behind that claim:

• A workflow can define a fallback model if one provider is down.
• Teams can self-host n8n close to their own data for privacy and control.
• Integrations are maintained centrally by n8n, so if an API changes, the fix happens once for everyone instead of every customer rebuilding the same connector.
• The platform handles operational concerns like retries, deployment, and execution state.

That matters to PMs because many AI products look differentiated in demos, but converge quickly once users ask, "What happens when the model times out, the API changes, or the workflow fails at 2 a.m.?" Jan's answer is that those questions are the product.

Auditability builds enterprise trust

• With generated code, Jan says you usually see the input and the final output, but not the reasoning path in between.
• n8n instead exposes each execution step by step. A user can inspect what data went into each node, what came out, and where the workflow branched.
• A team can also rerun only part of a workflow from a specific point instead of restarting everything.
• For handoff and governance, n8n adds sharing, version history, and review steps before publishing changes.

For PMs, the point is bigger than debugging. Auditability is how a company decides whether an AI system is trustworthy enough for compliance, security, onboarding, offboarding, or other business-critical work.

AI needs deterministic neighbors

Jan repeatedly argues that good AI products mix models with ordinary software, not replace ordinary software with models.

• An if statement is cheaper.
• An if statement is faster.
• An if statement is 100% reliable.
• A model should be used only where reasoning is actually needed.

He also showed this in the demo. Sending an email or booking a meeting did not happen automatically. Those actions sat behind an approval step, so the agent had to ask before taking a destructive action. For PMs, that is a design pattern: pair probabilistic reasoning with deterministic control.

Start with narrow workflows

Jan's advice for companies adopting AI is almost the opposite of a transformation memo.

• Do not start by trying to reinvent the whole business.
• Start with a small workflow that is painful, repetitive, and easy to value.
• Expand only after the team has seen real usage and learned what breaks.

His favorite example was a company that automated employee password resets. The use case was not flashy, but it saved multiple full-time employees' worth of time each year because lockouts had previously left workers stuck for hours. The lesson for PMs is that small operational wins often create more adoption than ambitious but vague AI programs.

Win the agent build point

Jan's product strategy view is that "adding an AI button" usually creates only incremental growth. His phrase was that sprinkling AI on top might create 10 to 30% improvement, but owning the place where people actually build agents can create much more.

That is how he explains n8n's growth:

• Revenue grew 10x over the last year.
• The company is now above $100 million in revenue.
• n8n has around 1.5 million active users.
• n8n has more than 1,200 enterprise customers.
• n8n recently crossed 200,000 GitHub stars.

The PM takeaway is strategic. If AI is changing your category, ask whether your product merely uses AI or whether it sits in the value chain where the new work actually happens.

Technical depth now matters

Jan is unusually explicit about how technical he wants AI PMs to be.

• n8n runs in small squads of 3 to 5 engineers, 1 to 2 PMs, and 1 designer. In a setup that lean, a PM cannot be only a coordinator.
• He wants PMs, and even designers, who can use tools like Claude Code, build functional demos, and hold their own in discussions about reliability and scalability trade-offs.
• He looks for people who can go deeper than AI buzzwords and explain what really happens when a workflow scales, fails, or switches models.
• n8n has a dedicated AI trust team that owns evals, but Jan still thinks PMs should understand evals because they are how teams compare prompts and models without guessing.
• He also prefers live problem-solving over polished take-home assignments, because AI makes authorship hard to judge.

The broader implication for PMs is that AI product management is moving closer to systems design. The job increasingly rewards builders who can reason through architecture, not just write requirements.

Mental Models & Frameworks

Prototype then operationalize

Use a two-stage mental model for AI work:

• Stage 1: prototype quickly with a tool like Claude Code.
• Stage 2: operationalize in a system that supports logging, versioning, approvals, retries, and team ownership.

This model helps PMs avoid a common trap: assuming the tool that made the first demo is also the right place to run the production workflow.

Reliability stack for agents

Jan's view of a production-ready AI workflow is a stack, not a prompt.

• Model flexibility: choose the right model for each task, and keep fallback options.
• Execution control: define retries, runtime behavior, and where the workflow runs.
• Integration stability: rely on maintained connectors instead of custom glue code everywhere.
• Data control: self-host when privacy or security requires it.
• Operational visibility: inspect every execution and rerun from a specific failure point.

Use this stack when a workflow affects revenue, security, employee access, compliance, or any other process where failure is expensive.

Cheap logic before models

Before adding a model call, ask whether the step is really a reasoning problem. If the answer is no, use deterministic logic. Jan's argument is not anti-AI. It is about using the cheapest and most reliable mechanism that can do the job.

This is a useful PM heuristic because many AI products become slower, more expensive, and less predictable simply because teams let models absorb steps that should have stayed as rules.

Approval gates for risk

A human approval gate is Jan's preferred pattern for actions that can cause damage if the model is wrong.

• Put the model in charge of drafting or recommending.
• Put the human in charge of final execution for sensitive actions.
• Show exactly what will happen before approval.
• Preserve the approval event in the audit trail.

Use this pattern for emails, calendar changes, account changes, employee onboarding or offboarding, and workflows that touch sensitive business systems.

Decision Principles

Principle: Optimize for handoff readiness

• When: deciding whether an AI workflow is ready to leave a prototype tool and become part of a team's real operating system.
• Why: if another person cannot inspect it, edit it, review changes, and understand what happened when it failed, the workflow is still a prototype no matter how impressive the first demo looked.

Principle: Put AI inside workflows

• When: choosing whether to bolt AI onto an existing feature or redesign the place where users actually create value.
• Why: Jan believes the strategic upside comes from owning the agent-building layer, not from scattering AI helpers across the edges of the product.

Principle: Escalate direction, not details

• When: bringing product questions to a CEO or senior product leader.
• Why: Jan wants PMs to involve leaders early on major direction and trade-offs, so resources are not wasted. He does not want every taste-level UI choice or minor button decision escalated upward.

Trade-offs & Nuance

Power raises product complexity

Jan openly admits that n8n can look technical. That is not an accident. The product is optimized for power, flexibility, and control.

That choice creates a real trade-off:

• Teams with complex, business-critical workflows get more leverage.
• Users who only want the fastest possible personal automation may prefer something simpler.

For PMs, this is a reminder that usability is not just about reducing complexity. Sometimes the right product keeps complexity visible because the user needs the control.

Human gates trade speed

Approval steps reduce autonomy. A fully autonomous workflow will move faster than a workflow that pauses for a person.

Jan's point is that speed is not the only thing being optimized. When a workflow can send external communication, handle sensitive data, or create operational risk, slower execution may be the correct design choice.

Adoption first delays monetization

n8n does not obsess over lead generation or converting every free user as fast as possible. Jan also resists defaulting to per-seat pricing. He says the company is profitable enough to think longer term.

The trade-off is clear:

• Short-term revenue optimization likely goes down.
• Long-term usage, community depth, and market position may go up.

This is relevant to PMs because pricing and funnel choices reveal strategy. n8n is optimizing for becoming the place people build and run automations, not merely the place where they buy seats.

Enterprise growth needs humans

Jan changed n8n's internal ambition from a revenue target with under 500 employees to 1 billion users with under 1,000 employees. One reason was practical: even if product creation gets much more automated, enterprise buying is still a people-heavy process.

His example was blunt. Companies do not sign large contracts without talking to people. The nuance for PMs is that AI can compress delivery work faster than it compresses enterprise sales and trust-building.

Common Mistakes

Mistake: Transform everything at once

Companies often start AI adoption with a huge ambition statement instead of a bounded problem. Jan says that usually leads to weeks of building the wrong thing.

The better move is to start with one workflow that has clear pain, clear ownership, and visible ROI.

Mistake: Replace rules with models

A common failure mode is handing an entire workflow to a model because it feels more modern. Jan argues that this makes systems more expensive and less reliable than necessary.

The better approach is to keep deterministic steps deterministic and reserve models for tasks where judgment actually adds value.

Mistake: Escalate trivial product details

Jan wants PMs to bring direction, not noise. If a PM pulls in senior leadership for every minor detail, the organization slows down without making better decisions.

The better approach is to escalate early on bets, architecture, and product direction, then own the smaller execution choices inside the team.

Mistake: Stop at prototype success

A workflow that worked once in a coding tool is not finished. It may still lack logs, reviews, retries, handoff paths, privacy controls, and model fallback.

The better approach is to treat the first successful run as the start of product work, not the end of it.

Practical Application

Separate prototype from production

Before approving an AI workflow for broader use, write a short readiness checklist:

• Who owns the workflow after launch?
• What happens if the primary model is unavailable?
• Which steps need logs for debugging or compliance?
• Which actions require human approval?
• How will another teammate edit or review changes?
• Where does version history live?

If those questions have no answer yet, the workflow is still in prototype mode.

Add approval gates early

For any workflow that can send an email, book a meeting, change a record, or touch security-sensitive data:

• Add an explicit approve or reject step.
• Show the exact action before execution.
• Decide who gets asked for approval.
• Preserve the approval event in the execution history.

This turns vague "human in the loop" language into a concrete product behavior.

Mix rules with models

Take one AI workflow and label each step as one of three types:

• Rule: deterministic logic such as routing, thresholds, formatting, or branching.
• Model: reasoning-heavy work such as drafting, extraction, summarization, or synthesis.
• Human: approvals, overrides, or exception handling.

Then remove model calls from any step that is really just a rule. This usually improves cost, latency, and reliability at the same time.

Automate one painful workflow

Pick a recurring workflow with clear business value. Good candidates from Jan's examples include:

• employee password resets
• employee onboarding or offboarding
• security monitoring and alert handling
• inbox or calendar triage

Keep the first version intentionally small. A narrow workflow that people trust is a better starting point than a broad workflow nobody adopts.

Interview for technical reasoning

If you hire PMs for AI products, add a live exercise instead of relying too much on a polished take-home assignment.

Ask the candidate to reason through a real scenario, such as:

• what happens if the primary model goes down
• which steps need deterministic logic instead of a model
• where a human approval gate belongs
• how to inspect failures or compare model changes

Jan's point is that AI makes it easy to fake fluency in a take-home artifact. Live reasoning reveals whether the PM actually understands the system.

Questions to Consider

• Where is your team treating a successful AI prototype as if it were already production-ready, even though nobody has defined fallback behavior, approval gates, or execution logs?
• Which recurring workflow at your company has enough pain and clear ROI to justify automation now, even if the first version uses almost no AI at all?
• In your current AI product, which steps are true reasoning problems for a model, and which steps should be deterministic rules because rules are cheaper, faster, and more reliable?
• If a PM on your team described an AI system today, could that PM explain model fallback, auditability, retries, and evaluation strategy in concrete terms instead of buzzwords?

Bottom Line

Jan Oberhauser's core message is that AI product quality is defined less by model magic than by system design. The winning products are the ones that combine models with rules, approval gates, logs, and handoff paths so the workflow can be trusted by a real company, not just admired in a demo.

Case Studies Mentioned

SAP embeds n8n directly

SAP did not only make a strategic investment in n8n. Jan says SAP is also adding n8n directly into its product so SAP customers can use it out of the box without a separate install or separate billing setup.

The product lesson is about distribution. When orchestration becomes the default layer inside a large platform, adoption gets easier because the workflow tool is present at the moment the need appears.

Password resets saved headcount

Jan described a company that automated employee password resets with n8n. The work was not glamorous, but employees had previously been locked out for hours, and the automation saved multiple full-time employees' worth of time each year.

The lesson is that AI and automation value often comes from operational bottlenecks, not from the most visible demo use cases.

OpenAI launches lifted demand

Jan said n8n has been declared dead many times, including when OpenAI launched its own agent builder. Instead of hurting demand, that period became one of n8n's fastest growth moments.

The lesson is that category expansion can help adjacent products when they solve a different layer of the stack. More interest in agents can increase demand for orchestration, reliability, and governance.

Tools & Products

People to Follow

Jan Oberhauser

Jan Oberhauser is the founder and CEO of n8n. He is especially useful to follow if you care about AI orchestration, how to make agents production-ready, what technical depth he expects from AI PMs, and how a profitable AI company thinks about adoption, community, and long-term product strategy.