TSYSGroupBOD/TSYSGroupHandbook
2
0
Fork 0
Code Pull Requests Actions Packages Projects Releases Activity

merging in material that will be folded in

Browse Source
This commit is contained in:
Charles N Wyble - admin
2021-08-03 21:48:37 -05:00
parent ca1e9cebd4
commit e6f1eae94f
71 changed files with 5990 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

45
SourceMaterial/strategy/business-model.md Normal file
View File

@@ -0,0 +1,45 @@
---
title: Business Model
sidebar: Handbook
showTitle: true
---
<br />
PostHog is a for profit company that balances the need to improve the open source code of PostHog with the need to add source-available features in order to generate income. We will build an open core business model.
## Why would you work on the Community Edition?
A concern could be that given our business model, we'd only work on paid features.
The reality is that paid features can increase our revenue, thus our ability to grow and hire more developers, who we will use on both versions of the product. When we work on the Community Edition, it increases the community size, which means we end up with more features, and thus a better product. This means we get yet more community growth and it also helps with revenue growth since the source-available product will also improve.
At the moment, 100% of our focus is on the Community Edition of the software.
## Promises
1. We won't introduce features into the open source codebase with a delay.
1. We will always release and open source all tests we have for an open source feature.
1. The open source codebase will never contain arbitrary limits (i.e. event volumes, user numbers).
1. The majority of new features made by PostHog will remain open source.
1. The product will always be available for download without leaving an email address or logging in.
1. We will always allow you to [benchmark](https://news.ycombinator.com/item?id=18103162) PostHog.
## What features are paid only?
If the wider community contributes a new feature that isn't already a source-available feature, we aim to nearly always include it into the open source codebase.
When PostHog makes a new feature, we ask ourselves two questions:
1. Who is the likely type buyer of this feature?
1. Would this feature help more users find and use PostHog?
If the likely buyer is an individual contributor, the feature will be open source. Otherwise, if the likely buyer is a manager, director or executive, it will be source available. The exception to this is if the feature will significantly help the community to increase. For example, initially we planned "multiple users" as a feature for the source-available version. However, we decided that having multiple users would help the community to grow, which benefits everyone disproportionately.
## How open source benefits from open core
1. PostHog contributes many new features to the open source version. Having a viable business model makes it easier for us to invest more here.
1. Security fixes.
1. Support until the community can self sustain itself.
1. Performance improvements.
1. Running an upgrade server.

59
SourceMaterial/strategy/investor-updates.md Normal file
View File

@@ -0,0 +1,59 @@
---
title: Working with Investors
sidebar: Handbook
showTitle: true
---
<br />
PostHog brings investors on as partners.
There is a lot of value added from investors:
* Financing so we can build a better and more ambitious product, hence growing faster
* Strategic or tactical advice
* Connections to valuable finance partners
* Connections to valuable potential customers
* Help with hiring a world-class team
# Investor Updates
Investor updates are sent on a monthly basis. This keeps news small and actionable, creates discipline, yet isn't so frequent that much time is spent on reporting.
The format is as follows:
```
------------------------------------------------
Thanks
This is to encourage people to be helpful, which is in everyone's interest, and is part of being nice to work with!
------------------------------------------------
Asks
We may need help with connections to people or organizations, with hiring, or troubleshooting / rubber-ducking.
------------------------------------------------
Key metrics
Investors have a right to know how we're doing. Putting up regular numbers keeps our team focused, and makes many problems more obvious so we can tackle them.
------------------------------------------------
Lowlights
We don't want to surprise people, and by raising issues we may have others help us. We will commit to 3 lowlights every month so we have to include something here.
------------------------------------------------
Highlights
We should surface key opportunities or exciting moments so we can aim to grow fast and to keep people excited.
------------------------------------------------
Expectations
What we're planning for the next month. This context increases our chances of getting help from investors.
------------------------------------------------
```
We do not share investor updates publicly. This is because we often need to mention specific clients, legal and finance issues, all of which are in the rare category of being potentially harmful to discuss.

46
SourceMaterial/strategy/investors.md Normal file
View File

@@ -0,0 +1,46 @@
---
title: Investors
sidebar: Handbook
showTitle: true
---
PostHog are proud to have many world-class investors.
## Series A
We raised a \$9M Series A round, led by Alphabet’s VC firm GV, with participation from YCombinator's Continuity Fund and Tapas Capital.
We brought on board Jason Warner (CTO GitHub) as an investor.
## Seed
We raised a \$3M seed round, led by YCombinator and 1984 VC.
We are also grateful to work with the support of the following:
* Unusual Ventures
* Liquid2 Ventures
* Kima Ventures
* Sunflower Ventures
* Uncorrelated
* Tapas Capital
* SV Angel
* Twenty Two Ventures
## Angels
We have brought on a brilliant group of angel investors throughout PostHog's life:
* David Buxton (founder of Arachnys)
* Dalton Caldwell (founder of imeem / YC Head of Admissions)
* David Cramer (founder of Sentry)
* Brad Flora (founder of PerfectAudience)
* Adam Goldstein (founder of Hipmunk)
* Solomon Hykes (founder of Docker)
* Rujul Zaparde (founder of FlightCar)
* Many more (add yourself via a pull request!)
## Interested?
If you'd like to talk to us about an investment in PostHog, please drop us a line at [investors@posthog.com](mailto:investors@posthog.com).
If you are a startup and want an introduction or advice, please email us at [hey@posthog.com](mailto:hey@posthog.com). We can get very busy but we'll do our best to at least respond in all cases.

208
SourceMaterial/strategy/prioritization.md Normal file
View File

@@ -0,0 +1,208 @@
---
title: Prioritization
sidebar: Handbook
showTitle: true
---
As there is a lot of autonomy at PostHog, it's useful to have a common framework for how to make prioritization decisions.
## Our mission
Our mission is to increase the number of successful products in the world.
To achieve this, we will need revenue to be able to re-invest into making a better product.
## How is our Product-Market Fit?
Below is a table of how we see our product-market fit for various sizes of companies and various job roles.
<span class="table-borders">
<table>
<tr>
<td></td>
<td>Enthusiast</td>
<td>Startup</td>
<td>Scaleup</td>
<td>Enterprise</td>
</tr>
<tr>
<td>Engineers / PMs with technical expertise</td>
<td style="background:var(--success)"></td>
<td style="background:var(--success)"></td>
<td style="background:var(--warning)">Scalability<br />Advanced analytics</td>
<td style="background:var(--warning)">Scalability<br />Advanced analytics</td>
</tr>
<tr>
<td>Non-technical PMs, marketing, sales, business</td>
<td style="background:var(--warning)">Too technical</td>
<td style="background:var(--warning)">Too technical<br />Feature set / integrations</td>
<td style="background:var(--warning)">Too technical<br />Feature set / integrations</td>
<td style="background:var(--warning)">Too technical<br />Feature set / integrations</td>
</tr>
<tr>
<td>Analysts</td>
<td style="background:var(--success)"></td>
<td style="background:var(--success)"></td>
<td style="background:var(--warning)">Direct SQL access<br />Plugins for data lakes</td>
<td style="background:var(--warning)">Direct SQL access<br />Plugins for data lakes</td>
</tr>
<tr>
<td>Enterprise procurement</td>
<td style="background:var(--muted)"></td>
<td style="background:var(--muted)"></td>
<td style="background:var(--muted)"></td>
<td style="background:var(--warning)">SOC 2<br />VPC</td>
</tr>
</table>
</span>
As you can see, we have good product-market fit with engineers generally, and specifically for enthusiasts and startups.
## Value
Now let's look at how building things for the different size companies helps us achieve our two goals:
1. Increase the number of successful products in the world
2. Increase revenue so we can re-invest in #1
Given scores from 1-5, here's how each type of company stacks up against those two values.
<span class="table-borders">
<table>
<tr>
<td></td>
<td>Enthusiast</td>
<td>Startup</td>
<td>Scaleup</td>
<td>Enterprise</td>
</tr>
<tr>
<td>Successful products</td>
<td>Low (1/5)</td>
<td>Very high (5/5)</td>
<td>High (4/5)</td>
<td>Low (1/5)</td>
</tr>
<tr>
<td>Revenue</td>
<td>Low (1/5)</td>
<td>Mid (2/5)</td>
<td>High (4/5)</td>
<td>Very high (5/5)</td>
</tr>
<tr>
<th>Combined</th>
<th>Low (1/5)</th>
<th>High (3/5)</th>
<th>High (3.5/5)</th>
<th>High (3/5)</th>
</tr>
</table>
</span>
## Putting it together
When thinking of building a new feature, we can combine the product-market fit table and the priority table into one.
We have three options for each box:
- Deprecate: stop supporting
- Maintain: fix bugs but don't introduce new features
- Grow: fix bugs, do marketing and make PostHog easier to get started with but don't build new features.
- Build: all of the above + building new features specifically for these categories
<span class="table-borders">
<table>
<tr>
<td></td>
<td>Enthusiast</td>
<td>Startup</td>
<td>Scaleup</td>
<td>Enterprise</td>
</tr>
<tr>
<td>Engineers</td>
<td style="background:var(--muted)" rowspan="3">Maintain</td>
<td style="background:var(--success)">Build</td>
<td style="background:var(--success)">Build</td>
<td style="background:var(--success)">Build</td>
</tr>
<tr>
<td>Non-technical roles</td>
<td style="background:var(--muted)">Maintain</td>
<td style="background:var(--muted)">Maintain</td>
<td style="background:var(--muted)">Maintain</td>
</tr>
<tr>
<td>Analysts</td>
<td style="background:var(--muted)">Maintain</td>
<td style="background:var(--success)">Build</td>
<td style="background:var(--success)">Build</td>
</tr>
<tr>
<td>Enterprise procurement</td>
<td style="background:var(--muted)" colspan="3">N/A</td>
<td style="background:var(--success)">Build</td>
</tr>
</table>
</span>
## Comparing features
If you're trying to decide between two things to work on, a useful exercise can be the following:
1. Estimate the number of successful products that could come out of each category globally (example numbers given)
2. Estimate the amount of revenue we could grab from those categories (example numbers given)
3. Estimate how many of the successful products we could create if we had this feature
4. Estimate how much revenue we could get if we had this feature
5. Repeat steps 1-4 for the feature you're trying to compare
For example, for our virtual private cloud feature we came up with the following numbers:
<span class="table-borders">
<table>
<tr>
<td></td>
<td>Enthusiast</td>
<td>Startup</td>
<td>Scaleup</td>
<td>Enterprise</td>
</tr>
<tr>
<td>Global successful products</td>
<td>10m</td>
<td>1m</td>
<td>10k</td>
<td>10k</td>
</tr>
<tr>
<td>Global revenue</td>
<td>$0</td>
<td>$240m</td>
<td>$500m</td>
<td>$4B</td>
</tr>
<tr>
<td>Additional successful products from feature</td>
<td>0%</td>
<td>5%</td>
<td>5%</td>
<td>10%</td>
<th>51.5k</th>
</tr>
<tr>
<td>Additional revenue from feature</td>
<td>0%</td>
<td>15%</td>
<td>15%</td>
<td>30%</td>
<th>$1,311m</th>
</tr>
</table>
</span>
The point of this exercise is not to come up with the 'correct' numbers. The point is to go through a thought exercise that'll help you figure out the impact of what you're working on.
The idea also isn't that you should do this for every feature you build. Instead, you'll now have a framework for how to think about the impact of what you're building.

51
SourceMaterial/strategy/roadmap.md Normal file
View File

@@ -0,0 +1,51 @@
---
title: Roadmap
sidebar: Handbook
showTitle: true
---
Our mission is to increase the number of successful products in the world.
Our roadmap for 2021 will do three things:
1. Create a solid core product that's easy to use
2. Ensure the best developer platform for event-based analytics
3. Set PostHog up to service huge volumes
# 1. Core product
PostHog is a product that people love, primarily because it covers 90% of analytics use cases but bundled into one package.
Some examples of the functionality we've built last year:
- Product analytics
- Session recording
- Feature flags
- Heatmaps
- Autocapture
There's plenty of work to be done within those categories to make a product that is especially useful for engineers and other product minded people. To add on to that, this year we want to build:
- A/B testing
- User feedback
- Data pipelines
On top of those new categories we have a lot of work to do to make our product more stable at higher volumes (especially when self-deploying), much easier to get started with and to catch up with other state-of-the-art analytics software.
# 2. Best developer platform
Developers like using PostHog for many reasons. We're open-source at our core, which has helped a huge amount in gaining trust and adoption from the developer community.
It's easy to debug, you can self-host and PostHog is now starting to become extensible.
This year we're going to lean into that last item. We've kept plugins relatively quiet so far, but we believe plugins will be what will make PostHog the default choice for developers.
We see a ton of usecases, like integrating PostHog into an existing data warehouse, pulling in stats from other APIs and pushing data into other services.
There will be work on three main fronts:
- Building plugins ourselves
- Giving our community the tools to create their own
- Promote adoption of these plugins.
# 3. Service huge volumes
We are getting a lot of inbound interest from enterprise customers who want to either have us host PostHog or want to host it themselves.
We are starting to have experience scaling instances, but we'll need to get a lot better at this to service the biggest customers.
This isn't just about one-off scaling challenges. To do this at scale, we'll need to productize the deployment of a large instance of PostHog.

45
SourceMaterial/strategy/strategy.md Normal file
View File

@@ -0,0 +1,45 @@
---
title: Strategy overview
sidebar: Handbook
showTitle: true
---
> PostHog's mission is to increase the number of successful products in the world.
## Meet our users, and their problems
Our best users look a little like this:
* They are a founder, product manager or an engineer (often a senior one)
* They may work in a startup, scaleup or enterprise
* Their company builds software, at least in some capacity, and cares about the end users of their software
## How we'll meet their needs
We're consolidating a fragmented set of tools in the market that help software teams understand and act on user behavior. Companies already know why product analytics matter.
Being open source uniquely enables this approach - we're the only team able to build a true platform that others can build on, to accelerate our breadth of tools that we consolidate.
This is generating opportunities to redefine the category by strengthening the integrations between these tools.
Breadth does come at the expense of depth. We do not aim to answer 100% of questions a product manager or engineer may have about user behavior, so making it easy to integrate PostHog with an existing stack of tools (such as data lakes) is important, mainly for larger volume users.
## Traction
We've had ~3,000 deployments since we started.
PostHog helps power products as diverse as those in airlines and banks, to indie gamers making it more fun to protect earth from aliens to underwear startups working on their retention. Across all devices.
## The future
Software is a good chunk through eating the World.
Product led growth is just getting started with eating software. See Figma, Slack, Dropbox, or Google. Incumbent software companies will either become product led or they'll get disrupted.
PostHog today is focused on enabling engineering teams and product teams to work together, better. That gives us the foothold to steer decision making in every team in every company. For product led companies, it all starts from their user behavior.
## What do we need to do next
We have a [strategy project](https://github.com/orgs/PostHog/projects/5), which is visible for PostHog team members.
We have a [prioritization framework](/handbook/strategy/prioritization) to figure out what to work on next.