PostHog, Mixpanel, Amplitude, Heap - what Data Driven Product Development actually looks like

What Am I Missing
,
1

Hi all!

I’d like to think SaaS companies use data for decision-making around product development way more than traditional industries do. But I’m curious to get perspective from Founders, Product Managers, UX Designers, Growth Officers & more on Relay to dig deeper into how these product analytics solutions are being used in day-to-day practice.

What we’ve seen at our startup (https://www.orchest.io) is that while we collect the event data and have access to it through both PostHog UI & Metabase for custom queries, we tend to overlook the data in day-to-day product development processes (review meetings, roadmap prioritization sessions, etc.).

If you have opinions/perspectives/learnings to share please leave them in this thread.

For those who are interested: I’m looking to connect 1:1 to talk in more detail about this topic. Please shoot me a message on rick at orchest.io if you want to dig deeper and share detailed learnings about what works & doesn’t or simply brainstorm together.

3 Likes
2

Hey Rick! We definitely struggled with that too at eesel. What we found works best is to create a “systematic” way to check in on these metrics, so it’s not just looked at on whims.

  • We aligned on some key metrics (like active users, growth). Each weekly / monthly planning, before we discuss the week’s / month’s goals, we look at the metrics for the past week / month. It’s a concrete part of planning.
  • We made a “growth plan” which defines our “path to default alive” and we check in on that every month. I wrote a blog on this and shared the template we have - Track your path to default alive - The Paperclip by eesel.app
  • When we roll out a new beta / experiment, we “systematically” have a Metabase dashboard for it, and look at the key metrics each week.

It comes down to both defining the metrics in a systematic way (wrote a blog on that - Your metrics belong in a system - The Paperclip by eesel.app) and consuming them in a systematic way.

We’re definitely not experts on this haha, but it seems to be working alright.

4 Likes
3

Tricky topic indeed!

The 2 things I found to be helping
1/ have no intermediary, make sure the data is accessible by any PM/EM that would tend to access it. Using products like june.so or amplitude help dramatically make sure people don’t overlook data simply because they can’t handle it on their own
2/ Make it a habit: In every product pitch we build, we have a section dedicated to it + in every weekly update, and every investor update (my monthly ritual), report on the same simple KPIs, over and over.

Good luck Rick!

4 Likes
4

:100: agree here. Layers = friction.

I really like that! Proposals need data ^^

@amogh thanks for contributing your thoughts.

  • Metabase dashboards for experiment/beta metrics sounds great. I guess you did the hard work of making sure the data for those reaches the Metabase configured sources :slight_smile: Or did you magically make that painless? If so, do share, haha.
  • “Path to default alive” is a great focus. Even for venture backed startups it’s a great milestone to hit because it gives you the additional freedom to do what’s right for the company.
  • Really enjoyed reading both articles you linked. Especially ‘Your metrics belong in a system’ shows really clearly how metrics in isolation aren’t as useful as understanding the bigger picture they’re a part of.
2 Likes