principles for shipping new products fast

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.

contents/handbook/wide-company.md

@@ -55,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.
+And if that list turns out not to be helping our metrics? Switch the goal to a new thing.

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',