Using your own product is a superpower
Why you should dogfood your product and how we do it at PostHog
Welcome to Product for Engineers, a newsletter created by PostHog for engineers and founders who want to build successful startups.
When was the last time you actually used your product? What about signing up fresh, going through onboarding, and using basic features? If you had to think about it, it was probably too long ago and you’re missing out.
Everyone at PostHog “dogfoods” our product, including non-product teams like marketing and sales. This helps us:
Ship faster. Feedback from your teammates is a lot easier and faster than getting it from users alone. It’s one of the ways we’ve designed our company for speed.
Intercept problems. We almost always discover and fix usability issues or bugs before users report them. Again, this saves us time and improves the product.
Stay motivated. If your product is good, it increases your team’s confidence in it. If your product is bad, it motivates the team to make it better.
Deeply understand our product. We’re better at identifying and fixing cross-functional issues, discovering interesting use cases, and promoting PostHog.
Develop empathy. If we find something annoying, we know our users will too – even more so, probably. This + constantly talking to users = customer obsession.
But none of this happens by accident. It requires a strong, intentional culture of feedback, transparency, and simple, repeatable processes. This is how we do it.
When should you dogfood?
The simple answer is all the time, but we find it most useful when:
1. No one else can do it for you
HogQL, our version of SQL (and an entire querying service), was largely driven by dogfooding. This is because a query language is an advanced tool that takes a lot of effort to adopt. Most users weren’t going to put this effort in.
Instead, we forced internal adoption by making it the underlying query engine for all insights. This revealed a bunch of missing functionality, performance issues, and advanced use cases.
Michael, for example, discovered HogQL was missing missing OFFSET support when he tried to calculate the average number of times a dashboard is viewed.
Adopting HogQL internally helped us discover the limitations of the current system, which ultimately benefitted our users. Had we relied on user feedback alone, it would have taken longer to ship, and been a worse experience for both us and our users.
2. You need to scratch your own itch
Our product team found booking user interviews laborious. They needed to identify users, send them emails, and coordinate a time before getting any feedback. Across hundreds of interviews, this takes up a significant amount of time.
To solve this, they leveraged our site app functionality to build a popup that used feature flags to target the right users with a button to book a meeting in Calendly.
This saved them a massive amount of time while also validating an important use case for what is now surveys. In this way, dogfooding helped us both at that moment and guided our roadmap in the longer term.
3. You should be using your product, but you’re not
A key part of our strategy is being the source of truth for product and customer data, but we still found we needed some non-PostHog tools to do customer analysis.
Identifying and fixing this was the inspiration behind the data warehouse, which enables users to link and query data from external sources like Stripe, Hubspot, and Zendesk. This enables us to dogfood our own solution instead of relying on an external one.
Once we built the basic version, the needs and queries of our sales and product teams guided further development. On top of that, a majority of feedback about issues and usability came from internal teams during alpha.
How to make it happen
Dogfooding seems simple enough when you’re a small team, but you need to embed it into your culture and development process for it to endure as you scale.
We’ve found the following important for doing this:
1. It starts at the top
We really mean everyone. The responsibility for dogfooding does not belong to one person or team. This starts at the top. Our co-founders James and Tim still dogfood the product like they did in the early days.
We celebrate great feedback publicly in our weekly all-hands, and all feedback happens in the open in a dedicated Slack channel. We also funnel lots of user feedback into the same channel via surveys and support tickets, so everyone is reading and engaging with feedback all the time.
2. Trust and feedback over process
This is one of our core values as a company – dogfooding doesn’t work without it. We ask people to be specific, assume positive intent, acknowledge, and use it how they want. We have specific guidelines outlining how to give and receive feedback well.
3. Treat teams like customers
If you’ve read The magic of small engineering teams, you’ll know we have a lot of teams at PostHog. We’re ~47 split into 15 small teams right now.
Making another internal team happy is a common, dogfooding-related goal at PostHog. We go out of our way to interview other teams and ask them for specific feedback. We treat interviews with other team members just like an interview with a paying customer.
4. Tight feedback loops
If you never action feedback, your dogfooding is going to waste. Two ways we do this at PostHog are:
Product engineers. Our engineers take full ownership of a product. This means they can dogfood, use feedback and their experience to figure out what to build next, and write the code to implement it.
Bias for impact. We encourage pull requests over issues and messages. A change that fixes your issue (even if it isn’t perfect) helps us implement feedback faster and ensures the feedback isn’t lost.
5. Separating deployment from release
Feature flags enable us to dogfood without releasing features to everyone. This means we can test in production, fix issues, and ship a more polished product.
Mistakes to avoid
Too much dogfooding can cause you to think you are building what users want, but really only build what you want. Be conscious of the following to avoid it:
1. Dogfooding instead of talking to users
It shouldn't be the only strategy you use to develop your product. Talk to users, run experiments, research your industry and competitors, and analyze your usage data. Remember: your goal is to build something your users want, not just yourself.
2. Over indexing on dogfooding
Dogfooding too much can slow you down and cause you to focus on easy, minor fixes. Real-world usage and feedback are still more important than your own experience, or feedback from your teammates. You must be comfortable shipping big features before they are fully ready, and talking to real users.
3. Your personal and collective biases
Your team is (hopefully) a tiny portion of users representing a small portion of use cases. Dogfooding can bias you toward these use cases and limit the full potential of your product. Not everyone is an engineer building in B2B SaaS.
4. Forcing your team to dogfood
This is a sign there is a fundamental mismatch between the work your team wants to do and the product you are building. You either haven’t created the right culture, your team isn’t your ideal user, or your product isn’t good enough. See: Meta’s Horizon Worlds.
If you decide that dogfooding is right for you, implement it as a culture and practice, and avoid the pitfalls listed here, you unlock a superpower for building a better product. We know this because we heavily relied on it and recommend leveraging it when possible.
Good reads 📖
How to create a culture of dogfooding –
, director of product at Duolingo, dives deeper into how companies like Airbnb, Duolingo, and Etsy build dogfooding into their culture.Eagerly discerning, discerningly eager – Michelle Bu, a product tech lead at Stripe, writes about how dogfooding plays a critical role in creating effective, future-proof APIs developers want to use.
AI’s $600B Question – Sequoia’s David Cahn on the widening gap between the cost of AI and the actual revenue.
The right kind of stubborn – Paul Graham on the difference between persistence and stubbornness, and why it’s essential to startup success.
Words by Ian Vanagas, who refuses to explain where the term “dogfooding” came from.
Interesting. For me it feels that dogfooding is actually sometimes an excuse for not talking to users. It's easy and available. Perhaps we should decide on the % of people we want to have using our product that are not internal, and aim to satisfy that %.
"Too much dogfooding can cause you to think you are building what users want, but really only build what you want"
This is pretty much what's happening over Twitter. Elon was a power user who figured he could make the Twitter experience better for him if he bought the platform. But his experience is very different from the majority of users' so it ended up degrading the experience for everyone else.