TSYSGroupHandbook/SourceMaterial/growth/strategy.md

100 lines
3.9 KiB
Markdown

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