mirror of
https://github.com/BillyOutlast/posthog.com.git
synced 2026-02-04 03:11:21 +01:00
Light edits to the company handbook (#8047)
* light edits to the company handbook tagging in @andyvan-ph to look these over first up. Most changes are pretty minor, couple of bigger edits on sentences that were tricky to parse * Apply suggestions from code review Co-authored-by: Andy Vandervell <92976667+andyvan-ph@users.noreply.github.com> * Update current-status.md --------- Co-authored-by: Andy Vandervell <92976667+andyvan-ph@users.noreply.github.com>
This commit is contained in:
James Temperton
@@ -31,9 +31,9 @@ We've also got:
|
||||
|
||||
At the start of 2023, we went from “product analytics with some extra stuff thrown in” to “Product OS”, and started charging for session replay separately.
|
||||
|
||||
It went great, we grew session replay revenue, usage and got way better feedback, which lead to a better product.
|
||||
It went great, we grew session replay revenue, usage, and got way better feedback, which lead to a better product.
|
||||
|
||||
In Q3, we want to position externally as having multiple products more clearly than we did at the start of the year. That means – product analytics, session replays, feature flags, A/B testing, and perhaps CDP, each as their own first class product. It makes it easier for new folk to get what we do, means we can give more ownership (which means more speed) to our own teams, and it means we can compete on commercials very effectively.
|
||||
In Q3, we want to position externally as having multiple products more clearly than we did at the start of the year. That means: product analytics, session replays, feature flags, A/B testing, and perhaps CDP, each as their own first-class product. It makes it easier for new folk to get what we do, means we can give more ownership (which means more speed) to our own teams, and it means we can compete on commercials very effectively.
|
||||
|
||||
However, PostHog really is the integration between all these things.
|
||||
|
||||
@@ -43,13 +43,13 @@ We’re already doing this. It’s hard, but we’re already adding more compani
|
||||
|
||||
Examples of “integration”:
|
||||
|
||||
- **HogQL** - get any visualizations we offer + build on us long term via the API + remove technical debt by standardizing our queries.
|
||||
- **HogQL:** Get any visualizations we offer + build on us long term via the API + remove technical debt by standardizing our queries.
|
||||
|
||||
- **Notebooks** - new product = more people will find us + could provide standard way to save / search for research instead of using saved insights/dashboards/playlists.
|
||||
- **Notebooks:** New product = more people will find us + could provide standard way to save / search for research instead of using saved insights/dashboards/playlists.
|
||||
|
||||
- **Warehouse** - new product = more people will find us + increases order sizes dramatically + solves data parity issues in every product in a way no other product analytics point solution can do + enhances insights, notebooks, etc., with more data + enables building data apps in the long run.
|
||||
- **Warehouse:** New product = more people will find us + increases order sizes dramatically + solves data parity issues in every product in a way no other product analytics point solution can do + enhances insights, notebooks, etc., with more data + enables building data apps in the long run.
|
||||
|
||||
- **CDP** - Product Analytics / HogQL / Notebooks / Warehouse all become more powerful.
|
||||
- **CDP:** Product Analytics / HogQL / Notebooks / Warehouse all become more powerful.
|
||||
|
||||
### Q4 2023 - "Win the Internet"
|
||||
|
||||
@@ -57,26 +57,26 @@ Since Q3 is about to finish, we've started planning for Q4.
|
||||
|
||||
Currently, we are often mentioned as an alternative to product analytics tools.
|
||||
|
||||
We have the capabilities now, but we are winning the internet when we get more of this for our _other_ products (we don’t have to win everything, but we need to get into the comparison each time). This is _starting_ to happen, but to Win the Internet, we need to see this happening daily.
|
||||
We have the capabilities now, but we are winning the internet when we get more of this for our _other_ products. (We don’t have to win everything, but we need to get into the comparison each time.) This is _starting_ to happen, but to Win the Internet, we need to see this happening daily.
|
||||
|
||||
We’ve got multiple products that are early:
|
||||
|
||||
- **Warehouse**, so people can query however they want.
|
||||
|
||||
- **ETL** (simple imports of other data sources like Postgres or Stripe into our warehouse) are needed for the above to make sense.
|
||||
- **ETL**, simple imports of other data sources like Postgres or Stripe into our warehouse, are needed for the above to make sense.
|
||||
|
||||
- **Surveys** (being used a lot but not paid / lots of quality improvements we can make).
|
||||
- **Surveys**, being used a lot but not paid, and lots of quality improvements we can make.
|
||||
|
||||
- **Feature flags and experiments** - we’ve just started making our first revenue. Let’s get 100% sure we have [product-market fit](/blog/product-market-fit-game) for these tools.
|
||||
- **Feature flags and experiments** - we’ve just started making our first revenue. Let’s be 100% sure we have [product-market fit](/blog/product-market-fit-game) for these tools.
|
||||
|
||||
- **CDP** - we have been rebuilding our pipelines first, webhooks next, but eventually playing offense and having a standalone first-class CDP is where the greatest returns are.
|
||||
|
||||
- **Notebooks** has some awesomeness, but isn’t mass released / is starting to overlap a bit with PostHog 3000, and we’re refactoring insights in HogQL still. Figuring out the right combo of these things will lead to more word of mouth growth by taking us from just as good, to far better, for some of our existing products (#noteforce3000sql).
|
||||
- **Notebooks** has some awesomeness, but isn’t mass released and is starting to overlap a bit with PostHog 3000. We’re also still refactoring insights in HogQL. Figuring out the right combo of these things will lead to more word-of-mouth growth by taking us from just as good, to far better, for some of our existing products (#noteforce3000sql).
|
||||
|
||||
- With **web analytics**, we’ve been thinking it through carefully and getting the leader of this product up and running with PostHog engineering in general, but haven’t actually shipped anything here.
|
||||
|
||||
- And of course there is a lot of supporting work:
|
||||
- Helping teams with their per product onboarding and growth experiments, infra, ingestion, dev tooling, sales, support and marketing.
|
||||
- Helping teams with their per product onboarding and growth experiments, infra, ingestion, dev tooling, sales, support, and marketing.
|
||||
- Promoting each product in its own right (i.e. through what we cover in marketing).
|
||||
- Keep nurturing the content / community growth, i.e. newsletter, and the /posts concept.
|
||||
|
||||
@@ -84,21 +84,22 @@ We’ve got multiple products that are early:
|
||||
|
||||
We have a bunch of awesome products generating revenue. Since last quarter:
|
||||
|
||||
- feature flags and experiments has got product market fit
|
||||
- we've got a warehouse with early meaningful usage
|
||||
- we figured out notebooks vs PostHog 3000 and have shipped a new UX for everyone
|
||||
- web analytics has been shipped and is getting plenty of usage
|
||||
- stability has remained excellent
|
||||
- Feature flags and experiments has got product-market fit
|
||||
- We've got a warehouse with early meaningful usage
|
||||
- We figured out notebooks vs PostHog 3000 and have shipped a new UX for everyone
|
||||
- Web analytics has been shipped and is getting plenty of usage
|
||||
- Stability has remained excellent
|
||||
|
||||
A lot of new user-facing things got shipped last quarter. However, every product could be improved a lot.
|
||||
|
||||
This is a quarter of caring about the craft of your product.
|
||||
This is a quarter of caring about the craft of your product:
|
||||
|
||||
- Major missing features vs competitors
|
||||
- Scalability/stability
|
||||
- Developer UX
|
||||
- Talking to users and incorporating their feedback
|
||||
- Nailing support for your product - fixing things
|
||||
|
||||
Products are not limited to people working on the app - it includes what customer success / marketing / ops are working on. Everything can be considered a product.
|
||||
Products are not limited to people working on the app – it includes what customer success, marketing, and ops are working on. Everything can be considered a product.
|
||||
|
||||
Each team should be aiming to feel proud of what they've built by the end of the quarter.
|
||||
Each team should be aiming to feel proud of what they've built by the end of the quarter.
|
||||
|
||||
@@ -5,15 +5,15 @@ showTitle: true
|
||||
---
|
||||
## Stay calm and default alive
|
||||
|
||||
We don't optimize for short run revenue growth, but we do make sure we have enough money to never feel dependent on future fundraising.
|
||||
We don't optimize for short-run revenue growth, but we do make sure we have enough money to never feel dependent on future fundraising.
|
||||
|
||||
If we average 5% MoM growth, we are default alive (i.e. we'll become profitable before we run out of capital). If we average 7.5% we'll hit $100M by the end of 2026.
|
||||
If we average 5% MoM growth, we are default alive (i.e. we'll become profitable before we run out of capital). If we average 7.5% we'll hit $100m by the end of 2026.
|
||||
|
||||
Maintaining a strong financial position helps us optimize for long term revenue growth. For example, we've [removed products and revenue](/blog/sunsetting-helm-support-posthog) for long-term gains.
|
||||
Maintaining a strong financial position helps us optimize for long-term revenue growth. For example, we've [removed products and revenue](/blog/sunsetting-helm-support-posthog) for long-term gains.
|
||||
|
||||
## Fundraising principles
|
||||
|
||||
Rule #1: Never have to fundraise... and fundraise if all the following are true:
|
||||
Rule #1: Never have to fundraise – and only fundraise if all the following are true:
|
||||
|
||||
* It will speed us up.
|
||||
* We can use the money effectively.
|
||||
@@ -29,4 +29,4 @@ The advantage of our approach is that it's more efficient – $1 spent on produc
|
||||
|
||||
The disadvantage is that scaling an engineering team is, in our opinion, harder than scaling a sales team. Since engineers' work very heavily overlaps, there is more complexity to getting this right. We may not be able to grow beyond a certain rate, no matter how much we spend.
|
||||
|
||||
The final disadvantage is that it's harder to predict how fast we'll grow (compared to a company that grows by hiring salespeople with targets), so it takes more thought and often requires more faith!
|
||||
The final disadvantage is that it's harder to predict how fast we'll grow compared to a company that grows by hiring salespeople with targets, so it takes more thought and often requires more faith!
|
||||
@@ -12,14 +12,14 @@ What motivates us is building an epic product and company.
|
||||
|
||||
We're excited by:
|
||||
|
||||
* figuring out how far we can go
|
||||
* helping engineers build products - reduce the need for product and data teams
|
||||
* beating all the point solution competitors
|
||||
* having customers buy _from_ us instead of us selling _to_ them
|
||||
* Figuring out how far we can go
|
||||
* Helping engineers build products - reduce the need for product and data teams
|
||||
* Beating all the point solution competitors
|
||||
* Having customers buy _from_ us instead of us selling _to_ them
|
||||
|
||||
We're *not* excited by:
|
||||
|
||||
* selling the company for $1 billion - we think we can build a much bigger company by staying independent
|
||||
* Selling the company for $1 billion – we think we can build a much bigger company by staying independent
|
||||
|
||||
## $100M by 2026
|
||||
|
||||
@@ -33,4 +33,4 @@ Everyone at PostHog has options in the company – that means they can be a shar
|
||||
|
||||
However, at different stages of the company's life, the value of each person's stock may be hundreds of thousands, millions, or even tens of millions of dollars. If someone doesn't have much capital but has $10 million in stock options, they'll start wanting us to sell.
|
||||
|
||||
Therefore, we aim to let people sell some of their stock when we fundraise once their stock has very significantly increased in value, to keep everyone focused on building something bigger and longer term. This depends on what we can negotiate every time we fundraise, but it's the general philosophy we have.
|
||||
As a result, we aim to let people sell some of their stock when we fundraise and once their stock has very significantly increased in value. This helps keep everyone focused on building something bigger and longer term. What we can offer will depend on what we can negotiate every time we fundraise, but this is our general philosophy.
|
||||
@@ -40,13 +40,13 @@ If you aren't able to make a change yourself, create an issue in GitHub. Avoid s
|
||||
|
||||
For discussions, public repos are the best place. Then private ones, then Slack public channels, then Slack private channels or DMs. This is part of our _"We are open source"_ value, and helps with general context setting for the wider team, which means everyone can work more autonomously.
|
||||
|
||||
There are only a few exceptions to what we can't share publicly, for example if you are discussing security concerns, specific customers (for privacy reasons), revenue or growth numbers (since these cause signalling issues with investors or competitors).
|
||||
There are only a few exceptions to what we can't share publicly, for example if you are discussing security concerns, specific customers (for privacy reasons), revenue, or growth numbers (since these cause signalling issues with investors or competitors).
|
||||
|
||||
Internally, _everything_ can be shared apart from people issues – such as HR / personal (i.e. recruitment or health data).
|
||||
|
||||
### Be proactive with community questions
|
||||
|
||||
Don't _only_ help the community when you're the person on support hero in your small team. No matter what your goals may be, if you can quickly ship fixes to real life user problems, then you are going to build goodwill, word of mouth growth, and a better product all in one swoop.
|
||||
Don't _only_ help the community when you're the person on support hero in your small team. No matter what your goals may be, if you can quickly ship fixes to real life user problems, then you are going to build goodwill, word-of-mouth growth, and a better product all in one swoop.
|
||||
|
||||
You can find these in [posthog.com/questions](https://posthog.com/questions).
|
||||
|
||||
@@ -64,25 +64,25 @@ A beginner's guide to some of our custom Slack emojis and various anecdotes you'
|
||||
|
||||
* Mr Blobby. We once changed how we ingest session recording data, to use S3 blob storage. We called it Mr Blobby. [Mr Blobby](https://en.wikipedia.org/wiki/Mr_Blobby) is a creepy '90s TV character from the UK. This project was nightmarishly hard, which is why this character was fitting.
|
||||
|
||||
* Paul will make you eat Gelato at every offsite.
|
||||
* Paul will make you eat gelato at every offsite.
|
||||
|
||||
* Sometimes people screenshot each other's faces and zoom screens and use them as their backgrounds. Usually when an all hands is too dry.
|
||||
* Sometimes people screenshot each other's faces and Zoom screens and use them as their backgrounds. Usually when an all-hands is too dry.
|
||||
|
||||
* Charles wore a suit to his performance review. He is the only person in history to wear a suit to anything PostHog related. Unsure if he was making a point, we later abandoned the practice of performance reviews regardless.
|
||||
* Charles wore a suit to his performance review. He is the only person in history to wear a suit to anything PostHog-related. Unsure if he was making a point, we later abandoned the practice of performance reviews regardless.
|
||||
|
||||
* We took lots of buses at an offsite in Portugal. The roads were incredibly twisty, the driver was in a bad mood, drove too quickly, and people threw up. It was bad.
|
||||
|
||||
* <Emoji name="sparksjoy" src="/images/emojis/sparksjoy.png" /> / <Emoji name="does_not_spark_joy" src="/images/emojis/does_not_spark_joy.png" /> A reference to <a href="https://konmari.com/marie-kondo-rules-of-tidying-sparks-joy/">Marie Kondo's book</a> on tidying your house, generally used to describe things that are particularly good or bad from a user's perspective
|
||||
|
||||
* <Emoji name="eu-thumbsup" src="/images/emojis/eu-thumbsup.png" /> / <Emoji name="thumbs-down-eu" src="/images/emojis/thumbs-down-eu.png" /> We once made <a href="https://www.isgoogleanalyticsillegal.com">isgoogleanalyticsillegal.com</a> when there were privacy rulings about Google Analytics. We put it on HN, got the top of the front page, and it was our biggest <em>ever</em> day of signups at the time. The website was supposed to be tongue in cheek, but the internet took it seriously. The person in the emoji is Ursula von der Leyen who introduced the GDPR legislation.
|
||||
* <Emoji name="eu-thumbsup" src="/images/emojis/eu-thumbsup.png" /> / <Emoji name="thumbs-down-eu" src="/images/emojis/thumbs-down-eu.png" /> We once made <a href="https://www.isgoogleanalyticsillegal.com">isgoogleanalyticsillegal.com</a> when there were privacy rulings about Google Analytics. We put it on Hacker News, got the top of the front page, and it was our biggest <em>ever</em> day of signups at the time. The website was supposed to be tongue in cheek, but the internet took it seriously. The person in the emoji is Ursula von der Leyen, who introduced the GDPR legislation.
|
||||
|
||||
* IPO promises. There is a list of these that is brought out at certain moments. You may see.
|
||||
|
||||
* [Marius](/community/profiles/1) will train you on Post-it notes if you go to an offsite with him. Success of a good Post-it note posting is in the lift away from the surface – the most important thing is to peel, as opposed to pulling, the Post-it note off.
|
||||
* [Marius](/community/profiles/1) will train you on Post-it notes if you go to an offsite with him. Success of a good Post-it note posting is in the lift away from the surface – the most important thing is to peel off the Post-it note, as opposed to pulling.
|
||||
|
||||
* Three finger rule - another Marius invention, if someone holds up three fingers while you're talking, it means you aren't being concise enough. We don't actually use this much as it's predictably awkward and distracting, so ruins any meeting it could have otherwise helped.
|
||||
|
||||
* When we hit 10,000 GitHub stars, [Ian](../community/profiles/269) read every username on a live stream that took over 6 hours.
|
||||
* When we hit 10,000 GitHub stars, [Ian](../community/profiles/269) read every username on a live stream that took over six hours.
|
||||
|
||||
* We like to nail things. It's not uncommon to see a GitHub issue titled "Nail [feature name]". Sometimes we'll even assign an absurd version number like "3000". (The codename for the next generation UI of the PostHog app is referred to as PostHog 3000, and other projects have also adopted this naming convention as well.)
|
||||
|
||||
|
||||
@@ -6,35 +6,35 @@ showTitle: true
|
||||
|
||||
Over 100,000 users have signed up to PostHog.
|
||||
|
||||
Most companies build their product with a particular user in mind. We built _everything_ around our ideal customer profile.
|
||||
Most companies build their product with a particular user in mind. We build _everything_ around our ideal customer profile.
|
||||
|
||||
So when it comes to marketing and sales, we are optimizing for developer experience.
|
||||
|
||||
## Context – why we're like this
|
||||
## Why we're like this
|
||||
|
||||
We've met multiple successful founders in our space, with companies well over $100M in annual revenue, filled with regret! The one regret they _all_ had in common was letting go of their growth engine (people recommending their product to each other) and getting focused on sales. They all wound up exiting. That's why they told us this stuff.
|
||||
We've met a lot of successful founders in our space who are full of regret, despite leading companies with well over $100m in annual revenue! The one regret they _all_ had in common was letting go of their growth engine (people recommending their product to each other) and getting focused on sales. They all wound up exiting. That's why they told us this stuff.
|
||||
|
||||
The way this pans out? They gradually shifted as they got bigger from building for users, to building for buyers to optimize for revenue growth. Over time, that killed their word of mouth growth, which caused them to have to work harder for each sale. So they got more salesy, and so on. They became companies that focused on making a bunch of money _by_ building a product, instead of being companies focused on building a great product.
|
||||
|
||||
We simply won't make this mistake.
|
||||
We won't make this mistake.
|
||||
|
||||
## Marketing for us is producing useful content
|
||||
## For us, marketing is creating useful content
|
||||
|
||||
Our [marketing team](/teams/marketing) is small. Way, _way_ smaller than our competitors'. Winning on volume of content is out of the question. So we'd better win on quality.
|
||||
|
||||
This constraint has worked out pretty well for us. Distribution is pretty easy when the thing you're working on is good enough to generate word of mouth growth... and this helps build an enduring developer brand.
|
||||
This constraint has worked out pretty well for us. Distribution is pretty easy when the thing you're working on is good enough to generate word of mouth growth – and this helps build an enduring developer brand.
|
||||
|
||||
We even hire full stack developers into our marketing team to make sure we can cover the full depth needed in a lot of our tutorials, docs, and posts.
|
||||
We even hire full-stack developers into our marketing team to make sure we can cover the full depth needed in a lot of our tutorials, docs, and posts.
|
||||
|
||||
Things you won't find our marketing team doing: removing information from our website to increase conversion, focusing on paid ads, or letting their colleagues ship content they aren't proud of.
|
||||
Things you won't find our marketing team doing: removing information from our website to increase conversion, focusing on paid ads, or letting colleagues ship content they aren't proud of.
|
||||
|
||||
## We happily spend lots of money on our website
|
||||
|
||||
Most companies call it their "marketing website". You already know it's going to be crappy.
|
||||
|
||||
We treat ours as a product. With real investment. When we were just a couple of people, we realized that our website _is_ our sales team – since our users would want to self-serve as much as possible.
|
||||
We treat our website as a product. With real investment. When we were just a couple of people, we realized that our website _is_ our sales team – since our users would want to self-serve as much as possible.
|
||||
|
||||
We also realized when we started that all our competitors had crappy marketing websites.
|
||||
When we started out, we also realized that all our competitors had crappy marketing websites.
|
||||
|
||||
And, as with so much that we do, we get an _increasing return_ on quality. If we do things noticeably better than everyone else, then we're remarkable. That results in word of mouth growth.
|
||||
|
||||
|
||||
@@ -8,29 +8,29 @@ We make money from those that have it and like our products. We don't make money
|
||||
|
||||
## How we do sales is based on the best experience for our Ideal Customer Profile
|
||||
|
||||
I cannot think of any harder group to convince via a cold call or email to buy software, than developers. Therefore, we should focus all our energy on inbound, so we don't do outbound sales at all.
|
||||
I cannot think of any harder group than developers to convince via a cold call or email to buy software. We should focus all our energy on inbound – that's why we don't do outbound sales.
|
||||
|
||||
All the other rules here are based on what we felt would be the best experience for an engineering customer whilst allowing us to grow revenue in the long run.
|
||||
All the other rules here are based on what we felt would be the best experience for an engineering customer, whilst allowing us to grow revenue in the long run.
|
||||
|
||||
## Don't let pricing get in the way
|
||||
|
||||
Before a user has decided to buy the product, we should let them try it for free. Not only does this mean they can immediately self-serve without having to get budget internally, it reduces the need for a large sales team to convince them otherwise. When someone is looking for a solution, they are ready to install it if we can get out of the way commercially.
|
||||
Before a user has decided to buy the product, we should let them try it for free. Not only does this mean they can immediately self-serve without having to get budget internally, it also reduces the need for a large sales team to convince them otherwise. When someone is looking for a solution, they are ready to install it – but only if we can get out of the way commercially.
|
||||
|
||||
Once a user likes the product, we don't want to create a big decision around continuing to expand their usage with us. (For example, if we suddenly charged a large recurring price per month.) Instead, we charge a tiny fraction of a cent for each extra event they send.
|
||||
|
||||
## Charge based on what people use, and give users control
|
||||
|
||||
Some users want to start with just a little usage of one product. Others replace 5 products with us. We should price to reflect this. We believe it's better to have a little extra pricing complexity to provide a much better value option, than an "all-in-one" price.
|
||||
Some users want to start with just a little usage of one product. Others replace five products with us. We should price to reflect this. We believe it's better to have a little extra pricing complexity to provide a much better value option, than an "all-in-one" price.
|
||||
|
||||
We charge by product _and_ by usage of those products that people need.
|
||||
|
||||
Beyond which products we use, we look for other ways to give users control, such as spending limits on session recordings.
|
||||
|
||||
Overall, these principles mean that they will spend less than they otherwise would have, _but_ it means they'll stick around. We don't want users to churn if they are unhappy with what they're spending; we want them to better manage how they use the platform.
|
||||
These principles mean that they will spend less than they otherwise would have, _but_ it means they'll stick around. We don't want users to churn if they are unhappy with what they're spending; we want them to better manage how they use the platform.
|
||||
|
||||
## Be the cheapest for each individual product
|
||||
|
||||
We can make it up on selling other products to the customer over time. This way, it's always a no-brainer to pick PostHog, we get as much word of mouth growth as possible, _and_ our single product competitors can't compete since they have nowhere to go.
|
||||
We can make it up by selling other products to the customer over time. This way, it's always a no-brainer to pick PostHog, we get as much word of mouth growth as possible, _and_ our single product competitors can't compete since they have nowhere to go.
|
||||
|
||||
## Principles for dealing with big customers
|
||||
|
||||
@@ -40,6 +40,6 @@ The most important thing here is to remain focused on building the best product,
|
||||
|
||||
* **We don't contract deliverables,** and we especially don't contract to provide deliverables by a certain date. This is because, on principle, a single customer is forcing us to build something.
|
||||
|
||||
* **We will build things for a big customer, as long as we are confident they won’t be the only user of that thing.** Re-shuffling the roadmap order a bit could make sense - but adding new things that others wouldn't use, doesn't.
|
||||
* **We will build things for a big customer, as long as we are confident they won’t be the only user of that thing.** Re-shuffling the roadmap a bit could make sense - but adding new things that others wouldn't use, doesn't.
|
||||
|
||||
* **Customers need to try PostHog before they expect us to change things.** We love feedback from customers. We don't love big requirement documents from people that haven't used our product before.
|
||||
@@ -4,27 +4,27 @@ sidebar: Handbook
|
||||
showTitle: true
|
||||
---
|
||||
|
||||
We want our customers to spend their money on their engineering team, not on buying 10 software products.
|
||||
We want our customers to spend their money on their engineering team, not on buying ten software products.
|
||||
|
||||
Here is the list of advantages we have and why they matter.
|
||||
|
||||
## We can sell multiple products to the same people
|
||||
|
||||
So, do you want to buy 10 products for $1k each or all 10 for $5k? Or, better yet, each one separately.
|
||||
So, do you want to buy ten products for $1k each or all ten for $5k? Or, better yet, each one separately?
|
||||
|
||||
We can pull this off because we're focused on getting in first – we don't follow the whims of whatever an enterprise may have.
|
||||
|
||||
## No sales needed
|
||||
|
||||
Our competitors spend more on sales and marketing than product development. Nearly all our sales are self-serve _and_ 70% of our customers find us through word of mouth growth.
|
||||
Our competitors spend more on sales and marketing than product development. Nearly all our sales are self-serve _and_ 70% of our customers find us through word-of-mouth growth.
|
||||
|
||||
## Multiple products, one dataset
|
||||
|
||||
We aim to be the source of truth for customer and product data. The products we build all work from this same dataset, instead of 10 different vendors all paying to store the same data as each other – each with their own platform teams.
|
||||
We aim to be the source of truth for customer and product data. The products we build all work from this same dataset, instead of ten different vendors all paying to store the same data as each other – each with their own platform teams.
|
||||
|
||||
## A technical audience who need _docs_, not technical support
|
||||
|
||||
Many of our products are traditionally sold to non-technical people. They need more help setting up SDKs or snippets. We work with engineers, who simply need good docs. Writing and maintaining those (and an open-source codebase that people can inspect or even fix bugs in themselves) saves thousands of support questions each year.
|
||||
Many of our products are traditionally sold to non-technical people. They need more help setting up SDKs or snippets. We work with engineers who simply need good docs. Writing and maintaining those (and an open-source codebase that people can inspect or even fix bugs in themselves) saves thousands of support questions each year.
|
||||
|
||||
## Using open-source technology
|
||||
|
||||
|
||||
@@ -4,7 +4,7 @@ sidebar: Handbook
|
||||
showTitle: true
|
||||
---
|
||||
|
||||
User happiness is of fundamental importance. So, how do we achieve this?
|
||||
User happiness is fundamentally important. How do we achieve this?
|
||||
|
||||
## Building products that people want
|
||||
|
||||
@@ -12,16 +12,16 @@ First, someone internally will suggest an idea. Sometimes this will come from Ja
|
||||
|
||||
If it requires a new team to build it – which it usually will – we'll start by hiring an ex-founder who is technical. We'll onboard them into the existing team that has the most overlap. This helps get them used to working with our codebase, and with the culture we look for from each team.
|
||||
|
||||
That person builds the MVP, and the only goal is to figure out if anyone will use it. With some products, the MVP may have more scope if we feel especially confident. Once the new product is in a non-embarrassing state (that won't harm our brand), we add pricing to it and position it on our website. This drives much more demand. At this stage, the goal is to get the product to [product-market fit](/blog/product-market-fit-game) in PostHog's platform, which means working with customers until we have 5 delighted, paying customers.
|
||||
That person builds the MVP, and the only goal is to figure out if anyone will use it. With some products, the MVP may have more scope if we feel especially confident. Once the new product is in a non-embarrassing state (that won't harm our brand), we add pricing to it and put it on our website. This drives more demand. At this stage, the goal is to get the product to [product-market fit](/blog/product-market-fit-game) in PostHog's platform, which means working with customers until we have five delighted, paying customers.
|
||||
|
||||
Once all this is done – which we'd expect to take a few months – we can start to innovate. This usually means some kind of platform play, such as extending the product to enhance everything else we're working on, or shipping another new product that would work well with it.
|
||||
|
||||
## Engineers talk to users and provide support
|
||||
|
||||
You should be _as close as possible_ to your users, feeling whatever they feel, so you have as much signal as possible to make the product great.
|
||||
You should be _as close as possible_ to your users, feeling whatever they feel, so you have as much information as possible to make the product great.
|
||||
|
||||
For established products with a lot of usage questions (how do I create an insight that does X for example), Customer Success helps with support.
|
||||
For established products with a lot of usage questions (how do I create an insight that does X, for example), Customer Success helps with support.
|
||||
|
||||
For example, before a new product is even made, we'll add it to our [public roadmap](/roadmap). Once it ships, we'll use our own tools to get customer interviews, feedback, and data, and we'll always aim to "close the loop" with users - coming back with a) a pull request, b) a GitHub issue they can follow in the open, or c) at least saying why we can't do a feature they've asked for.
|
||||
Before a new product is even made, we'll add it to our [public roadmap](/roadmap). Once it ships, we'll use our own tools to get customer interviews, feedback, and data, and we'll always aim to "close the loop" with users - coming back with: a pull request, a GitHub issue they can follow in the open, or an explanation of why we can't make a feature they've asked for.
|
||||
|
||||
In one fell swoop, this means the product improves, users are impressed and recommend us to others, _and_ we show users that we listen, encouraging them to keep going through this loop with us, faster and faster.
|
||||
This means the product improves, users are impressed and recommend us to others, _and_ we show users that we listen, encouraging them to keep going through this loop with us, faster and faster.
|
||||
@@ -24,13 +24,13 @@ showTitle: true
|
||||
|
||||
## Handbook
|
||||
|
||||
Like many things at PostHog, the handbook has scrappy origins.
|
||||
Like many things at PostHog, this handbook has scrappy origins.
|
||||
|
||||
[Tim](../community/profiles/108) and [James](../community/profiles/71) were planning on launching on [HackerNews](https://news.ycombinator.com/), and we wanted to look as mature as possible – we felt that few people would want to use a flaky new startup's product seriously. So, we asked ourselves, how do we signal that we're mature?
|
||||
[Tim](../community/profiles/108) and [James](../community/profiles/71) were planning on launching on [HackerNews](https://news.ycombinator.com/), and wanted to look as mature as possible. We felt that few people would want to use a flaky new startup's product seriously. So we asked ourselves: how do we signal that we're mature?
|
||||
|
||||
We looked around at some big, boring companies and realized they all had huge footer sections on their websites with lots of links! How do we produce a lot of content to add to our footer when the product, at that time, was so simple? We should write up how we want to work.
|
||||
We looked around at some big, boring companies and realized they all had huge footer sections on their websites with lots of links! How do we produce a lot of content to add to our footer when the product, at that time, was so simple? The answer: we should write up how we want to work.
|
||||
|
||||
Once we started writing it, we realized it would transform our company. Every team member, and even strangers on the internet could suggest changes. If you're doing something in public, you're going to think it through better. Ultimately, it made us treat the company as our product.
|
||||
Once we started writing the handbook, we realized it would transform our company. Every team member, and even strangers on the internet, could suggest changes. If you're doing something in public, you're going to think it through better. Ultimately, it made us treat the company as our product.
|
||||
|
||||
It's a classic example of getting information by doing, rather than by planning too carefully.
|
||||
|
||||
@@ -38,29 +38,29 @@ It's a classic example of getting information by doing, rather than by planning
|
||||
|
||||
### Jan 2020: The start
|
||||
|
||||
PostHog was founded by James and Tim on January 23rd, 2020.
|
||||
PostHog was founded by James and Tim on January 23, 2020.
|
||||
|
||||
We started working together on a startup in August 2019 with the first idea being to help engineers manage technical debt. It didn't work out, but we realized the power of treating growth as an engineering problem. We also knew that many engineers struggle to understand their impact on their users.
|
||||
We started working together on a startup in August 2019. Our first idea was to help engineers manage technical debt. It didn't work out, but we realized the power of treating growth as an engineering problem. We also knew that many engineers struggle to understand the impact they have on the people who use what they build.
|
||||
|
||||
There are plenty of product analytics tools out there, but all the alternatives are SaaS-based. While they are very powerful, they can be frustrating for developers. From our perspective, these tools can be problematic because:
|
||||
There are plenty of product analytics tools out there, but all the alternatives are SaaS-based. While they're powerful, they can be frustrating for developers. From our perspective, these tools can be problematic because:
|
||||
|
||||
* We didn't want to send all our user data to 3rd parties.
|
||||
* We wanted full underlying data access.
|
||||
* They don't give you choice and control over pricing.
|
||||
* We don't want to send all our user data to third parties
|
||||
* We want full underlying data access
|
||||
* They don't give you choice and control over pricing
|
||||
|
||||
### Feb 2020: Launch
|
||||
|
||||
We got into Y Combinator's W20 batch, and just a couple of weeks after starting realized that we needed to build PostHog.
|
||||
We got into Y Combinator's W20 batch, and, just a couple of weeks after starting, realized that we needed to build PostHog.
|
||||
|
||||
We launched on [Hacker News](https://news.ycombinator.com/item?id=22376732) with our MVP, just 4 weeks after we started writing code. PostHog was our sixth idea – we had been pivoting almost once a month for the last half a year. Boy were we relieved!
|
||||
We launched on [Hacker News](https://news.ycombinator.com/item?id=22376732) with our MVP, just four weeks after we started writing code. PostHog was our sixth idea – we had been pivoting almost once a month for half a year. Boy were we relieved!
|
||||
|
||||
The response was overwhelmingly positive. We had over 300 deployments in a couple of days. 2 weeks later, we'd gone past 1,500 stars on [GitHub](https://github.com/PostHog/posthog).
|
||||
The response was overwhelmingly positive. We had over 300 deployments in a couple of days. Two weeks later, we'd gone past 1,500 stars on [GitHub](https://github.com/PostHog/posthog).
|
||||
|
||||
Since then, we've realized we weren't just onto a cool side project, we were onto what could be a huge company. It turned out there were lots of developers liked us who wanted a better choice, built for them.
|
||||
Since then, we've realized we weren't just onto a cool side project, we were onto what could be a huge company. It turned out there were a lot of developers who liked us who wanted a better choice, built for them.
|
||||
|
||||
### Apr 2020: $3M Seed round
|
||||
### Apr 2020: $3m seed round
|
||||
|
||||
After we finished Y Combinator, [we raised a $3.025M seed round](../../blog/raising-3m-for-os). This was from Y Combinator's Continuity Fund, 1984 Ventures.
|
||||
After we finished Y Combinator, [we raised a $3.025m seed round](../../blog/raising-3m-for-os). This was from Y Combinator's Continuity Fund, 1984 Ventures.
|
||||
|
||||
As we started raising, we started hiring. We brought on board [Marius, Eric and James G](/blog/posthog-first-five).
|
||||
|
||||
@@ -74,45 +74,45 @@ This was a major update – PostHog started providing [ClickHouse support](../bl
|
||||
|
||||
### Nov 2020: Building a platform
|
||||
|
||||
We realized that our users, whether they're startups, scale ups or enterprises, have simple needs across a broad range of use cases in understanding user behavior.
|
||||
We realized that our users, whether startups, scale ups or enterprises, have simple needs across a broad range of use cases in understanding user behavior.
|
||||
|
||||
PostHog now supported [product analytics](/product/trends), [feature flags](/product/feature-flags), and [session recording](/product/session-recording).
|
||||
|
||||
### Dec 2020: $9M Series A
|
||||
### Dec 2020: $9m Series A
|
||||
|
||||
We kept growing organically and took the opportunity to raise a $9M Series A, topping our funding up to [$12M](../blog/posthog-announces-9-million-dollar-series-A) led by [GV](https://www.gv.com/) (formerly Google Ventures).
|
||||
|
||||
Our focus remained firmly product, engineering and design oriented, so we increased our team in those areas.
|
||||
|
||||
We now had people in 10 countries around the world, and it still felt like day one.
|
||||
We now had employees in ten countries, and it still felt like day one.
|
||||
|
||||
Everyone takes a mandatory two weeks off over Christmas to relax.
|
||||
|
||||
### Jun 2021: $15M Series B
|
||||
### Jun 2021: $15m Series B
|
||||
|
||||
We raised a $15M Series B [a little ahead of schedule](../blog/why-we-raised-a-15m-series-b-ahead-of-schedule), led by existing investors Y Combinator.
|
||||
We raised a $15m Series B [a little ahead of schedule](../blog/why-we-raised-a-15m-series-b-ahead-of-schedule), led by existing investor Y Combinator.
|
||||
|
||||
We're now focused on achieving strong [product-market fit](/blog/product-market-fit-game) with our target segment in 2021.
|
||||
|
||||
Our team had now grown to 25 people in 10 countries.
|
||||
Our team had grown to 25 people in 10 countries.
|
||||
|
||||
### Sep 2021: Product-market fit achieved for PostHog Scale
|
||||
|
||||
We achieved product-market fit for our open-source product and PostHog Scale.
|
||||
|
||||
Our revenue quickly rose as a result, now we needed to optimize it.
|
||||
Our revenue quickly rose as a result. Now we needed to optimize it.
|
||||
|
||||
We were 30 people in 12 countries.
|
||||
|
||||
### Jan 2022: Sales comes from our team, not our founders
|
||||
|
||||
We added two Customer Success people dealing with all inbound requests. We hired two more engineers, since most questions customers have are technical.
|
||||
We hired two Customer Success experts dealing with all inbound requests. We hired two more engineers, since most questions customers have are technical.
|
||||
|
||||
### Dec 2022: 6x revenue growth
|
||||
|
||||
We had a fantastic year. While the tech market crashed, we grew 6x and reached millions in revenue, with a sub-2 month CAC payback period. We set $10M ARR as our next goal, with a gross margin of 70% – both of which should mean we've got all the metrics needed for the next fundraise.
|
||||
We had a fantastic year. While the tech market crashed, we grew 6x and reached millions in revenue, with a sub-two-month CAC payback period. We set $10m ARR as our next goal, with a gross margin of 70% – both of which should mean we've got all the metrics needed for the next fundraise.
|
||||
|
||||
We optimized revenue growth by implementing a product-led CRM for our customer success team, adding to our marketing team size, and creating a 2-person growth engineering team. These teams all make a big difference!
|
||||
We optimized revenue growth by implementing a product-led CRM for our customer success team, adding to our marketing team size, and creating a two-person growth engineering team. These teams all make a big difference!
|
||||
|
||||
We deepened all of our product areas significantly – we frequently win deals as a standalone session recording, feature flagging or experimentation tool. Session recording usage started to match product analytics usage.
|
||||
|
||||
@@ -122,9 +122,9 @@ We're now 38 people in lots of countries. We're not adding lots of headcount ove
|
||||
|
||||
### Feb 2023: Focus on mass adoption
|
||||
|
||||
We're very doing well at monetizing high-growth startups due to our optimization work, averaging over 15% MoM for the last 6 months.
|
||||
We're doing well at monetizing high-growth startups due to our optimization work, averaging over 15% MoM for the last six months.
|
||||
|
||||
We've decided to double down on mass adoption of the platform in high potential startups instead of focusing on enterprise. Simply, this will better help us increase the number of successful products in the world. As a result, we've removed support for paid self-hosted deployment and are doubling down on our open source and cloud projects. We have released a PostHog free tier.
|
||||
We've decided to double down on mass adoption of the platform in high potential startups instead of focusing on enterprise. Simply, this will better help us increase the number of successful products in the world. As a result, we've removed support for paid self-hosted deployment and are doubling down on our open source and cloud projects. We have released a free tier of PostHog.
|
||||
|
||||
In the product, we're working on making the experience slicker, and we have plans for a standalone quality CDP in Q2.
|
||||
|
||||
@@ -134,11 +134,11 @@ For a long time, we were happy competing with lots of $1-2 billion companies, ea
|
||||
|
||||
But we kept seeing companies streaming their PostHog data to a warehouse - such as [BigQuery](https://cloud.google.com/bigquery). We even lost our then-largest customer for this reason - where their source of truth became their warehouse instead of PostHog.
|
||||
|
||||
So... we decided we would ship our own warehouse, enabling us to remain the source of truth for customer and product data. This would let us offer a better integrated offering to our customers, and meant we could work on a bigger challenge.
|
||||
So we decided we would ship our own warehouse, enabling us to remain the source of truth for customer and product data. This would let us offer a better integrated service to our customers, and meant we could work on a bigger challenge.
|
||||
|
||||
### Aug 2023: Growth continues
|
||||
|
||||
We've doubled revenue so far this year without any increase in headcount. We've hit 15.7% MoM for the last 12 months. Our CAC payback is now just 5 days. Our numbers are exceptional. We even discounted several of our products. We've added 10 extra roles and will be profitable in around a year.
|
||||
We've doubled revenue so far this year without any increase in headcount. We've hit 15.7% MoM for the last 12 months. Our CAC payback is now just five days. Our numbers are exceptional. We even discounted several of our products. We've added ten extra roles and will be profitable in around a year.
|
||||
|
||||
We have user surveys and the data warehouse in private beta.
|
||||
|
||||
|
||||
@@ -12,7 +12,7 @@ _Talent Compounds_ is one of our values. 90% of a startup's problems are solved
|
||||
|
||||
**Easy to work with.** People who are low ego, flexible, energetic, and upbeat will raise those around them. We often, but don't exclusively, hire those with more experience since it's easier for them to contribute meaningfully. Things can and do get _very_ hard here – whether it's scaling, shipping complex products, handling a stream of support requests, or trying to ship something that touches multiple teams. We need those who won't get disheartened, and will collaborate, iterate, and ship their way out of anything. We proactively reward those that do these things, not those that self-promote.
|
||||
|
||||
**Will join us on the journey.** Some people are inspirational to work with – they lift others up. We have a _huge_ opportunity at PostHog, and it often feels like we've caught lightning in a bottle. _Anyone joining the company at this stage could make this the last job we all ever need._ We want people that will push to get this done, for each other's sake. We don't hire mercenaries. We need to feel people here are producing the best work of their lives.
|
||||
**Will join us on the journey.** Some people are inspirational to work with – they lift others up. We have a _huge_ opportunity at PostHog, and it often feels like we've caught lightning in a bottle. Anyone joining the company at this stage could make this the last job we all ever need. We want people that will push to get this done, for each other's sake. We don't hire mercenaries. We need to feel people here are producing the best work of their lives.
|
||||
|
||||
**Drivers not passengers.** Proactive people that can fully own projects and get them done (or make sure they get help) are what we need. For many of our roles, while it isn't a common job title, internally we have the concept of [product engineers](/blog/what-is-a-product-engineer) – people who can take high-level requirements, decide what to build, do so with customers, and keep iterating.
|
||||
|
||||
@@ -29,16 +29,16 @@ Let's start with **why you _should_ join:**
|
||||
|
||||
* Getting a pay rise. We pay generously, but you'll need to _love_ building to be happy here. You'll need to be here a long time to get the real upside from options.
|
||||
|
||||
* Mainly wanting to lead others. Reluctant managers are often the best. We don't pay more if you manage others. We want people to lead by example – by doing an exceptional job of individual work.
|
||||
* Mainly wanting to lead others. Reluctant managers are often the best. We don't pay more if you manage others. We want people to lead by example by doing an exceptional job of individual work.
|
||||
|
||||
## A small group of stronger people and compensation
|
||||
|
||||
When we raised our Series A, one of the first things we did was to make sure we didn't lose our existing team (at least for pay reasons!) _before_ we added more people to it. Today this is still true – we proactively review everyone's pay 3-4 times a year and increase it if people have leveled up.
|
||||
When we raised our Series A, one of the first things we did was to make sure we didn't lose our existing team (at least for pay reasons!) _before_ we added more people to it. This is still true today – we proactively review everyone's pay three to four times a year and increase it if people have leveled up.
|
||||
|
||||
When it comes to churn due to pay, fairness is just as important as the absolute level. We do this in line with a transparent pay system that we even [make public](/handbook/people/compensation). We aim to pay generously and fairly between people.
|
||||
|
||||
For options, we offer [the most generous terms possible](/handbook/people/share-options) as it feels like the right thing to do. We think this makes it as likely as possible people can see huge upside if we are successful (making it easier to raise _and_ more realistic that people will actually get money from them). That motivates everybody.
|
||||
|
||||
One of the hardest parts about building a high performance team, is letting people go when they aren't performing. We are decisive and do this faster than many others would. We offer 4 months severance when we let people go for performance reasons to give people more time to move on – and so it's easier for us to make a change if we need to.
|
||||
One of the hardest parts about building a high performance team, is letting people go when they aren't performing. We are decisive and do this faster than many others would. We offer four months severance when we let people go for performance reasons to give people more time to move on – and so it's easier for us to make a change if we need to.
|
||||
|
||||
While we will give direct feedback, if we don't see this being responded to quickly ahead of letting someone go, we will part ways, so people can find a job they are better suited to, and so we can find a team member better suited to the job. The end result is that everyone on the team is contributing meaningfully.
|
||||
@@ -4,13 +4,13 @@ sidebar: Handbook
|
||||
showTitle: true
|
||||
---
|
||||
|
||||
These are principles for the behavior we care about:
|
||||
These are the principles for the behavior we care about.
|
||||
|
||||
## 1. We are open source
|
||||
|
||||
Building a huge community around a free-for-life product is key to [PostHog's strategy](/handbook/why-does-posthog-exist).
|
||||
|
||||
We default to transparency with everything we work on. That means we make public our handbook, [our roadmap](/handbook/strategy/roadmap), [how we pay](/handbook/people/compensation) (or even [let go of](/handbook/people/offboarding)) people, [what our strategy is](/handbook/why-does-posthog-exist), and [who we have raised money from](/handbook/strategy/investors). Internally, we go even further – providing financial information, live updates on fundraising, and board slide access.
|
||||
We default to transparency with everything we work on. That means we make a lot of things public: our handbook, [our roadmap](/handbook/strategy/roadmap), [how we pay](/handbook/people/compensation) (or even [let go of](/handbook/people/offboarding)) people, [what our strategy is](/handbook/why-does-posthog-exist), and [who we have raised money from](/handbook/strategy/investors). Internally, we go even further – providing financial information, live updates on fundraising, and board slide access.
|
||||
|
||||
This enables the strongest community growth possible. It causes the core team to raise the bar on their work, it provides the context needed for people to work across multiple timezones, and it enables a deep work-heavy and meeting-light culture. It creates trust.
|
||||
|
||||
@@ -22,7 +22,7 @@ We should never stop iterating. You learn faster and help PostHog perform better
|
||||
|
||||
## 3. Everyone codes
|
||||
|
||||
...although this doesn't mean everyone has to be a software developer, and not everyone needs experience in this before they join. Our platform's adoption starts with developers using our open-source project, so we use GitHub to share most of our work publicly and to build a large community of technical users.
|
||||
... although this doesn't mean everyone has to be a software developer, and not everyone needs experience in this before they join. Our platform's adoption starts with developers using our open-source project, so we use GitHub to share most of our work publicly and to build a large community of technical users.
|
||||
|
||||
No matter your role, being able to use the basics of GitHub helps you understand our audience. Beyond that, we'll encourage you to build your technical skill, rather than delegating more challenging tasks to others, so you become a more effective contributor.
|
||||
|
||||
@@ -30,21 +30,21 @@ No matter your role, being able to use the basics of GitHub helps you understand
|
||||
|
||||
There are two ways to scale – trust and feedback, or process. We choose the former because we're building a wide platform with many products, so autonomy is more important than control. We hire people that work well with high level direction and will step on toes if needed to get things done.
|
||||
|
||||
When giving / receiving feedback, we assume positive intentions and focus on giving specific examples. Many of our team's peak experiences at PostHog have been receiving direct feedback. Feedback should be acknowledged, but what you do with it is up to you - no one built anything great by committee.
|
||||
When giving or receiving feedback, we assume positive intentions and focus on giving specific examples. Many of our team's peak experiences at PostHog have been receiving direct feedback. Feedback should be acknowledged, but what you do with it is up to you - no one built anything great by committee.
|
||||
|
||||
We expect you to pick out the very most important thing you can think of, and work on that. Discard plans as you see fit.
|
||||
We expect you to pick out the very most important thing you can think of and work on that. Discard plans as you see fit.
|
||||
|
||||
We judge your performance based on the impact you deliver overall, no matter what your role.
|
||||
|
||||
## 5. Bias for impact
|
||||
|
||||
Proactive people are the most successful at PostHog. Prioritize hard and make sure you focus your energy on what's most valuable of our customers / company, then take ownership of making it happen.
|
||||
Proactive people are the most successful at PostHog. Prioritize hard and make sure you focus your energy on what's most valuable for our customers and the company, then take ownership of making it happen.
|
||||
|
||||
Today, across many product areas, we deliver the most impact when we move fast and maintain a high quality bar. It improves retention and accelerates word of mouth growth.
|
||||
Today, across many product areas, we deliver the most impact when we move fast and maintain a high bar for quality. It improves retention and accelerates word-of-mouth growth.
|
||||
|
||||
In engineering, this means that bias for impact is likely to mean putting more effort into prioritization, scoping out the problem, and designing before implementation. It doesn't mean we aim to spend weeks in slow feedback loops. Instead, we get together and focus all our energy on rapidly understanding the problem and solution upfront.
|
||||
In engineering, this means that bias for impact is likely to involve putting more effort into prioritization, scoping out the problem, and designing before implementation. It doesn't mean we aim to spend weeks in slow feedback loops. Instead, we get together and focus all our energy on rapidly understanding the problem and solution upfront.
|
||||
|
||||
Solving a small customer support issue super-quickly to delight them is also highly impactful since we know this is a strong contributor to our word of mouth growth.
|
||||
Solving a small customer support issue quickly to delight them is also highly impactful since we know this is a strong contributor to our word-of-mouth growth.
|
||||
|
||||
For other areas of PostHog, this is likely to involve prioritizing and focusing our efforts on bigger bets which we believe can have an outsized impact (e.g. increasing sign-ups, getting a new large enterprise to start paying, increasing our rank on Google, etc.)
|
||||
|
||||
@@ -54,6 +54,6 @@ Getting into PostHog is a huge challenge. Once you're here, it stays that way. W
|
||||
|
||||
In return, you get to work with others producing the best work of their careers.
|
||||
|
||||
We are a team, not a family. This means we have very ambitious goals, [compensate](https://posthog.com/handbook/people/compensation#how-it-works) generously and transparently, offer [exceptional benefits](/handbook/people/benefits), and do everything we can to provide an environment for you to do your best work.
|
||||
We are a team, not a family. This means we have very ambitious goals, [compensate](https://posthog.com/handbook/people/compensation#how-it-works) generously and transparently, offer [exceptional benefits](/handbook/people/benefits), and do everything we can to provide an environment for you to do your best work.
|
||||
|
||||
Often this means everyone, [especially managers](/handbook/company/management), getting out of your way. It's also [not ok to let your teammates fail](/handbook/company/culture/#dont-let-others-fail). We expect everyone to provide direct feedback to help everyone perform at their best. We pay [generous severance](/handbook/people/compensation#severance) if things aren't working out.
|
||||
Often this means everyone, [especially managers](/handbook/company/management), getting out of your way. It's also [not okay to let your teammates fail](/handbook/company/culture/#dont-let-others-fail). We expect everyone to provide direct feedback to help everyone perform at their best. We pay [generous severance](/handbook/people/compensation#severance) if things aren't working out.
|
||||
@@ -10,15 +10,15 @@ Shipping them in the right order is key to a fast return on investment from ever
|
||||
|
||||
Products we build into the platform should:
|
||||
|
||||
* Be recognizable/positioned as products that our ICP already uses. We don't want to ship a new product unless it already has [product-market fit](/blog/product-market-fit-game) somewhere else.
|
||||
* Be recognizable and positioned as products that our ICP already uses. We don't want to ship a new product unless it already has [product-market fit](/blog/product-market-fit-game) somewhere else.
|
||||
|
||||
* Improve our other products – for example, by using or adding to customer or product data
|
||||
* Improve our other products – for example, by using or adding to customer or product data.
|
||||
|
||||
* Be designed to enable us to get in first with that product (even if in practice we often rip and replace an existing product)
|
||||
* Be designed to enable us to get in first with that product, even if in practice we often rip and replace an existing product.
|
||||
|
||||
* Help customers build more successful products (this doesn't _just_ mean writing code, it means commercial stuff too).
|
||||
* Help customers build more successful products. This doesn't _just_ mean writing code, it means commercial stuff too.
|
||||
|
||||
* Work with our snippet, so customers can switch on new functionality immediately.
|
||||
* Work with our snippet so customers can switch on new functionality immediately.
|
||||
|
||||
[This diagram](https://miro.com/app/board/uXjVMF-MT74=/?share_link_id=847485164707) shows example products we could ship:
|
||||
|
||||
@@ -26,4 +26,4 @@ Products we build into the platform should:
|
||||
|
||||
At earlier stage companies, technical founders will do _every_ role, so tools traditionally used by those further from engineering (i.e. support) are likely to get usage if built into PostHog's platform. In later stage companies, we need - for now - to remain closer to engineering tools
|
||||
|
||||
If we decide to build a product, we should build the version that gets adopted _earliest_, to avoid having to rip and replace an existing solution. For example, we are currently working on a data warehouse. We need this to work for people that have _not_ already got a warehouse set up – it needs to be inexpensive and simple.
|
||||
If we decide to build a product, we should build the version that gets adopted _earliest_, to avoid having to rip and replace an existing solution. For example, we are currently working on a data warehouse. We need this to work for people who have _not_ already got a warehouse set up – it needs to be inexpensive and simple.
|
||||
@@ -6,20 +6,20 @@ showTitle: true
|
||||
|
||||
AKA our [ideal customer profile](/newsletter/ideal-customer-profile-framework) or ICP.
|
||||
|
||||
We build for the highest-performing **product teams** (engineers, PMs, designers) building the **most loved products** at **high-growth startups**. We focus specifically on the **product-engineers** (full-stack engineers skewed towards the frontend), but it should be usable by everyone in the product team.
|
||||
We build for the highest-performing **product teams** (engineers, PMs, designers) building the **most-loved products** at **high-growth startups**. We focus specifically on the **product engineers** (full-stack engineers skewed towards the frontend), but it should be usable by everyone on the product team.
|
||||
|
||||
> Example: PostHog anytime from their Series B to IPO
|
||||
> Example: PostHog anytime from Series B to IPO
|
||||
|
||||
Marketing and customer success should primarily focus on this ICP, but should also develop **high-*potential* customers** – customers that are likely to later become high-growth customers (e.g. James and Tim during YC). We should be in maintenance mode for **hobbyists**, such as engineers building side projects. We want to be the first tool that technical founders add to their product.
|
||||
|
||||
Why? We believe that the best tech companies are increasingly engineering-led. By building for the best product-engineers, we'll create a positive feedback loop of being the best product for them. This is clearly differentiated from others in the space which are focused on less technical PMs. As more of the leading tech companies adopt being engineering-led and having highly technical PMs, PostHog will become the clear product leader.
|
||||
Why? We believe that the best tech companies are increasingly engineering-led. By building for the best product engineers, we'll create a positive feedback loop of being the best product for them. This is clearly differentiated from others in the space who are focused on less technical PMs. As more leading tech companies become engineering-led and have highly technical PMs, PostHog will become the clear product leader.
|
||||
|
||||
## Our current ICP
|
||||
|
||||
| | High-growth startup |
|
||||
| --- | --- |
|
||||
| **Description** | Startups that have product-market fit and are quickly scaling up with new customers, hiring, and adding more revenue. |
|
||||
| **Criteria** | - 15-500 employees<br />- $100k+/month in revenue OR very large number of consumer users<br />- Raised from leading investors<br />- Not yet IPO’ed |
|
||||
| **Criteria** | - 15-500 employees<br />- $100k+/month in revenue _or_ very large number of consumer users<br />- Raised from leading investors<br />- Not yet IPO'ed |
|
||||
| **Why they matter?** | - Able to efficiently monetize them<br />- Very quick sales cycle<br />- Act as key opinion leaders for earlier-stage startups/slower moving companies<br />- Strong opinions on what they need - helping us build a better product |
|
||||
| **Job role** | We build for the power users of the **the product team**<br /><br />**Primary focus**<br />- [Product engineers](https://posthog.com/blog/what-is-a-product-engineer)<br/>- Technical founders <br />- Highly technical product managers <br /><br />**Should be usable by**:<br />- Designers<br />- Less technical product managers<br />- Marketers<br />|
|
||||
| **Examples** | PostHog anytime from their Series B to IPO, Linear, Ramp, Vercel, Retool |
|
||||
@@ -32,7 +32,7 @@ Each team will focus more or less on different members of the product team. This
|
||||
|
||||
**Background**
|
||||
|
||||
- We have good product-market fit with engineers and ok fit with less technical product managers.
|
||||
- We have good product-market fit with engineers and an okay fit with less technical product managers.
|
||||
|
||||
- Most of the existing product analytics tools are built for product managers who are less technical, not engineers.
|
||||
|
||||
@@ -40,11 +40,11 @@ Each team will focus more or less on different members of the product team. This
|
||||
|
||||
**Principles**
|
||||
|
||||
- We should double-down on the best product engineers at the best product companies.
|
||||
- We should double down on the best product engineers at the best product companies.
|
||||
|
||||
- Going incredibly far with a more specific user type instead of placating everybody means that we'll get over the threshold for "I need to tell my engineer friends about this". We only get word-of-mouth growth by doing a remarkable job, not an average one for lots of people.
|
||||
- Going incredibly far with a specific type of user instead of placating everybody means we'll get over the threshold for "I need to tell my engineer friends about this." We only get word-of-mouth growth by doing a remarkable job for a specific kind of user, not an average one for lots of people.
|
||||
|
||||
- We develop a strong feedback loop: by building for the best product engineers we'll attract more of the best product engineers and the best companies. This improves PostHog and drives more word of mouth growth from high authority individuals/companies.
|
||||
- We develop a strong feedback loop: by building for the best product engineers we'll attract more of the best product engineers and the best companies. This improves PostHog and drives more word-of-mouth growth from high authority individuals and companies.
|
||||
|
||||
- As more of the best companies become engineering-led and grow faster as a result, PostHog gains significant market share.
|
||||
|
||||
@@ -52,7 +52,7 @@ Each team will focus more or less on different members of the product team. This
|
||||
|
||||
- We have good PMF with engineers and not yet with product people.
|
||||
|
||||
- Instead, we should make the tool much simpler and more accessible to product managers, so we can better work for them and the companies with product manager led cultures.
|
||||
- Instead, we should make the tool simpler and more accessible to product managers so we can better work for them and companies with product manager-led cultures.
|
||||
|
||||
- This could potentially help us grow faster in the short-term. However, this is less convincing for long-term growth and less clearly differentiates PostHog from existing tools.
|
||||
|
||||
@@ -60,48 +60,48 @@ Each team will focus more or less on different members of the product team. This
|
||||
|
||||
- We should focus on the [high-expectation customer](https://review.firstround.com/what-i-learned-from-developing-branding-for-airbnb-dropbox-and-thumbtack). "This isn’t an all encompassing persona, but rather the most discerning person within your target demographic. Most importantly, they will enjoy our product for its greatest benefit and help spread the word."
|
||||
|
||||
- Generally, we should build for the **best product engineers** building the **most loved products** at **high-growth startups**.
|
||||
- Generally, we should build for the **best product engineers** building the **most-loved products** at **high-growth startups**.
|
||||
|
||||
- These kinds of users are speaking to customers, looking at data, and quickly building and shipping features. They operate collaboratively within a diverse team including designers, other PMs, marketers and executives. We want to be loved by the sophisticated power users and still good to use for the others on the team.
|
||||
|
||||
- For product analytics, product managers who are technical (ex-engineer type) are the power users of analytics (further evidence in the data analysis of paying users). They have the desire and the time to go significantly deeper into the data.
|
||||
- For product analytics, product managers who are technical (ex-engineers, for example) are the power users of analytics. They have the desire and the time to go significantly deeper into the data.
|
||||
|
||||
### What is a high-_potential_ customer and why do they matter?
|
||||
|
||||
- Our product is very sticky. By being the default choice at the highest potential startups we can grow with them and learn from them. Other small stage (but less high-potential) companies index on what they use.
|
||||
- Our product is very sticky. By being the default choice at the highest potential startups we can grow with them and learn from them. Other small-stage (but less high-potential) companies index on what they use.
|
||||
|
||||
- High-potential startups haven’t cracked it (product-market fit) yet but are rapidly iterating towards it. They are founded by excellent product people that likely played key IC roles in other companies or founded a company previously. Often in top accelerators.
|
||||
- High-potential startups haven’t cracked product-market fit yet, but are rapidly iterating towards it. They are founded by excellent product people that likely played key IC roles in other companies or founded a company previously. Often in top accelerators.
|
||||
|
||||
- Compared to the individual contributor personas in high-growth startups, at high-potential startups the CTO/technical co-founder will often take more of a lead.
|
||||
|
||||
- We want to be the first tool that technical founders add to their product – e.g. James and Tim pivoting and exploring ideas before and during YC
|
||||
- We want to be the first tool that technical founders add to their product – e.g. James and Tim pivoting and exploring ideas before and during YC.
|
||||
|
||||
- Suggested criteria:
|
||||
- Small team <20 employees
|
||||
- Backed by leading accelerators or previously worked at top-tier startups/bigtech
|
||||
- 0-$100k/month in revenue
|
||||
- $0-$100k/month in revenue
|
||||
|
||||
### What is a hobbyist and why do they matter?
|
||||
|
||||
- The kind of people that build passion projects and explore new technologies drive technology decisions for their org or new startup. They are often vocal online or in their communities to promote word-of-mouth growth.
|
||||
|
||||
- Specifically: Hobbyists are engineers spending their nights and weekends building a passion project. Normally working solo or working with a friend – e.g. Ben White building Mealyo while he was a software engineering consultant
|
||||
- Specifically: Hobbyists are engineers spending their nights and weekends building passion projects. Normally working solo or working with a friend – e.g. Ben White building Mealyo while he was a software engineering consultant.
|
||||
|
||||
- Suggested criteria:
|
||||
- Side-project or very early stage commercial project
|
||||
- Normally 1 person, 3 people max
|
||||
- Normally one person, three people max
|
||||
- Very little funding
|
||||
- Significant bonus points:
|
||||
- Their day job is at an ICP
|
||||
- They have a large active social media reach
|
||||
- They are in major tech cites e.g. San Francisco, Austin, New York, London, Berlin etc.
|
||||
- They are in major tech cites e.g. San Francisco, Austin, New York, London, Berlin, etc.
|
||||
|
||||
### Why the data team?
|
||||
|
||||
- The data team is a team that we should experiment with for marketing and customer success as we have seen early signs of them being the champion within the org or the person responsible for paying.
|
||||
- The data team is a team that we should experiment with for marketing and customer success. We have seen early signs of them being the champion within the org or the person responsible for paying.
|
||||
|
||||
- Additionally, the data products are strategically advantageous to us. The product and customer data is used throughout the organization. By enabling the data team to serve other teams across the company (e.g. marketing/revenue ops) we form a strong moat and can enable the data team to be our advocates.
|
||||
- Data products are strategically advantageous to us. The product and customer data is used throughout the organization. By enabling the data team to serve other teams across the company (e.g. marketing, revenue ops) we form a strong moat and can enable the data team to be our advocates.
|
||||
|
||||
### What about marketing?
|
||||
|
||||
- The features should be usable by the marketing team, but we shouldn’t focus on building features specifically for them. Generally, they have a very different level of technical ability to our core power users.
|
||||
- The features should be usable by the marketing team, but we shouldn’t focus on building features specifically _for_ them. Generally, they have a different level of technical ability to our core power users.
|
||||
|
||||
@@ -14,16 +14,16 @@ To help engineers build better products.
|
||||
|
||||
We want engineers to engineer their products, not their data, and to not have to hire lots of product managers to pull together context from lots of tools.
|
||||
|
||||
By integrating all these tools we can make this easy – no integration needed, no extra vendors, no extra JavaScript, no sending data to extra 3rd parties, and workflows to guide engineers through feature development.
|
||||
By integrating all these tools we can make this easy – no integration needed, no extra vendors, no extra JavaScript, no sending data to extra third parties, and workflows to guide engineers through feature development.
|
||||
|
||||
### Get in first
|
||||
|
||||
We shouldn't aim to integrate with a stack of existing tools that we don't believe in.
|
||||
|
||||
Instead, we should get in first – and take people into what we consider best practices. Largely, just having everything in one place. By focusing on engineers, we can be their preferred choice and get in before any other tools are set up, not that we'll say no if someone wants to migrate to us later on.
|
||||
Instead, we should get in first – and take people into what we consider best practices. Largely, just having everything in one place. By focusing on engineers, we can be their preferred choice and get in before any other tools are set up. Though we won't say no if someone wants to migrate to us later on.
|
||||
|
||||
By already being used by our customers, we’re the default for each additional tool they add. By laddering our tools – for example, session recording is used much earlier in the lifecycle of the product than others like the CDPs – we can avoid competition.
|
||||
|
||||
### Be the source of truth for customer and product data
|
||||
|
||||
Traditionally as companies scale, their data warehouse becomes the source of truth, and non-warehouse native tools (like product analytics) become less relevant as people lose trust in the data in them. However, by providing the data and data-intense tools in one place, we can enhance the power of our products (like product analytics), provide increased trust, _and_ enable companies to build on top of the warehouse itself as they see fit, all _without_ them having to set up a complex stack.
|
||||
Traditionally, as companies scale, their data warehouse becomes the source of truth, and non-warehouse native tools (like product analytics) become less relevant as people lose trust in the data in them. By providing the data and data-intense tools in one place, we can enhance the power of our products (like product analytics), provide increased trust, _and_ enable companies to build on top of the warehouse itself as they see fit, all _without_ them having to set up a complex stack.
|
||||
@@ -12,11 +12,11 @@ This means we need to ship a _lot_ of products into one platform. We can see a n
|
||||
|
||||
After we'd started hiring, we asked ourselves a question – how could we structure the company to optimize for speed above everything else?
|
||||
|
||||
I happened to go to an excellent talk by Jeff Lawson (Twilio CEO). It made me realize I should be asking, "Who ships more per person, a startup or an enterprise?" Clearly the former. Let's structure like a series of startups then.
|
||||
I happened to go to an excellent talk by Jeff Lawson, the CEO of Twilio. It made me realize I should be asking, "Who ships more per person, a startup or an enterprise?" Clearly the former. So we structured PostHog like a series of startups.
|
||||
|
||||
## Small teams
|
||||
|
||||
We decided that we should split PostHog into a series of [small teams](/teams), each working like its own startup, fully owning (at least) one of our products.
|
||||
We decided that we should split PostHog into a series of [small teams](/teams), each working like its own startup, fully owning at least one of our products.
|
||||
|
||||
As with any startup, the principles that govern these small teams are:
|
||||
|
||||
@@ -36,23 +36,23 @@ This means that, if you need something or need to flag an issue, you are strongl
|
||||
We have a tiny exec team - this is what they are responsible for:
|
||||
- Set the overall direction and strategy for PostHog
|
||||
- Decide which products to build
|
||||
- Make key people decisions (ie. who to hire, pay, disciplinary issues)
|
||||
- Make key people decisions (e.g. who to hire, pay, disciplinary issues)
|
||||
- Ensure complicated cross-team initiatives run smoothly (e.g. pricing)
|
||||
|
||||
For _everything else_, you and/or your small team should be able to decide this or talk directly to the teams involved. This includes deciding which feature to build next within a particular product. We trust you to bring in the right people as you think is appropriate, relative to the scale of what you're doing.
|
||||
For _everything else_, you and/or your small team should be able to decide this or talk directly to the teams involved. This includes deciding which feature to build next within a particular product. We trust you to bring in the right people as you feel appropriate, relative to the scale of what you're doing.
|
||||
|
||||
PostHog is _not_ a good place for managers who (i) are territorial and (ii) prefer for all communication to go through them for 'efficiency'. Over time, doing this would undermine autonomy and cause our best people to quit!
|
||||
PostHog is _not_ a good place for managers who are territorial and prefer for all communication to go through them for 'efficiency'. Over time, doing this would undermine autonomy and cause our best people to quit!
|
||||
|
||||
## Goal setting
|
||||
|
||||
When you build a startup from scratch, you are in an existential crisis. One day you might be building a gym, the next day a software product for accountants. The problem changes. At PostHog, we give each small team a product to build. (James and Tim focus on _which_ products we should build, as they often need sequencing.)
|
||||
|
||||
Once we had [product-market fit](/blog/product-market-fit-game) (and we had reached 15 people or so), we realized we needed to set some kind of goals. We started by using OKRs as they're pretty standard.
|
||||
Once we had [product-market fit](/blog/product-market-fit-game), and we had reached 15 people or so, we realized we needed to set some kind of goals. We started by using OKRs as they're pretty standard.
|
||||
|
||||
*However*, one of our engineers one day told me "I realized I needed to change my objective. Then I started rewriting my OKRs into the handbook. I realized I was spending time stressing about the wording of it, which was going to have zero impact on what I knew I had to build." That seemed pretty silly, so instead we make a point of calling them just "goals". We intentionally don't sweat the wording.
|
||||
*However*, one of our engineers one day told me, "I realized I needed to change my objective. Then I started rewriting my OKRs into the handbook. I realized I was spending time stressing about the wording of it, which was going to have zero impact on what I knew I had to build." That seemed silly, so instead we make a point of calling them just "goals". We intentionally don't sweat the wording.
|
||||
|
||||
Another best practice we choose to ignore is "goals should be output driven". It sounds great in principle, but what is going to happen after a product team (which is nearly every team here) sets an output driven goal like "improve activation by 20%"?
|
||||
Another best practice we choose to ignore is "goals should be output driven". It sounds great in principle, but what is going to happen after a product team, which is nearly every team here, sets an output driven goal like "improve activation by 20%"?
|
||||
|
||||
Either (i) the team will decide on some things it should build or (ii) they won't manage to figure out what to build to do this. In either case, if a team knows what it should achieve, it should then figure out which things it needs to ship, and write those things down instead. It's clearer, and clearer is faster.
|
||||
Either the team will decide on some things it should build, or they won't manage to figure out what to build to do this. In either case, if a team knows what it should achieve, it should then figure out which things it needs to ship, and write those things down instead. It's clearer, and clearer is faster.
|
||||
|
||||
If that list turns out not to be helping our metrics? Switch the goal to a new thing.
|
||||
And if that list turns out not to be helping our metrics? Switch the goal to a new thing.
|
||||
@@ -4,15 +4,13 @@ sidebar: Handbook
|
||||
showTitle: true
|
||||
---
|
||||
|
||||
Ok, so we've got to be quick to build all the tools in one. We better have a world-class engineering environment, so we can build everything.
|
||||
|
||||
How do we do that?
|
||||
We know we've got to be quick to build all the tools in one. So we better have a world-class engineering environment that lets us build everything. How do we do that?
|
||||
|
||||
## No product management by default
|
||||
|
||||
Engineers decide what to build. If you need help, our product manager (we have 1 today) will give you coaching.
|
||||
Engineers decide what to build. If you need help, our product manager (we have one today) will give you coaching.
|
||||
|
||||
If an engineer at PostHog believes they should work on X, they can build X. We'd much prefer you ship 10 things quickly (and make a couple of mistakes) than plan too much. You will tend to gather more information by _doing_ rather than _planning_.
|
||||
If an engineer at PostHog believes they should work on X, they can build X. We'd prefer you ship ten things quickly (and make a couple of mistakes) than plan too much. You will tend to gather more information by _doing_ rather than _planning_.
|
||||
|
||||
There are _some_ exceptions - for example, where we need to work on architecture, but we leave it down to you to decide when you should plan more or just get started.
|
||||
|
||||
@@ -24,15 +22,15 @@ PostHog is exceptionally transparent. You're reading our public handbook after a
|
||||
|
||||
## It starts with hiring
|
||||
|
||||
And, finally, we hire people we think will flourish in an autonomous environment. We often hire people with broader rather than narrower skill sets, who are more flexible. They've often started (and often failed) their own startups. They're low ego and flexible. They're builders at heart who love innovating and working like this.
|
||||
Finally, we hire people we think will flourish in an autonomous environment. We often hire people with broader rather than narrower skill sets, who are more flexible. They've often started (and often failed) their own startups. They're low ego and flexible. They're builders at heart who love innovating and working like this.
|
||||
|
||||
One of the things we've learned is the very strongest engineers are usually those who want autonomy the most, and so freedom is a great way to attract and retain world-class talent. Now that we're lucky enough to have people like this already here, people see PostHog as a destination company, accelerating further our access to some of the best people in the world at what they do.
|
||||
|
||||
## A high percentage of the company are engineers
|
||||
## A high percentage of our employees are engineers
|
||||
|
||||
If we want to ship a lot, we need to figure out how we can have most of capital go into engineering.
|
||||
|
||||
We have zero outbound sales, and a hyperefficient go-to-market, largely driven by self serve. Since we focus on engineers, we have less customer support and set up handholding than all our competitors.
|
||||
We have zero outbound sales, and a hyperefficient go-to-market, largely driven by self-serve. Since we focus on engineers, we have less customer support and set-up handholding than all our competitors.
|
||||
|
||||
80% of the company are shipping product.
|
||||
|
||||
@@ -42,4 +40,4 @@ When you're doing engineering, you're in the business of building up large, abst
|
||||
|
||||
We therefore have meeting-free days every Tuesday and Thursday. We encourage you to call it out if things are going into your calendar on these days. Since we also are all remote, these usually give you lengths of uninterrupted time to get your work done.
|
||||
|
||||
The only exceptions to this rule are for customer success and recruitment, who may need to have external meetings with users/candidates on these days in order to do their jobs.
|
||||
The only exceptions to this rule are for customer success and recruitment, who may need to have external meetings with users or candidates on these days in order to do their jobs.
|
||||
Reference in New Issue
Block a user