---
title: Growth Strategy
sidebar: Handbook
showTitle: true
---

<br />

##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](https://twitter.com/adam_g?lang=en) has given some excellent [talks on this topic](https://www.heavybit.com/library/video/self-serve-go-to-market/), 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 business 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.


<table>
    <tr>
        <th>Function</th><th>Free</th><th>Team (Self Serve)</th><th>Enterprise (C-Level)</th>
    </tr>
    <tr>
        <td>Marketing</td>
        <td colspan="2" style="text-align: center;">Marketing (Developer Evangelism)</td>
        <td>Enterprise Product Marketing</td>
    </tr>
    <tr>
        <td>Sales</td>
        <td>Developer Experience</td>
        <td>Customer Success</td>
        <td>Enterprise Sales</td>
    </tr>
    <tr>
        <td>Support</td>
        <td colspan="3" style="text-align: center;">Developer Experience</td>
    </tr>
    <tr>
        <td>Success/Retention</td>
        <td>Developer Experience</td>
        <td>Customer Success</td>
        <td>Customer Solutions Architect</td>
    </tr>
    <tr>
        <td>Business Ops</td>
        <td colspan="3" style="text-align: center;">Business Ops</td>
    </tr>
</table>


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 Business 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 business 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.