- The Product-Led Geek
- Posts
- š Unconventional Growth Secrets from PostHog
š Unconventional Growth Secrets from PostHog
Ben Williams
March 11th, 2025
Welcome folks! š
Todayās edition is epic. It turned out to be one of my favourite Product-Led Geek posts ever. And itās a big one - it will take 15-20 minutes to read, but I promise it will be worth it.
Itās the unconventional growth story of PostHog, courtesy of an in depth interview from co-founder James Hawkins. This isn't your typical growth playbook; it's a deep dive into the contrarian approach thatās elevated PostHog to legendary status in the developer world.
Without further ado, letās dig in!
TOGETHER WITH INFLECTION.IO
If you've used Clay, you mustāve seen this viral "week in review" emails from Clay, either directly or in countless LinkedIn posts by other Clay users.
These emails are so well-received that they are being organically shared and praised by customers on LinkedIn.
By focusing on what matters most to their usersāpersonalized product stats and key insightsātheyāve managed to make their emails stand out in a crowded inbox with Inflection.
Learn how Clay built this viral 'Week in review' email with Inflection.io in this case study.
Please support our sponsors!
GEEK LINKS
3 interesting, amusing, or enlightening links
1. Engineering Viral Growth: The Science Behind Word-of-Mouth Loops
2. Lessons in Product Scaling and Storytelling from Figmaās CPO
GEEK OUT
Unconventional Growth Secrets from PostHog: From Zero to Scale, the Open-Source Way
Today, Iām diving deep into the fascinating story of PostHog, the open-source product analytics (++) suite that quickly captured the attention and admiration of developers worldwide with their positioning and no-bullshit approach to product.
Iāve been fortunate enough to have the opportunity to pick the brains of James Hawkins, Co-founder and Co-CEO of PostHog, and the insights he shared honestly blew my mind, while simultaneously seeming like complete common sense. š¤
This is a must read for anyone building in the dev tool space, or indeed anyone who leans toward just doing the right thing in product and growth - pragmatically and from first principles.
What you will read about is a contrarian, sustainable, and profoundly effective approach to scaling a developer tool ā one meticulously crafted on word-of-mouth, authentic audience building, radical transparency, and a foundational belief in the enduring power of open source.
Iām so excited to share this post; it's a deep dive into the foundational approach, strategies and mindset that propelled PostHog to the forefront of the product analytics space, and beyond.
If you're a founder, product leader, or growth operator serving developers (or just anyone with an interest in grass-roots, first-principles driven growth), prepare to challenge your assumptions and see a new perspective on what truly drives sustainable, product-led growth.
The Genesis of PostHog: Frustration as Fuel, Open Source as the Path
The PostHog story isn't one of overnight success or accidental virality.
Nor was it a straight line to success.
Instead, their path to product-market fit was paved with six distinct product pivots in just nine months.
This relentless iteration and willingness to learn from each misstep is a key aspect of their growth story.
After 5 early pivots, they landed on dev-first analytics.
And this direction not only gained traction, but is one rooted in personal frustration and a deliberate choice to challenge the status quo.
James and his co-founder felt the pain points of existing analytics solutions acutely.
They were tired of the sales friction, the opaque pricing, and the feeling that existing tools weren't truly built for them.
āAs two fairly technical people, we just wanted to get started using analytics without āhopping on a quick callā to talk to salespeople and feeling ripped off about pricing!
In terms of the category of product, we also felt developers often have good ideas about what to build and are repressed by product managers. We wanted to provide product tools to developers as a result."
nobody will remember:
- your salary
- how ābusy you wereā
- how many hours you workedpeople will remember:
- if you hopped on a quick call
- when you hopped on a quick call
- how many quick calls you hopped on
- how you made them feel when you hopped on a quick callā james hawkins (@james406)
2:01 PM ā¢ Aug 15, 2024
They saw a gap in the market ā a developer-first, transparent, and accessible analytics solution ā and they were uniquely positioned to fill it.
The first PostHog ICP for dev analytics
And they leant into open source as the philosophical cornerstone of their approach.
āIf a developer can pick software that is also open source, itās just better.
You can dig into bugs a bit yourself, trust what it is doing way more, and it shows that the company just gets what they want - which usually means they also just get how to do engineering better and will have a higher quality experience in general.
We donāt care that much about enterprise - we have a bunch of fortune 500 companies, but they come inbound so we donāt go out of our way. Our focus is signing up hundreds of thousands of companies of any size!āā
For PostHog, taking the open source path was about trust, transparency, and a deep respect for the developer community.
It was about building a product with developers, not just for them.
PLG Go-To-Market
When PLG was really starting to gain traction as an effective GTM motion, PostHog were right there with it.
They eschewed outbound sales entirely, choosing to cultivate inbound growth through content, community, and a relentless focus on word-of-mouth.
How do they grow?
āWord of mouth and audience building is how Iād frame it.
We started with word of mouth - we figured this out by asking users.ā
But this wasn't a passive, "build it and they will come" approach.
It was a deliberate, strategic choice to build an audience of passionate advocates who would organically spread the word.
They understood that in the developer world, credibility and trust are earned, not bought.
āThe really interesting thing was then asking them why they got recommended us. It turns out four things - all the tools in one, low pricing, support from technical people and developer brand.
We just do those things to the greatest extent possible!
No growth hacks.ā
Their GTM strategy didnāt focus on pushing a product; instead they emphasised building a community around a shared problem and offering a solution that developers genuinely loved and trusted.
And itās clear that their strict focus on inbound growth through open-source has shaped their product development and go-to-market strategies differently from traditional B2B SaaS companies:
āVery differently. I think most point solution companies offering one product, with VC backing, have to go upmarket to accelerate revenue growth.
This means they wind up focusing on the features super huge companies need to drive sales.
Weāve been able to ship āeverythingā (well, weāre trying) that 2 person software teams need instead - because we donāt prioritize big customers.
We prioritize selling more tools to our existing customers instead.
Big ones turn up along the way - one day weāll have more enterprise stuff, but on a pull basis. Maybe 5 years from now.ā
Everything the PostHog team has built (+ WIP and roadmap items) in a short time
But the approach has not been without itās challenges for the PostHog team:
āCommunity has been super hard.
Iām still not happy at all with it really.
Weāve wound up with a gazillion support questions, that weāre gradually working on making more self sustaining - we built a forum and Q&A into our docs first, which have proven popular but people donāt help each other out much yet.
Next, weāre going to ship a karma / merch system for helpful users.
Weāve put more energy into trying to do community on line than in person.
Now weāre bigger though we think we can pull off a series of events, weāre playing around with how this will work still though.ā
Something that fascinated me about the approach that PostHog took was them delaying monetisation to focus on building a strong user base.
I asked James to walk me through the strategic framework they used to determine the right timing and approach for introducing paid features without alienating their open-source community:
āYes. Rule 1 - do you have competitors doing lots (ie $100M ARR) or more of revenue?
If you do then monetization will be easy, but standing out will be hard, so work on standing out and getting any usage first.
If you donāt have successful competitors (NB a big fundraise does not always mean lots of revenue), then very early on try to make some money.
As a devtool, people look us up online long ahead of talking to us.
Get pricing on your pricing page on your website super early, and make it incredibly easy to contact you about it.
We used our website a lot to signal what we offer, what it costs and how to buy things.
Donāt hide this stuff - optimize for learning.
Ahhh, music to my ears.
For more on how great dev tools present themselves to the world (including an example from PostHog) check out the Ultimate Guide to building Developer Tool Websites:
Paradoxical Pricing
PostHog's pricing strategy sticks a middle finger up to conventional B2B SaaS wisdom.
In a market where competitors often charge a hefty premium for enterprise features, PostHog opted for enduringly low prices, prioritising accessibility and widespread adoption.
āLower prices increase adoption, retention and usage.
This offsets the decrease in lifetime value - so we make more money by charging less.
Itās awesome.
We can get away with big moves like this because our revenue is diversified across our products whereas most competitors have it very concentrated on just one thing so they only discount new products that have little traction.ā
They got a lot of airtime with a recent price DROP, accompanied by a brilliant campaign āWeāve decided to make less moneyā:
Geek Note: The little touches are brilliant and a hallmark of how PostHog communicates with the world.
Notice the * at the bottom of the email:
*Our marketing team insists we should say we're 'best value' rather than 'cheapest' but š¤·
Taking a step back, their pricing strategy fundamentally redefined value in the product analytics space.
PostHog recognised that lower prices, combined with a comprehensive, open-source platform, could create a powerful flywheel effect, driving adoption, usage, and ultimately, long-term revenue.
āWe figured it was better for users and because we dominate PLG in our industries, felt it would help maintain this advantage.
We were in a meeting debating some super complex āreverse trialā that downgrades you, to try to lure customers into paying more often, but we came up with something simpler ācharge less than the big competitorsā, which was quicker to implement and worked well.
Marketing it was super easy because itās an insanely popular move to make with users. Itās harder to market things that suck like high prices!
I donāt want to sell ice to an inuit, I want to sell it to people on a hot day.ā
Their philosophy here goes beyond affordability.
What theyāre doing is democratising access to powerful product analytics (++) and aligning their pricing with the values of the open-source community.
Itās also interesting to look at PostHogās revenue transition from self-hosted to cloud.
Given the roots of the company, this was a significant pivot, so I asked James to tell me more:
āSome users were self hosting for no reason other than they liked us so we just hosted it for them - ālo a cloud product was born.
Cloud users were way happier and needed far less support.
We went from 0% revenue in cloud and 100% from self host, to 90% revenue in cloud and 10% self host because cloud grew so much quicker as a result, and cloud customers would buy faster and were less risk adverse.
However, even with a 90:10 split, the support questions were 30:70! And that was mostly debugging other peopleās k8s over slack, which isnāt much fun frankly. We dropped the paid self hosted product, got SOC2 types 1 and 2, and HIPAA, then nearly every customer moved over. We gave it for free to a few that couldnāt do cloud.
We sped up massively as a result and leant into being way wider than every other product in cloud with our newfound engineering velocity.ā
Radical Transparency
In an era of carefully curated marketing messages and opaque corporate practices, PostHog chose radical transparency as a core tenet of their brand.
They open-sourced their code, shared their roadmap publicly, and even made their compensation structure transparent to their team.
āFrom the start, it has been about trust.
The foundation of trust is transparency.
Why wouldnāt you just do something that increases customer trust?
I shall tell you - fear about competitors!
Breaking news: startups die by a lack of interest, not competitors, virtually 100% of the time.ā
No feel-good PR exercises here; this was a deliberate strategy to build unshakeable trust with their developer audience.
Developers are inherently skeptical of marketing hype, and PostHog chose to build trust through authenticity and openness.
āMore trust with customers was the start, later though it built an awesome employer brand and means we can hire 100% inbound which is great.
It has meant we just run the company really freaking well.
Nothing like getting someone else to look at your work to up your game, so chucking it all out there online for anyone to judge is probably the most extreme version of that, and it drives down organizational debt (the equivalent of tech debt but for short term decisions about how you run the business).
Writing this stuff down really helps with clarifying your thoughts, let alone running things more fairly and efficiently.ā
For PostHog, transparency is a competitive advantage - attracting talent, fostering community, and streamlining internal operations.
And of course, we canāt mention PostHog and transparency in the same sentence without linking out to their incredible Handbook which has been there from day one.
As PostHog launched, their public handbook signalled maturity and built trust even before they had a large team or extensive resources.
It really is a wonderful and enlightening read and I encourage you all to go check it out (after youāre finished with this post of course!).
Metrics as a Compass
PostHog's data-driven culture ignores vanity metrics and obsessing over short-term gains.
They use metrics as a compass to guide product evolution and ensure they're delivering genuine value to their users.
āWe track a ton (30+) of metrics for every product.
We do a monthly grow review.
We use this to set context for how itās going with the team lead for each product team.
They then decide if they need to tweak any of their priorities.ā
PostHog Feature Flags and Experimentation Usage Growth
Their metrics framework directly supports empowering product teams to own their growth and make data-informed decisions.
I probed for a bit more detail around the metrics they cared about, and (in wonderfully transparent style) James shared:
āFor the products we do growth reviews for (all of our mature products with standalone revenue streams), we have a standardised metrics template we use.
That also allows us to compare metrics across products, and understand if a product is performing majorly above / below average compared to others.
Some of the top metrics we care about:
On the revenue side:
ā”ļø Overall revenue growth rate
ā”ļø New revenue growth rate (revenue % of first time paying customers)
ā”ļø Revenue expansion rate
ā”ļø Revenue churn rate
On the usage side:
ā”ļø No. of customers using the product + customer growth rate
ā”ļø Activation rate
ā”ļø Usage retention rate
Plus we track a NPS score, but here we care more about the qualitative responses to our NPS survey than the actual rating.
The decision to prioritise improving a certain metric is always made in relation to other products.
e.g. if for a product, there are no glaring feature gaps we need to fill immediately to make customers happy, general customer satisfaction is good, product usage continues to grow, but our revenue retention is below average (what we can see in other PostHog products and industry benchmarks), thatās a very good indicator for the team to spend more time on that metric, first figuring out what causes churn, and then implementing improvements and/or running A/B tests to try and reverse the trend.ā
I think this is a great reminder that while having abundant data to hand is important, focusing on a few things that matter is usually a better approach than trying to follow everything but the kitchen sink.
Of course, as an open-source company that helps others track product analytics, PostHog is in a unique position regarding telemetry.
So how do they navigate the inherent tension between wanting to instrument PostHog itself to improve the product, while respecting the privacy-conscious nature of self-hosted users?
āWe donāt focus on the most privacy focused customers - since the ultimate in privacy focused analytics is no analytics at all.
For open source stuff, we track things at an individual (but anonymised) level mostly.
This is enough.
For cloud we track de-anonymised data which is useful for understanding who is using our stuff, and thus if theyāre in our ideal customer profile or not.
That informs if we should try to talk to them, how heavily to weight their feedback and what we should expect their retention to be like etc.ā
They use metrics to understand user behaviour, identify friction points, and continuously refine their product to better serve their community.
āWe use this to set context for how itās going with the team lead for each product team. They then decide if they need to tweak any of their priorities.ā
For PostHog, metrics go beyond measuring commercial progress and success - far more important to them is understanding their users and guiding their product towards ever-increasing value.
But what about platform-wide Growth?
āWe have three people on a growth team. They own quite a lot of stuff:
1. Activation (since people may activate into one or more products)
2. Our billing system - this will get split out into its own team one day (and perhaps should become a user facing product)
3. Our āTeamā and āEnterpriseā plans and associated features - these will get split out into their own team(s) too one day
In practice, the last two things have occupied 85% of our time pretty easily.
The team does a monthly growth review that is for company wide metrics (since often this involves querying the billing system) too - this is a useful session and I attend most of them.
This team is starting to look at things like cross sell, overall retention etc.
Things that an individual product would miss but matter greatly to us.ā
When I probed more about one of my favourite topics - Activation - hereās what James shared:
āEvery product has a unique activation metric.
Typically, it's a combination of events that correlate to above average retention.
For example, activation for our session replay is analyzing five recordings, and applying a replay list filter at least once.
The repetition is important here.
Someone watching just one or two recordings didn't correlate to higher retention.
Our process starts by gathering a big list of events we think might "hook" users into our product.
We get these by looking at usage of that specific product and by asking customer-facing teams what they think.
Next, we create groups of 3-5 events to test together.
We aim for 5-10 different groups, including the number of times the event occurs (e.g. watched 5 replays vs. watched 1 replay).
We then compare the retention against our product's average retention rate for all companies.
We look for a retention percentage that's higher than our average retention rate.ā
Beautifully simple and practical.
PostHog Product Analytics Activation
Small Teams, Nimble Execution
PostHog's organisational structure is a reflection of their values ā lean, agile, and fiercely independent.
They've embraced the small, cross-functional team model, fostering a culture of autonomy, creativity, and rapid iteration.
āIt gives a product advantage - we ship more, so we can offer more products. Thatās the number one reason people recommend our stuff. When we offer more products, we can charge less for each one.
Those two added up mean people say ājust use PostHogā.ā
The PostHog Teams!
This structure enables speed, but also empowers individual contributors, fosters a sense of ownership, and enables a culture of continuous shipping and learning.
āMost of our thinking revolves around how to maintain our culture as we grow.
For example, it's hard to be spontaneous and have fun in a big team, so we keep our teams small, which encourages autonomy and individual creativity.
For us, this means product teams no larger than six people, and not being precious about existing teams.
If it makes sense to create a new team, or split an existing team into smaller ones, we just do it with little ceremony.
At most companies, reorganizing a team would be a major event. At PostHog, it's just a regular day.
This also means people can go where their curiosity takes them. We never want people stuck doing something that isn't fun for them.ā
By prioritising small, autonomous teams, PostHog has created an environment where innovation thrives, decisions are made quickly, and the focus remains squarely on delivering value to their users.
Stepping on Toes
Perhaps the most fascinating takeaways from PostHog's growth story is their unwavering commitment to "fun" and "stepping on toes without taking it personally."
For PostHog this is a deeply ingrained cultural value that shapes their leadership, decision-making, and overall approach to building a company.
āWeāll just do fun things when we want to. The end result I believe is people will work here way longer, and it will help reduce undesired churn of our team.
Frankly you live once and Iād rather have a nice time.
If we want to build a $100bn company, or bigger, itāll take a long time - weāre trying to win a marathon.ā
This emphasis on fun isn't frivolous; it's strategic.
It fosters a culture of long-term commitment, reduces employee churn, and creates a more sustainable, enjoyable path to growth.
The "stepping on toes" philosophy, while seemingly abrasive, promotes direct, honest feedback, accelerates decision-making, and builds a culture of radical candour.
āMy cofounder is Dutch and can be super direct.
Iāve learned a lot from him on this front.
Our engineers just build what they want, but likewise Iāll just declare changes I want to make.
I donāt screw around with socializing ideas endlessly in private 1/1s (aka politics), I will just post them in Slack for others to agree or pushback in public.
My ideas donāt always happen, just like everyone elseās.
Doing this from a well intentioned place over and over as a team builds an incredible degree of trust and honesty - both of which help you scale.
The reality of a startup is you are default screwed, so you better be honest.
Softly padding around things isnāt really honest and will hurt your performance because step one is realizing what it is.
Being honest will mean your team has a higher degree of trust.ā
I love this so much.
For PostHog, culture isn't an afterthought; it's a core growth driver, attracting talent, fostering innovation, and creating a workplace where people genuinely enjoy building and scaling a product they believe in.
PostHog's journey is a blueprint for a different kind of B2B SaaS company.
āWe doubled in size in the last six months of 2024, it was super smooth and low stress, I believe as a direct result of a very clear set of opinions on how we work, that already pre-selected candidates who want to work like that before they even applied.ā
It's a testament to the power of challenging conventional wisdom, embracing transparency, prioritising user value, and building a company culture that's as human as it is high-performing.
If you're building a developer tool startup, PostHog's unconventional wisdom offers a refreshing and highly effective path to consider.
Put aside traditional growth playbooks, embrace radical transparency, focus on building a product developers love, and create a company culture that's as unique and impactful as your solution.
Aim to build a company that developers trust, admire, and want to be a part of.
For developer tools, that's the ultimate growth hack.
Before we wrap up, I asked James what one piece of advice heād give himself if he were starting over with PostHog:
āGo multi product in cloud. You owe me 2 years of saved time. Have fun!
In reality - āthe more ambitious you are, the easier it will getā.
I wish Iād been more ambitious in the first year or two. Investors/customers and employees come more easily and itās more entertaining.ā
I want to say a huge thanks to James for taking the time to satisfy my curiosity and be so forthright in sharing incredibly valuable detail. š
Actionable Takeaways from PostHogās Growth Story: Your 5-Point Implementation Plan
Now that Iāve unpacked the intricate details of PostHog's journey, I want to arm you with a concise, actionable plan inspired by the way James and his team organise and work.
Here are five core takeaways, transformed into concrete implementation steps you can integrate into your developer tool startup immediately:
1. Ditch the Growth Hacks, Master the Fundamentals
PostHogās ascent isn't attributed to fleeting growth hacks or viral gimmicks. Itās rooted in a relentless, almost obsessive focus on the foundational elements: building genuinely valuable product, offering it at disruptively low prices, providing unparalleled developer support, and cultivating an authentic developer brand.
š” Geek Tips: Conduct a brutal audit of your current growth strategy. Are you chasing fleeting tactics, or are you truly investing in the fundamentals?
Product Value Audit: Objectively assess your core product. Does it deliver exceptional value for your ICP? Gather user feedback (interviews, surveys) to identify areas where value is lacking. Refocus your roadmap on core value enhancements, not just feature additions.
Pricing Accessibility Review: Compare your pricing against competitors, especially those with strong PLG motions. Is your pricing truly accessible to individual developers and small teams? Experiment with lower entry-point pricing tiers or expanded free plan offerings.
Developer Support Deep Dive: Map your current developer support channels. Are they genuinely helpful and technically proficient? Ideally staff those channels with devs. Invest in training for support teams, create developer-centric documentation, and actively participate in developer communities to provide authentic support.
Brand Authenticity Check: Analyse your brand messaging across all platforms. Does it genuinely resonate with developers? Is it authentic, technically credible, and free of marketing jargon? Refine your brand voice to prioritise developer empathy and technical depth.
For early-stage startups, this also means resisting the urge to chase complex features or premature scaling. Focus maniacally on building a truly valuable MVP, accessible pricing, and providing hands-on support to your first 1000 users. PostHog's early pivots were all about refining the core product and finding that initial, passionate user base.
2. Let Your Users Lead the Way - Harness the Power of Word-of-Mouth
PostHog didn't force a top-down, sales-driven go-to-market motion. They listened intently to their users, recognising word-of-mouth as their most potent growth engine. They didn't just rely on organic buzz; they actively nurtured it by understanding why users recommended them.
š” Geek Tips: Become a student of your user advocates. Systematically gather user testimonials and case studies, focusing on why they recommend you.
User Interview Sprint: Conduct a sprint of user interviews (10-15) specifically targeting users who are vocal advocates. Uncover the specific reasons behind their recommendations. What features, value points, or aspects of your brand resonate most?
Feedback Loop Analysis: Analyse existing feedback channels (support tickets, community forums, social media). Identify recurring themes in positive feedback and testimonials. What value points are consistently highlighted by your advocates?
Referral Program Audit: If you have a referral program, analyse its performance. Which users are most likely to refer? What incentives are most effective? Refine your program to amplify word-of-mouth referrals.
Amplify User Stories: Showcase user testimonials prominently on your website, landing pages, and marketing materials. Highlight users vs their companies. Use specific quotes and quantifiable results to maximise impact. Create case studies and user spotlights that tell compelling stories of user success.
3. Use Transparency as a Growth Multiplier
PostHog's radical transparency, from open roadmaps to compensation structures, is a deliberate growth strategy. Being open isnāt enough - the aim should be to build unshakeable trust with developers, a community that inherently values authenticity and technical rigour.
š” Geek Tips: Embrace radical transparency, starting incrementally.
Public Roadmap Initiative: If you don't have one, create a public product roadmap. Share your vision, planned features, and timelines. Solicit community feedback and actively incorporate it.
Open Decision-Making Documentation: Document key product and growth decisions publicly (blog posts, community forums). Explain your rationale, data points, and trade-offs.
Behind the Scenes Content: Create content that pulls back the curtain on your company culture and operations. Share "day in the life" blog posts, team interviews, or "how we built this" technical deep dives.
Community Trust Audit: Actively monitor community sentiment. Are developers trusting your brand? Are they engaging in open, honest discussions? Identify areas where you can build more trust through increased transparency.
4. Prioritise Product Breadth and Depth Over Premature Enterprise Focus
PostHog resisted the siren song of early enterprise deals, instead focusing on building a comprehensive, multi-product platform for their core developer audience. This patient, product-centric approach allowed them to build strong traction in their market segment. Enterprise revenue comes, but not at the expense of their product and business fundamentals.
š” Geek Tips: Re-evaluate your product roadmap and sales focus. Are you prematurely (the key word) prioritising enterprise features at the expense of core product value for your primary users?
Product Roadmap Re-Alignment: Conduct a roadmap review, prioritising features that expand product breadth and depth for your core ICP. Delay or de-prioritise enterprise-specific features that don't directly benefit your broader user base.
Small Team Focus Initiative: Launch a dedicated initiative focused on serving smaller teams and individual developers exceptionally well. This could include tailored onboarding, content, and community programs.
Enterprise Feature Pause: If necessary, deliberately pause or slow down development of new enterprise features. Communicate this transparently to your team and stakeholders, emphasising the strategic rationale of prioritising core product value.
5. Use Metrics as a Compass, Not Just a Scoreboard
PostHog doesn't track vanity metrics; they obsess over actionable data that empowers product teams. They use a rich tapestry of metrics, but focus on a few such as revenue growth rate, retention, activation, usage ā to guide product decisions and empower teams to own their growth.
š” Geek Tips: Revisit your metrics framework to focus on actionability and product-led insights.
Metrics Audit & Re-Definition: Audit your current metrics. Are they truly actionable? Do they empower your product teams to drive growth? Re-define key metrics to focus on user behaviour, engagement, and product value delivery (e.g. Weekly Fixing Orgs, Feature Adoption Rate, Habit Moment, Conversion).
Product-Level Metrics Dashboards: Implement product-level metrics dashboards, similar to PostHog's model. Empower product teams to directly access and analyse these metrics in monthly growth reviews.
Growth Review Cadence: Implement monthly growth review meetings for each product team. Use a standardised metrics template to ensure consistency and comparability across products. Focus discussions on data-driven insights and actionable next steps.
Metrics Champion Program: Identify and train "metrics champions" within each product team. These individuals become experts in data analysis and evangelists for data-informed decision-making.
Enjoying this content? Subscribe to get every post direct to your inbox!
THATāS A WRAP
Before you go, here are 3 ways I can help:
Take the FREE Learning Velocity Index assessment - Discover how your team's ability to learn and leverage learnings stacks up in the product-led world. Takes 2 minutes and you get free advice.
Book a free 1:1 consultation call with me - I keep a handful of slots open each week for founders and product growth leaders to explore working together and get some free advice along the way. Book a call.
Sponsor this newsletter - Reach over 7600 founders, leaders and operators working in product and growth at some of the worldās best tech companies including Paypal, Adobe, Canva, Miro, Amplitude, Google, Meta, Tailscale, Twilio and Salesforce.
Thatās all for today,
If there are any product, growth or leadership topics that youād like me to write about, just hit reply to this email or leave a comment and let me know!
And if you enjoyed this post, consider upgrading to a VIG Membership to get the full Product-Led Geek experience and access to every post in the archive including all guides.
Until next time!
ā Ben
RATE THIS POST (1 CLICK - DON'T BE SHY!)Your feedback helps me improve my content |
PS: Thanks again to our sponsor: Inflection.io
Reply