Abdallah Absi, co-founder and CEO of Village, on using PostHog for product analytics

There is an acknowledgement that these connections are not strong. This very same team that is responsible for say, network health is the same team that is responsible for network growth. It's understandable there's a balance to build there because it's like the team that's maintaining that trade-off between, “Let's go and try to get as many daily engaged users and get people to connect,” because as a product manager, when you look at those AB tests, you're going to realize that people connecting with more people is going to drive you back more to the platform, to look at your feed. If you're less connected, you're not going to be driven back to LinkedIn. 

You need to connect with more people. They want to push you. LinkedIn was one of the first companies that came up with the “people you may know” even before Facebook. This idea of pushing you to connect with more people is something that Facebook has also done and you could say contributed to its downfall over time. With LinkedIn, it is a different case because this is a professional network, not a pop culture social network. People build their careers over time. They create a brand. It's not something that's going to change as often as their Facebook.

How does Village work? What are the signals you are using—is it proprietary stuff? Is it stuff from other tools that you're ingesting? What does that look like?

People have a lot of connections, but they don't know how keep up with them. Twenty-five percent of your connections will move jobs in the coming year. That's on average. Everyone moves in four years. People lose a lot of contacts about all their connections, and it's very hard to maintain that manually. Obviously you cannot do that right now on LinkedIn because it's too much noise, and other tools fall shart at helping you know where your contacts are now and how they could be useful and who they can connect you to.

Village uses a mix of public data and private data. The easiest is to look at, say, private data—I sync in my Google contacts, Google calendar, and it’ll detect that now we've met. 

On Village, it's going to say, “You know Jan, because you've met once” and that connection is okay. It's not strong yet. This other person you've met with 50 times because he's on your team. You have a very strong connection there. This is at the very basic level.

We also extract relationships from public data. We know, for example, that you work with Walter and you guys have a small team. You’re working at Sacra at the same time and have a team of four, so you absolutely know each other. So since we’re connected now, Village will show me that I have a warm path to Walter through you. 

Imagine the majority of companies out there are small companies. A lot of people have worked with others at small companies. We're able to build a lot of relationships just based off of public data.

We also look at funding data so we can help you discover paths to investors through founders who have raised money from them. E.g. if a friend or a fellow portfolio founder raised money from The Weekend fund, I know I could ask her for an intro to Ryan Hoover (founder of the weekend fund).

What does the workflow around Village look like for a customer?

For example, let’s say a pre-seed fintech founder is looking to raise a seed round. They can search on Village “fintech seed investors” and we’ll instantly show them 100s of warm intros - for example, a fellow portfolio founder (even if they’re not on Village) raised money from Lightspeed and can make an intro to them.  

When you bring your team on Village, your network multiples. So a head of sales or recruiter on the team can see who their founder can get intros to, making their prospecting exponentially faster and more effective.

This is especially useful for sales and recruiting, and we plan to dive deeper in this route.

What are the key use cases right now that people are using it for? Is it a lot of VCs? They are really a big part of the market for products like this. The other one that we've talked about in the past and seen people using is Bridge to some extent, but unclear how much.

The primary use case now is fundraising or I would say it's our beachhead use case because we got plenty of data on funding. What we've done is, we've mapped around 14,000 VCs funding rounds. Any venture backed founder is able to—as soon as they join Village—join let's say 1984 ventures and they're going to instantly see hundreds of warm intros to follow-on investors, customers, and talent through people in the community—even if these people in the community are not on Village—just purely from public data. But that's not the end goal because fundraising is a small market, it's a seasonal use case. It's hard to build a SaaS business out of it. 

Our end goal, and that's what we're working towards now, are sales and recruiting. A salesperson could sync their new customers to Village and they could instantly other potential customers that they could introduce you to.

What do you use PostHog for? How do you use it? Who on the team is using PostHog?

It started with me using it the most. Of course the engineers would have to plug everything in and make sure that it's passed for tracking—we made sure that every single feature we launch is tracked, the engineer is responsible for tracking it and creating a dashboard like an insight for it on PostHog. It's a way of creating accountability and ownership for them as well. When they release a feature, they get to see how successful it is. If not, they understand how product decisions are being made, so they can make some of these, themselves. 

The way we use PostHog, we are mostly creating insights and that is one of the most valuable things we've seen in comparison with other products. We've used Segment before and there, you have to hook up Segment and then, push the data to Mixpanel or a other services, such as  Heap. Each one of them is specific and good for a specific thing.

What we've realized is that, even with tools—obviously Google Analytics is one of them—but Mixpanel and all these products make it hard to get started and show insights right away. Like the speed for example—I wouldn't say just the speed of deploying the tool, but I think that was something that was mentioned as being able to track with JavaScript, all events, regardless of whether you're tracking them or not. This is valuable, but I wouldn't say this is the number one that actually brought us to PostHog.

What brought us here was the speed from having an event and being able to create an insight and visualize this insight in so many different ways in a very intuitive experience. We could create a funnel in literally 30 seconds. If you were to do that on Mixpanel, you'd have to scratch your head so many different times and it'd be too raw. You’d have to actually think too much about what to really do. It's like having access to a database and then, you have a visualization tool. Or let's say Excel and then you have charts. You can do whatever you want with the charts, but I don't want to think too much. I don't want to spend hours of having to think about how I want this chart to be. 

One thing PostHog does, for example, by default, is that everything is tracked over a time series. It's absolutely fascinating. I don't know how this is not mainstream. But everything on PostHog is like the default insight. If you have an event, it is going to show you over time how this event is trending. Then you can say, “I want to only see unique users who are doing this event.” Now I want to add another event so it adds another trend line. Now I want to make it a funnel so it immediately turns it into the funnel. It's as simple as that. What helps us in their product is that it's opinionated in a way, so they do not try to make it super flexible that you can do any chart.

They just focus on the most needed charts—the time series, the funnel, and stickiness. With even those, I feel they're harder generally for the average user creating stickiness workflows. It's not a trivial thing. 

But having to do these things on Mixpanel and other tools were a pain in the past. We had to think a lot. We had to organize or orchestrate the way we track events so that it's possible to generate this particular chart and then, if you want to create a different chart, we have to redo the event tracking so that it comes up in a different way.

When you say insight, that's like a PostHog term, a PostHog feature, so one of those would be funnels, retention charts. Is that the idea?

Yes. I can show you a quick example.

This is probably too big but it is a people search, it’s an event. I can do it by day, by week. This is a time series. Everything is over time. There's nothing that is not over time because when you think about a startup, you're just trying to iterate and improve and you want to see how you're improving over time. I never want to look at a snapshot of data. I would say very few times, but generally almost all insights, everything you're going to iterate on.

Being able to easily add an event and say, “I'm looking just for the unique users” and then, I'm looking only for let's say monthly active users. Then, I want this to be instead, a cumulative chart. The VCs don't like that, but you can simply do that. Then, let's say I want to see, okay, from people search to doing some, let's say, paths viewed. So this is total count. Now I have two lines. I can simply turn this into a funnel. Instantly, it's a funnel and it's flexible.

I can customize it in ways that help me do better attributions. These are more advanced. I really find the ability to filter out internal users to be extremely valuable because you can't imagine how easy it is to contaminate data by internal users and it's just almost impossible to filter it out. This is just an example. Currently, what our engineers do is, they create an event and either create a trend—like a line chart—or a funnel out of it.

Most of the time, in 90 percent of the cases. We're just seeing that we built it, launched this week, and this is how many people are using it. Let's see next week how people are using it—is that number increasing or not? We are always iterating. Rolling out a new insight and tracking it week-on-week is something that does not take time at all now. It used to take a lot of time so, we had to plan it before with Mixpanel. 

My experience from LinkedIn as well is that these kinds of charts have their internal tool to monitor, do AB testing. PostHog also has AB tests. But we are not at the scale where AB tests are really useful.

However, rolling out tests, doing AB tests, and seeing charts was a very expensive effort by engineers. We had to spec it out in detail because the engineers had to build these charts meaning that they had to do a lot of customization to build them. It's not like a low code or a no code experience like what PostHog has now. I would say the potential of this is not just for startups. Startups want it for speed, but I even see that big companies need ways to track faster using tools like PostHog.

Do you make use of other PostHog features like session replay?

Yes. I mentioned a lot about there insights only, and it's extremely powerful—just getting these insights and charts and being able to play with them. It's like 10 times even more powerful having everything together. 

I can instantly see that these users performed a certain event and I can right away, click on a specific user who performed that event and see a video recording. How beautiful is that? To know who actually engaged with the product and what they did and actually see those events happening as they do them and why they dropped off. Otherwise in most products, you'd have to rely on another tool and you have to jump back and forth cross-checking whether this user session is the same. Most people won’t do this cross-checking work because it’s not draining.

You mentioned this idea that as part of PostHog, engineers can make more product decisions. Can you talk a little bit more about that? Tell us—what kind of decisions do engineers end up making? Is it product decisions when they're using PostHog? How is that an advantage?

All of us are involved in thinking about how we can fix things and what our ideas are to improve that funnel. Eventually, engineers also need to be able to focus on building, product development, and spec'ing. It takes a lot of thinking time and not building time. What ends up happening is that I need to—as the product person on a small team —I have to do a lot of the product stuff.

But then, I realized that once you have a dynamic where you have someone giving orders and someone just building, it just doesn't feel like much ownership for them. Why are we building this? When don’t things go as planned, which is 90 percent of the cases? You have a hypothesis and then you come up with an MVP for it, and then, you have to iterate to mature it. People lose motivation when they don't have the full context. One of the things that PostHog helps with is because the speed of creating an insight is pretty fast.

It makes it easy for the engineers to do it themselves and makes the feedback loop much faster. For example, one of our engineers now is responsible for the virality of Village. Whenever someone joins, how are they bringing on other users and what are the things and the bells and whistles we're creating to bring on other users? There's a very clear chart to get other users and how these invites are working. He's instantly able to see that people are dropping off here, so can see the recording as to why they're dropping off. He can make quick decisions without having to go back to me. Or at least he's owning the whole process and he can run with it versus having me look at those recordings and then go back to him with the suggestions. 

What that helps with is not just that the person feels more ownership, they empathize more with the users. As they build things across the whole product, they get to see more of, “This is something we've experienced and we've seen before, so we will avoid doing it.”

This is also at the engineering level. Architecting things in a way that are extendable for the future. What I mean by extendable is that most features that you build in a startup are going to fail. You would need to iterate them and mature them over time until they actually lead to traction.

The engineer is able to think of, “We're doing this as an experiment now because this is what we've seen with previous experiments and here's how we envision future things that will impact these metrics.” I have to build it in a way that allows me to have all these different variables in mind. It is not just what I end up sharing with them as product specs, but what they also are able to write as extendable code —when they architect their technical work. This means a lower possible for tech debt and faster development.

This transcript is for information purposes only and does not constitute advice of any type or trade recommendation and should not form the basis of any investment decision. Sacra accepts no liability for the transcript or for any errors, omissions or inaccuracies in respect of it. The views of the experts expressed in the transcript are those of the experts and they are not endorsed by, nor do they represent the opinion of Sacra. Sacra reserves all copyright, intellectual property rights in the transcript. Any modification, copying, displaying, distributing, transmitting, publishing, licensing, creating derivative works from, or selling any transcript is strictly prohibited.