Self-serve
We believe this approach will lead to the best product for end users, which is how we'll build the best company.
Adam Gross has given some excellent talks on this topic, that we've borrowed from.
#1-2-3 framework
Product
This means the path to revenue starts with adoption of a Free version, then working out how to get teams (whether a small team at a big company or a 20 person startup) onto a paid version, and ultimately how to get departmental adoption at large enterprises.
| 1 - Free | 2 - Team (Self Serve) | 3 - Enterprise (C-Level) | |
|---|---|---|---|
| Value | Creation | Collaboration | Compliance |
| GTM | Free/Adoption | Self-serve | Enterprise |
Examples of other companies following (part) of this
Postman
As an individual, it is useful for organizing your own API creation activity.
In team mode, it is a way for multiple teams to organize distributed development effort. If you're building across multiple teams with different services, how you coordinate these teams is a big, strategic problem. By using the same tool with modifications, you can orchestrate this.
LaunchDarkly
As an individual, you can view as a pure utility for launching feature flags. I can write myself or use this thing off the shelf to save time. Interesting but limited value proposition.
In team mode, it becomes a way for a team to organize its business process between Product Management and Engineering. It becomes a product management process tool on rails.
Our structure
As we grow, it'll get important to work out which teams in PostHog own different functions.
| Function | Free | Team (Self Serve) | Enterprise (C-Level) |
|---|---|---|---|
| Marketing | Marketing (Developer Evangelism) | Enterprise Product Marketing | |
| Sales | Developer Experience | Customer Success | Enterprise Sales |
| Support | Developer Experience | ||
| Success/Retention | Developer Experience | Customer Success | Customer Solutions Architect |
| Sales Ops | Sales Ops | ||
Following the 1-2-3 framework, we are currently focused on building our team in the first and second columns - Free and Team - and already have Developer Experience and Sales Ops people in place. Only after we have brought in people to take care of Marketing/Developer Evangelism and Customer Success will we then look at recruiting people into the roles in the third column, Enterprise.
Structure FAQ
Why do you have "sales" for the free product?
Developer experience will help ensure the open source product is properly adopted, for $0 in this case.
What's 'Enterprise Product Marketing' versus 'Marketing (Developer Evangelism)'?
Product marketing is making sure that PostHog is positioned as a platform that can be used organization-wide, to aid with expansion. For example, organizing roadmap discussions with large clients.
Developer-evangelism is more about adoption of the first users - creating content, building an audience across social media and GitHub, etc.
What's the difference between Customer Success and Developer Experience?
Customer success is a more commercially-oriented function, focused on inbound sales.
What are sales ops?
It'll be important we have good processes in place to grow usage from free to team and beyond. This means making sure we have a CRM set up, integrated with our product, etc.