Design PostHog Inbox, the self-driving inbox that turns detected product issues into prioritized fixes, for a 10-person startup team.

Introduction

PostHog's stated ambition is to make products "self-driving": instead of humans digging through dashboards, the platform notices problems and proposes fixes. Inbox is the surface where that happens. It gathers signals that PostHog already detects across Error Tracking, Session Replay and Replay Vision, Surveys, Experiments and Product Analytics, clusters related findings into issues, and can open pull requests with proposed changes. The question asks me to design Inbox for a 10-person startup team. This is a hard question because the design has to balance three things: signal quality (no noise), trust (the team must believe the ranking), and action (findings must turn into shipped fixes). I'll clarify, explain why it matters, segment users, find pain points, and then design, prioritise and measure.

Step 1

Clarify Questions (3 minutes)

• What does the 10-person team look like?

• Why it matters: Who reads Inbox decides its format.
• Hypothetical answer: Six engineers, one designer, one founder-CEO, one support/success person, one growth marketer. No dedicated PM or data analyst.
• Impact: Engineers are the main users; the founder needs a summary view.

• Which signals feed Inbox?

• Why it matters: Scope of detection.
• Hypothetical answer: New and spiking errors, rage clicks and dead clicks flagged by Replay Vision, funnel drops, negative survey responses, and experiment results.
• Impact: Inbox must merge different signal types into one issue model.

• Can Inbox act on its own?

• Why it matters: Autonomy level shapes risk.
• Hypothetical answer: It can draft pull requests through a GitHub integration, but a human must merge.
• Impact: Design the review step carefully.

• Is this a new product or a redesign?

• Why it matters: Expectations and existing habits.
• Hypothetical answer: Inbox exists in early form; we are designing the version teams rely on daily.
• Impact: We can learn from early-usage behaviour.

Propose the Goal

Help a small team spend its limited engineering time on the product issues that hurt users and revenue most, by turning raw signals into a short, trusted, ranked list of issues that move quickly from detection to a merged fix.

Define the Scope

In scope: issue clustering, ranking, the issue page, ownership, PR drafting and the feedback loop. Out of scope: building new detectors and pricing.