PostHog：让工程师自发去线下演示产品的机制与流程

Since I joined PostHog in summer 2025, we've gone from doing 1 IRL event to over 100 in a year. Roughly 95% of those events involve speaking to customers, and over 50% of the company has gone out and demoed in cities around the world – and that percentage keeps growing.

Every developer marketing team I've ever talked to struggles to get the people actually building their products to go out IRL (in real life) and demo them. Even though it's a clear way to help drive retention and expansion, it's only a small subset of internal yappers who prioritize this.

This is crazy compared to previous places I've worked where speaking opportunities were seen as favors or obligations, and many other dev tool companies will tell you the same.

Here's how our IRL events team at PostHog makes it happen (without twisting any arms).

Product engineers FTW

There's an old adage in developer relations circles that goes, "Ship stuff, show people." And we have plenty to talk about.

But so do many other companies building products at a fast pace. What makes us different is that one of our company's values is to make it public. Everything we do is open source, and we've always loved writing about what we're working on. Some of our earliest marketing was just James posting stuff he learned about being a founder that went viral on HackerNews.

Making it public isn't just for views, though. Whether in written form or a demo format, sharing helps others take advantage of what we're learning, builds trust, and also forces us to be clear about our thinking. All of that becomes a self-reinforcing loop:

The problem I see at other companies is if engineers in your org need convincing to share what they've made is actually better for customers. This is painless at PostHog because most of our engineers are product engineers:

"Product engineers talk to users. They decide what to build. They own pricing, revenue, and user experience. They support customers directly. They're accountable primarily to their users and paying customers. They own product decisions." (Source: Our Product Engineering Handbook)

With more ownership and transparency, engineers will naturally want to demo the products that they've built. This leads to more customer interaction, which leads to curiosity and empathy for users, which leads to more demos, interviews, and blogs. And it all loops back into itself.

This event recap from Meikel after he did a talk at a dev meetup in Milan earlier this summer shows what it looks like when product engineers love what they work on and sharing it with users:

Culture of demoing

It also helps that demoing is second-nature here. You can't get far on any given work day at PostHog without seeing a demo of what people are working on internally thanks to:

• Our weekly all-hands meetings. These end with 15-20 minutes of people across the company sharing screens (while praying to the demo gods).
• Our many hackathons. Whether it's at a small team gathering or the annual all-hands company offsite, our hackathons always end with each team demoing what they worked on.
• Our #demo-posthog-anything channel. People post here at any time to keep demos going all week long, rather than waiting for the next all-hands.

For example, here's Sam demoing scatter plots working in our SQL insights product:

Keep in mind that a demo != a slide deck. We care about showing the thing working, not just talking about it. Many of the latest AI community meetups around the world prioritize the same because it contributes to better attendance, participation, and enthusiasm.

Of course, there are exceptions to this – mainly deeper topics that are beyond a product, feature, or tool – but we emphasize showing actual solutions, not just sales pitches or conceptual frameworks. Ew.

Get out of the way

Because we work asynchronously, the events team's role is to propose speaking opportunities and then just get out of the way. We're always available to answer questions and give feedback but, ideally, even that's not necessary.

We trust that our engineers know how to give demos because they're the experts at their topic since, well, they built it. We don't make slides for them, we don't do run-throughs, we just let them do their thing. This is also related to one of our other values called "you're the driver". No one is here to tell you what to do.

We do provide some guidelines, resources, and assets from the brand team. For example, here's what someone will need in order to attend and speak at an IRL event:

• Who, what, where, when. The event details are the first thing we share with all speakers.
• Merch to give out to attendees. The events team ships merch for speakers to give out in person.
• Budget to travel. A subset of the events budget is allocated to travel when necessary.
• Official branded slides, logos, hogs. Anything brand asset related is readily available.
• Guidelines and tips. We have some handbook pages and a newsletter on how to give S-tier demos based on what's worked well in the past.

Even before reaching out to speakers with opportunities, we use a speaker-expertise skill that fellow builder relations teammate Kliment created. It takes that employee's GitHub handle, researches their merged PRs across the PostHog org over the last 6 months, and then produces an outline of their work, candidate tech-talk topics with detail, and a N/10 talk-worthiness score per topic. This helps us come to the table with starting ideas rather than putting that on the employee.

Here's an excerpt from the skill output after looking at Alex Lebedev's work:

He used this as a starting point for his talk on self-driving at WAWTECH in Warsaw, which drew a large crowd:

Some engineers even go on to organize their own events (dinners and meetups mostly) and speak at events without us even being involved. We love that – it's yet another example of our "you're the driver" company value.

Once people demo, they're hooked

So far we've seen that once an engineer does a speaking opportunity, they get hooked. Some of our yappers actually look forward to future events and reach out to us proactively. This is especially great if they're working on a product that is a high priority; we look for more chances to get people building those out to bat.

Still, you can always have too much of a good thing, so we try to toe the line to avoid overwhelming any single person or team with events. We are always mindful of when someone did their last demo and try not to exceed a quarterly or bi-monthly cadence.

We also take the geography into consideration with demo opportunities. In places like Seattle - with lots of ICP overlap for us - we present more opportunities than smaller markets like, say, Kansas City. Either one. Or both. Combined.

Dylan is one of our engineers in Seattle who is often willing to demo and genuinely enjoys it. Here's a recap of his event where he demoed self-driving for his local AI Tinkerers dev tools edition meetup:

So if you're trying to get your engineers out IRL, the fix probably isn't a better speaker program and training. It's giving them ownership over what they've built so that they already have something they actually want to show, and then getting out of their way when they do.

As a disclaimer, no one is required to do _any of this at PostHog, and at least 20% of the company has let the events team know that they have no interest in demoing at events or public speaking. It's not for everyone, nor should it be expected. Because of this, it's always fine when speaking asks are declined – no questions asked._