+
+ )
+}
+```
+
+The rendered value is not a special data binding that causes it to listen. It is merely a reflection of a new value rendered as a result of calling the setter.
+
+Can return a cleanup function from the effect and declare when it should run
+
+```jsx
+function ApiStatus({ service }) {
+ const [isOnline, setOnline] = useState(null)
+
+ const { id } = service
+ useEffect(() => {
+ const handleStatusChange(status) => {
+ setOnline(status.isOnline)
+ }
+ SomeApi.subscribe(id, handleStatusChange)
+
+ return () => SomeApi.unsubscribe(id, handleStatusChange)
+ }, [id]) // Only run when `id` changes (sync to state)
+
+ // rendering
+}
+```
+
+### useLayoutEffect
+
+Same as `useEffect`, but runs callback synchronously during commit lifecycle phase
+
+### useMemo
+
+Recalculates value only when dependencies change
+
+### useCallback
+
+Updates callback function reference when dependencies change
+
+### useRef
+
+Mutable ref used to access returned child.
+
+- Persists between renders
+- Default: `{ current: null }`
+- Plain object; mutating does not trigger re-renders
+
+### Custom Hooks
+
+Listeners and API connections can be extracted to a custom hook and reused
+
+Examples from popular libraries:
+
+- React-Redux: `useSelector`, `useDispatch`
+- React-Router: `useHistory`, `useLocation`, `useParams`
+- `useFormState`
+
+## Useful resources
+
+- [Dan Abramov - A Complete Guide to useEffect](https://overreacted.io/a-complete-guide-to-useeffect/)
+- [Mark Erikson - A Complete Guide to React Rendering Behavior](https://blog.isquaredsoftware.com/2020/05/blogged-answers-a-mostly-complete-guide-to-react-rendering-behavior/)
+
+**[Back: Technologies to learn](../technologies-to-learn)**
+
diff --git a/SourceMaterial/engineering/beginners-guide/notes/typescript.md b/SourceMaterial/engineering/beginners-guide/notes/typescript.md
new file mode 100644
index 0000000..79c717b
--- /dev/null
+++ b/SourceMaterial/engineering/beginners-guide/notes/typescript.md
@@ -0,0 +1,23 @@
+---
+title: Our Notes On TypeScript
+sidebar: Handbook
+showTitle: true
+hideAnchor: true
+---
+
+The best way to learn TypeScript is to read introductory material then get hands on with exercises.
+
+## Exercises
+
+You can complete the exercises on the [TypeScript Playground](https://www.typescriptlang.org/play)
+
+You can use the same [exercises for Python](python) as starting place.
+
+## Great places to learn
+
+- [TypeScript via learnxinyminutes](https://learnxinyminutes.com/docs/typescript/)
+- [TypeScript in 5 minutes](https://www.typescriptlang.org/docs/handbook/typescript-in-5-minutes.html)
+- [TypeScript Handbook](https://www.typescriptlang.org/docs/handbook/intro.html)
+
+**[Back: Technologies to learn](../technologies-to-learn)**
+
diff --git a/SourceMaterial/engineering/beginners-guide/technologies-to-learn.md b/SourceMaterial/engineering/beginners-guide/technologies-to-learn.md
new file mode 100644
index 0000000..bac9f02
--- /dev/null
+++ b/SourceMaterial/engineering/beginners-guide/technologies-to-learn.md
@@ -0,0 +1,33 @@
+---
+title: 5. Technologies To Learn
+sidebar: Handbook
+showTitle: true
+hideAnchor: true
+---
+
+Each of the links below will send you to the best resources for learning I found. As I went through learning the
+various technologies, I took notes. Below you'll find all the notes that I took along with resources I felt were
+particularly useful. I'd suggest using *our notes* links as you would a cheatsheet.
+
+## Backend
+
+- [Python](https://www.python.org/) ([our notes on Python](notes/python))
+- [Django](https://www.djangoproject.com/) ([our notes on Django](notes/django))
+- [Django Testing](https://docs.djangoproject.com/en/3.1/intro/tutorial05/)
+- [Pytest](https://docs.pytest.org/en/stable/getting-started.html)
+- [Clickhouse](https://clickhouse.tech/) (enterprise database)
+- [Celery](https://docs.celeryproject.org/en/stable/) (we use Redis as Celery's message broker)
+- [Docker](https://www.docker.com/) ([our notes on Docker](notes/docker))
+
+## Frontend
+
+- [React](https://reactjs.org/docs/hello-world.html) ([our notes on React](notes/react))
+- [Redux](https://redux.js.org/introduction/core-concepts)
+- [Kea](https://kea.js.org/docs/introduction/what-is-kea) ([our notes on Kea](notes/kea))
+- [TypeScript](https://www.typescriptlang.org/) ([our notes on TypeScript](notes/typescript))
+
+## Useful tech
+
+- [Tmux](https://github.com/tmux/tmux/wiki)
+- [Fish](https://github.com/fish-shell/fish-shell)
+- [Zsh](https://github.com/ohmyzsh/ohmyzsh)
\ No newline at end of file
diff --git a/SourceMaterial/engineering/bug-prioritization.md b/SourceMaterial/engineering/bug-prioritization.md
new file mode 100644
index 0000000..7301f87
--- /dev/null
+++ b/SourceMaterial/engineering/bug-prioritization.md
@@ -0,0 +1,57 @@
+---
+title: Bug Prioritization
+sidebar: Handbook
+showTitle: true
+---
+
+## User experience degradation
+
+When bugs are reported it's critical to properly gauge the extent and impact to be able to prioritize and respond accordingly. These are the priorities we use across the entire engineering org, along with the relevant labels to quickly identify them in GitHub.
+
+> Please always remember to tag your issues with the relevant priority.
+
+
+{value}
+ +| GitHub Label | +Description | +
| P0 | +Critical, breaking issue (page crash, missing functionality) | +
| P1 | +Urgent, non-breaking (no crash but low usability) | +
| P2 | +Semi-urgent, non-breaking, affects UX but functional | +
| P3 | +Icebox, address when possible | +
+Security issue information should not be made public until a fix is live and sufficiently (ideally completely) adopted. ++ +PostHog security issues include a priority (severity) level. This level is based on our self-calculated CVSS score for each specific vulnerability. CVSS is an industry standard vulnerability metric. You can learn more about CVSS at [FIRST.org](https://www.first.org/cvss/user-guide) and calculate it using the FIRST.org [calculator](https://www.first.org/cvss/calculator/3.1). + +| GitHub Label | Priority Level | CVSS V3 Score Range | Definition | Examples | +|---|---|---|---|---| +|**security-P0**|Critical|9.0 - 10.0|Vulnerabilities that cause a privilege escalation on the platform from unprivileged to admin, allows remote code execution, financial theft, unauthorized access to/extraction of sensitive data, etc.|Vulnerabilities that result in Remote Code Execution such as Vertical Authentication bypass, SSRF, XXE, SQL Injection, User authentication bypass| +|**security-P1**|High|7.0 - 8.9|Vulnerabilities that affect the security of the platform including the processes it supports.|Lateral authentication bypass, Stored XSS, some CSRF depending on impact| +|**security-P2**|Medium|4.0 - 6.9|Vulnerabilities that affect multiple users, and require little or no user interaction to trigger.|Reflective XSS, Direct object reference, URL Redirect, some CSRF depending on impact| +|**security-P3**|Low|0.1 - 3.9|Issues that affect singular users and require interaction or significant prerequisites (MitM) to trigger.|Common flaws, Debug information, Mixed Content| + diff --git a/SourceMaterial/engineering/common-issues.md b/SourceMaterial/engineering/common-issues.md new file mode 100644 index 0000000..55eef75 --- /dev/null +++ b/SourceMaterial/engineering/common-issues.md @@ -0,0 +1,13 @@ +--- +title: Common Issues +sidebar: Handbook +showTitle: true +--- + +A page to host big issues raised by users (rather than small bugs) that we have certain answers for. + +### Shopify Event-Logging "Bug" + +Admin users who have PostHog setup for Shopify may experience their events being logged for another user. + +This is not an issue with PostHog. Rather, this is due to a feature Shopify offers where it stores all the session data and lets you browse your website as if you were your client with all their cookies and local/session storage. \ No newline at end of file diff --git a/SourceMaterial/engineering/development-process.md b/SourceMaterial/engineering/development-process.md new file mode 100644 index 0000000..9f12569 --- /dev/null +++ b/SourceMaterial/engineering/development-process.md @@ -0,0 +1,75 @@ +--- +title: Development Process +sidebar: Handbook +showTitle: true +--- + +> _**Note:** This guide is aimed at people who work for PostHog. If you want to contribute, [see our Contributing Guide](/docs/contributing)._ + +
+ +Any process is a balance between speed and control. If we have a long process that requires extensive QA and 10 approvals, we will never make mistakes because we will never release anything. + +However, if we have no checks in place, we will release quickly but everything will be broken. + + +## 1. How to Decide What to Build + +There are 3 places that work comes from. + +- Issues/bugs (raised by the community or us) +- [Roadmap](/handbook/strategy/roadmap) +- "This should be better" + + +## 2. Sizing a Task + +When picking up a task, it should be doable in a day, including code review and QA. If it's not, you need to break it down into smaller chunks until it is. Tasks of this size are easy to test, easy to deploy, less likely to cause merge conflicts, and should still deliver some kind of value. + +Even if you're contributing, this is helpful as it means you'll be able to contribute to PostHog faster. + +## 3. Writing Code + +We're big fans of Test Driven Development (TDD). We've tried to create test infrastructure that helps you rather than annoys you. If that isn't the case, please raise an issue! Keeping tests on point is a high priority to keep developer productivity high. + +Other than that, you know what to do in this section. + +## 4. Creating a PR + +To make sure our issues are linked correctly to the PRs, you can tag the issue in your commit. + +```bash +git commit -m "Closes #289 add posthog logo to website" +``` + +## 5. Code Review + +When we review a PR, we'll look at the following things: +- Does the PR actually solve the issue? +- Does the solution make sense? +- Will the code perform with millions of events/users/actions? +- Are there tests and do they test the right things? +- Are there any security flaws? + +Things we do not care about during review: +- Syntax. If we're arguing about syntax, that means we should install a code formatter + +See: [How we review](/handbook/engineering/how-we-review). + +## 7. Merging + +Merge anytime. Friday afternoon? Merge. + +Our testing, reviewing and building process should be good enough that we're comfortable merging any time. + +## How to Test + +See: [How to test](/docs/contributing#testing). + +## How we Review + +See: [How we review](/handbook/engineering/how-we-review). + +## How to release a new version + +See: [Release new version](/handbook/engineering/release-new-version). diff --git a/SourceMaterial/engineering/how-we-review.md b/SourceMaterial/engineering/how-we-review.md new file mode 100644 index 0000000..f58450a --- /dev/null +++ b/SourceMaterial/engineering/how-we-review.md @@ -0,0 +1,46 @@ +--- +title: How We Review PRs +sidebar: Handbook +showTitle: true +--- + +Almost all PRs made to PostHog repositories will need a review from another engineer. We do this because, almost every time we review a PR, we find a bug, a performance issue, unnecessary code or UX that could have been confusing. + +## How to review + +1. Have a flick through the code. + - What to look for: + - Code that does the wrong thing or will produce bugs + - Code that you think will cause performance issues + - Are there tests for all of the new functionality, and do they test the right thing? + - Any security issues or project leakage? + - Is the code properly instrumented to allow tracking of every relevant action (i.e. all the relevant frontend elements have unique and helpful `data-attr`s, and there are backend events where appropriate)? + - What _not_ to look for: + - Formatting issues (prettier should handle this, raise a PR to fix that) + - "I would have done it differently" (Unless the code is completely incomprehensible or unreadable, or will cause us massive harm long term - as long as it works, it's good enough.) + +2. Open the review app or check the branch out locally. + - What to look for: + - Bugs in the new functionality (if you're reviewing the insights page, make sure you try breakdown, cohorts, filters, different time frames etc) + - Confusing UX + - Confusing wording + - Backend tracked events not being fired properly or with an incorrect payload. + - Should the code be behind a feature flag? + - If the code is behind a feature flag, do all cases work properly? (in particular, make sure the old functionality does not break) + - Are we building the right thing? (We should be willing to throw away PRs or start over) + - Don't be shy here - try to break it! + - What not to look for: + - Issues _not_ related to this PR. Create a new issue for those. + +The emphasis should be on getting something out quickly. Endless review cycles sap energy and enthusiasm. + +## Setting up Heroku Test Environment + +1. Go to the pull request you want to QA on. +2. Go to the Heroku test environment. + Check/do the following: + 1. If the environment was already deployed, it should say "This branch was successfully deployed" + 1. If it says ‘This branch was not deployed’ go to the Heroku pipeline and click ‘Create review app’ + 1. If the PR was submitted from a fork, you'll need to test the changes locally. +3. Open the app, create a new account, and start testing! + diff --git a/SourceMaterial/engineering/onboarding-customer.md b/SourceMaterial/engineering/onboarding-customer.md new file mode 100644 index 0000000..bc3b64c --- /dev/null +++ b/SourceMaterial/engineering/onboarding-customer.md @@ -0,0 +1,54 @@ +--- +title: Onboarding Customers +sidebar: Handbook +showTitle: true +--- + +A lot of people want to set up PostHog on their own without talking to anyone, and we'll make sure that path is as optimised as possible. However, sometimes it's more efficient/better to talk to one of us over a call. + +Our user notes are not shared publicly. [Read them here](https://docs.google.com/document/d/1gJlsUDrlW7ur8zT5scqRvXZhapm_0JdvKGiw68Iyx9E/edit#heading=h.q9lg9hgl34g2). + +A standard structure you could maintain while doing that call is: + +## 1. Introductions / Find Out About Their Business + +1. Make sure you introduce yourself and check it's ok if you take notes. +1. Introduce PostHog: "We're open-source product analytics. Think Mixpanel or Amplitude, but with full control over your data and focused on engineers" +1. Ask questions about their business: + - Why did they reach out in the first place? + - What are their main goals/most important metric for this quarter/batch/year? + - Are they familiar with other product analytics tools? Are they using any right now? + - What stage is their company at - do they have users, are they about to launch, are they trying to expand? + - How does their app work? + - Where does the app live? Website, online app, mobile app, backend? + +## 2. Demo + +Share your own screen and wizz through a demo of PostHog. The following order tends to work best: + +1. Tell them the big picture of how the demo will work "I am going to show you two main things - how we collect data and what we help you do with it" +1. Go to /events, show raw events coming in and explain how we're different from Mixpanel/Amplitude as we track all clicks, which means no `posthog.track()` calls necessary +1. Go to /trends, show filtering by url, DAU, breakdown by initial domain referrer, anything else they ask for. It's a good opportunity to share some knowledge e.g. how to understand where traffic is coming from (UTM tags or referring domain) +1. Go to /funnels, explain how those work and that PostHog specifically allows you to see each user that goes through the funnel, rather than aggregates +1. Go to /people/retention and explain how the Retention table works +1. Show off the Toolbar using the "Launch Toolbar" button +1. Explain Feature Flags +1. Go to Default Dashboard +1. Optional: show paths +1. Ask if any questions + +## 3. Setup + +Flip it around and ask them to share their screen. + +0. If they haven't setup PostHog yet, walk them through and help them install the snippet on their website (and anywhere else necessary) +1. Based on the questions from Section 1, set up relevant dashboards for them. + - DAUs are already there, but they might want a /trends view split out by different pages. Have them add that to default dashboard. They may also want to see where traffic is coming from as a separate item in trends to add to the dashboard. + - Have them create an action for a click on their CTA on the home page + - Create a funnel with two steps: pageviews and the CTA action +1. (Optional) if they have an app, help them set up `identify` calls correctly +1. Ask if there any questions + +## 4. Conclusion + +1. Ask them to join our Slack group (and send an email right after!) diff --git a/SourceMaterial/engineering/release-new-version.md b/SourceMaterial/engineering/release-new-version.md new file mode 100644 index 0000000..13fed0b --- /dev/null +++ b/SourceMaterial/engineering/release-new-version.md @@ -0,0 +1,58 @@ +--- +title: Releasing a New Version +sidebar: Handbook +showTitle: true +--- + +At the moment, we release a new version every two weeks ([unless it makes sense not to!](/blog/we-ship-whenever)). This might change in the future. + +## Version Numbers + +Every week we up the 'minor' in `major.minor.patch`. At the moment, we're at version 1 for major. This will only change once we have released sufficient functionality under stage 2 of [our Roadmap](/handbook/strategy/roadmap/). + +Hopefully we will not have to do many patch versions, but if between versions we discover a breaking bug, we will. + +## Timeline + +Three days before we release, on Monday, we institute a code freeze. We branch master into release-[version] and deploy that to our production environment (app.posthog.com). Only bugfixes are allowed to be merged into this branch (and thus put on production) between Monday and the release going out. This gives us about three days to test if this release has any bugs. + +## Checklist + + Figure out what's updated in this release + - `git checkout release-[version]` + - `git log --pretty=format:%s [old-version]..head` + +
+ + Write up the PostHog Array [blog post](/handbook/growth/marketing/posthog-array) + + Copy from PostHog Array and write up the changes into `CHANGELOG.md` following the structure of the previous release + - `git add CHANGELOG.md` + - `git commit -m "Changelog version 1.7.0"` + +
+ + + Update the `VERSION` in `posthog/version.py` + - `git checkout release-[version]` + - `git add posthog/version.py` + - `git commit -m "Bump version [version]"` + +
+ + Tag the version + - `git tag -a [version] -m "Version [version]"` + - `git push origin head --tags` + + +Once a new Docker image has been built (see [Docker Hub](https://hub.docker.com), password in 1password) for the new version, open the [charts](https://github.com/PostHog/charts) repo and make the changes: + +1. Edit the **two** Chart files: [Chart.yaml](https://github.com/PostHog/charts/blob/master/charts/posthog/Chart.yaml) and [ChartV3.yaml](https://github.com/PostHog/charts/blob/master/charts/posthog/ChartV3.yaml), in both: + - Bump `appVersion` to the latest app version (same number as on the docker image). + - Bump `version` (chart version) patch number, unless making big changes to the chart itself. Lesson learned: this can only be `x.x.x`. It can't have a fourth part. +2. Change the docker tag in [values.yaml](https://github.com/PostHog/charts/blob/master/charts/posthog/values.yaml#L6) to point to [the latest tag](https://hub.docker.com/r/posthog/posthog/tags?page=1&ordering=last_updated). +3. `git commit -m 'Bump PostHog app version to 1.0.XX, release chart version 1.0.YY'` +4. `git tag -a 1.0.YY -m "Version 1.0.YY"` +5. `git push && git push origin head --tags` + +Finally to bump the `latest-release` docker image, log to [hub.docker.com](https://hub.docker.com/repository/docker/posthog/posthog/builds) and configure a new automatic build. Set the docker tag to `latest-release` and the source to the tag `1.XX.YY`. Delete any older tag with the same name if present and click "save & build" diff --git a/SourceMaterial/engineering/releasing-python.md b/SourceMaterial/engineering/releasing-python.md new file mode 100644 index 0000000..277e179 --- /dev/null +++ b/SourceMaterial/engineering/releasing-python.md @@ -0,0 +1,12 @@ +--- +title: Releasing a New Version (Python Library) +sidebar: Handbook +showTitle: true +--- + +## How to Release +1. Increase `VERSION` in `posthog/version.py` +2. Update `CHANGELOG.md` with a short summary of the changes +3. run `make release` and `make release_analytics` +4. `git commit -am "Release X.Y.Z."` (where X.Y.Z is the new version) +5. `git tag -a X.Y.Z -m "Version X.Y.Z"` (where X.Y.Z is the new version). \ No newline at end of file diff --git a/SourceMaterial/engineering/setup-ssl-locally.md b/SourceMaterial/engineering/setup-ssl-locally.md new file mode 100644 index 0000000..80d7b7f --- /dev/null +++ b/SourceMaterial/engineering/setup-ssl-locally.md @@ -0,0 +1,137 @@ +--- +title: Setup SSL locally +sidebar: Handbook +showTitle: true +--- + +Setting up HTTPS locally can be useful if you're trying to debug hard +to replicate issues (e.g cross domain cookies, etc). + +There are two ways you can get HTTPS locally: + +1. ngrok +2. NGINX and a local certificate. + +The easiest option is to use ngrok. + +## Set up SSL via ngrok + +1. Make sure you [have ngrok installed](https://ngrok.com/download). + +2. Sign up for an ngrok account (or sign in with GitHub) and run `ngrok authtoken
+ +We aim to regularly publish content in the form of videos and articles as part of providing value [to build a big community](content). + +As a result, we have formulated a loose strategy for how to approach publishing the content produced once it is ready to be exposed to the world. + +#### Suggested Workflow + +1. If the content requires a visual element, create a [design request](https://posthog.com/handbook/company/working-with-design) (more than 24 hours in advance) to have a graphic produced. For example, if the content is a YouTube video, we'll make a thumbnail image. If it's a blog post, we'll create a post image that is featured at the top of the post. +1. Make sure the content is actually live: If it is an article, ensure that the changes are reflected on the website following the merge of the pull request, which might take 10 to 30 minutes. +1. Post a link to the article/video on our `#editorial` channel in the PostHog Users Slack group. This group should always the first to hear about new content. +1. Include the article in the **body** of an email and schedule it to be sent the next day via Mailchimp to people in the 'PostHog Newsletter' audience. +1. Schedule a tweet to be posted 1-2 days later with a link to the content. +1. Consider making a post on HackerNews on the same day as the content goes live on Twitter. Not all posts should go on HN, only the ones that make sense for that specific audience. Videos generally do not do well on HackerNews, for example. +1. Evaluate if the content can also benefit from being published in other mediums, such as LinkedIn, Reddit, or Medium. If unsure, you're generally better to publish it and see what happens. +1. Create an annotation on [app.posthog.com](https://app.posthog.com) about the content release, so that we can determine if it was the cause of any changes in our metrics. \ No newline at end of file diff --git a/SourceMaterial/growth/sales/billing.md b/SourceMaterial/growth/sales/billing.md new file mode 100644 index 0000000..25bcb59 --- /dev/null +++ b/SourceMaterial/growth/sales/billing.md @@ -0,0 +1,105 @@ +--- +title: Billing +sidebar: Handbook +showTitle: true +--- + +## Managing billing + +This handbook section is sort of the operation manual for the billing engine. If you're looking for the technical details or need to troubleshoot something check out the relevant [tech docs](https://github.com/PostHog/posthog-cloud#additional-docs) + +### Self-hosted +For customers with special pricing (i.e. very large volumes or Enterprise & Supported plans), we need to manually set up the billing information on the system. This page contains instructions for setting up billing. Please note this page covers the process after an official PostHog quote has been approved by the customer. For information before this stage, please refer to the [Sales](/handbook/growth/sales/sales-operations) section of the handbook. Contrary to cloud plans, **all self-hosted _paid_ plans must be manually prepared today** (i.e. there's no self-serve option yet). To set up billing for self-hosted, please follow these instructions: + +#### Pre-setup +This process only needs to happen once. +1. Download the Postman collection from [license][license]. +1. Open the collection & set up the required environment variables (per the instructions on the repo). +1. To test that everything is working as expected go to the "List licenses" request and make sure you get a 200 status code. + +#### Setting up a subscription +1. Log in to the [Stripe dashboard](https://dashboard.stripe.com/customers) and go to customers. +1. Tap on New and fill out the form. At minimum please provide the customer's email address. However, it's recommended to add as much information as possible to make ongoing maintenance easier. It is particularly recommended to add the customer's Hubspot ID in the metadata section with a `hubspot_record` key (you need to save the customer record first). +1. Copy the customer ID from the Stripe dashboard (it starts with `cus_`). +1. Open the Postman collection and go to the "Create license [all options]" request. +1. If you don't have the price ID of the plan you can obtain it from the [products page](https://dashboard.stripe.com/products). Be sure to copy the **price ID, not the plan ID** (it should start with `price_`). +1. On the body section, adjust the appropriate parameters (for details on the parameters check out the [license][license] repo), + ```json + { + "valid_until": "2021-06-01T00:00:00.000000Z", // Timestamp (UTC) of when the license should expire (this won't affect the ongoing subscription agreement) + "plan": "enterprise", + "client_name": "Company, Inc.", + "client_contact": "John Doe", + "billing_email": "customer@example.com", + "stripe_customer_id": "cus_iwdnHIV5", + "stripe_price_id": "price_1HIbh9QhdPP", + "coupon_id": "qthElB", // Optional (ID coupon for special pricing) + "trial_end": "2021-01-22T00:00:00.000000Z" // Timestamp (UTC) of when the trial should end + } + ``` +1. After sending the request, make sure that Test Results show `(1/1)` (see below) and open the visualize tab. You should see a message like the one below with a link to set up billing. **Send that link to the customer** who can use it to enter their card details on their own. + + + +1. Finally, go to the _pretty_ tab and you will see the license key for the user. You may share that key with the customer once they have activated their subscription. After [#10](https://github.com/PostHog/license/issues/10) when the activation process happens automatically, you may share the license key with the customer immediately. + +#### Activate subscription + +As a customer, to redeem a license key: +1. Go to the license page in your PostHog instance. `
+ +##Self-serve + +We believe this approach will lead to the best product for end users, which is how we'll build the best company. + +[Adam Gross](https://twitter.com/adam_g?lang=en) has given some excellent [talks on this topic](https://www.heavybit.com/library/video/self-serve-go-to-market/), that we've borrowed from. + +#1-2-3 framework + +## Product + +This means the path to revenue starts with adoption of a Free version, then working out how to get teams (whether a small team at a big company or a 20 person startup) onto a paid version, and ultimately how to get departmental adoption at large enterprises. + + +| | 1 - Free | 2 - Team (Self Serve) | 3 - Enterprise (C-Level) | +|---|---|---|---| +|Value|Creation|Collaboration|Compliance| +|GTM|Free/Adoption|Self-serve|Enterprise| + + +### Examples of other companies following (part) of this + +#### Postman + +As an individual, it is useful for organizing your own API creation activity. + +In team mode, it is a way for multiple teams to organize distributed development effort. If you're building across multiple teams with different services, how you coordinate these teams is a big, strategic business problem. By using the same tool with modifications, you can orchestrate this. + +#### LaunchDarkly + +As an individual, you can view as a pure utility for launching feature flags. I can write myself or use this thing off the shelf to save time. Interesting but limited value proposition. + +In team mode, it becomes a way for a team to organize its business process between Product Management and Engineering. It becomes a product management process tool on rails. + +## Our structure + +As we grow, it'll get important to work out which teams in PostHog own different functions. + + +
| Function | Free | Team (Self Serve) | Enterprise (C-Level) | +
|---|---|---|---|
| Marketing | +Marketing (Developer Evangelism) | +Enterprise Product Marketing | +|
| Sales | +Developer Experience | +Customer Success | +Enterprise Sales | +
| Support | +Developer Experience | +||
| Success/Retention | +Developer Experience | +Customer Success | +Customer Solutions Architect | +
| Business Ops | +Business Ops | +||
+ (Voluntary leavers only) Schedule [Exit interview](https://forms.gle/DaNGRhmvQJcLGfpa9)
+ Arrange company property to be returned
+ (Contractor only) End their contract on Deel
+ (UK employee only) Email DRG with their last day, remaining annual leave and to remove them from the pension scheme
+ (UK employee only) Email Parallel to remove them from Bupa and Medicash
+ (UK employee only) Email team member P45 and upcoming payslips
+ (US employee only) Remove the team member from Gusto (Gusto will automatically end any benefits provided via the platform, e.g. medical insurance
+ (US employee only) Get the team member to sign their termination certificate
+ Put on an out of office (forward email if the leavers expects external communication), then deactivate the GSuite account for the team member
+ Make any outstanding notice payments (if applicable)
+ Cancel team member's company card on Brex/Revolut - _check if they have any company subscriptions first that need transferring_
+ Offboard member on CharlieHR
+ Add departure to hiring forecast on Pry
+ Remove team member from PostHog organization in GitHub
+ Remove team member from the internal company Slack
+ Remove team member from PostHog Users Slack
+ Remove team member from 1password
+ Remove team member from app.posthog.com
+ Remove team member from AWS
+ Remove team member from Workable
+ Remove team member from the [Team page](https://posthog.com/handbook/company/team)
+ Ask their manager for any other accounts they need to be removed from
diff --git a/SourceMaterial/people/onboarding.md b/SourceMaterial/people/onboarding.md new file mode 100644 index 0000000..6952371 --- /dev/null +++ b/SourceMaterial/people/onboarding.md @@ -0,0 +1,141 @@ +--- +title: Onboarding +sidebar: Handbook +showTitle: true +--- + +As a remote organisation, doing a great job of welcoming a new member of the PostHog team is really important. You may find that you need to invest extra time and effort into onboarding someone than you might at a company where everyone is physically located together. + +We have members working all around the world, so their onboarding process may look a little different depending on where they are based and what type of contract they are on. We either bring on new people as an employee or contractor (with equivalent terms and benefits as an employee) dependent on the jurisdiction. + +If you have any questions on any of this stuff, ask Charles, James or Tim. + +The best way to run through this checklist is to copy the relevant sections below into an onboarding issue on the [Ops Roadmap](https://github.com/orgs/PostHog/projects/2) in GitHub. + +## Upon Offer Acceptance + +Eltje or Charles will create the contract needed, depending on who is joining. Only James and Tim are allowed to sign on behalf of the company. + +### US Team Member Checklist + + Create a contract using the [Google Docs template](https://docs.google.com/document/d/15cdfWfGj5OWBpVST6VcMwb5TP5qLVPQd9SGWKSnB9bc/edit?usp=sharing) in the Legal Docs shared drive
+ If we are employing someone in a new state for the first time, check the tax filing requirements on Gusto as soon as possible, as there can be a long lead time
+ +### UK Team Member Checklist + + Create a contract using the Google Docs templates for [CIIA](https://docs.google.com/document/d/1r7Xc1ALf-JKUrL3g_oyzaQ8H3SOuVchBpJrGp7TINdc/edit?usp=sharing) and [Offer Letter](https://docs.google.com/document/d/1ZzF5hbVmTmKIYKxW7JkXzrBFFNrztkcNvcdO643r6sY/edit?usp=sharing) in the Legal Docs shared drive
+ Email Parallel to add them to our pension scheme
+ +### Non-US nor UK Team Member Checklist + + Use [Deel](https://letsdeel.com) to set up as a contractor. Choose 'Create a contract' and select fixed. Follow the instructions. This contract will cover pay, notice period, confidentiality and IP assignment.
+ Choose the last day of the month to make payments for ongoing work, else choose something appropriate for a short term contract
+ Select a notice period of 30 days
+ Select for the contractor to upload necessary compliance documents
+ Select for the contractor to be potentially allocated equity in the future (if this has been agreed)
+ Under 'Other Specifics' add the following as a special clause: _Contractor agrees to comply with any rules, policies and procedures set out in the Company Handbook, a copy of which is available on the Client's website. To the extent that there is any conflict between the terms of this Agreement and the Company Handbook, the terms which are more favorable to the Contractor shall prevail._
+ +## The Week Before They Join + +Eltje and the new team member's manager will mostly do this. + + Add the team member to [CharlieHR](https://posthog.charliehr.com/) and ask them to fill in all details, upload relevant docs (e.g. passport scan). Once they are on, manually change their profile so their holiday requests are auto-approved.
+ (UK only) Send a copy of their HMRC new starter form on CharlieHR to DRG, and include their salary and if they are full or part time
+ (UK only) Ask if they want to be part of our [private healthcare](/handbook/people/benefits#private-health-insurance) and if they want to contribute our [pensions](/handbook/people/benefits#pension-and-401k-contributions)
+ Send team member a copy of this page so they can check everything has been done
+ (US only) Add the team member to [Gusto](https://app.gusto.com)
+ (UK only) Send the team member the HMRC new starter form, pass it on to DRG once signed for payroll
+ Create GSuite account for the team member
+ Add team member to 1password
+ Check that the team member is invited to the daily standups and any other regular meetings (e.g. retros, life stories)
+ Send team member a link to the [Handbook](/handbook)
+ Send team member a digital company card
+ Team member to purchase any necessary equipment as per the [spending money](/handbook/people/spending-money) guidelines
+ Ask Charles to give them $100 credit to spend on Shopify
+ Share the [Important Company Details](https://docs.google.com/spreadsheets/d/1k4o4VN5VSsgFZpVYrN28Ib0z_pCJFTJyQdfkZEHhOV0/edit?usp=sharing) sheet with them
+ Add team member to the PostHog app
+ Send them an invite to [Drata](https://app.drata.com) to do security onboarding and their background check
+ Add the team member's details to our hiring plan in Pry
+ Add the team member's share options to Captable.io (if relevant)
+ +## On Their First Day + + Manager to book a weekly 1:1 with the team member
+ (UK only) Schedule a [right to work](https://www.gov.uk/guidance/coronavirus-covid-19-right-to-work-checks) check with Eltje + Send them these instructions on adding the [team time off cal](https://intercom.help/charliehr/en/articles/839648-importing-your-time-off-calendar-to-google-calendar) to their Gcal
+ For the first week or so, book extra sessions as appropriate to provide extra help
+ Add team member to any relevant Google Groups
+ Add team member to the internal company Slack (and give them a warm welcome!)
+ Also add them to the virtual-coffee and standup channels on Slack
+ Add team member to PostHog Users Slack
+ Add team member to PostHog organization in GitHub
+ Share user interview notes with them, found in [this doc](https://docs.google.com/document/d/1762fbEbFOVZUr24jQ3pFFj91ViY72TWrTgD-JxRJ5Tc/edit). If the person is particularly interested in more historical context, here are the notes from [Q4-2020](https://docs.google.com/document/d/1gJlsUDrlW7ur8zT5scqRvXZhapm_0JdvKGiw68Iyx9E/edit), and [Q3-2020](https://docs.google.com/document/d/1vrwn-owF320otkm3oODCFjvqj7gptF6QaFFO6v-_RhY/edit).
+ Team member should add themselves to the [customer interviews calendar](https://calendar.google.com/calendar/?cid=Y19tczllaWN1Ym92ZGgxYWhzNmtoY2xpNTQ3b0Bncm91cC5jYWxlbmRhci5nb29nbGUuY29t). + +> Not a hard requirement by any means, but we highly recommended that you join a feedback call and/or product demo in your first weeks. It provides great context on our users. + +### Additional Access + +Add these if appropriate for the role: + +#### Engineering + + 'Team' group in AWS
+ PagerDuty and into on-call rotation - make sure the alerts work
+ Papercups for customer support
+ Heroku
+ Add team member to Grafana, Sentry, and ask yourself if there are any other dev tools in use that the team member needs access to (then update this list)
+ +#### Ops + + Workable if they are involved in recruitment
+ Google Voice - an admin will need to issue them a licence, add the company address and assign them a number, then invite
+ Any relevant job boards we advertise on
+ Gusto, Deel and/or CharlieHR admin access if they are involved in people ops
+ Hubspot if they are involved in customer-facing roles (e.g. sales, user interviews)
+ Any relevant banking or accounting software (very unlikely)
+ +## PostHog buddy + +Starting a new job is really exciting, but it can also be a little bit overwhelming. To make your first few weeks a bit easier, we started a buddy system. +The buddy can help with any questions that pop up and with socializing during the first couple of weeks at PostHog. Of course, everyone is available to help, but it’s nice to have a dedicated person to help. + +We will pair people in similar time zones to make sure you get the most out of each other. The goal is to have a catch up at least once a week during the first few weeks, including time to chat about non-work topics. + +## Tools we use + +We use a number of different tools to organise our work and communicate at PostHog. Below is a summary list of the most important ones - this list is not intended to be exhaustive + +### Everyone +- Google Suite - Gmail, Google Apps such as Docs, Sheets, Slides +- GitHub - most comms and product work +- Slack - we have an internal workspace and a users Slack as well +- Brex (US) or Revolut (UK) - company cards and expenses tracking +- Shopify - powers our merch store +- CharlieHR - holiday tracking, personal details + +### Engineering +- AWS +- Pagerduty +- Heroku +- Grafana +- Sentry + +### Design +- Figma - our main design tool + +### Ops +- HubSpot - for managing all sales +- Papercups - our support platform +- Pry - financial modelling +- Captable.io - cap table management +- Fondo - US accounting +- Xero - UK accounting +- Calendly - external meeting scheduling (e.g. demos, sales) +- Gusto - US payroll +- Deel - international payroll and contracts +- Workable - recruitment tool + +## Signatories + +James and Tim at this time are the only people able to sign legal paperwork on behalf of the company. diff --git a/SourceMaterial/people/side-gigs.md b/SourceMaterial/people/side-gigs.md new file mode 100644 index 0000000..a9ecc7b --- /dev/null +++ b/SourceMaterial/people/side-gigs.md @@ -0,0 +1,23 @@ +--- +title: Side gigs +sidebar: Handbook +showTitle: true +--- + +PostHog looks for passion in the people it hires. This often correlates with people who do things like public speaking or have side projects as a hobby. For example, we view pre-existing open source work as a strong qualifier that you're good enough at programming that it's fun to do rather than frustrating and hard! + +These side gigs may sometimes earn you money. Sometimes, you may one day want your side gig to become your main gig. + +We have deliberately called them "side gigs", as we are ok with you earning money on the side. We are not ok with this being your main focus and PostHog being just a paycheck. Quite simply, we are too small for PostHog not to be your main motivation. + +## Managing Time + +The key distinction to something being a side gig, and thus it being appropriate, is its impact on your work and the amount of time involved. + +A few hours a month on a paid side gig is acceptable. Over 10 hours a week on a paid or open source side gig is a significant amount of extra work which we would expect to start impacting your performance. + +If you are doing paid speaking, make it clear that you work for us, and the exception based on time does not apply - we view this as a great way to get PostHog's name out there. + +In a few cases, you may want your side gig to become your full time work one day. That is ok - please just let us know, so we can create a plan. We will try to match you with tasks at PostHog that will help your long term goals, while not impacting your work performance, and will create a timeframe for you that works. We know the key to motivated people is to help you achieve your long term goals, and to align this with what PostHog needs, whether or not you eventually achieve them with us. + +Above everything else, if you are going above and beyond for PostHog and you're still able to look after yourself properly, side gigs (whether paid or unpaid) are totally fine. We don't think that's possible beyond a certain level of time/energy commitment to them, but we are very happy for you to spend a little time on them each week. diff --git a/SourceMaterial/people/spending-money.md b/SourceMaterial/people/spending-money.md new file mode 100644 index 0000000..e335c7e --- /dev/null +++ b/SourceMaterial/people/spending-money.md @@ -0,0 +1,167 @@ +--- +title: Spending money +sidebar: Handbook +showTitle: true +--- + +There are many occasions when you will need to spend company money. + +PostHog is a lean organization - the less we spend, the more time we have to make sure the company takes off. However, it is more important you are productive, healthy, and happy. + +Please just spend company money like it's your own. + +If it's a trivial expense, just buy it. We provide you with a company card with a \$1,000/month spending limit for this reason. We use Brex for everyone, and also provide UK team members with a Revolut card. + +If you live in the UK, you should use your Revolut card for UK-specific spending (i.e. ordering from UK sites), and Brex for everything else. This is for UK accounts-reporting reasons, as we have a UK subsidiary. + +For larger expenses which don't fit into the items here, please **raise a policy suggestion for it as a pull request** in this doc, so we can document our decision making into our policy rather than making everything case by case. + +## Trivial Expenses + +Just do it. + +This means expenses that are under \$75 one off or under \$20/month recurring that we can cancel easily. + +## Saving Receipts + +Make sure you *keep copies for all receipts*. If you expense something on a company card and cannot provide a receipt, this may be deducted from your pay. + +You should default to using your company card in all cases - it has no transaction fees. If you need to use your personal card in an emergency, please just let Charles know afterwards to get reimbursed manually. + +PostHog uses Brex and Revolut's built-in expenses tracking feature. You'll find using their apps the easiest way to submit receipts. + +### Brex + +- Buy something on your Brex card. +- If it's a digital invoice, just forward it to receipts@brex.com. If it's a physical receipt, respond to the Brex or SMS notification with a picture of your receipt. +- You _only_ need to submit receipts for purchases of \$75 or more. +- That's it! + +Make sure you forward digital invoices to Brex from your PostHog email address - it won't work if you send from another email address. + +### Revolut + +- Buy something on your Revolut card. +- If it's a digital invoice, just forward it to ukinvoices@posthog.com. If it's a physical receipt, take a picture and forward it to the same place. +- You need to submit receipts for _all_ purchases. + +Accidentally bought something on the company card when it was a personal expense? Don't worry! Again, just let Charles know _as soon as you become aware_ and he will provide you with the relevant bank details for you to repay the company. + +## Making Larger Purchases + +If your purchase fits within the policy below, there is no need to ask. We **cannot** pay you back for anything without a receipt if you use your personal card. + +You may not have enough space on your company card if you're a new starter, just ask Charles (and if he's unavailable, James H or Tim) to increase your limit. + +## Equipment + +PostHog is an all-remote company. This means it's important you have an ergonomic setup at home to be as productive as possible. + +PostHog will provide you with office equipment. Please note that it remains PostHog's property. + +### Laptop + +We'd prefer you to use a laptop. This is so when we host meetups in real life, you can easily bring your work with you. We'd prefer everyone uses Apple laptops, just to keep life simpler - for example, that means everyone can use the same software, and as we get bigger, it'll mean we're dealing with one supplier, not many. + +* If you are in an engineering role, we recommend a Macbook Pro with an Intel processor with 32GB of RAM. The processor selection here is important as we want to ensure that you're able to run all the technologies in our stack and several of them have yet to be adapted on the new Apple architecture. Base processor and storage. +* If you are in a design role, we recommend a Macbook Pro with an Apple Silicon processor and 16GB of RAM. Base processor and storage. +* If you are in a non-technical role, we recommend a Macbook Air with an Apple Silicon processor and 8GB of RAM. Base processor and storage. + +These are just general guidelines - the most important thing is that you select the model that is appropriate for _your_ needs. If your requirements are different to the guidelines above please just ask. + +Apple offer multiple screen sizes. The larger screen sizes (15 inches +), are disproportionately more expensive. These make sense if you do a ton of work in coworking spaces or cafés where you do not have a second screen. If you are realistically going to do most of your work at home, it is more rational to pick a smaller laptop size, and to get a large (27 inch) monitor. + +When buying something at Apple we can get 3% cashback on purchases through Brex. You should be able to find that in the 'Rewards' tab on brex or ask Tim or Charles. + +You may be asked if you wanted to purchase Apple Care - please don't buy this as it's not great value for money. + +We would expect to spend \$1200 to \$2000 on a laptop, depending on what you need to run. We find the easiest solution is to just purchase directly from Apple's website in your territory. + +### Monitor + +For monitors, we suggest you pick one that supports 4K. This means you'll get a higher resolution than a standard HD monitor, and thus can fit more content onto the screen. + +We would expect to spend \$250 to \$350 on a monitor. Philips have a [great value model](https://www.amazon.com/Philips-276E8VJSB-3840x2160-UltraNarrow-DispalyPort/dp/B07JXCR263). It comes with an HDMI cable, but you'll need an adaptor to USB-C with most Apple laptops. + +### Keyboard, Mouse, and Laptop Stand + +We'd encourage you to buy a keyboard, mouse and laptop stand. + +Again, Apple items for keyboards and mice should be what you default to - refurbished is usually fine. + +[Nextstand](https://www.amazon.co.uk/NEXSTAND-K2-Adjustable-Foldable-Portable/dp/B01HHYQBB8) make great value laptop stands that are portable. + +### Chairs and Desks + +We find that most people already have a desk and chair that are comfortable. + +If you do not, please suggest something to us. We aren't yet at the stage where we can afford the latest and greatest here, but we will aim to be reasonable. + +For example, if you would like a standing desk, buy one you consider to be good value. + +We would expect to spend \$250 on a desk, and around the same for a chair. + +### Headphones + +If you need to work in a noisy environment and don't already have noise cancelling headphones with a microphone, feel free to buy a pair. + +We would expect to spend \$250 on noise cancelling headphones. + +## Software + +Software expenses are treated as above and will generally fall into trivial. + +We are *strongly opposed* to introducing new software that is designed for collaboration by default. There needs to be a very significant upside to introducing a new piece of software to outweigh its cost. + +The cost of introducing new collaborative software is that it creates another place where todo items / comments / communication can exist. This creates a disproportionate amount of complexity. + +Our entire stack for collaborative software is pleasingly simple. All we use is: + +* Google Sheets - spreadsheets +* GitHub - documents, code, discussion +* Slack (premium) - chat (although we encourage you to default into discussion of features/strategy etc into GitHub) +* PostHog - product analytics +* Figma - graphic design + +Individual software is down to your personal preference, and we encourage you to share cool software. + +### IDEs + +* IDEs range widely in cost. Best in class IDE suites can cost up to \$700, which is a bad value proposition for most engineers. However, we are happy to revisit this policy if you have very specific needs. +* Before then, if you wish to spend up to \$200 on an IDE, that is fine. Visual Studio, VIM and PyCharm are the most popular within our team. + +## Work Space + +We care about you being healthy, happy and productive. + +While PostHog will use the money saved from not having office space for real life meetups, we are happy to cover some expenses related to where you work. Most people do most of their work from home, but we understand that getting out of the house from time to time can help you escape cabin fever! + +You can spend up to \$200/month to work in cafés or coworking spaces if working from home is impractical. As always, you must provide receipts for all costs, and in this case, they must only be for yourself. + +If you live in the US, a particularly good way to use this budget is to cover the cost of Amex Platinum which provides WeWork access. Outside of the US, you may sign your own agreement or buy day vouchers as needed. We will not cover costs beyond this amount of money. + +## Celebrations and life events + +It's important to us at PostHog to celebrate team member milestones and achievements. + +**Birthdays** + +We have a budget of $50 for a personalised birthday gift. Eltje will reach out to the team a week before the birthday to start a virtual birthday card and ask for gift ideas. + +**PostHog anniversaries** + +For every PostHog anniversary, we will donate $50 to a charity of your choice. And just like for birthdays, we will also send a virtual card. + +**Significant life events** + +For events like childbirth, weddings, return to work after extended sick leave or the loss of a loved one, Eltje will send flowers and a gift, the budget is $100. We will also send a virtual card. + +## Client Meetings + +If you are meeting a user for an interview or a potential customer, we would encourage you to pick up the bill. + +At PostHog's current stage, a fancy coffee shop is encouraged. A fancy lunch or dinner is not. + +## Training + +We have a separate section on spending money on [training](/handbook/people/training) (which covers things like books and conferences). diff --git a/SourceMaterial/people/team-structure/_team_template.md b/SourceMaterial/people/team-structure/_team_template.md new file mode 100644 index 0000000..dd4011b --- /dev/null +++ b/SourceMaterial/people/team-structure/_team_template.md @@ -0,0 +1,23 @@ +--- +title: Team Example +sidebar: Handbook +showTitle: true +hideAnchor: true +--- + +## People + +- [Jane Doe (Team Lead, Full Stack Engineer)](/handbook/company/team/#jane-doe-software-engineer) +- [Max Mustermann (Full Stack Engineer)](/handbook/company/team/#max-mustermann-software-engineer) + +## Mission + +## Responsibilities + +## Customer + +## Output metrics + +## Slack channel + +[#team-example](https://posthog.slack.com/messages/team-example) diff --git a/SourceMaterial/people/team-structure/core-experience.md b/SourceMaterial/people/team-structure/core-experience.md new file mode 100644 index 0000000..fb869d1 --- /dev/null +++ b/SourceMaterial/people/team-structure/core-experience.md @@ -0,0 +1,39 @@ +--- +title: Team Core Experience +sidebar: Handbook +showTitle: true +hideAnchor: true +--- + +## People + +- [Eric Duong (Team Lead, Full Stack Engineer)](/handbook/people/team/#eric-duong-software-engineer) +- [Paolo D'Amico (Product Manager)](/handbook/people/team#paolo-damico-product-team) +- [Buddy Williams, Full Stack Engineer](/handbook/people/team/#buddy-williams-software-engineer) +- Sam Winslow, Full Stack Engineer +- [Li Yi Yu, Full Stack Engineer]((/handbook/people/team/#li-yi-yu-software-engineer)) + +## Mission + +To create the easiest way to discover insights about products and its users + +## Responsibilities + +- Extending feature set as suggested by requests, by our own ideas, and by need for parity with other platforms +- Maintaining data quality and clarity +- Ensuring performant and clear user experience across all analytics functionality + + +## Customer + +- Any PostHog user, whether they're an engineer or a product manager, should be able to effectively analyze their product. + +## Output metrics + +- Retention per feature + +[Dashboard](https://app.posthog.com/dashboard/1124) + +## Slack channel + +[#team-core-experience](https://posthog.slack.com/messages/team-core-experience) diff --git a/SourceMaterial/people/team-structure/design.md b/SourceMaterial/people/team-structure/design.md new file mode 100644 index 0000000..a2ed294 --- /dev/null +++ b/SourceMaterial/people/team-structure/design.md @@ -0,0 +1,41 @@ +--- +title: Team Design +sidebar: Handbook +showTitle: true +hideAnchor: true +--- + +## People + +- [Cory Watilo (Team lead, Lead Designer)](/handbook/company/team/#cory-watilo-lead-designer) +- [Lottie Coxon, Graphic Design)](/handbook/company/team#lottie-coxon-graphic-designer) +- Mike Nicklas, Front End Engineer + +## Mission + + + +## Responsibilities + +- Support Small Teams (and contributors) in building better versions of PostHog +- Enable customers to build better products (using PostHog) +- Communicate to prospective customers the value we provide + +Tangibly, we: + +- Initiate new projects to support the responsibilities above +- Support Small Teams in completing their sprint tasks +- Iterate based on feedback from customers + +## Customer + +- The other small teams - [here is a guide](handbook/company/working-with-design) on how to best work with the Design team. + +## Output metrics + +- Acquisition +- Retention + +## Slack channel + +[#team-design](https://posthog.slack.com/messages/team-design) diff --git a/SourceMaterial/people/team-structure/extensibility.md b/SourceMaterial/people/team-structure/extensibility.md new file mode 100644 index 0000000..d7cf268 --- /dev/null +++ b/SourceMaterial/people/team-structure/extensibility.md @@ -0,0 +1,59 @@ +--- +title: Team Extensibility +sidebar: Handbook +showTitle: true +hideAnchor: true +--- + +## People + +- [Marius Andra (Team lead, Full Stack Engineer)](/handbook/company/team/#marius-andra-software-engineer) +- [Michael Matloka (Full Stack Engineer)](/handbook/company/team/#michael-matloka-software-engineer) +- [Yakko Majuri (DevRel + Full Stack Engineer)](/handbook/company/team/#yakko-majuri-technical-writer-and-developer) + +## Mission + +Team Extensibility's job is to turn PostHog into a platform that everyone can integrate with. +In essence, we enable users to: +- get data _into_ PostHog +- get data _out of_ PostHog +- extend PostHog itself according to their needs + +## Responsibilities + +Team Extensibility is particularly responsible for: +- the plugin server +- the data ingestion pipeline +- PostHog integrations with all sorts of platforms (JS, Go, iOS, Zapier, Segment, etc.) +- the user experience of extensibility features in PostHog (e.g. plugins, webhooks) + +## Priorities + +1. Making sure there are no cracks in the walls and that we always keep in mind safety, security, and data + integrity of our systems. We code defensively, prefer allowlists to denylists, and so on. +2. A fabulous user experience. Connecting things to PostHog either via plugins or integrations + should spark joy. + +## Customer + +- Plugin developers, contributors to extensibility +- Plugin users (and in extension, all PostHog app users – who we'd love to make use of plugins) +- Integration users + +## Output metric + +- Number of plugins installed and/or in active use +- Used plugin-seconds on cloud, breakdown by team (for billing) +- Number of integrations and their usage + +[Dashboard](https://app.posthog.com/dashboard/1865) + +## Meetings + +- Sync: Monday, 9:00 UTC +- Sync: Wednesday, 15:00 UTC +- Internal release planning: Friday every other week + +## Slack channel + +[#team-extensibility](https://posthog.slack.com/messages/team-extensibility) diff --git a/SourceMaterial/people/team-structure/growth-engineering.md b/SourceMaterial/people/team-structure/growth-engineering.md new file mode 100644 index 0000000..825fbd8 --- /dev/null +++ b/SourceMaterial/people/team-structure/growth-engineering.md @@ -0,0 +1,62 @@ +--- +title: Team Growth Engineering +sidebar: Handbook +showTitle: true +hideAnchor: true +--- + +## People + +- [Kunal Pathak (Team lead, Growth Engineer)](/handbook/company/team#kunal-pathak-growth-engineer) + +## Mission + +Generate scalable growth by applying focused efforts of product, data, and engineering to specific areas of our business. + +## Responsibilities + +* Own activation flow +* Own revenue flow +* Proactively search for (and execute) opportunities to run experiments to improve output metrics anywhere in the business + +## Customer + +Growth engineering works + +## Output metrics + +* Acquisition +* Activation +* Revenue + +## Principles + +### Solve Problems, not Metrics + +We do not focus on moving a number– we are focused on solving real problems and solving real pain to drive growth. Metrics are used to help inform the work we do, check our assumptions, and measure our progress. However, we believe metric growth is a side effect of great experiences and solving real pain. + +### Find the 80-20 + +It is important that we approach problems with pragmatic solutions – focus on finding the 20% that will solve 80% of the pain. + +As a team with a narrow and dynamic focus, it is critical for us to boil down problems to their core and to effect change on those. Future work or progress should be summarized and shared as learnings with the broader team so we can reprioritize when appropriate. + +We are a dynamic team that jumps across many different areas. We believe that it is better to be growing and getting better day by day for the next year than to be stagnant everyday but great in a year. + +### Any Jank is Jank + +We believe in product-led growth. This means that the product experience is always the most important thing to maintain. + +Pragmatism, dynamic ownership, and the 80-20 rule are not reasons to ship poor or broken product experiences. + +Nothing hurts growth more than a bad product. + +### Control the Inputs, Trust the Process + +Great execution beats everything. + +We believe that rapid iteration, compounding our learnings, and following our experiment process will eventually lead to success. We trust that as long as we are making sound decisions and running great analyses, the right things will happen. + +## Slack channel + +[#team-growth-engineering](https://posthog.slack.com/messages/team-growth-engineering) \ No newline at end of file diff --git a/SourceMaterial/people/team-structure/infrastructure.md b/SourceMaterial/people/team-structure/infrastructure.md new file mode 100644 index 0000000..56699a1 --- /dev/null +++ b/SourceMaterial/people/team-structure/infrastructure.md @@ -0,0 +1,73 @@ +--- +title: Team Infrastructure & Deployments +sidebar: Handbook +showTitle: true +hideAnchor: true +--- + + + +## People + +- [James Greenhill](/handbook/company/team/#james-greenhill-software-engineer) (Team lead, Data/Infra Engineer) +- [Karl-Aksel Puulmann](/handbook/company/team/#karl-aksel-puulmann-software-engineer) (Full Stack Engineer) + +## Mission + +Make using and developing for PostHog as reliable as running water. Wherever you want it. + +## Goals + +- We don't lose events +- Data is as up to date as possible +- Engineers always be able to ship and build +- Fail fast. Fix faster. +- Ship anywhere +- Stack scales with demand +- Support Small Teams (and contributors) in building and debugging Posthog +- Be frugal. + +## Responsibilities +Concrete things we take responsibility over: + +- [app.posthog.com](app.posthog.com) and its infrastructure +- On Prem & Single Tenant deployments +- CI/CD - How we deploy +- Data infrastructure (Clickhouse, Kafka) +- Monitoring and Alerting stack + +## Customer + +- Other Small Teams in making sure they have the tools (databases, queues, etc) and the ability to deploy effortlessly that they need to build +- End users (Both cloud and on-prem teams) + +## Output metrics + +### VPC +###### Retention +- Metric: Retention +- Objective: Better than cloud +### Cloud +###### Data Loss +- Metric: Data loss % +- Objective: < 0.1% +###### Uptime +- Metric: Uptime +- Objective: > 99.99% +###### Speed +- Metric: Speed +- Objectives + - Event ingestion: TBD + - Query response: TBD +- Overall: We should anticipate increasing demand (either manually or automatically) +##### Cost +- Metric: Infra Costs +- Objective: Our costs should grow at a rate that is sublinear relative to scale +### Dev Experience +##### Dev Experience NPS (Infra) +- Metric: Developer experience (relating to infra) (maybe NPS?) +- Objective: TBD (maybe NPS?) + +## Slack channel + +[#team-deployments-and-infrastructure](https://posthog.slack.com/messages/team-deployments-and-infrastructure) diff --git a/SourceMaterial/people/team-structure/marketing.md b/SourceMaterial/people/team-structure/marketing.md new file mode 100644 index 0000000..f8138cb --- /dev/null +++ b/SourceMaterial/people/team-structure/marketing.md @@ -0,0 +1,36 @@ +--- +title: Team Marketing +sidebar: Handbook +showTitle: true +hideAnchor: true +--- + +## People + +- Mo Shehu, Content Marketer + +## Mission + +Make PostHog a ubiquitous developer tool. + +## Customer + +Innovative technical teams, who care about: + +* a unified product analytics platform +* open source +* control: hosting, pricing, source, data, privacy and security + +We will expand to non-technical teams when we have achieved technical awareness saturation. + +## Output metrics + +* Acquisition + +## Philosophy + +Be kind, concise and direct. + +## Slack channel + +[#team-marketing](https://posthog.slack.com/messages/team-marketing) diff --git a/SourceMaterial/people/team-structure/people.md b/SourceMaterial/people/team-structure/people.md new file mode 100644 index 0000000..59ddf9e --- /dev/null +++ b/SourceMaterial/people/team-structure/people.md @@ -0,0 +1,45 @@ +--- +title: Team People +sidebar: Handbook +showTitle: true +hideAnchor: true +--- + +## People & Culture + +- [Eltje Lange](/handbook/company/team#eltje-lange-people-and-talent) +- [Recruitment and Operations Coordinator](https://apply.workable.com/posthog/j/554EC800BE/) (currently hiring!) + +## Mission + +Make PostHog the best place everyone here has ever worked. Our goal is to create a world-class (remote) culture, prioritising impact, autonomy and personal development. + +## Responsibilities + +Our people team works across talent, people operations and culture: + +- We attract, engage and hire top talent from around the world, while ensuring an outstanding candidate and hiring manager experience. +- Building a [diverse and inclusive culture](/handbook/company/diversity) is at the heart of everything we do. +- We support our team throughout the entire employee lifecycle - from making an offer, to onboarding and career development, to parental leave and eventually parting ways. +- We create light-touch initiatives and processes that allow PostHog to act fast (while complying with local legislation) and [iterate](/handbook/company/culture#iteration) continuously. +- In the people team, we live and breathe our [culture](/handbook/company/culture) and [values](/handbook/company/values), and constantly work to make PostHog an even better place to work. + +## Customer + +All small teams as well as current, future and past candidates. + +## Output metrics + +Talent: +- Hiring progress vs. plan +- Time to hire +- Percentage of hires from [under-represented groups](/handbook/company/diversity#how-diversity-helps-us) + +People and culture: +- Quarterly Team engagement survey +- Turnover rate (voluntary and involuntary) + +## Slack channel + +[#people](https://posthog.slack.com/messages/people) - internally public, default for most people discussions +[#people_ops](https://posthog.slack.com/messages/people_ops) - internally confidential, for minority of issues, e.g. salaries, candidate offers \ No newline at end of file diff --git a/SourceMaterial/people/team-structure/team-structure.md b/SourceMaterial/people/team-structure/team-structure.md new file mode 100644 index 0000000..99e6c12 --- /dev/null +++ b/SourceMaterial/people/team-structure/team-structure.md @@ -0,0 +1,48 @@ +--- +title: Team structure +sidebar: Handbook +showTitle: true +hideAnchor: true +--- + +We've organised the team into small teams that are multi-disciplinary. [You can read about why we've done it this way.](/handbook/people/team-structure/why-small-teams). + +## Engineering + +- **Core experience** + - [Eric Duong (Team Lead, Full Stack Engineer)](/handbook/people/team/#eric-duong-software-engineer) + - [Paolo D'Amico (Product Manager)](/handbook/people/team#paolo-damico-product-team) + - [Buddy Williams, Full Stack Engineer](/handbook/people/team/#buddy-williams-software-engineer) + - Sam Winslow, Full Stack Engineer + - [Li Yi Yu, Full Stack Engineer]((/handbook/people/team/#li-yi-yu-software-engineer)) + +
+ +- **[Extensibility](extensibility)** + - [Marius Andra (Team lead, Full Stack Engineer)](/handbook/company/team/#marius-andra-software-engineer) + - [Michael Matloka (Full Stack Engineer)](/handbook/company/team/#michael-matloka-software-engineer) + - [Yakko Majuri (DevRel + Full Stack Engineer)](/handbook/company/team/#yakko-majuri-technical-writer-and-developer) + +
+ +- **[Infrastructure and Deployments](infrastructure)** + - [James Greenhill](/handbook/company/team/#james-greenhill-software-engineer) (Team lead, Data/Infra Engineer) + - [Karl-Aksel Puulmann](/handbook/company/team/#karl-aksel-puulmann-software-engineer) (Full Stack Engineer) + +
+ +- **[Growth engineering](growth-engineering)** + - Kunal Pathak (Growth Engineer) + +## [Design](design) + +- Cory Watilo (Team lead, Lead Designer) +- Lottie Coxon (Graphic Designer) + +## [Marketing](marketing) + +- Mo Shehu (Content Marketer) + +## [People & Culture](people) + +- [Eltje Lange](/handbook/people/team#eltje-lange-people-and-talent) (People and Talent) diff --git a/SourceMaterial/people/team-structure/why-small-teams.md b/SourceMaterial/people/team-structure/why-small-teams.md new file mode 100644 index 0000000..932e500 --- /dev/null +++ b/SourceMaterial/people/team-structure/why-small-teams.md @@ -0,0 +1,110 @@ +--- +title: Why Small Teams +sidebar: Handbook +showTitle: true +hideAnchor: true +--- + +PostHog is structured for speed, autonomy and innovation. + +Many traditional organizations have big, separate functions. You have a product team, an engineering team, customer support, and so on. This slows things down when you scale because there are more layers of communication and complex approval chains. This stifles innovation - you have to get your boss to talk to someone else's boss to get work done. It also means that people can't really see the impact of their work. + +PostHog started off as a completely flat company with one big goal: to increase the number of successful products in the world. + +As we are getting bigger, we anticipate that it will get harder for people to see the direct impact of their work, which reduces the sense of ownership. + +We have therefore introduced Small Teams. These are designed to each operate like a startup. + +# How it works + +* The overall goal is for a Small Team to be as close to its own startup as possible, with only a handful of centralized processes +* A Small Team should never be more than six people +* A Small Team has an Accountable Person responsible for its performance - whoever is most appropriate depending on what the team is working on. This does _not_ mean the most senior person on the team. +* A Small Team must have (1) a customer (internal or external), (2) a mission and (3) metrics +* There may be certain functions where at our current stage we don't need a Small Team yet. +* Each Small Team runs its own retrospective + sprint every week. This must be done transparently. +* A Small Team has the final call in which of its features get into production, with no need for external QA/control - within our existing release schedule. +* A Small Team will, at some stage, be able to create its own pricing (too complex in immediate future to do this, however) +* Small teams should document what they build. + +# Small Teams list + +* Core Experience (trends, retention, funnels) +* Extensibility (plugins/APIs) +* Deployments and Infrastructure (AMI/VPC/PostHog Cloud) + +# Functional teams + +* People & Culture +* Marketing (includes website) +* Growth Engineering (proactive experiments / activation flow / revenue flow) +* Design + +# FAQ + +## Who do Small Teams report to? How does this work with management? + +The Accountable Person has the final say in a given Small Team's decision making - they decide what to build / work on. + +Each person's line manager is their role's functional leader (if possible). For example, engineers, no matter which Small Team they're in, will report to an engineer. It's important to note that management at PostHog is [very minimalist](management) - it's critical that managers don't set tasks for those in Small Teams. + +Think of the Small Team as the company you work for, and your line manager as your coach. + +## Can someone be in multiple Small Teams? + +No. This defeats the purpose of ownership. We should be hiring in both places. Sometimes that'll mean we "overstaff" certain teams, but in reality there will always be further projects we can move people onto if they run out of work. It's better to do this than to be perpetually understaffed and for our product to suffer as a result. + +## Who is in a Small Team? + +No more than 6 people, but that's the only rule. It could be any group of people working together. + +## Will this lead to inconsistent design? + +Eventually, yes. Other companies have a UX team that build components for everyone to use. Since we currently use [Ant Design](https://ant.design/), we don't need this just yet. + +## Can I still [step on toes](/handbook/values)? + +Yes. In fact it's actively encouraged. We still expect people to have an understanding of the entire company and what various people are working on. In engineering, we still expect you to understand how the entire system works, even if you're only working on infrastructure. You can only do your job well if you understand how it fits in with other parts of the system. + +You're actively encouraged to raise pull requests or propose changes to stuff that doesn't have anything to do with your small team. + +## Can people change teams? + +We try to keep moves infrequent and when needed. We anticipate moving people roughly every 3-9 months. We'd rather hire new people than create gaps by shifting people around. + +There are two scenarios that will trigger a move: + +* The Small Team may realize they no-longer need someone, or that they could really do with someone currently in another Small Team internally. +* An individual team member may wish to move in order to develop their skills or experience. + +It is at the discretion of the _manager_ of that person if they can move. + +## Aren't most our Small Teams way too small? + +In certain cases, but not everywhere. This will clarify where people will work. In fact, it'll make sure we keep the scrappy fun side of working here as we get bigger. A team doesn't _have_ to be six people. + +## How does hiring in the Small Team work? + +The Small Team is responsible for creating roles for those that they need. + +We have a centralized team that will then help you hire. + +James and Tim will meet every hire we make - it's a standard startup failure for founders to get too removed from hiring. We are very happy to then give you complete autonomy on the work you do, as best we can. + +## Does a Small Team have a budget? + +Spend money when it makes sense to do so. See our general policy on spending money. + +## How do you keep the product together as a company? + +Marcus (Tim until Marcus starts) will be ultimately responsible for us having (i) no gaps in product (ii) eliminating duplicate work (iii) making sure all Small Teams are working on something rational. This is how we manage the product. + +## How do you stop duplicate work? + +Marcus (Tim until Marcus starts) has the ultimate responsibility to make sure we don't build the same thing in two different teams, or that we don't accidentally compete with each other internally. + +By keeping communication asynchronous and transparent, this is made much easier to do than is typical at other organizations. + +## Can a Small Team "own" another Small Team? + +Not for now, no. Perhaps when we're much larger this is something to think about. diff --git a/SourceMaterial/people/team.md b/SourceMaterial/people/team.md new file mode 100644 index 0000000..492a60c --- /dev/null +++ b/SourceMaterial/people/team.md @@ -0,0 +1,710 @@ +--- +title: Team +sidebar: Handbook +showTitle: true +hideAnchor: true +--- + + + +
+
+
+
+
+
+
+
+
+
+
+
+We are proud to be misfits. Why?
+ +Building an unusually great company starts with an unusual team. + +We don't care if you haven't finished (or attended) school, if you were super important at a FAANG company or if you ran a startup that crashed and burned. + +What we do care about is your ability to learn, iterate, and ship. + +That's why we have people in Belgium, the East and West coast of the US, England, Estonia, South Africa, the Democratic Republic of Congo, among other places. Learn more about [diversity](diversity) at PostHog. + +
+
+
+
Our team of 22 is distributed across 10 countries. + +
+
+Our team of 22 is distributed across 10 countries. + +
+
+## Core Team
+
+
+
+
+
+
+
+
+
+
+
+
+
+### James Hawkins, Co-Founder & CEO
+
+
+
+
+
+
+
+I spent the first 10 years of my career trying to be a professional cyclist. I used to do web development part time to make some money on the side. I wasn't particularly good at either.
+
+I live in Cambridge with Fran (wife), Ruby (daughter), and Wally (cat). Since you're probably wondering, the cat's name is a reference to [WALL-E](https://en.wikipedia.org/wiki/WALL-E) - work for us to find out why.
+
+After a growing sense of my own mortality combined with a bunch of large crashes put me off continuing with my cycling career, I bootstrapped an online marketing company to several million dollars a year.
+
+I wanted more experience of working in a VC backed startup, so I could work on something really ambitious. I moved to [Arachnys](https://arachnys.com), and somehow wound up as a their VP of Sales for a little over 4 years, where I used to manage a team selling very large enterprise software deals. We learned how to take our sales from an average of \$5K/year to over \$1M/year.
+
+I started working with Tim on a few ideas that didn't work out in August 2019. We built PostHog during the YCombinator W20 batch, and launched in February. You can work out what I've been up to since by stalking me online.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+### Tim Glaser, Co-Founder & CTO
+
+
+
+
+
+
+
+I've been coding since I've been 11, which isn't as long ago as I'd like it to be. Someone first paid me to write code when I was 13 (though I'm sure they regretted it) and [someone else](https://en.wikipedia.org/wiki/Cloud9_IDE) gainfully employed me when I was 16.
+
+Originally from the Netherlands, though I quickly moved to London (I do not generally enjoy nice weather) where I joined Arachnys and shortly afterwards met James Hawkins. I went from being a software engineer, to product manager, to "leading" an R&D team, which consisted of just me.
+
+After four years I thought it was time to go do something else and had lined up a new job. Roughly 37 seconds after it was announced James wanted to "grab a beer." While plying me with alcohol, he convinced me to give up this fancy new job and instead start a startup with him.
+
+In my 'spare' time, I fall down snowy mountains, wrestle in the mud over an egg-shaped ball and watch a lot of Bondi beach in order to perfect my Australian accent.
+
+[See my README for tips on how to work with me](/handbook/company/team/tim-glaser)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+### Marius Andra, Software Engineer
+
+
+
+
+
+
+
+I first got into programming in 1994 when I wanted to make my own computer games... and asked my father for help. He sat me behind a Turbo Basic interpreter, wrote `PRINT "Marius on tubli poiss"` and then left me there. I was 8 years old.
+
+Luckily we had a [Yamaha YIS-805/128R2](https://www.msx.org/wiki/Yamaha_YIS-805-128R2) lying around... with floppy disks full of random .BAS files. I was hooked. Cue to the beautiful loops of CLS, PRINT and GOTO statements that ensued. I even made some games where you could move two dinosaurs who got points when they kissed each other. It was glorious.
+
+I also got into "web development" in 1997 after seeing Netscape at my mother's university. They even provided me with a generous 10MB of space to host my own [beautiful website](https://web.archive.org/web/19980128032518/http://rasi.lr.ttu.ee/~marius/), complete with animated gifs, a Mortal Kombat fanpage and a strong recommendation to use 800x600 with HiColor!
+
+This was followed by years of writing games in C++ and then [writing tutorials](https://web.archive.org/web/20110626030555/http://cone3d.gamedev.net/) about them, coding websites in Perl, PHP, Java and Ruby... and "losing" a decade as the CTO of two failed startups.
+
+On the side I built an [open source database analytics platform](https://github.com/mariusandra/insights)... and when that [got on Hacker News](https://news.ycombinator.com/item?id=22347516), James reached out... and the rest is history.
+
+These days I live in Belgium and code [state management libraries](https://kea.js.org/) in JavaScript for fun.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+### Eric Duong, Software Engineer
+
+
+
+
+
+
+
+I recently graduated and while in college I helped cofound a social dining platform. I spent two years trying to get strangers to cook and dine with each other. In reality, it turned into a 2 year stint of teach yourself as much mobile development as you can while simultaneously trying to build a usable platform. My cofounders and I had our fair share of contemplating dropping out of school and becoming a unicorn in 5 years—it didn't work out.
+
+Somewhere along the way I fell down the bitcoin rabbit hole and after realizing day trading crypto wasn't a feasible nor fulfilling long term goal, I remained fascinated by digital currency. This led me to briefly work with a company building a digital cash transfer system for developing economies.
+
+I currently work as a generalist around most of Posthog's stack building many of the user-facing features but occasionally pick up backend tasks.
+
+To end with an obligatory "I dO MoRE ThAN COdE" detail: I plan to take advantage of Posthog's all remote policy to travel and hike as many major mountain treks around the world as possible. Ambitions subject to change as always though.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+### James Greenhill, Software Engineer
+
+
+
+
+
+
+
+When I was a kid the first thing I remember wanting to be was a pilot, so naturally here I am knee deep in code and data!
+
+Growing up was slightly different in Florida. Things that are normal there are growing up in the water and spending almost all of your free time in it. In the Gulf of Mexico for me. We’d go swimming, scuba diving, or fishing in that warm body of water almost every weekend.
+
+Nowadays I’m spending my free time on a bike finding some new trail up in the northern bits of the Bay Area that I call home now. If not on a bike you’ll find my friends and I on a hike either around here or over in Tahoe or some National Forest east of here. Lately I’m trying to get back into flying. I’ve got about 80 hours of flight in the book, but still don’t have my ticket! It’s time to change that. In the winter time you can find me ruining skis on some mountain.
+
+In my professional life I’ve generally managed mopping up the 1’s and 0’s. I’ve led data at an [upstart music streaming company](https://en.wikipedia.org/wiki/Grooveshark), and dove way too deep into the depths of the comment section leading data at [Disqus](https://en.wikipedia.org/wiki/Disqus). Kept an eye on a fleet of [Autonomous Ubers](https://en.wikipedia.org/wiki/Uber#Self-driving_car_research). Most recently I combined my interest in bikes with data leading data engineering at [Jump](https://en.wikipedia.org/wiki/Jump_(transportation_company)), still the best micromobility company out there.
+
+When I’m not out and about in nature you can find me at home with my cat Tesla and Taco our goofball of a Lab Corgi mix.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+### Michael Matloka, Software Engineer
+
+
+
+
+
+
+
+Got into software by tinkering with bada OS – if anyone even remembers that! – and just never stopped (though I did move to Android soon and later became an iOS fan).
+
+Before graduating from high school here in Poland – and having some open-source projects under my belt, including [a Discord bot with thousands of users that became my gateway to Python](https://github.com/Twixes/somsiad) – I decided that the most interesting way to grow and meet some great people along the way will be to work on a quality product commercially.
+
+Happy to report that I ended up joining PostHog, where open-source software, a quality product and great people all mix freely!
+In free time, I dabble in [outer space](https://www.kerbalspaceprogram.com/), [math](https://codepen.io/Twixes/pen/Zwxxdv), [design](https://www.lingscars.com/), [photography](https://unsplash.com/@twixes) and [cinema](https://www.nowehoryzonty.pl/index.do?lang=en). Decidedly a fan of precipitation and overcast weather, I have a secret plan to move to the Nordics or the UK one day.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+### Paolo D'Amico, Product Team
+
+
+
+
+
+
+
+I started coding when I was about 9 years old, starting with the very basic LEGO RCX & Turbo Pascal language. I always enjoyed learning new languages, frameworks or technologies on my own, especially with a good book. Funnily enough, I decided not to study computer science.
+
+Before joining PostHog, I lead a product team at Grow Mobility, the largest micro-mobility company in Latin America at the time. Before that, I co-founded Flinto, a Y Combinator startup targeting financial inclusion in developing economies. I enjoy reading while walking around strange places, and have tripped more than once.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+### Lottie Coxon, Graphic Designer
+
+
+
+
+
+
+
+I am from the UK - so by default I love the pub, marmite and tea (but not all at once, that would be a sin).
+
+I spent my youth trying to master fine art, after my teacher said I was awful and that I should try something else.
+In my stubbornness I decided to prove her wrong, and here I am - a designer.
+
+I was quite a weird child. I once ran a race with locked legs (Forest Gump style) because I had a dream the night before that I won by doing so. For those who are wondering, no I did not win. But I would rather be the weird child than the boring one.
+
+I took Graphic Design at university and graduated this summer and instead of a summer of fun, I was faced with a crashing economy, a pandemic and and a collapsing job market. But thankfully, after putting my portfolio on twitter, I was contacted by PostHog a mere 24 hours later.
+
+I am now their Graphic Designer, and spend my days composing layouts for the website, designing the product’s aesthetic, and most importantly drawing hedgehogs with sunglasses on.
+
+On a side note I have decided to move to Senegal (Africa) to be with my boyfriend George. It’s a bold decision really as I cannot speak French, but I will (try) learn.
+
+*French accent* C’est la Vie
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+### Yakko Majuri, Developer Experience
+
+
+
+
+
+
+
+Often on the move, sometimes by choice, and sometimes by chance, I'm a Brazilian-Finn who has lived in 5 countries across 4 continents.
+
+Passionate about teaching (but far from an academic), I taught an official high school course before graduating high school, became a Visiting Scholar before joining university, and presented my first paper at the European Central Bank during my freshman year (anonymous submission - they thought I had a PhD).
+
+Prior to PostHog, I was a technical consultant for clients which included a Fortune 500 company. A fan of building useful things, I'm a self-taught developer who has worked on an a wide variety of projects, from a travel app, to multiple websites and browser extensions, and even some white-hat hacking. For the past three years, I developed a nice habit of writing about my projects, which led me to a [Medium page](https://yakkomajuri.medium.com) that surpassed 250k views in just 30 days.
+
+When I'm not working, I have been found hitchiking in foreign lands, taking pictures of political demonstrations, and trying to learn Korean after one too many beers. I'll pick playing cards with my grandmother over the club on any Friday night, and my favorite place to spend the Saturday is on top of a mountain.
+
+Oh, and I'm also part of the select group of software developers who have won a dunk contest in their lifetime. If that means anything.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+### Karl-Aksel Puulmann, Software Engineer
+
+
+
+
+
+
+
+I spent my childhood in a tiny village in the middle of nowhere (Väätsa, Estonia), playing football, working in construction and driving tractors. I used it buy my own computer, but did not do much more than listen to music, play games and watch anime with it.
+
+Things changed in highschool, where we had a programming class. I started creating my own games, participating in competitions (even going to International Olympiad once) and generally learning and reverse engineering anything I could get my hands on.
+
+Some time has passed since then - I have since been a student, teacher, first engineer at a guitar learning startup, worked in fintech, helped scale a database cluster holding 1PB of data at an analytics company, learned and helped automate manufacturing of stickers, been a CTO in agritech startup and now learning how this open source business works.
+
+In personal life, you can find me in the wilderness looking for geocaches or hiking, buying too many books and recently trying to figure out this parenting thing.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+### Charles Cook, Business Operations
+
+
+
+
+
+
+
+Born and raised in the United Arab Emirates, I'm half British, half Lebanese, and lived in a variety of places growing up across the Middle East, Africa and Europe. Now based in London, I live with my wife Steph and son Remy, who was serendipitously born right at the beginning of lockdown here in the UK.
+
+I take care of all things business ops-related at Posthog, across finance, people, legal and basically anything else that doesn't involve actually building the product! Posthog is now my 3rd startup - I was previously COO at [Vitl](https://vitl.com), (personalised nutrition), and before that I was Director of Product at [ROLI](https://roli.com) (electronic music products).
+
+I'm a big fan of terrible jokes, beautifully crafted sandwiches and looking at [designer houses](https://www.themodernhouse.com/) I will never live in. I like to occasionally torment my son with my piano playing and spend more time than is probably reasonable making lists of things, à la [High Fidelity](https://en.wikipedia.org/wiki/High_Fidelity_(film)).
+
+[See my README](/handbook/company/team/charles-cook) on tips for how to work with me.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+### Eltje Lange, People and Talent
+
+
+
+
+
+
+
+Hi, I'm Eltje (_pronounced Elt-ie_), originally from Northern Germany, I moved to the UK in 2017 and I am now based in East London.
+
+Just like James, I used to be a professional cyclist until I realised you can’t make a living as a female cyclist. After a short identity crisis, I started university with the goal to become a management consultant. That never happened, I luckily realised my skills and personality are much better suited in a people (I guess non-startup people call it HR) role.
+
+At PostHog I look after our People and Talent function and my goal is make PostHog THE best company to work for. Previously I worked in very a similar role at a startup called [Farewill](https://farewill.com), who offer services around death (yes, you read right). Prior to that, I worked for a couple of companies later on the scaling journey, like [TransferWise](https://transferwise.com/) and [Xing](https://xing.com).
+
+Outside of work, I am working on my [Masterchef](https://en.wikipedia.org/wiki/MasterChef) skills and you can usually find me outdoors - either on my bike or during a long walk.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+### Cory Watilo, Lead Designer
+
+
+
+
+
+
+
+As one of the few PostHoggers who never attempted to enter the world of professional cycling, I instead spend much of my free time exploring new coffee shops or wine bars, generally sipping a cold brew iced coffee in the morning and a nice rosé once it hits 5:00 somewhere.
+
+Due to the fact that I generally require both warmth and sunshine to function at any normal capacity, my wife and I bought an RV a couple years ago and hit the road fulltime, our sole requirement being that wherever we travel _must_ have a [UV index](https://www.google.com/search?sxsrf=ALeKk010aYaVBhFgzWm_AysLPp_ytPyFRg:1610376210393&q=What+is+the+best+UV+index+to+tan%3F&sa=X&ved=2ahUKEwjMk-bvjpTuAhXBp1kKHXVtDIwQzmd6BAgTEAU&biw=1080&bih=946&dpr=2) of 6 or greater. (At 45 feet long, our RV is larger by square footage than many apartments in New York or San Francisco!)
+
+Our party of 2 became a party of 3 last year. 🎉 Now that I am officially a dad, I am now legally entitled to make dad jokes. So in light of the rich cycling history of our company, I present the following: "Why couldn't the bicycle stand up by itself? It was two tired."
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+### Kunal Pathak, Growth Engineer
+
+
+
+
+
+
+
+Hi! My name is Kunal. I'm a Bay Area native and a bit of a startup vet.
+
+I love helping teams discover new ways to apply data, product, and engineering to drive business outcomes.
+Most recently, I led the growth team at Amplitude and at an education technology startup prior to that.
+
+When I'm not working on growth, you'll find me studying the Mamba Mentality, re-learning guitar chords, or making some ravioli (a lasagna if it's going poorly).
+
+In terms of cycling– a friend once convinced me to go on a bike ride from San Francisco to Mill Valley. We took the ferry home.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+### Buddy Williams, Software Engineer
+
+
+
+
+
+
+
+Howdy! I live in Atlanta, Georgia with my amazing partner of five years. I have
+two truly wonderful kids, boy-9 and girl-12 who both level up in July. Oh,
+geez, I'll have a teenager! I'm a hobbyist: unicycles, juggling,
+acroyoga, hiking, cooking, rollerblading, skiing, climbing, and
+lifting. My partner and the kids especially love hiking, playing video games,
+and performing amazing acroyoga feats for folks in the park.
+
+I got started in programming at twelve years old. My grandfather was a
+retired FFA engineer with access to old decommissioned hardware. He'd
+bring it home for me to play with. My first computer was a TI-99/4A
+where you recorded your programs on cassette tapes! I fell in love with
+programming because I enjoyed both creative and reason based projects.
+From drawing and crafts to math, science, and philosophy. Programming
+gave me a big canvas for imaginary worlds, a place for self-expression
+I hadn't found anywhere else.
+
+I was sixteen when I landed my first programming gig as a frontend engineer
+for an agency. Afterwards, I helped co-found a radiology software company who
+ensured patients received follow-up care. These patients were slipping
+through the cracks, leading to fatal results not to mention expensive legal
+settlements. From there I worked in big tech where I learned corporate politics
+were no fun. After a few years of exploring I went back to my roots and founded
+a tech consultancy. During this time, I had an idea for a revolutionary platform
+for designers. So, I built a no-code app platform that allowed creatives to
+design applications rather than code them. It was a wild and exhausting ride!
+After a few years of catching my breath, I joined up with PostHog to
+pursue their mission of making more successful products in the world!
+I'm looking forward to all we will accomplish together.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+### Li Yi Yu, Full Stack Engineer
+
+
+
+
+
+
+
+HI! I'm Li from NYC. I fell in love with coding towards the end of college, jumped into a programming bootcamp right after, worked at a healthtech company for two years, and here I am today!
+
+Some things I enjoy: karaoke, Switch/PC/board games, a good movie or series, struggling on hikes because I've spent too much time indoors, and exploring the NYC food scene.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+## Contributors
+
+
+
+### Sam Winslow, Full Stack Engineer
+
+
+
+
+
+
+
+Hi! I’m Sam. I recently graduated from NYU, where I studied the interaction of media, technology & society. My earliest experiences with programming were building games on a TI-83 calculator and teaching myself BASIC at age 10. The first application I made was an MS Paint clone. I have worked in design, marketing, and software engineering since then.
+
+In my free time, I love building hardware projects, reading about logic & philosophy, cycling around NYC, and taking care of my puppy, Louie.
+
+One of the projects I'm most proud of was a social network for sharing music reviews. We had modest success among college students, and the biggest lesson I learned was that I wanted to spend more time coding new features and less time fighting the analytics tools in order to figure out what to build.
+
+I am always at the beginning of my journey to learn.
+
+
+
+
+
+
+
+
+
+
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+
diff --git a/SourceMaterial/people/time-off.md b/SourceMaterial/people/time-off.md
new file mode 100644
index 0000000..97cff81
--- /dev/null
+++ b/SourceMaterial/people/time-off.md
@@ -0,0 +1,55 @@
+---
+title: Time off
+sidebar: Handbook
+showTitle: true
+---
+
+PostHog encourages its team to take time off to recharge.
+
+We have a flexible time off policy. Sometimes you need an extra day or two.
+
+We believe people need 20 days off a year plus a sprinkling of national holidays to have meaningful time with their families, to explore or just to relax.
+
+PostHog therefore offer unlimited time off, but with an expectation that you take _at least 25 days off a year_, inclusive of national holidays.
+
+This is to make sure that people can take time off flexibly, whilst not feeling guilty about taking time off.
+
+The reason for this policy is that it's critical for PostHog that we hire people we can trust to be responsible with their time off - enough that they can recharge, but not so much that it means we don't get any work done.
+
+## Permissionless Time Off
+
+You do not need to "clear" time off with your manager.
+
+We care about your results, not how long you work. Whilst no approval is needed, it shouldn't be at the expense of business getting done. For example, having the entire technical team off means we can't be responsive to community issues. Please coordinate with your team.
+
+When you pick a date(s) to have off, please enter it into [CharlieHR](https://posthog.charliehr.com/) and it will be automatically approved and added to the team time off calendar. Remember to set an out of office message on your email.
+
+The same rules as above apply regardless of the vacation length.
+
+You can add the team time off calendar to Google Calendar by following [these instructions](https://intercom.help/charliehr/en/articles/839648-importing-your-time-off-calendar-to-google-calendar) on CharlieHR as well. CharlieHR only refreshes the calendar twice a day, so any changes you make won't be reflected immediately.
+
+## When You Should Have Time Off
+
+### You are sick
+
+If you are sick, you don't need to work and you will be paid. This is assuming you need a day or two off, then just take them.
+
+Please let your manager know if you need to take off due to illness as soon as you are able to.
+
+For extended periods of illness, please speak to us so we can work out a plan. In some countries, we may be required to request a doctor's note from you.
+
+### Jury Duty / Bereavements / Voting / Child Admin Disasters
+
+There are lots of situations where life needs to come first. Please let it - just be communicative with us and fit your work around it as you need.
+
+## Parental Leave
+
+Parental leave is exceptional as it needs to be significantly longer than a typical vacation. Anyone at PostHog, regardless of gender, is able to take parental leave, and regardless of the way you've become a parent - childbirth, adoption or foster care.
+
+If you have been at PostHog for over 1 year, you can take up to 12 weeks off on full pay. You can take a further 4 weeks unpaid leave if you need more time. After this, if you need to stagger your return to work, you can come back at 50% capacity on 50% pay afterwards. If you live in a country where a statutory parental leave benefit is available, you will be required to claim statutory parental leave pay (if you are eligible) and PostHog will supplement any gaps.
+
+If you have been at PostHog for under 1 year, we will pay you according to your local jurisdiction's legal requirements.
+
+Please communicate parental leave to your manager as soon as you feel comfortable doing so, and in any case at least 2 months before it will begin.
+
+We are aware that there are local laws around time off for new parents in every country, and that these may vary. Wherever there is a discrepancy between local regulations and PostHog policy, local laws will override PostHog.
diff --git a/SourceMaterial/people/training.md b/SourceMaterial/people/training.md
new file mode 100644
index 0000000..2ee971d
--- /dev/null
+++ b/SourceMaterial/people/training.md
@@ -0,0 +1,25 @@
+---
+title: Training
+sidebar: Handbook
+showTitle: true
+---
+
+The better you are at your job, the better PostHog is overall!
+
+## Books
+
+*Everyone* at PostHog is eligible to buy books to help you in your job.
+
+The reason we think books can be more helpful than just Googling stuff, is that the level of quality has to be higher for them to get published.
+
+You may buy a couple of books a month without asking for permission. As a general rule, spending up to \$40/month on books is fine and requires no extra permission.
+
+Books do not have to be tied directly to your area, and they only need be loosely relevant to your work. For example, biographies of leaders can help a manager to learn, and can in fact be more valuable than a tactical book on management. Likewise, if you're an engineer, a book on design can also be particularly valuable for you to read.
+
+## Training budget
+
+We have an annual training budget for every team member, regardless of seniority. The budget can be used for relevant courses, training, formal qualifications, or attending conferences. You do not need approval to spend your budget, but you might want to speak to your manager first, in case they have some useful feedback or pointers to a better idea.
+
+The training budget is \$1000 per calendar year, but this _isn't_ a hard limit - if you want to spend in excess of this, have a chat with your manager. Where the costs are higher than \$1000, please give Charles a heads-up, so he can increase your card limit.
+
+If possible, please share your learnings with the team afterwards!
diff --git a/SourceMaterial/strategy/business-model.md b/SourceMaterial/strategy/business-model.md
new file mode 100644
index 0000000..cfd223a
--- /dev/null
+++ b/SourceMaterial/strategy/business-model.md
@@ -0,0 +1,45 @@
+---
+title: Business Model
+sidebar: Handbook
+showTitle: true
+---
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
++ +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. diff --git a/SourceMaterial/strategy/investor-updates.md b/SourceMaterial/strategy/investor-updates.md new file mode 100644 index 0000000..a56434a --- /dev/null +++ b/SourceMaterial/strategy/investor-updates.md @@ -0,0 +1,59 @@ +--- +title: Working with Investors +sidebar: Handbook +showTitle: true +--- + +
+ +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. diff --git a/SourceMaterial/strategy/investors.md b/SourceMaterial/strategy/investors.md new file mode 100644 index 0000000..513319c --- /dev/null +++ b/SourceMaterial/strategy/investors.md @@ -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. diff --git a/SourceMaterial/strategy/prioritization.md b/SourceMaterial/strategy/prioritization.md new file mode 100644 index 0000000..b841632 --- /dev/null +++ b/SourceMaterial/strategy/prioritization.md @@ -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. + + +
| + | Enthusiast | +Startup | +Scaleup | +Enterprise | +
| Engineers / PMs with technical expertise | ++ | + | Scalability Advanced analytics |
+ Scalability Advanced analytics |
+
| Non-technical PMs, marketing, sales, business | +Too technical | +Too technical Feature set / integrations |
+ Too technical Feature set / integrations |
+ Too technical Feature set / integrations |
+
| Analysts | ++ | + | Direct SQL access Plugins for data lakes |
+ Direct SQL access Plugins for data lakes |
+
| Enterprise procurement | ++ | + | + | SOC 2 VPC |
+
| + | Enthusiast | +Startup | +Scaleup | +Enterprise | +
| Successful products | +Low (1/5) | +Very high (5/5) | +High (4/5) | +Low (1/5) | +
| Revenue | +Low (1/5) | +Mid (2/5) | +High (4/5) | +Very high (5/5) | +
| Combined | +Low (1/5) | +High (3/5) | +High (3.5/5) | +High (3/5) | +
|---|
| + | Enthusiast | +Startup | +Scaleup | +Enterprise | +
| Engineers | +Maintain | +Build | +Build | +Build | +
| Non-technical roles | +Maintain | +Maintain | +Maintain | +|
| Analysts | +Maintain | +Build | +Build | +|
| Enterprise procurement | +N/A | +Build | +||
| + | Enthusiast | +Startup | +Scaleup | +Enterprise | +|
| Global successful products | +10m | +1m | +10k | +10k | +|
| Global revenue | +$0 | +$240m | +$500m | +$4B | +|
| Additional successful products from feature | +0% | +5% | +5% | +10% | +51.5k | +
|---|---|---|---|---|---|
| Additional revenue from feature | +0% | +15% | +15% | +30% | +$1,311m | +