Sprint 1.45.0 1/2 - Feb 6 to Feb 17

[lharries]

Global Sprint Planning

3 things that might take us down

1. Migration in progress
2. Recordings needs to change storage - Ben on it
3. Primary keys running out of numbers - @fuziontech will review the urgency

Retro: What can we do better next sprint?

None

Support hero this sprint

Week 1: @tiina303
Week 2: @mariusandra

Team sprint planning

For your team sprint planning copy this template into a comment below for each team.

Team ___

## Retro

<!-- Grab the high and low priority items from last time and add whether that item was completed or not -->

- 

## Hang over items from previous sprint

<!-- For each item, decide to re-prioritise (and add below) or deprioritise -->

- Item 1. prioritised/deprioritise

## OKR

1. OKR, status (red/yellow/green) and action points if yellow/red


### High priority

-

### Low priority / side quests

-

[mariusandra]

Team Product Analytics

Retro

• Data exploration: Tiles on dashboards @pauldambra

  • Carry over. Some interruptions

• Data exploration: Slick filters @mariusandra

  • Carry over.

• PostHog 3000 prerequisites: Continue yeeting ants Automated visual regression tests for everything @Twixes

  • Not much yeeted. Carries over. Realistically Michael did something more important: visual regression tests.

OKR

1. OKR, status (red/yellow/green) and action points if yellow/red

• Objective 1: Ship PostHog 3000 UX. 10 happy ICP beta customers.
  • Red: haven't really started yet, fixing all other prerequisites
  • HogQL work is powerful and a prerequisite for this, so feeling great overall.
• Objective 2: Make PostHog performance frustration free for our 10 largest customers
  • Green: Continuous progress happening here
• Objective: Systematically prevent regressions across PostHog Part 2
  • Green: A lot of work done on this front already. We have visual regression tests on a lot of scenes now.

High priority 🏮🏮🏮

Week 2 @mariusandra support hero

• Work with team infra to get US ClickHouse less bespoke @macobo
  Why? Infra work needed for performance work that's blocking us.
• PostHog 3000 prerequisites: continue yeeting ants @Twixes
  Why? Michael's priority nr 2 for the last few sprints got promoted to nr 1.
• HogQL unleashed & data exploration loose ends @mariusandra
  Why? It's going to be glorious and you'll wonder how we ever lived without it.

Hang over items from previous sprint

• @pauldambra continues with data exploration tiles on dashboards
• @yakkomajuri continues with never ending performance work
• @thmsobrmlr continues with merging insights with data exploration

[benjackwhite]

Team RRecordings

Retro

• @benjackwhite personal PTO mixed with balancing lots of different topics felt unproductive and exhausting
  • Support in particular absorbing a lot of time to understand
  • @alexkim205 - ignoring support is sometimes the right call otherwise it can be confusing and demotivating
• @alexkim205 Not super productive due to sickness
  • Focused objectives to get default on and network out and achievable despite sickness
  • Setting up an issue and focusing what needs to be done helped keep on track (+1 from BW)
  • Moments wishing could help more directly with stuff on Ben's plate, unsure how to actually get involved
  • @benjackwhite I could be more vocal when getting swamped with things

Hang over items from previous sprint

• ✅ Rollout Network panel to some beta users @alexkim205
  • Will be rolled out to all users end of week (silently)
• ✅ Turn on Recordings by default @alexkim205
  • Should also be done end of sprint
• ❌ Mobile Session Recordings published (alpha)
  • This was a bit stalled due to time off, mostly due to focus on quota limiting

OKR

• O1: Eliminate the biggest reasons product engineers would choose a competitor over PostHog Session Recording
  • 🟡 KR1: Release iOS Mobile Recordings to 5 happy beta testers
  • 🟢 KR2: Release the ‘Network Tab’ to 10 happy customers
• O2: Enable product engineers to quickly find meaningful insights using PostHog session recordings
  • 🌑 KR1: Getting to recordings from an Insight is “slick”
    • Dependent on initial 3000 work from #team-product
  • 🌑 KR2: Filtering for your recordings is intuitive and fast
    • Dependent on DataTables / HoqQL work for this
• NEW OBJECTIVE: Our customers can rely on Session Recordings
  • KR1: Rollout RRWeb2 and improve our ability to fix / improve
  • KR2: Move to new S3-backed storage for cheaper and longer storage

High priority

• Mobile Session Recordings published (alpha) @benjackwhite
  why?: Due to other focuses we made little progress here so same reason as before
• RRWeb upgrade - allow optional switch to v2-alpha @alexkim205
  why?: Identified more critical bugs and issues blocking people from using Recordings

Low priority / side quests

• Contribute some code to iOS recordings @alexkim205
• Following up on feedback from Network panel

[kappa90]

Team CA$H 💸

Retro

High priority

• Hook up pricing page to billing server @raquelmsmith
  • Status: Technically not launched, but should be done by the end of the week
• Rate limiting with special guest @benjackwhite & @kappa90
  • At the final lap, might be fully merged early next week, but we won't rate limit, just log for now, for safety
• Defaulting users into a paid plan on signup @kappa90
  • We have done all the background grunt work, we need to add something in the frontend to explain users what's going on

Low priority

• Verify email addresses @raquelmsmith
  • We'll work on it tomorrow
• Billing emails @kappa90
  • Nothing has been done, prioritised for next sprint
• Improve onboarding flow to explain better session recordings and autocapture @raquelmsmith
  • @alexkim205 has been starting working on this, will collab with session recordings team

OKR

1. Objective 1: Feel confident in our definitions and metrics for all our areas of responsibility

   • Status: 🍏
   • Brand new Growth dashboard, with links to sub-dashboards: https://app.posthog.com/dashboard/54139

2. Objective 2: Improve conversion to paid

   • Status: 🍋
   • Metric we set at the beginning is not relevant (we don't know where the number came from)
   • Currently at ~1% conversion rate from signup to paid, and ~3% from just activation (Discoveries) to paid
   • Action point: run the experiments we have planned, all work done so far is going to enable experimenting much faster

3. Objective 3: We can iterate quickly on pricing

   • Status: 🍏
   • We have refactored the whole billing service to use Plans that can be quickly iterated upon to experiment on both pricing and feature allowances
   • We just need to finalise the last cherries on the pie

High priority

• Rate limiting, if it's not done by the end of this sprint @kappa90
• Defaulting users into a trial of the paid plan on signup @kappa90
• Use the billing Plans API to gatekeep features @raquelmsmith
• Add a new paid plan with no free allotment @raquelmsmith
• Billing emails @kappa90

Low priority

• Verify email addresses @raquelmsmith
• Refactor the Customer.io plugin @kappa90

[EDsCODE]

Team Feature Flags/Experiments

Retro:

• All other client and server libraries for resiliency and JSON payload

  • posthog-js/js-lite
  • python
  • ruby
  • WIP: posthog-ios, posthog-android, react-native
    - Deprioritized most of the other server libraries atm (will add on request)

• Rate Limiting all API endpoints

  • Step 1 in
  • TODO: Adjust limits and then actually blocking

• Documentation @neilkakkar delegated to Ian

Objective:

• Eliminate the biggest reasons product engineers would choose a competitor over PostHog Feature Flags
  • Solid progress (JSON payloads, rate limiting, resiliency)
• Make the experience of creating a feature flag in PostHog slicker
  • Mainly just starting (environments planning)

Planning:

• Posthog-node refactor to be stateless @neilkakkar
  • Will address several user issues:
• JSON payload rollout + iteration @EDsCODE
• Environments @liyiy
  https://github.com/PostHog/product-internal/pull/396
• Cohort CSV issue @EDsCODE

[lharries]

Feedback on the new format:

• Like having OKRs here rather than in the all hands
• Suggestion from Ben to write out the retro but not speak it through during the call

[tiina303]

🚰 Team Pipeline 🚰

Retro

Last goal: PoE “Person Overrides” ingestion shipped and queries enabled for team 2
why: Query Performance while maintaining Data Quality

• @fuziontech - good bit done, but this was very much a fire week (co-location of Luigi and support hero + the incident), feels ok if it only happens occasionally. Didn't really make any improvements to pipeline stuff.
• @hazzadous - felt like Luigi helps protect for export stuff at least. Enjoyed getting the query stuff done, lots of pairing with constraints etc.
• @tiina303 - exports feel like a hot potato. Impressed with folks pushing through the postgres incident & everyone shifted to working on this rather than sticking to sprint priorities & worked well as a team.
• @xvello - for support requests, it's hard to know if something is broken or it's a user problem, e.g. S3 export doesn't work need to check first before telling the user their config is bad
• @tomasfarias - with the Postgres incident it was hard to know where we were, better status for waking up. Lets try to use incident channel better.

Next sprint

Goals:

• PoE “Person Overrides” read & write path shipped and queries enabled for teams who already use PoE @hazzadous
  why: Query Performance while maintaining Data Quality
• Postgres incident follow-ups @hazzadous
  why: Data trust, operational safety
• Exports problems (slow S3 & Snowflake) & metrics @fuziontech
  why: Customers are actively depending on this and it's not working well

OKRs

Objective: Performance

• 🟢 Key Results: We have wrapped up the person-on-event project and have deprecated the old non-person-on-events queries
  • Why? Performance speed up
  • Progress Good progress, high confidence this will ship
• 🟠 Key Results: We have reduced the cost per event for capture by an order of magnitude
  • Why? Infra savings and improves performance
  • Progress Not started, we'll be doing some lightweight capture unlocking. Medium confidence to ship it. We might reduce scope here.

Objective: Reliability

• 🟢 Key Results: We have converted all current US dashboards into IaC dashboards configured in Terraform and made all necessary migrations from StatsD to Prom to support this.
  • Why? Gets US and EU equivalent in terms of monitoring
  • Progress Not started, will be starting work in this sprint. high confidence we'll ship it.
• 🟡 Key Results: All of our alerts have runbooks
  • Why? Improve incident recovery times and share knowledge with all engineers, so that most incidents can be resolved without escalating to the team
  • Progress Not started, will do later. Medium confidence we'll ship it, might reduce scope.
• 🟡 Key Results: Backfills do not slow us down or take down the system. We have tests for this.
  • Why? Improves service quality and protects against bad actors
  • Progress Some progress tied to hot partitions which is related. Medium confidence we'll ship it, might reduce scope.
• 🟠 Key Results: Erroring apps fail gracefully, do not take down anything else, and we have tests to prove this. And re-enable after temporary unavailability
  • Why? Improves service quality and tackles customer annoyance of apps turning off when there's an error
  • Progress Not started. Improved specific apps reliability (replicator and snowflake). Low confidence we'll ship it.