search

PostHog / posthog.com

Official docs, website, and handbook for PostHog.
https://posthog.com
Other
368 stars 382 forks source link

Blog: Why and how we do dogfooding at PostHog #8736

Closed ivanagas closed 1 day ago

ivanagas commented 2 weeks ago

Summary

Write a short paragraph on what this article is about. If applicable, what's the opinion or point we want to make in this article?

Write about why and how we do dogfooding at PostHog. Dogfooding gets a lot of search (12k/m), we do it, and our products (feature flags) help us do it better.

Where will it be published?

select any that apply

  • [x] Blog
  • [ ] Founders Hub
  • [x] Newsletter
  • [x] Product engineers Hub
  • [ ] Tutorials
  • [ ] Other (please specify)

Why type of article is this?

select any that apply

  • [ ] High intent (i.e. comparisons and similar)
  • [x] Brand / opinionated (how we work and why, etc.)
  • [ ] High-level guide (concepts, frameworks, ideas, etc.)
  • [ ] Low-level guide (step-by-step guide / tutorial)
  • [ ] Other (please specify)

Who is the primary audience?

select any that apply

  • [x] Founders
  • [x] Engineers
  • [ ] Growth
  • [ ] Marketing
  • [ ] HackerNews
  • [ ] Existing PostHog users
  • [x] Potential PostHog users

What (if any) keywords are we targeting?

list any that apply

dogfooding

Headline options

suggest a few angles

Why and how we do dogfooding at PostHog

Will it need custom art?

Outline (optional)

draft headings / questions you want to answer

  • What is dogfooding?
  • Using your own product
  • Similar to testing in production
  • Resist the urge to do a hogfooding pun
  • Why do we do it?
  • We build tools for companies that look like us. This would be much more difficult if this wasn’t the case. We mention ourselves as ICP: https://posthog.com/handbook/who-we-are-building-for
  • We use a lot of tools ourselves (and want to be all in one). For example, we query Hubspot and Stripe (now data warehouse), we need to book user interviews (now surveys), we use webhooks to work with customer.io and Zapier (webhooks)
  • Building something people want can start with building something you want
  • We test in production. Dogfooding is linked with testing in production. Testing in production isn’t really real unless you are dogfooding, you are missing some of the behaviors that real users might do.
  • Getting feedback from teammates is easier than getting feedback from users. Feedback is super valuable.
  • Engineers do support. They need to know how the product works to help solve problems. Issues can touch multiple products, areas of code.
  • How do we do it? With examples
  • Test in production
  • Use feature flags, canary releases, feature previews.
  • Rely on product engineers to be able to figure out the roadmap and ship code
  • Work cross-functionally, get feedback from other teams. Ask other teams for feedback, let people know when features are being test. Dogfooding does not mean that you don’t need to communicate.
  • Examples:
  • Events without person profiles on posthog.com. We found some issues this way.
  • Managed reverse proxy. We missed adding ui_host when we needed to
  • Data warehouse. Getting requests and figuring out how to query them, get the data into PostHog.
  • Surveys. User interviews, other teams asking about their surveys
  • HogQL support offset without limit: https://posthog.slack.com/archives/C0368RPHLQH/p1687276647298639 and early aggregations: https://posthog.slack.com/archives/C0368RPHLQH/p1674228764423899
  • The pitfalls of dogfooding
  • Dogfood driven development
  • There have been plenty of situations where we let what we needed most drive the roadmap
  • User interview surveys
  • Data warehouse connectors (literally the 3 tools we use)
  • We had a Mykonos OST session on dogfooding where we identified some future areas to dogfood.
  • This gets us real feedback as fast as possible and creates a good base to work off of, we can work with users from there
  • If we can’t dogfood, we need to work hard to find out if users actually need this, how they will use it, work with them to build it. It is slightly a bad sign if we can’t dogfood something, slows us down.
  • Many early features are what we would use, it provides some signal.
andyvan-ph commented 2 weeks ago

Something to consider... the 'how' part is the way more compelling than the why, which I think most people will already be familiar with. I'd probably drop 'Why' from the headline entirely.