Automated Product Intelligence

The problem

Analytics can show where people drop off or stop engaging, but deciding what to do next still takes work. At Revnest, I needed a clearer way to turn usage across the free marketplace and paid product into product priorities.

The solution

I built an automation that reviews PostHog analytics and recommends what to improve at Revnest. The automation compares recent usage with the previous period and looks for changes in conversion and engagement.

It ranks possible improvements by impact, supporting evidence, confidence and effort, then sends them to Slack for review. A separate automation checks for approval before creating Linear tickets.

How it works

The architecture, at a glance.

  1. PostHog

    Aggregate events, funnels and comparison periods

  2. AI analysis

    Evidence checks, strategic filters and ranking

  3. Slack review

    A person approves the proposed ranked opportunities

  4. Linear

    Duplicate check and a ticket with formal write-up

Each ticket includes a metric and a review window, so later results can be compared with the original data.

Analysis and approval run separately. A recommendation needs approval before it becomes a ticket, and still needs to go through development (see: Software Factory) before it can be released.

Technology

Analytics
PostHog Query API and HogQL for product events, funnels and period comparisons.
Orchestration
Scheduled AI (GPT 5.6 Sol) automations with saved run records and identifiers for each opportunity.
Handoff
Slack for human review and Linear for implementation requirements and measurement plans.

Worth mentioning

Knowing when there isn’t enough evidence

I built the ranking around what people actually do in the product. Small samples, missing totals and guesses about why something happened all reduce confidence. If the evidence is too weak, the automation makes no recommendation.

Keeping a person in the decision

The analyzer can recommend work, but it can’t change the product or create tickets. A separate automation checks that someone has approved the recommendation before creating work in Linear and then moving to development.

Avoiding duplicate work

Each opportunity gets an identifier so repeat runs can check whether it has already been raised. The ticket keeps the original evidence and measurement plan for review later.