POSTHOG SETUP & INSTRUMENTATION — $3,997 · 2-WEEK SPRINT

Jake McMahon — ProductQuant

8+ years B2B SaaS · Behavioural Psychology + Big Data (Masters)

Every product question answered from data — not a Slack thread that dies in #analytics.

Most PostHog instances accumulate events nobody queries, dashboards nobody opens, and naming conventions nobody agreed on. This sprint turns your PostHog instance into an analytics system your team actually uses — so every product question gets a data answer in minutes, not a Slack thread that dies in #analytics.

Book the PostHog Setup Sprint → See what’s included ↓

Fixed scope, fixed price. Full refund if you don’t have a working analytics system at the end.

WHAT GETS BUILT

Event taxonomy Every user action mapped, named, and documented

Dashboards 5–8 covering activation, retention, and revenue

HogQL library 20+ pre-built queries for the metrics that matter

Instrumentation spec Engineer-ready tracking plan your team can maintain

Team training 1-hr walkthrough so your team runs it independently

$3,997 · fixed price · 2 weeks · everything stays with you

WHAT IS ACTUALLY HAPPENING RIGHT NOW

Events fire but nobody trusts the data

“We have 300 events in PostHog. Half of them were named by interns, a quarter are duplicates, and nobody knows what ‘button_click_new_v2’ refers to. We can’t answer basic questions without reading the source code.”

Head of Product — B2B SaaS

Dashboards get built and abandoned

“We built five dashboards in onboarding. Two are broken, one uses the wrong event, and the other two no one checks because they don’t answer anything we argue about in planning.”

VP Engineering — Series A

Every question takes 45 minutes to answer

“Our PM wants to know the activation rate for users who used Feature X in their first week. We know it’s in the data. It takes an analyst half a day to write the query every time someone asks.”

Product Manager — B2B SaaS

Engineering and product speak different languages

“Product calls it ‘onboarding completion.’ Engineering fires ‘user_setup_done’. Analytics queries ‘signup_finished’. We have three events that might be the same thing, and no one is sure which one to use.”

Head of Growth — Series B

WHAT THIS TYPICALLY UNCOVERS

Your most-queried events are rarely the ones that predict retention or expansion.

The events your team queries are rarely the ones that matter most.

In our experience, the most-queried events tend to be the ones that were easiest to fire — not the ones that answer the questions your team debates in planning. The taxonomy audit typically reveals that the highest-value user actions are either untracked or misnamed.

Dashboard abandonment usually points to a naming problem, not a design problem.

When dashboards go unused, teams assume the visualisations are wrong. More often, the underlying events are inconsistent or mislabelled — so the charts show data nobody trusts. Fix the taxonomy and the dashboards become useful without rebuilding them.

A HogQL library typically cuts ad-hoc query time from hours to minutes.

Most teams re-write the same queries from scratch every time someone asks a question. A pre-built library with annotated parameters means your team answers follow-up questions in 2 minutes instead of 45.

Your instrumentation spec determines whether PostHog stays clean or drifts back.

Without a documented spec, every new feature ships with ad-hoc event naming. Within a quarter, the taxonomy is inconsistent again. The spec gives your engineering team a reference that keeps the taxonomy coherent as the product evolves.

WHY THIS IS DIFFERENT

Most PostHog setups end with events that measure past activity instead of the moments that actually predict business outcomes — activation, retention, expansion, monetization. This sprint aligns your events with those moments.

The standard approach is to document what you have, recommend what you should add, and hand it to engineering. Six weeks later, nothing has been implemented. The dashboards were built around the existing broken events because nobody had time to wait for new ones.

This sprint is designed differently. The taxonomy comes first — designed around the decisions your team actually needs to make, not the events that were easiest to fire. The dashboards are built to answer specific questions, not to check a box. The HogQL library means your team can answer follow-up questions in two minutes, not two days. And the training session means the taxonomy, dashboards, and queries actually get used — not stored in a doc nobody reopens.

The goal is not a clean PostHog instance. The goal is dashboards your team opens in stand-up and queries they act on in planning. Those are different things, and most setup engagements only deliver the first one.

TIMELINE

Two weeks. Your team opens PostHog in Monday standup and gets the answer.

WEEK 1

Audit + Taxonomy Design

Read-only review of your PostHog instance. Every existing event assessed — what it captures, whether naming is consistent, and whether it answers questions your team actually asks. Missing events identified. Taxonomy designed around your product and decision framework.

→

WEEK 2

Dashboards + HogQL + Spec

5–8 dashboards built inside your PostHog instance. 20+ HogQL queries written, tested, and annotated. Instrumentation spec drafted and reviewed with your team before sign-off.

→

DAY 14

Handover + Team Training

1-hour live session with your full team. Every dashboard walked through, every query demonstrated, every naming convention explained. Session recorded for future onboarding.

Day 14: your team opens PostHog in standup and makes the call — without waiting for anyone.

WHAT YOU GET

Your team answers their own data questions from day 14 — no analyst bottleneck.

Week 1 · Taxonomy

Event Taxonomy Design

Every meaningful user action in your product mapped, named, and documented. A clean taxonomy your engineering team can implement and your analysts can query without reading the source code to figure out what an event means.

Every meaningful user action identified and defined
Event properties specified for each action
No more Slack debates about what an event means
Existing events audited: keep, deprecate, or rename

Week 2 · Dashboards

5–8 Core Dashboards

PostHog dashboards covering the metrics your team needs to make decisions. Built around the specific questions your team argues about in planning — not the generic activation/retention/revenue triad that answers nothing specific.

Activation funnel: where users get stuck and how many
Retention cohorts: who comes back and at what intervals
Feature adoption: which features correlate with retention
Revenue signals: expansion, contraction, and early churn indicators

Week 2 · Query Library

HogQL Query Library (20+ queries)

20+ pre-built HogQL queries covering the metrics that matter most. Each one annotated with what it answers and when to use it. Your team can answer follow-up questions in two minutes without needing an analyst to write a query from scratch every time.

20+ queries covering activation, retention, engagement, and revenue
Any team member answers their own data question without waiting for engineering
Parameters documented so your team can adapt them
Organised by question type so the right query is findable

Week 2 · Engineering

Instrumentation Spec for Engineers

A living document your engineering team can implement from. Covers every event, every property, the reasoning behind naming decisions, and the acceptance criteria for each implementation. Engineers know exactly what they are building and why.

Every event with full implementation specs
Acceptance criteria for each event so QA is straightforward
Naming rationale documented for each decision
Update process so the spec stays current as the product changes

Day 14 · Training

1-Hour Team Training Session

A live walkthrough with your team covering every dashboard, every query in the library, and how to use the taxonomy going forward. Recorded for future onboarding. Your team operates PostHog independently from this session.

Live 1-hour session with your team
Every dashboard walked through: what it answers and when to check it
HogQL library demonstrated with live examples
Recorded for future team member onboarding

On the cost of re-work: every month your team operates with inconsistent naming is a month of queries built on unreliable data. The dashboards built on broken events do not get better with time — they get abandoned. This sprint fixes the foundation so every analysis after it can be trusted.

FIT CHECK

Your events fire but they do not predict what happens next.

GOOD FIT

PostHog is installed but the data is not usable

Events firing · Nobody trusts the data

The situation

You have PostHog in place. Events are firing. But the taxonomy was designed by whoever set it up first, naming is inconsistent, and every time someone asks a question in planning the answer is “we need to check with engineering.” The data exists but it is not usable without interpretation.

What changes

Taxonomy rebuilt around decisions, not convenience
Dashboards that answer the questions your team argues about
HogQL library that turns 45-minute analyses into 2-minute queries

Stand-up goes from “we should check that” to “here is what the data shows.”

GOOD FIT

Moving from Mixpanel or Amplitude and want a clean start

Migration in progress · New PostHog account

The situation

Migrations are a chance to fix the instrumentation you inherited. The bad habits from your previous tool — inconsistent naming, events fired for convenience rather than insight, dashboards built around what was easy to measure — do not have to carry over. This sprint designs the new taxonomy from scratch, so PostHog starts better than your previous tool ever was.

What changes

Clean taxonomy designed before any events are fired in PostHog
Previous tool’s data informs the design without carrying its problems forward
Migration plan that tells engineering what to fire, named correctly, from day one

PostHog starts with better data than any previous tool had.

GOOD FIT

Investor-ready analytics before your next round

Series A or B · Data room preparation

The situation

Investors look at your analytics in the data room. If your dashboards cannot clearly show activation rate, retention by cohort, and revenue expansion metrics — or if those numbers are built on events your team is not confident in — that is a conversation you do not want to have mid-round. This sprint gets your PostHog instance investor-ready in 2 weeks.

What changes

Clean dashboards showing the metrics investors ask for
Data you can stand behind when questioned on methodology
Taxonomy documented so investors can verify the underlying logic

The data room conversation becomes an asset, not a risk.

NOT A FIT

No PostHog, no analytics, or you need ongoing support

Wrong stage or wrong engagement

When this sprint doesn’t apply

If you do not have PostHog installed yet, there is nothing to audit or build on. If you want ongoing analytics support — monthly dashboard reviews, query maintenance, new feature instrumentation — that is a different engagement. And if you need someone to implement the tracking plan in your codebase, that is your engineering team’s work — this sprint gives them the spec.

Better starting points

PostHog Installation

Get PostHog installed and basic tracking in place before running this sprint.

Growth LAB

Ongoing analytics support with monthly reviews and query maintenance.

Analytics Audit

Not sure what you need yet? Start with a diagnostic of your current setup.

What this sprint doesn’t cover

The PostHog Setup Sprint delivers the taxonomy, dashboards, query library, instrumentation spec, and team training. Your engineering team does the code changes. If you need the full picture — including implementation and ongoing support — that’s a different engagement.

Implementing the tracking plan in your codebase — your engineering team ships the code changes
Ongoing analytics support — monthly reviews, new dashboards, query maintenance
PostHog installation from scratch — the sprint builds on an existing instance

For ongoing analytics support → Growth LAB

Jake McMahon — ProductQuant

Jake McMahon

8+ years building retention, activation, and growth programs inside B2B SaaS · Behavioural Psychology + Big Data (Masters)

I do this work myself — the audit, the taxonomy design, the dashboards, the HogQL library. It is not a team of analysts you coordinate with via Slack. You get the senior-level thinking on what your data structure should look like and why, from the first day of the sprint.

The thing most PostHog setups miss is that the taxonomy has to be built backwards from the questions, not forwards from the events. If you design events around what is easy to fire, you end up with data that is technically accurate but analytically useless. This sprint designs the taxonomy around the decisions your team needs to make. The events follow from that.

What I will not do:

Build dashboards that replicate what your team already ignores
Design a taxonomy without reviewing the decisions your team actually needs to make
Deliver a tracking plan without walking your team through how to use it
Implement the tracking plan in your codebase — that is your engineering team’s responsibility

What access do you need?

Read and write access to your PostHog project. I build dashboards and queries directly inside your instance. No code changes to your product are required for the taxonomy design and dashboards. The instrumentation spec tells your engineering team what to implement — they do the coding work.

Teams Jake has worked with

PRICING

Every product question answered from your own data — $3,997.

$3,997

fixed price · 2 weeks

One-time · 2 weeks · full refund guarantee

Event taxonomy design — every user action mapped and documented
5–8 dashboards covering activation, retention, feature adoption, and revenue
HogQL query library: 20+ pre-built queries, each annotated
Instrumentation spec for engineers — implementation-ready
1-hour team training session (recorded for onboarding)
Everything stays in your PostHog instance. No lock-in.

If you do not have a working analytics system at the end of the sprint, full refund. No questions.

Book the PostHog Setup Sprint →

Working means: dashboards your team opens in planning, a HogQL library your analysts use to answer follow-up questions, and a taxonomy your engineers can implement from. If those three things are not true at handover, you pay nothing. The refund is unconditional.

Questions.

Or book a call →

Do we need PostHog already installed? +

Yes. This sprint builds the right instrumentation on top of an existing PostHog instance. You need PostHog installed with at least basic tracking in place. If you have not installed PostHog yet, book a call and I can advise on the right starting point before the sprint begins.

Does this include implementing the tracking plan in our codebase? +

No. The sprint delivers an instrumentation spec that tells your engineering team exactly what to implement, with full specifications for every event and property. The actual code changes to your product are your engineering team’s responsibility. If you need implementation support, we can discuss adding that as a separate scope after the sprint.

What if we’re migrating from Mixpanel or Amplitude? +

Migrations are the best time to do this. Rather than copying a broken taxonomy into PostHog, the sprint designs a clean one from scratch. Your previous tool’s event structure informs the decisions, but you will not carry its naming inconsistencies or architectural problems forward. PostHog starts better than any previous tool you have used.

What access do you need? +

Read and write access to your PostHog project. I build dashboards and write queries directly in your instance. A 30-minute kickoff call to understand your product and the decisions your team needs to make. No access to your codebase or production environment is required.

How quickly can we start? +

Typically within 5 business days of booking. The sprint runs 2 weeks from kickoff. Book a call and I will confirm availability and a start date that works for your team.

What happens after the sprint if we want ongoing analytics support? +

The PostHog Setup Sprint gives your team a system they can run independently. If you want ongoing analytics support — monthly dashboard reviews, query maintenance, new feature instrumentation — that is covered by the Growth LAB. Most teams run the setup sprint first and either operate independently from there, or move into the Growth LAB once they have seen how the system works.

Every product question answered from data — not a Slack thread that dies in #analytics.

Your most-queried events are rarely the ones that predict retention or expansion.

Two weeks. Your team opens PostHog in Monday standup and gets the answer.

Audit + Taxonomy Design

Dashboards + HogQL + Spec

Handover + Team Training

Your team answers their own data questions from day 14 — no analyst bottleneck.

Your events fire but they do not predict what happens next.

What this sprint doesn’t cover

Every product question answered from your own data — $3,997.

Questions.

Every sprint starts with data your team trusts — not a debate about whether the numbers are right.