On developer products the buyer is often also installing the SDK at night. Growth work here is less about tricks and more about finding where people stall before the thing works.

I have wired PostHog and similar tools into products (including meeting surfaces at Huddle01). Same loop every time: name the funnel, measure real activation, fix friction, try one change with a rollback.

Activation is not "signed up"

For tools like ours the useful path usually looks like:

1. Land on docs or marketing
2. Account or API key
3. First integration step
4. First successful connection / publish / API call
5. Come back with real usage

Signup alone is weak. First proof in their environment matters.

export const ACTIVATION_EVENTS = {
  SDK_INSTALLED: "sdk_installed",
  FIRST_CONNECTION: "first_connection",
  FIRST_PUBLISH: "first_publish",
  RETURNING_SESSION: "returning_session",
} as const;

If you cannot say the aha event in one sentence, the charts will look busy and mean little.

Keep event names boring

We mix three kinds of data and they should stay separate:

Past tense. Snake case. One owner per event, even if ownership is a table in the repo. No names in properties unless you have a real privacy review.

// Bad
track("clicked_button", { btn: "start", userName: user.name });
 
// Better
track("onboarding_step_completed", {
  step: "create_api_key",
  duration_ms: elapsed,
  plan: workspace.plan,
});

Experiments need an exit

Flags with a hypothesis, a primary metric, and a kill switch. I also want an expiry date so dead experiments do not live forever in the codebase.

Rough template:

We think putting the API key step earlier raises first_connection in 24h.
Watch signup rate and "api key" support tickets.
Ship if lift holds and those do not get worse for a few days.

I am not putting fake lift percentages here. The point is pairing the win with guardrails.

Docs are the funnel

Developers bounce from a broken first snippet faster than from a plain landing page.

Things that helped:

• Copy-paste env blocks with ugly placeholders, not poetry
• A troubleshooting table built from real top errors
• Errors that link to the exact doc section
• A tiny "did this work" check (CLI or health endpoint)

## Quickstart
 
- [ ] API key created
- [ ] SDK installed
- [ ] env var set
- [ ] doctor command all green

Checklists convert. Fancy prose usually does not.

Stuff I will not do

• Force newsletter signup to read an error code
• Hide self-serve pricing behind sales
• Log customer payload bodies "for analytics"
• Rate-limit docs on purpose

Those boost a chart once and make the product feel hostile.

First month if you have nothing

Week 1: define activation with eng + product, delete duplicate events.
Week 2: server events for money-critical steps, client events for form failures, a funnel dashboard.
Week 3: read failures (tickets or replays), fix one heavy docs page, one experiment.
Week 4: event registry in git, experiment checklist somewhere people use, monthly review that includes eng.

If an experiment needs a comment apologizing for its existence, give it an end date.