How PostHog Grows: The Power of Being Open-Core

...and having a weird hedgehog

👋 Welcome to How They Grow, my newsletter’s main series, where I bring you in-depth analyses into the growth of popular companies, including their early tactics, current strategies, and actionable business-building lessons we can learn from them.

---

---

Friends, I’ve been looking forward to writing about today’s company for a while.

There’s not one company I’ve ever seen…not one…that has so many incredible resources available for people like me to read up on and study. I had a call scheduled with the founder/CEO for this piece but ended up canceling because I could find everything I wanted to know through their documentation.

PostHog is truly an open book about everything. And that, to put it plainly, is the bedrock of their strategy: Open-Core everything.

They want you to know how and when they fail. They want you to know how their teams are set up. They want you to know how they get customers. They want you to know how they upsell their customers, and what their strategy is. They want you to know everything that goes on inside.

You might not have heard of PostHog before. If that’s the case, this is all you need to know: PostHog is the analytics platform for product engineers.

I know, we’ve covered a few analytics companies before. But we’re not talking about analytics products today. You know what these companies offer at the core level, and most of you are not building a directly relatable product. Everything we cover today can apply to you…the lens I’ve written through here is all about universal ways you could build and grow whatever you’re working on.

They’re just doing so much right that I had to give you a breakdown.

And if you want to see what PostHog does (product/web analytics, Session Replays, experiments, feature flags, surveys, CDP, etc), take a scroll of their site for a minute and come back. It’s worth doing even just to peak their unique legendary design/brand system and meet their hedgehog, Max.

Expectations for today 🧠 🛠️

• Part 1: Along came a hedgehog (and their first 1000 users)

  • A story of 6 pivots

  • The first 1000 users

  • Playing for Product-Market Fit

• Part 2:

  • A laser-focused who

  • The open-core growth strategy

  • How this hedgehog does sales

  • Not boring

  • Selling microservices (and breaking up a monolith)

  • Nine ways this hog builds for speed

Reading time: 29 minutes 

---

I. Along came a hedgehog (and their first 1000 users)

PostHog’s path to product-market fit was defined by a series of rapid pivots.

Over nine months, founders James Hawkins and Tim Glaser built six distinct products, each addressing different challenges they encountered in their previous roles. They learned from each pivot too, going well beyond refining their ideas to sharpening their understanding of product-market alignment.

So without further ado, here’s how each iteration shaped their journey.

A tale of six pivots

#1: Sales territory management tool

The Idea: Inspired by James’ experience as a VP of Sales, their first product was a predictive analytics tool to help sales teams prioritize deals. By pulling pipeline data from CRM systems, the tool analyzed past deal data to predict the probability of success and flagged low-performing deals for removal.

What Happened: They secured interest from 15 sales leaders who agreed to test the product. But only one clicked the sign-up link. Still, the idea resonated conceptually, but it was overpowered for small teams and a poor fit for big ones who needed vast data sets to make it work.

Lesson Learned: → Confusion is costly. Targeting a large, mixed audience led to a disconnect between the product’s complexity and user needs. They learned that a good product needs a very well-defined customer profile. Without clear audience alignment, even a sound idea can fall flat.

#2: CRM with predictive analytics

The Idea: After seeing a friend replace their CRM with PostHog’s sales tool, they wondered if simplifying the CRM experience could be the solution. They built a CRM with predictive analytics, targeting small companies in need of a lightweight, intelligent CRM system.

What Happened: Getting meetings suddenly became a problem. The market was flooded with CRMs, and adding predictive analytics wasn’t how PostHog could sufficiently differentiate themselves. They secured one customer at $20 per month who ultimately didn’t even pay the invoice.

Lesson Learned: → Don’t enter crowded markets without a unique differentiator. By creating another lightweight CRM without a clear edge, they learned that relying solely on popular buzzwords or marginal features falls flat when creating product-market fit. Differentiation needs to be specific, clear, and rooted in a genuine user need.

#3. A 1:1 tool with predictive analytics

The Idea: Shifting their focus to help managers prioritize their team’s tasks, they built a 1:1 meeting tool inspired by Andrew Grove’s High Output Management. The twist? The tool included predictive analytics that highlighted deals worth discussing, adding context to performance meetings.

What Happened: They saw some early excitement, but only one out of 10 teams actually used it post-login. They hadn’t gone deep enough during discovery into whether users actively searched for a 1:1 tool, or if the problem of unstructured meetings was truly painful for them.

Lesson Learned: → Ask “why not?” before building. By failing to validate whether users actually needed or prioritized the tool, they built something that ultimately didn’t solve a pressing problem people would cough up for. This pivot reinforced the importance of asking whether a target user has actively gone out looking for solutions or workaround methods. Why? Because if not, there may not be real demand.

#4: Technical debt monitoring tool

Our idea was to help engineers manage technical debt. It didn't work out, but we realized the power of treating growth as an engineering problem. We also knew that many engineers struggle to understand the impact they have on the people who use what they build.

There are plenty of product analytics tools out there, but all the alternatives are SaaS-based. While they're powerful, they can be frustrating for developers. From our perspective, these tools can be problematic because:

• We don't want to send all our user data to third parties

• We want full underlying data access

• They don't give you choice and control over pricing

— James

The Idea: Aiming to tackle tech debt, a pain they knew from experience, they built a tool that prompted developers to log delays and frustrations after each pull request. This feedback then generated a “technical debt heatmap,” showing where in the codebase debt was slowing progress.

What Happened: This tool resonated the most. Enough to get them 600 users and a foot into Y Combinator. However, while teams found the tool helpful, the obstacle of tech debt remained. Product teams ultimately dictated priorities, limiting the tool’s influence and value.

Lesson Learned: → Focus on action, not just insights. People want more than insights alone. The best products empower users to take action or solve a problem. For tools targeting workflow or technical bottlenecks, it’s not enough to simply show users where their problems are—they need to show how to solve them.

#5: Engineering retention tool

The Idea: The 5th idea was a tool meant to spot disengaged developers early, allowing companies to address potential issues before they became critical. This idea came from conversations with advisors and targeted retaining engineering talent by monitoring team morale. 

What Happened: This was the shortest-lived pivot, getting canned in just five days. Engagement was low, and user response was indifferent. A conversation with a CTO who said he “didn’t have any big problems” underscored that their audience still didn’t see this as a high priority. Also, maybe a little Big Brother, no?

Lesson Learned: → Don’t chase ideas that lack founder conviction. Since this pivot didn’t originate from James and Tim’s firsthand experience or own insight, it was harder to articulate the problem and make it value for users. As you know, going after ideas that come from your team’s unique understanding is where the real winners come from. Speaking of real winners…

#6: Open-source product analytics platform

And on the 6th go, they found their home run play.

The Idea: Annoyed by relying on third-party tools to track their own product usage and the subsequent lack of developer control over data sent to these servers, they decided to build an open-source analytics platform for themselves…developers.

What Happened: This time, the pull was immediate. Within a month, they had hundreds of users, real community engagement, and positive feedback from the developer community. Unlike the previous 5 tries, they saw adoption and usage without extensive outreach.

Lesson Learned: → Listen to recurring frustrations to find product-market fit. This final pivot was rooted in a pain point they had felt firsthand and seen among other developers. By aligning deeply with a community need and solving it in an open-source way, they hit something with a very high ceiling of opportunity.

---

Learning from their pivots

1. Refine customer fit: Each pivot helped them refine their understanding of user fit, showing that not every “good idea” aligns with the right user profile.

2. Validate depth of pain points: They learned to find out whether their target market had any history of actively looking for a solution to a problem. This was how they learned to see if people genuinely wanted to solve something.

3. Actively leverage insights: Valuable products empower users to take action on insights, not just learn about problems. Insights without tangible next steps offtered can limit traction and retention.

4. Stay true to convictions: The most successful pivot was one they believed in most, and that addressed real, recurring challenges among developers.

The first 1000 users

PostHog’s first 1,000 users came from a mix of organic growth and community-driven engagement. Here’s how they made it happen:

1. Launched in public spaces: PostHog’s Hacker News launch didn’t jus thelp with visibility, but it got people talking. The first inkling of community. Posting on GitHub, where developers naturally congregate, allowed them to tap into a thriving ecosystem of developers already looking for new tools.

2. Focus on open-source: As an open-source project they appealed directly to the developer community. GitHub stars served as a key social proof metric, and the open-source format encouraged users to fork, modify, and contribute, creating organic growth that didn’t require any heavy marketing.

3. Transparent communication: By sharing their journey publicly and actively engaging with users, PostHog built trust. They frequently shared updates, responded to GitHub issues, and encouraged contributions. This all helped build on that growing community around the product.

4. Co-building with the community: PostHog treated its users as co-creators, making user feedback integral to the product roadmap. This two-way relationship allowed users to feel super invested in the product. And that’s how they turned users into advocates who happily spread the word.

Playing for Product-Market Fit

PostHog saw product-market fit as an always-moving target.

The team treated PMF as a cycle of building, releasing, and watching how folks users the product to figure out which features hit best with their audience.

Their journey to PMF included three core strategies:

1. Feature expansion based on real demand: Instead of overloading their MVP with features, they launched with a lean product and expanded based only by following clear user pull. Early feature additions like product analytics, feature flags, and session recording were all driven by many people asking for it, making sure they only added what clearly added to the product’s value.

2. Close monitoring of usage data: PostHog used its own product to track how people engaged with the features. By closely tracking adoption patterns, they were able to shape their roadmap in real time, focusing on high-impact features while deprioritizing (and unshipping) low-impact ones. 

3. Broadening reach to adjacent markets: PostHog’s product was designed to be versatile—supporting startups, scale-ups, and enterprise teams. This meant they could attract a broad range of users while retaining the flexibility to expand feature sets according to different segment needs. Meaning, that they could iterate their way to PMF across various user bases rather than getting locked in on a single corner of the market.

The big thing to remember here is that PMF isn’t a once-off goal you just get to—it’s an always-moving target. Product-market drift is absolutely a real thing.

II. How this hog has gone wild

A laser-focused who

PostHog has always gone for precision when defining their Ideal Customer Profile (ICP). This was largely about doubling down on a very specific audience with high standards and influence: product engineers at high-growth startups.

Defining the ICP

Their ICP isn’t just any engineer or PM—it’s the ambitious, skilled product engineer working on high-craft products at high-growth, engineering-led startups. These startups typically fall between Series B and IPO, with 15-500 employees and revenues over $100K per month, and are backed by top-tier investors. They’ve already hit product-market fit and are growing at a good clip, with teams that build fast, ship often, and depend heavily on data.

The power of this ICP is that it creates a great feedback loop: PostHog builds for high-performing engineers, attracting more of them over time, which, in turn, sharpens PostHog’s product focus and keeps it ahead of less technical analytics tools.

Why product engineers?

There are analytics tools that cater to the flip side of the market (non-technical generalists), but PostHog saw a future in engineering-led product teams.

This positioning reflects a strong belief the founders have—that engineering-led product development is the future of high-growth tech.

By building for technical power users, they’re aligning everything they do to meet the demands of engineering-driven cultures and the people who understand the data at a deep level.

Learning from High-Expectation Customers

PostHog’s positioning around these high-expectation engineer-first customers works for a few reasons:

1. Demanding standards: These users have high standards, which pushes PostHog to improve and create new products continuously.

2. Influence in the industry: The ICP that PostHog focuses on acts as a “key opinion leader” within the tech ecosystem. By winning over respected product engineers, PostHog earns credibility that trickles down to other potential customers, including technical founders and high-potential startups.

3. Word-of-mouth growth: Building for a specific user with an influential voice drives organic growth. Engineers have always been community-centric, and they regularly discuss and recommend tools to each other in engineering circles, which translates into referrals, broader adoption, and brand trust.

Avoiding feature creep

Like any good strategy, 80% of the substance is about what not to do. Related, a core part of their ICP strategy is knowing who not to build for.

They’ve deliberately chosen not to dilute their focus by catering to less technical users or non-core teams like marketing. Instead, they concentrate on making PostHog highly functional for technical folks. The rationale here is clear: by doing one thing exceptionally well, PostHog attracts users who would rather switch to PostHog for its tailored power than rely on feature-heavy tools built for generalists.

This focus on a single ICP comes with the discipline of saying no. PostHog resists adding features that would cater specifically to marketers (and expand their TAM), as this very likely would add unnecessary complexity and compromise the usability for product engineers.

Features are built for marketing teams only if they increase company-wide adoption, create cross-functional value, and enhance the core product experience for engineers.

The strategy beyond engineering teams

The company stage component of PostHog’s ICP doesn’t just stop at high-growth startups; it also includes high-potential startups and influential hobbyists.

The idea is that by serving the “next generation” of high-growth startups early, PostHog will become the default choice as these startups grow up. These high-potential companies—those backed by accelerators or led by former big-tech talent—use PostHog to inch toward product-market fit. PostHog’s goal is for these small, high-potential teams to adopt the tool as a foundational part of their product stack.

Hobbyists also play an important, if auxiliary, role in PostHog’s growth strategy. Engineers working on side projects or passion projects are often influential within tech communities, sharing tools they like with colleagues and online audiences. By providing a “free preview” of the product to engineers in this category, PostHog earns a steady flow of organic awareness and word-of-mouth promotion

The open-core growth strategy

PostHog’s open-core model isn’t just a feature of their product; it’s the foundation of their entire strategy. For an analytics company, this approach is unusual and ambitious, but it’s precisely this differentiation that makes PostHog so compelling to engineering-led product teams.

By creating an open-source product and leaning very heavily into a transparent company ethos (more so than any other company I think), PostHog positions itself as a highly customizable and trustworthy alternative in a market traditionally dominated by closed tools.

Here’s how PostHog’s open source strategy works as a growth engine, why it resonates so well with their Ideal Customer Profile (ICP), and how other companies can adopt key elements of this playbook.

Why open works

Product engineers often want control over their tools, which includes having access to source code, customizing it to fit their needs, and running it on their own infrastructure. By choosing open source, PostHog offers several distinct advantages:

1. Data privacy and control: Traditional analytics tools require companies to send data to third-party servers, which can create compliance and security concerns. PostHog allows users to self-host, giving companies complete control over their data—a huge advantage for privacy-conscious organizations.

2. Transparency and trust: PostHog’s open-source model allows users to see exactly how the tool works. For engineers who value understanding their tools deeply, this transparency builds trust and a sense of ownership. As a result, PostHog becomes not just a tool but a trusted part of the team’s infrastructure.

3. Customization for technical teams: Engineering-led product teams often need unique customizations that aren’t possible with SaaS analytics solutions. With open source access, PostHog’s users can extend and tweak the platform to fit their precise needs, creating a powerful advantage over tools designed for broader, less technical audiences.

Open Everything…the PostHog Handbook

An open-source platform is cool and all, but what stands out most to me is that they are open everything.

One of the most striking elements of PostHog’s open-source ethos is the comprehensive, public-facing PostHog Handbook. This document isn’t just a set of guidelines; it’s a living, breathing resource that captures every part of the company’s approach—from product decisions to operational strategies. Built after their first hire but before their second, the handbook became an internal compass and a powerful external signal of PostHog’s commitment to transparency.

Here are a few of my favorite documents they share openly:

• Compensation Calculator

• Share options

• Company strategy

• Business Model

• Roadmap

• Their side gig policy

The PostHog Handbook serves multiple purposes:

• Signaling maturity: When PostHog launched on Hacker News, the handbook helped them appear more established than they actually were. In a competitive market, this signal was crucial to gaining trust with developers who were hesitant to adopt an unproven tool.

• Attracting talent and users: By documenting their values and playbooks, PostHog has attracted talent that aligns with their building ethos. This approach helps bring them people who are truly excited about open source and committed to the mission.

• Living documentation: The handbook also acts as a centralized resource where team members and the community can suggest improvements. This collaborative approach ensures that PostHog’s processes and values evolve in real-time with input from those closest to the product.

Their public content strategy

PostHog’s open-source approach extends beyond the product into its content strategy. Rather than a conventional content playbook focused on SEO keywords, PostHog’s content marketing prioritizes honest sharing about what’s going on inside the hog nest.

By sharing their journey, decision-making processes, and product experiments openly, they create a best-in-class “build in public” narrative that appeals to its core users.

This build-in-public play doesn’t just build credibility though; it builds pipeline. According to co-founder James Hawkins, transparency was essential in the early days to gain traction as unknown founders in a crowded space.

Around 70% of their initial growth came from recommendations, with the other 30% driven by inbound content marketing. By continuously sharing valuable, transparent content, they built a feedback loop that has driven tons of growth.

My favorite layer of their open content is their newsletter:

Here are the key components of their content strategy:

• Build-in-public: Sharing detailed updates, product decisions, and outcomes openly builds trust and interest.

• Always give actionable insights: By targeting their content to product thinkers, PostHog’s posts resonate with their ICP and drive inbound traffic from relevant audiences.

• Don’t sell: None of PostHog’s content tries to sell you on anything. They know content is about warming people up to the idea of one day buying. The goal is simple: add lots of free value, and keep people interested in our opinions.

• Engage the community: From their “community newspaper” to their newsletter Product for Engineers, PostHog uses content to keep their community engaged and involved in product development.

You, too, can be more open

For companies considering some level of an open-core strategy, PostHog lays out a few actionable steps we can take to use open source as a differentiator, regardless of your specific industry.

1. Find the right market fit for open source: Not every ICP values open source equally, so it’s important to ensure that open source is a benefit for your users.

2. Build trust with a public handbook: A public handbook has the potential to be a golden asset for you. It helps you outline your own thinking, it gives the team insights, and it’s a talent magnet. Companies can follow PostHog’s lead by documenting their principles, processes, and values, then sharing them openly. This not only helps you look more mature but also allows potential hires and customers to see if they align with your values.

3. Establish a build-in-public culture: Transparency doesn’t stop with a handbook. By sharing wins, failures, and lessons openly, you create a brand that feels accessible and trustworthy. PostHog’s content shows that technical audiences are hungry for real stories and actionable insights rather than polished corporate messaging. For companies starting out, consider sharing your journey.

4. Use open source as a product feature: If your ICP values customization, consider how you can make open source a core component of your product, giving your users the power to adapt and extend your tool to meet their needs.

How this hedgehog does sales

PostHog has built a developer-first approach to sales. One that’s built on transparency, speed, and user control. Unlike many SaaS companies that hide pricing and push multiple qualifying calls, PostHog leads with clear, usage-based pricing right on its website and a process geared for self-service.

If prospects need a demo, they skip the SDR gatekeeping and get a personalized call with a technical account executive who dives straight into the product, no fluff.

No hidden costs, just straightforward options

Hidden pricing or features bundled into opaque packages to maximize profit on each customer are all too common. PostHog cuts the curb here and offers utility-style, usage-based pricing that’s clear, flexible, and openly displayed. Customers see exactly what they’ll pay based on their usage, eliminating guesswork and building immediate trust.

It’s so worth checking out how they show their Pricing and Packaging. As you scroll, keep in mind how perfect this is for their ICP.

A snapshot of their price calculator

PostHog’s unique twist? Pick-your-own discounts. Customers who commit to longer contracts or higher usage levels can select a discount tier directly on the website—no back-and-forth haggling, no hidden negotiations. This approach removes friction and puts control back into the hands of the user, letting them make cost-saving choices without a sales pitch.

See their public “Choose your own discount” picker here.

From demo to deployment in days, not weeks

PostHog’s sales flow is designed for speed and minimal touchpoints. If prospects have questions beyond the website or pricing, they can book a demo directly with a technical account executive who can answer them. No layers of SDRs, no discovery calls for qualification—the focus is on value from the get-go.

PostHog aims to move users from demo to deployment in less than a week, offering shared Slack channels for prospects spending over $20K annually and setting up quick trials to get them hands-on immediately. Users get a direct line to experts and are encouraged to jump right into implementation—streamlining their path to value.

How to Apply This: Reduce your barriers between prospects and the product. Bypass qualifying calls and let technical prospects speak directly with product experts for faster onboarding.

Usage-based, modular pricing

Instead of bundling features into rigid packages, PostHog offers a modular approach that lets customers select only the products and usage they need. Customers are charged by individual products and usage, so they don’t overpay for features they don’t use. To further control costs, customers can set spending limits on certain features, like session recordings.

By allowing customers to start small and add products as they need them, PostHog creates a model that scales naturally with growth. This way, users don’t face large price hikes or restrictive tier upgrades as their usage grows—they can manage usage and costs on their own terms.

One contact from demo to deployment

Traditional SaaS models often hand customers off to various departments throughout the sales cycle, leading to a disjointed experience. PostHog assigns a single point of contact—a technical account executive—who works with the customer from demo to deployment. This continuity makes it easier for customers to get answers, understand the product deeply, and feel valued throughout the process.

To recap; here’s how they’ve made a dev-first sales model

1. Be transparent with pricing: Make all pricing information publicly accessible and straightforward.

2. Streamline sales for speed: Avoid multiple qualifying steps, letting prospects book directly with experts who can answer detailed questions.

3. Adopt modular, usage-based pricing: Charge for individual features or products based on usage to allow for more flexibility.

4. Assign consistent points of contact: Minimize hand-offs and ensure customers have a knowledgeable, single point of contact.

Not boring

PostHog stands out with a distinct, almost eccentric identity that’s instantly memorable. From the moment you see its quirky hedgehog mascot and vibrant, unapologetic design, it’s clear PostHog isn’t interested in playing it safe. They way they see it, brand is more than just a polished logo—it’s about amplifying their personality, reflecting their audience, and embracing the unconventional through honest weirdness.

As James Hawkins put it, “We’re going to have a weird, unusual style because we are the weird and unusual one that’s joined [the analytics market], and that’s how we'll win.”

A mascot that matches the mission

PostHog’s brand story is rooted in creativity and some eccentricity. The inspiration for their unique brand voice came from a chance Twitter encounter, where designer Lottie Coxon caught their eye with her unconventional portfolio. This led to the iconic hedgehog mascot—Max, a quirky figure that’s as memorable as he is unusual—and a visual identity that fits PostHog’s open-source, community-driven ethos.

It’s a brand where weirdness isn’t just tolerated; it’s celebrated and built into the DNA.

Early iterations of PostHog’s branding were more experimental than polished. Lottie describes how the initial brand look took shape: “The hedgehog mascot was somewhat of a happy accident. We wanted something that genuinely reflected who we are, and hedgehogs somehow just felt right.”

This happy accident was emblematic of PostHog’s core philosophy: sometimes, leaning into quirks reveals a brand’s true character better than any polished branding exercise ever could.

Consistent and memorable

Unlike most brands that tone down the oddities to appeal to a broad audience, PostHog leaned in. And they do it in big and small ways. Beyond the mascot, their website, product, and communication style have an irreverence that feels more like a zine or a fan club than a B2B software brand. Even their product copy avoids the safe, over-polished tone of typical SaaS. It’s unfiltered, often humorous, and directed squarely at engineers.

This is a company that isn’t afraid to be a little “too much” because it’s exactly what endears them to their user base.

One example of this is their FAQ section, which includes playful quips and refreshingly blunt responses like “Yes, we do hate bureaucracy too,” or “You’ll hate PostHog if you like lots of sales calls and qualifying sessions.” This voice is consistent across every touchpoint.

It’s obvious they’re not interested in being everything to everyone (remember—who they are not for)—they’re proudly the choice for the rebelliousness engineers. If it repels some, so be it. That’s design, and it’s PostHog’s way of keeping its community aligned with its culture.

Kill marketing-speak

“Marketing-speak” is the worse. More and more, it’s got a growing negative connotation.

Most companies avoid the quirky and opt for bland, broadly accessible branding out of fear it could alienate potential customers. PostHog’s knows, and has proven, this isn’t the right strategy today.

Being weird isn’t just a style; it’s a differentiator that helps them stand out. PostHog’s approach has built a tribe-like following, where customers feel aligned not only with the product but with the spirit of the company.

PostHog’s weirdness goes beyond its public image. Internally, the company embraces fun as a core value, from team Slack emojis to custom merch items (they started with a T-shirt, and now they’re experimenting with everything from shower curtains to collectibles).

When founder James talks about the role of fun, he refers to an insight from his executive coach: the most successful billion-dollar founders aren’t just in it for growth—they genuinely love what they do. That spirit permeates PostHog, creating a team that’s as excited about their brand as their customers are.

“Fun isn’t necessary to build a business, but if you want to build a huge business, it probably is.” — James Hawkins

Selling microservices (and breaking up a monolith)

We’ve somewhat touched on this with the pricing stuff, but there’s more to explore here.

Most SaaS companies bundle all their features into one platform, then sell that platform in one subscription. Let’s call this monolithic selling.

PostHog has taken another route, approaching each feature as its own standalone product. With each tool sporting an independent roadmap, team page, changelog, and even separate pricing, PostHog essentially functions as a suite of “micro SaaS” products housed under a broader data and analytics operating system. This is their “microservices” approach—a term more commonly seen in architecture but brilliantly applied here to software.

Here’s why it works, and how other startups might consider adopting similar principles.

Why not just bundle?

Most companies offer their features under a single product umbrella. It's simple and can be easier to sell. But simplicity in packaging doesn’t always translate to a better user experience. PostHog recognized that by allowing each feature to operate as its own product, users gain more flexibility, personalization, and freedom to pick what they need—whether it’s session replays, heatmaps, or advanced analytics.

Take Lempire another company known for selling microservices. By creating independent tools for each function (e.g., for email outreach, personalization, and lead management), they offer users a very modular experience that lets them pay only for what they need. Each product gets treated as it’s own startup with growth and commercialization metrics, and it becomes easy to establish a playbook for expansion—just launch another startup and give it the resources from the parent brand.

PostHog’s model is similar, allowing technical users to piece together an analytics stack rather than forcing them into a one-size-fits-all tool.

I absolutely love this approach, and if I ever build a software company again I’d want to build it this way. There’s just something very neat about having each product you build be its own siloed thing.

Why microservices work so well for PostHog

This approach plays to PostHog’s strengths and user needs:

1. Flexibility for power users: By making each feature a separate product, PostHog caters to technical users who appreciate control. Each tool can be turned on, off, scaled up, or scaled down as needed, giving users a developer-friendly modular experience.

2. More control and value for each product: PostHog can refine and improve each product independently, focusing on specific use cases and iterating faster. This allows the engineering team to prioritize enhancements within individual tools, leading to an overall platform that feels far more tailored and high-quality.

3. Differentiated pricing for developers: Each tool has its own pricing structure, which means users aren’t locked into an all-in-one model. They only pay for what they use, which fits the developer mindset of “don’t waste resources.” This approach lowers the barrier for users to start with PostHog and then expand as needed.

4. Maximizing market reach: The microservices structure gives PostHog the ability to enter new markets by creating entirely new products without impacting their existing ones. This approach has allowed them to rapidly expand their toolset, testing, and iterating on new products as they go. With each new product, PostHog increases its addressable market while keeping costs under control.

Building wide, operating small

This strategy is supported by PostHog’s organizational structure. Instead of one large engineering team, PostHog splits its workforce into smaller, startup-like units, each responsible for a specific product. These “mini-startups” are given autonomy, with teams free to make decisions and ship improvements without layers of management approval. It’s a refreshing model that prioritizes speed and autonomy and keeps PostHog nimble even as they expand their product suite.

…

For early-stage companies, the microservices model may not make sense immediately, but it’s definitely something to think about as a growth strategy once you’ve validated product-market fit for your first product. '

Here’s how you could start implementing a similar model

1. Design each new feature as a potential product: Treat each new feature like its own micro product, with a clear ICP, positioning statement, clear user outcomes, a roadmap, and metrics to gauge impact. This helps teams assess if the feature has the potential to stand alone, and if it resonates with users who might just want that one function.

2. Hire for product ownership: Look for hires who thrive with end-to-end responsibility. By hiring product leads who operate with a startup mentality, you create a culture of ownership, accountability, and entrepreneurship.

3. Think of your homepage as a storefront. If you’re selling microservice products, think of your main brand as the front-of-shop store where people can buy your products. Scroll through this site to see a good example.

The microservice model isn’t for every startup, but it’s a smart choice for those looking to serve a diverse range of users and scale product complexity without adding operational drag.

10 ways this hog builds for speed

This is more along the lines of how PostHog builds product, but that does directly tie into how they grow, because speed often = growth.

So I’ll, quickly, share a few things they do to ship fast.

1. No design by default: PostHog’s engineers don’t wait on designers to get started. Engineers design the UX, especially given a well-established design system. While a designer is available, they work reactively to support ongoing work without holding up the release.

2. Minimal product management: Product engineers take full ownership of user feedback, roadmap decisions, and metrics like revenue and costs. They’re empowered as “product engineers” rather than relying on traditional product management. There’s one PM who steps in only if a team needs extra support.

3. Hiring for autonomy: Every hire is screened not only for skill but for how well they work independently. Most are highly experienced and can self-manage, a key asset for PostHog’s all-remote, autonomous culture. New hires even work on a real project during hiring to gauge their independence/resourcefulness.

4. Small, startup-like teams: PostHog organizes teams around each product as mini-startups. Each team of up to six people has complete control over product decisions, including marketing and pricing, allowing them to ship quickly without waiting on cross-company approvals.

5. Engineering-led org: PostHog keeps overhead minimal, with most roles tied to engineering. Outbound sales are off the table, and the company’s marketing team is lean. The focus remains product-led, keeping development in line with user-driven product demand.

6. No meeting Tuesdays and Thursdays: To give engineers as much time as possible for deep work, PostHog avoids meetings twice a week. This focus on fewer, shorter meetings helps maintain productivity, with asynchronous updates and only essential synchronous catch-ups.

7. A late mover’s advantage: PostHog only builds products in markets with proven demand, where there are $1B+ competitors. This ensures demand while giving PostHog the opportunity to integrate tools in ways competitors can’t.

8. Strategic venture capital: With thoughtfully raised venture capital ($3M seed, $9M Series A, and $15M Series B), PostHog maintains a well-paced runway for building new products without excessive spending.

9. Trust and feedback over process: PostHog minimizes rigid processes, preferring to trust its teams and provide direct feedback when needed. The aim is for maximum autonomy, with a strong focus on trust rather than bureaucracy

10. Documenting everything: Writing things down saves time, eliminates scheduling headaches, and keeps the team aligned. Information becomes accessible to everyone, from onboarding to product strategy, and it helps to avoid endless meetings and gives everyone a clear sense of direction

this is one fast hedgehog

Go down the rabbit hole

• Non-obvious behaviors that will kill your startup

• How PostHog operates

• The companies that shaped PostHog

• Navigating Growth and Retention: Lessons from PostHog’s CEO

• The habits of effective remote teams

---

And that’s a wrap on our PostHog deep dive! I hope you learned something new and are walking away with some inspiration to bring to your own product.

I’ll see you next time.

—Jaryd