Roadmap
Goals
Q4 2026 goals
Our Q4 priority is to make Self-Driving's research valuable enough that customers return to it: surface important findings, help people act through PostHog or their own agents, and verify the impact.
The two most important questions we'd like to answer in Q4
- Why aren't more people trying Self-Driving?
- Do improvements to report quality deliver enough value for users to keep coming back?
Make Self-Driving easy to start and useful for ongoing work – Chris and Dylan
Increase activation – Chris
- Improve adoption. Let new users start from PostHog web. Simplify onboarding by making it UI-first. Run the CLI wizard in a cloud sandbox instead of on the user's machine.
- Improve onboarding and empty states so users understand the value and know how to get their first useful report.
- Help users discover and adopt more capabilities after their first useful report.
- Help users activate later in the user journey when they have data.
- Experiment with report access without GitHub. In this experiment, require a repository connection only for work that needs code access.
- Scouts on by default: every project has the canonical scouts and project-specific suggestions waiting, so turning one on is the whole journey – Andy.
Help committed users turn reports into completed work – Dylan
- Build an effective, enjoyable UI for understanding reports and managing tasks. Make the next action clear.
- Help users understand what was found, what changed, and what evidence supports it, so they can review work confidently with fewer decisions.
- Make assignment and personalization useful: show what each person owns, what needs their attention, and what matters to them.
- Help users find the reports that need attention first, based on urgency, relevance, and work status.
- Enable users to move from a report to implementation and review in PostHog Desktop.
- Improve report notifications so relevant findings reach the right people.
- Support use by larger orgs as report volumes and team sizes grow. Make reports work for teams with more than a few engineers, and keep ownership, work status, and review responsibilities clear.
Make the report layer independent of our UI – Dylan, Georgiy
- Provide reliable MCP access to discover reports, inspect evidence, assign work, and update report status.
- Let users connect their own agents or build their own UI without losing core report capabilities.
- Support PostHog AI for investigating and acting on reports. Provide task views that make ongoing work easy to manage.
- Keep report state consistent across PostHog and external tools.
Keep report quality high as we scale – Alex, Andy
- Improve report quality across signals and scouts.
- Tailor reports across signals and scouts to our target ICPs and personas.
- Measure scout report quality as a number: online judge scouts that score a sample of reports, plus an offline eval suite. Compare a model, prompt, or skill change without a manual multi-hour experiment.
Make Self-Driving pricing clear and sustainable
- Ship new pricing – Olly.
- Ship credit-based pricing for scout runs, so run caps go away and users decide how many scouts to run and how often – Andy.
- Figure out better cost controls for customers around different Self-Driving steps (signals, scouts, research, implementation, review, monitoring) – Olly.
- Achieve positive margin (flex tier, better-suited models, negotiated discounts) – shared.
- Switch ReviewHog to usage-based pricing – Olly.
Close the loop: monitor changes and verify their impact – Mikayla, Alex
- Define expected impact and success/failure criteria for implemented changes.
- Monitor those changes with PostHog data, report evidence, and trigger follow-up research when criteria aren't met.
- Make reports instrument PostHog in PRs by PostHog/external agents.
- Link reports, PRs, and verified outcomes, including PRs created outside PostHog.
Make Self-Driving customizable for our customers
- Let users customize their pipeline with automations in PostHog – Georgiy.
- Let users enable ReviewHog for Self-Driving PRs – Alex.
- Personal scouts: a scout owned by one person, watching their own work, delivering only to them (Slack DM first), with its own noise budget – Andy.
- Make Self-Driving act on feedback: use corrections, the context layer, report discussions, and dismissal reasons to improve future research, reports, and implementation, so users don't have to repeat the same instructions (ambient customization and steerability) – Andy.
- Give users control through settings, prompts, and skills (active customization) – Andy.
Make Self-Driving self-organize and orchestrate itself
- Let Self-Driving orchestrate scouts and signal sources – Mikayla.
- Scouts that act, opt-in per scout: a proposed action on the report with accept/reject, then actions inside PostHog (maintain dashboards, alerts, insights), then external actions through connected MCP servers, gated by per-scout write scopes and tool allow/deny lists – Andy.
- Let scouts improve themselves (without the need to manually run 10h+ experiments for model/effort changes, manually create scouts to look over other scouts, and so on) – Alex.
Experiment with building features – Andy, Olly
- Ship an experimental approach for Self-Driving to move beyond bug fixes and deliver new features.
Product and growth – Annika, Georgiy
- Define our ideal customer profile (ICP) for Self-Driving.
- Define metrics for report activation and repeat use.
- Step up marketing for Self-Driving, for instance, using banger reports to tell compelling stories and reach more customers.
- Work with Sales to clarify Self-Driving's positioning and enable earlier customer pitches.
Only if capacity remains
- Further ranking improvements: explore more advanced or learned ranking if report ordering prevents users from finding useful work. Basic prioritization remains part of the core report experience.
- Take ReviewHog to the next level and add other last-mile features (visual reviews, etc.).
- Make implementation better.
- Autoresearch: get v1 shipped for internal dogfooding – Andy.
- Scouts as a system: a scout schedules its own follow-up run, one-off scouts, and event-triggered scouts that share one trigger primitive with workflows.
- Scouts as a platform: other products build on scouts (Replay Vision digests are the first case), scout templates, and publishing scouts to the skills marketplace.
Anti-goals
- Trying to seek consensus on decisions – we have to lean on folks owning stuff as we're a big team.
- Spending overly long amounts of time debating naming or pricing strategies.
- Taking on ownership of more products.
Handbook
What this team does
We build PostHog's self-driving platform, allowing users to fix bugs and ship improvements in their apps before anyone gets around to reporting them. We help teams catch problems early, turn them into working pull requests, and merge them quickly and confidently.
Two paths run from your data (Session Replay, Product Analytics, Error Tracking, AI Observability etc.) to Reports, and from there to PRs:
- Data → Signals → Signal groups → Reports → PRs
- Data → Scouts → Reports → PRs
ICP
Self-driving is built for small, AI-pilled startups: YC-like companies of roughly 2 to 20 people who already ship with coding agents.
User personas
Assessing customer fit
Use this guide to determine if a prospect's use case is a good fit for Self-driving now, in the future, or at all.
Product engineers (product, growth, full-stack)
✅ Fully supported now
They get the most value since they own a slice of the product end to end and can merge a PR themselves, which turns a report into shipped code with no handoff and no review queue.