Part of our strategy is to provide all the tools in one for evaluating feature success.
Speed
This means we need to ship a lot of products into one platform. We can see a need for at least 20. That's a lot of engineering work.
After we'd started hiring, we asked ourselves a question – how could we structure the company to optimize for speed above everything else?
I happened to go to an excellent talk by Jeff Lawson (Twilio CEO). It made me realize I should be asking, "Who ships more per person, a startup or an enterprise?" Clearly the former. Let's structure like a series of startups then.
Small teams
We decided that we should split PostHog into a series of small teams, each working like its own startup, fully owning (at least) one of our products.
As with any startup, the principles that govern these small teams are:
- Can decide what to build within their own products
- Can ship without outside interference as far as possible
- No product by default
- No design by default
- Should work directly with its own users (until it has hit product-market fit within PostHog's platform)
- Should be small
Goal setting
When you build a startup from scratch, you are in an existential crisis. One day you might be building a gym, the next day a software product for accountants. The problem changes. At PostHog, we give each small team a product to build. (James and Tim focus on which products we should build, as they often need sequencing.)
Once we had product-market fit (and we had reached 15 people or so), we realized we needed to set some kind of goals. We started by using OKRs as they're pretty standard.
However, one of our engineers one day told me "I realized I needed to change my objective. Then I started rewriting my OKRs into the handbook. I realized I was spending time stressing about the wording of it, which was going to have zero impact on what I knew I had to build." That seemed pretty silly, so instead we make a point of calling them just "goals". We intentionally don't sweat the wording.
Another best practice we choose to ignore is "goals should be output driven". It sounds great in principle, but what is going to happen after a product team (which is nearly every team here) sets an output driven goal like "improve activation by 20%"?
Either (i) the team will decide on some things it should build or (ii) they won't manage to figure out what to build to do this. In either case, if a team knows what it should achieve, it should then figure out which things it needs to ship, and write those things down instead. It's clearer, and clearer is faster.
If that list turns out not to be helping our metrics? Switch the goal to a new thing.