Introduction

Most product analytics answer the question "how many?" - how many actives, how many signups, what percent retained. Those aggregates are useful, but they average away the thing an early-stage founder actually needs to see: individual people, deciding day after day whether your product is worth coming back to. A retention curve can look healthy while your best customer quietly churns; a DAU chart can climb while every new signup uses the product once and vanishes. The dot plot exists to make those stories impossible to miss. One row per user, one column per day, a dot every day that user got real value - no averages, no smoothing, just the raw texture of usage. Habits show up as solid horizontal lines, onboarding failures as rows that go dark after one dot, at-risk accounts as dense rows that suddenly stop, and product-market fit (or its absence) as something you can literally see.

The chart has a longer lineage than its recent popularity suggests. Dot plots entered statistics through William Cleveland's work at Bell Labs in the 1980s as a cleaner alternative to bar charts. The specific user-by-day activity grid borrows from two traditions: the cohort analysis tables that growth teams at Facebook and elsewhere made standard practice in the 2010s, and the visual idiom of GitHub's contribution graph, which taught a generation of builders to read a life in a grid of green squares. Its arrival as a startup retention tool is credited to Dave Lieb, who used it at Bump (later acquired by Dropbox) to judge whether the product was truly habit-forming, and who has since evangelized it as the most honest single view of product-market fit: if you can't find rows of durable dots, you don't have it yet - and if you can, those rows tell you exactly whom to call and learn from.

The traditional objection is cost: it's a custom visualization over per-user event data, which meant engineering time nobody wanted to spend. That objection no longer holds. The guide below recreates the Earmark-style dot plot - value event meeting_started, 60-day window, cohort curves and DAU/MAU alongside - as a self-refreshing report built and maintained entirely in conversation with Claude.

What you need

• Claude desktop app in Cowork mode

• The PostHog connector (MCP) hooked up to your project - or any analytics source Claude can query

• One clearly defined value event (ours is meeting_started) — the single action that means a user got value that day
  
  

Step 1 : Tell Claude what to build

Describe the visualization in plain language. The prompt that produced ours, roughly:

"Build a Dave Lieb-style dot plot from PostHog: one row per user, one column per day for the last 60 days. A dot = a day the user fired meeting_started, sized by count (1 / 2–4 / 5+). Ring the user's first-ever day. Add small ticks for secondary events (artifact_created, artifact_copied, vibe_edit), tint rows for users with calendar connected, and add a DAU/MAU strip and weekly cohort retention curves. Group by email domain. Make it a single HTML file."

Protip: copy and paste the transcript from Dave's talk from YouTube to enrich the context.

Useful specifics to include: your value event, the time window, secondary events, and any account/user properties you want shown (name, OS, integrations connected).

Step 2 : Let Claude design the data pipeline

Claude queries PostHog with HogQL and compresses the result so it fits in a single HTML file. Ours encodes each user as one line:

email|companyIdx|firstMeetingDate|grid60|cal|name|os

where grid60 is 60 base32 characters - one per day - packing meeting volume plus three event flags into a single character. 271 users × 60 days fits in ~30 KB. Three queries drive it: the per-user daily grid, per-user metadata (first-ever event date, email, name, OS), and current calendar-connection status from the persons table.

Tip: ask Claude to verify its own output - regex-check every data line, cross-check totals against an independent query, and run the page headlessly to catch JS errors before publishing.

Step 3 : Save it as a Cowork artifact

Ask Claude to save the page as an artifact (ours is earmark-dot-plot). Artifacts persist across sessions, so the page code becomes the single source of truth that later runs can update in place.

Step 4 : Schedule the weekly refresh

Say something like: "Every Friday at noon, refresh this with the latest 60 days of data, update the artifact, and summarize week-over-week." Claude creates a scheduled task whose instructions capture everything a fresh session needs: the exact queries, the encoding spec, verification rules, and known quirks of the data source. Each run only swaps the data payload and dates - the design stays untouched.

Our weekly summary reports: active users and user-days vs last week, one-and-done signups, the newest cohort's W1 retention, churn-risk users (heavy usage then 14+ days silent), and accounts whose active seats dropped.

Step 5 : Iterate in conversation

Changes are one message each, and Claude persists them to both the artifact and the scheduled task so future runs keep them. Real examples from this report: "make the email clickable so it copies to the clipboard," "add first/last name on hover," "add a PC or Mac designation as a column."

The Result

Lessons learned

• Pick one value event and stay loyal to it. The whole chart reads at a glance because a dot means exactly one thing.

• Encode server-side, decode client-side. Connector tools cap output size; compressing per-user data into short strings keeps queries fast and payloads small.

• Write the quirks into the scheduled task. Each run starts fresh, so anything you debugged once (HogQL type gotchas, row caps, join limitations) should live in the task instructions.

• Make verification part of the job. Every refresh re-checks line format, totals, and page rendering before touching the artifact.