From 2cf0488bbd371ff49450277b5fe8ba68930bedbf Mon Sep 17 00:00:00 2001 From: James Hawkins Date: Thu, 25 Jul 2024 11:46:17 -0700 Subject: [PATCH 1/4] titles based on what you do --- contents/handbook/wide-company.md | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/contents/handbook/wide-company.md b/contents/handbook/wide-company.md index 700d018e8baa..72b823cd1927 100644 --- a/contents/handbook/wide-company.md +++ b/contents/handbook/wide-company.md @@ -43,6 +43,17 @@ For _everything else_, you and/or your small team should be able to decide this PostHog is _not_ a good place for managers who are territorial and prefer for all communication to go through them for 'efficiency'. Over time, doing this would undermine autonomy and cause our best people to quit! +## Titles based on what you do + +Companies give out titles to people that primarily show how senior they are. + +This means titles, as adopted by the wider world, imply that _seniority_ is more important than what people do. We do not believe that seniority should not determine how decisions get made - people should own decisions in their area of the business. We trust every employee to fully own their area of the business. + +When you are prompted to put your title somewhere, please just say as clearly as you can what you are focused on. Please do not focus on how senior you are. + +Before "Senior Engineer at PostHog" +After "Product Analytics Engineer at PostHog" + ## Goal setting When you build a startup from scratch, you are in an existential crisis. One day you might be building a gym, the next day a software product for accountants. The problem changes. At PostHog, we give each small team a product to build. (James and Tim focus on _which_ products we should build, as they often need sequencing.) From 70769323d1ce1cc393ef50798913165e59bb62e2 Mon Sep 17 00:00:00 2001 From: James Hawkins Date: Mon, 23 Sep 2024 17:04:45 +0100 Subject: [PATCH 2/4] created new principles for new products --- .../product/building-new-products-fast.md | 20 +++++++++++++++++++ src/navs/index.js | 4 ++++ 2 files changed, 24 insertions(+) create mode 100644 contents/handbook/product/building-new-products-fast.md diff --git a/contents/handbook/product/building-new-products-fast.md b/contents/handbook/product/building-new-products-fast.md new file mode 100644 index 000000000000..128d9c6b3dc2 --- /dev/null +++ b/contents/handbook/product/building-new-products-fast.md @@ -0,0 +1,20 @@ +--- +title: Building new products, fast +sidebar: Handbook +showTitle: true +--- + +* Don’t innovate on the MVP even if not integrated properly with everything else. + * We stressed about this loads with the warehouse but quickly realized that people are happy to use our products pretty separately in the early days - we don't need to be better than the rest of the market on day 1 of launching. +* Don’t even think about pricing until you have users. If people are using it, money will come. + * Pricing is distracting and complicated and it's not necessary to ship a product and start getting feedback. You should move existing free users onto a paid plan if you create a paid plan later, but give them more usage as a thank you, and be upfront during the free period about this. +* We need separate teams to build new products. Don't create them within an existing team. + * Shipping from within an existing team causes things to take much longer because you'll get pulled onto bugs, merging PRs etc. +* Don't put new people on new products. Definitely don't have new people _lead_ new products. + * Learning how PostHog works isn't going to happen on a fresh product quite so well. Take people from existing teams to run the new product so they can do that having learned the PostHog way. +* Force usage from internal users as soon as possible, replace our 3rd party SaaS tools slightly early. + * We are a really good user for most of our products, so why wouldn't we. +* One person teams are fine to get started, but we should add a second person very quickly. + * This avoids the need for hiring to block getting started, and longer term prevents loneliness and helps with shipping speed. +* Build "must have" features ahead of more SDK coverage. + * Sometimes we could add more SDKs "to get more growth", but we should start by making sure we can offer the bare minimum within the first SDKs we support. Don't default to loads of SDKs if you know you have huge feature gaps as that will disappoint lots of users. diff --git a/src/navs/index.js b/src/navs/index.js index 3338a94dc739..b6c88dd31677 100644 --- a/src/navs/index.js +++ b/src/navs/index.js @@ -603,6 +603,10 @@ export const handbookSidebar = [ name: 'Releasing as beta', url: '/handbook/product/releasing-as-beta', }, + { + name: 'Building new products fast', + url: '/handbook/product/building-new-products-fast', + }, { name: 'Per-product growth reviews', url: '/handbook/product/per-product-growth-reviews', From 291153b19ea9881d232d5beb34620c6b944a2b72 Mon Sep 17 00:00:00 2001 From: James Hawkins <47497682+jamesefhawkins@users.noreply.github.com> Date: Mon, 23 Sep 2024 17:06:57 +0100 Subject: [PATCH 3/4] removed accidental page update! --- contents/handbook/wide-company.md | 13 +------------ 1 file changed, 1 insertion(+), 12 deletions(-) diff --git a/contents/handbook/wide-company.md b/contents/handbook/wide-company.md index 72b823cd1927..84feedb59ffe 100644 --- a/contents/handbook/wide-company.md +++ b/contents/handbook/wide-company.md @@ -43,17 +43,6 @@ For _everything else_, you and/or your small team should be able to decide this PostHog is _not_ a good place for managers who are territorial and prefer for all communication to go through them for 'efficiency'. Over time, doing this would undermine autonomy and cause our best people to quit! -## Titles based on what you do - -Companies give out titles to people that primarily show how senior they are. - -This means titles, as adopted by the wider world, imply that _seniority_ is more important than what people do. We do not believe that seniority should not determine how decisions get made - people should own decisions in their area of the business. We trust every employee to fully own their area of the business. - -When you are prompted to put your title somewhere, please just say as clearly as you can what you are focused on. Please do not focus on how senior you are. - -Before "Senior Engineer at PostHog" -After "Product Analytics Engineer at PostHog" - ## Goal setting When you build a startup from scratch, you are in an existential crisis. One day you might be building a gym, the next day a software product for accountants. The problem changes. At PostHog, we give each small team a product to build. (James and Tim focus on _which_ products we should build, as they often need sequencing.) @@ -66,4 +55,4 @@ Another best practice we choose to ignore is "goals should be output driven". It Either the team will decide on some things it should build, or they won't manage to figure out what to build to do this. In either case, if a team knows what it should achieve, it should then figure out which things it needs to ship, and write those things down instead. It's clearer, and clearer is faster. -And if that list turns out not to be helping our metrics? Switch the goal to a new thing. \ No newline at end of file +And if that list turns out not to be helping our metrics? Switch the goal to a new thing. From 821c3bb6929ada9a476ad93cbcb7c73e4a859640 Mon Sep 17 00:00:00 2001 From: timgl Date: Mon, 30 Sep 2024 12:19:49 +0100 Subject: [PATCH 4/4] Update building-new-products-fast.md --- .../product/building-new-products-fast.md | 22 ++++++++++--------- 1 file changed, 12 insertions(+), 10 deletions(-) diff --git a/contents/handbook/product/building-new-products-fast.md b/contents/handbook/product/building-new-products-fast.md index 128d9c6b3dc2..02d4136f9468 100644 --- a/contents/handbook/product/building-new-products-fast.md +++ b/contents/handbook/product/building-new-products-fast.md @@ -4,17 +4,19 @@ sidebar: Handbook showTitle: true --- -* Don’t innovate on the MVP even if not integrated properly with everything else. - * We stressed about this loads with the warehouse but quickly realized that people are happy to use our products pretty separately in the early days - we don't need to be better than the rest of the market on day 1 of launching. -* Don’t even think about pricing until you have users. If people are using it, money will come. +* **Don’t innovate on the MVP** + * Give customers something they're already familiar with first. Innovation can happen later +* **Don't overthink the integration** + * We stressed about how to integrate the data warehouse deeply into the product early on. People are happy to use our products pretty separately in the early days - we don't need to be better than the rest of the market on day 1 of launching. +* **Don’t even think about pricing until you have users. If people are using it, money will come.** * Pricing is distracting and complicated and it's not necessary to ship a product and start getting feedback. You should move existing free users onto a paid plan if you create a paid plan later, but give them more usage as a thank you, and be upfront during the free period about this. -* We need separate teams to build new products. Don't create them within an existing team. +* **We need separate teams to build new products. Don't create them within an existing team.** * Shipping from within an existing team causes things to take much longer because you'll get pulled onto bugs, merging PRs etc. -* Don't put new people on new products. Definitely don't have new people _lead_ new products. +* **Don't put new people on new products. Definitely don't have new people _lead_ new products.** * Learning how PostHog works isn't going to happen on a fresh product quite so well. Take people from existing teams to run the new product so they can do that having learned the PostHog way. -* Force usage from internal users as soon as possible, replace our 3rd party SaaS tools slightly early. - * We are a really good user for most of our products, so why wouldn't we. -* One person teams are fine to get started, but we should add a second person very quickly. +* **Force usage from internal users as soon as possible** + * We are a really good user for most of our products, so why wouldn't we. The best way to do this is force usage before we're fully ready, which will really focus the team on building the right things +* **One person teams are fine to get started, but we should add a second person very quickly.** * This avoids the need for hiring to block getting started, and longer term prevents loneliness and helps with shipping speed. -* Build "must have" features ahead of more SDK coverage. - * Sometimes we could add more SDKs "to get more growth", but we should start by making sure we can offer the bare minimum within the first SDKs we support. Don't default to loads of SDKs if you know you have huge feature gaps as that will disappoint lots of users. +* **Build "must have" features ahead of more SDK coverage.** + * Sometimes we could add more SDKs "to get more growth", but we should start by making sure we can offer the bare minimum within the most populair SDKs we support (posthog-js, python, typescript). Don't default to loads of SDKs if you know you have huge feature gaps as that will disappoint lots of users.