How to pitch self-driving

This is a living page for how we pitch PostHog making your product self-driving. It covers the concepts (so you can explain scouts, signals, and sources without tying yourself in knots), the strengths of each and which to lead with, the core pitch, how to run it, and a reverse demo format that lets the customer experience self-driving on their own data. We're still early, so treat this as a starting point and iterate on it as we practice the pitch and learn what lands.

This pitch sits on top of our brand story, so keep it consistent with how we describe PostHog everywhere else. Two things carry through from there: self-driving is the story (the narrative everything sits under), and the customer's product stays the subject – we make your product self-driving, PostHog isn't "a self-driving product" itself.

This page assumes you've already done the work in discovery – it covers what to say once you know their pain, not how to find it. For the mechanics of the wider deal, see new sales and running trials.

In a hurry before a call? Skip to the cheat sheet.

What you're selling

These are the core pieces. The docs pages are more thorough, but you at least need to have these concepts engrained before you can attempt a demo.

The full pipeline: something watches (source or scout) → it emits signals → the pipeline groups them into a report → the inbox researches it → an agent can open a PR. The docs walk the same chain in order, so the self-improving loop is the page to send anyone who wants the whole thing end to end.

Which to lead with - scouts vs signals

The core pitch

Keep it simple. Something like this:

PostHog already has all the behavioral data about how people use your product. We turn that data into signals, feed those signals to an agent running in a sandbox, and it automatically opens PRs that improve your product. The more you put into PostHog, the better the signals get.

That last line is the flywheel line. Every event, flag, and replay you capture improves the signals the agent works from, so more data in means better PRs out. In brand terms this is context – the fuel for the self-driving loop.

The flywheel is stronger than it first sounds, because it isn't limited to product analytics. A scout reads your data through the same PostHog MCP you'd connect to Claude Code, so anything you land in PostHog becomes watchable – a warehouse table, a Stripe sync, a support inbox, even a Slack channel relayed into the warehouse.

Why it works

The pitch resonates because the customer connects the dots themselves. You don't have to convince anyone that behavioral data is valuable, because they already believe it. You're just showing them the obvious next step, which is that data shouldn't sit in a dashboard waiting for a human to act on it. It should drive changes to the product directly.

When it goes well, the customer arrives at the conclusion before you finish. We've seen this play out on an on-site: as the pitch unfolded the team worked through it out loud, described the exact signals use case back to us, and then started sequencing their own rollout, ending with asking whether they should do a Fable 5 audit of all their instrumentation first to make sure they're tagging everything and getting as much as possible into PostHog.

When the customer starts planning their instrumentation rollout unprompted and immediately, you know pitch has landed!

How to run the self-driving pitch and demo

• Lead with the data they already have. Start from the behavioral data they're capturing in PostHog today, not from the agent. The agent is the payoff, not the opener.
• Draw the line from data to PR. Walk through it: data goes to signals, signals to an agent in a sandbox, and the agent to PRs that ship improvements. Let them follow the chain rather than asserting the conclusion.
• Ask what they check manually. "What does someone on your team open every morning?" is the single best scout-discovery question. Whatever they name is a scout, and naming it back to them lands harder than any feature list.
• Land the flywheel. Make sure they leave understanding that more data means better signals means better PRs. This is what turns it from a feature into a reason to instrument everything.
• Let them sequence the rollout. The strongest outcome is the customer proposing their own instrumentation audit. When they get there, help them plan it, since that's the start of the flywheel.
• Leave with one concrete thing, not a strategy. The commitment you want is small and specific: one source switched on for a stream they care about, or one scout pointed at one question. Either proves the concept on their own data, and it's the thing they'll show their team.

The reverse demo

A reverse demo (a term Clay recently popularized) flips the usual script: instead of you driving a polished demo environment, the customer drives their own data. It's a faster path to the aha moment because the value shows up in their product, not a sandbox account.

The catch for us is that a reverse demo only works once there's enough clean data in PostHog for the agent to act on. Clay can have someone build a lead list on the first call before they're even a customer; we can't conjure signals out of an empty project. That makes the reverse demo a great fit for existing customers who already have the data flowing (a natural play for TAMs), and a tougher one for prospects who haven't connected anything yet (TAEs will usually need to get data flowing first, see the pre-call prep below).

Pre-call prep

The whole demo depends on there being real signals to work from, so set that up before the call:

• Ask them to turn on error tracking and session replays for a window of time ahead of the call, so the agent has fresh, real signals to act on by the time you meet.
• Have them get PostHog Desktop downloaded and their GitHub and PostHog connected, so they can kick off a PR live.
• Frame the cost honestly: offer to credit any usage on errors and replays during the demo window, since you need them on to show it at its best, and they can turn them back off after. If it wows them, they'll want to keep them on anyway, and that's the flywheel starting.

Demo flow

Let them drive the whole way. You narrate, they click.

1. Have them open the PostHog Desktop inbox.
2. Walk them through what they're seeing in the reports and PRs tabs, using their own data.
3. Have them pick a report to inspect and kick off a PR from it themselves.
4. Explain the self-driving part: they can set it up to handle bugfix and maintenance PRs automatically, while humans still drive product decisions and new features. (This is the same line as "robots do maintenance, humans do creative work" below, made concrete.)

Using their data for this makes it click and get to the "aha!" moment much more quickly.

The scout-based reverse demo (no data prep or pre-ingest needed)

The source-led version above needs data to accumulate first. The scout-led version doesn't, which makes it the better opener for an account with historical data but nothing switched on yet.

1. In PostHog Desktop, open the scouts page and pick the "Make a scout" suggestion. It scans their actual project and proposes custom scouts grounded in their real data – which is itself the moment, because the suggestions are specific to them.
2. Let them pick the one that makes them go "huh, yeah, I'd want to know that."
3. Run it on demand right there on the call – no waiting for a schedule, and a scout that's still disabled can be run this way.
4. Read what it filed together. If it's good, turn it on. If it's noisy, that's a demo too: show them the dry run and scout notes, because "I can tell it that's known noise, in English" is often what closes it.

The thing to make land here is the memory. A scout reads back what earlier runs learned so it dedupes against itself and gets smarter.

For ideas that work across verticals, and the scout patterns cookbook behind them, send them to scout examples. For a deep dive with two real scouts traced end to end and a walkthrough video, What is a scout? are good references.

How AI observability can fit in

AI products are an easy self-driving pitch: they already know their agent misbehaves, and nobody is reading every trace. Two signal types turn AI observability data into inbox reports.

Evaluations (rolled out to everyone). Ingest AIO events → create an online evaluation that scores them → turn on evaluation reports, where an agent reads a batch of results and writes up what it found. That summary is the signal.

Anomaly detection (alpha). Ingest AI observability events, then add an anomaly detection alert on an AI errors, latency, or cost insight and turn on agent investigation. When the alert fires, the agent checks whether the anomaly is real and writes up what it found in a notebook. Only true positives reach the inbox, as a report summarizing the investigation.

Objection handling

Cheat sheet

For the five minutes before a call.

• The chain: something watches (source or scout) → signals → grouped into a report → inbox researches it → agent opens a PR → human merges.
• The trade-offs between Signals and Scouts: sources give determinism and guaranteed coverage, scouts give judgement and steerability.
• Lead with sources when there's significant volume to triage. Lead with scouts when everything is technically "something" and they need a filter.
• Best demo move: toggle a source and watch the queue fill, or make a scout on their data and run it on demand, live.
• On an AI account: eval + evaluation report ships today, anomaly detection + agent investigation is alpha. Both need AIO events flowing first.
• Never promise: auto-merge, total coverage from a scout, or a PR from every report.
• Links to share: What is a scout?, scout examples, self-driving docs.
• Have open in another tab: the FAQ for anything you get asked cold, and pricing so you never guess at a number.

Iterating on this page

We're actively refining this pitch. If you run it and learn something, whether what resonated, what fell flat, or a better way to frame the flywheel, add it here so the whole team gets sharper.