Deciding which products we build

Providing all the tools in one is a core part of our strategy.

Shipping them in the right order is key to a fast return on investment from every new product.

How we pick new products

Until products are built and launched, it's hard to predict which ones will do well. Because of this, we want to be working on a mix of new products at any given time. Some we're very sure will do well, others might be more of a bet with a potentially big outcome.

Products should fit these criteria before we build them:

• They add more data (for example, more events) or different types of data (for example, errors or logs), or use the data we already have
• They have an initial ICP of someone on the product team
  • Ideally, the ICP does not change quickly to someone far removed from the product team
• They already have $1bn competitors on the market, or are in extremely fast-growing markets
  • For example, AI Observability did not have a $1bn competitor when we started it, but the market was growing very quickly
• Someone is very excited about building this product internally
  • People pursuing their interests get more done, go much further, and execute to a better standard
  • Additionally, each product must have a Blitzscale sponsor
• The product has a future in 2030, i.e. it's not something 2020-style

Are there any exceptions?

We build lots of cool things at hackathons and when inspiration strikes. Not all of those should become paid-for products, but it's nice to let them see the light of day, especially if it can make a customer happy.

We encourage you to build things that can be turned into open-source software and offered in that way. This is a great option for dev tools, tangential projects, and cool little things you just want to hack away at.

How new products get built

Sometimes the Blitzscale team will decide a new product needs to be built. They'll find someone internally to run it, ideally someone who's been at PostHog for at least 6 months (we tried getting new people to ship new products, but they often struggled to ship quickly).

Other times you might have an idea for a great product we should build. In that case, use the New Product RFC template. You might choose to hack together a prototype of the product to demo and show off, which you should do! Blitzscale only needs to get involved if you want to start working on this product full time. At that point, we are choosing whether to invest a pretty serious amount of money into launching it, so we want to get that right.

The best products are often ones that not everyone thinks is a good idea before launch. For example, Tim was against building Session Replay, and it's one of our most popular products. To make sure we take big bets, any Blitzscale team member can OK a new product being built, even if other Blitzscale members disagree. That Blitzscale person will be the one who the new team reports to. This way we avoid consensus stopping us from making big bets.

For a complete walkthrough of the product lifecycle, see releasing new products and features.

See our roadmap for what we're currently working on.

How to pick which feature within an existing product to build

In the early days, you'll be shipping the main few features that your category of product has as standard. In product analytics, this would be something like (1) capturing events, (2) trends, (3) funnels, (4) retention, and (5) person views.

Once this is done, you'll get a stream of feature requests and bug reports from users. You can't go too wrong if you listen to these and, by default, prioritize those that help us get in first, first. For example, with our data warehouse, we picked multi-tenant architecture because we wanted startups to be able to get started for free or very little initial cost - even though a single tenant approach would have given us an MVP faster. Sometimes, if sales are asking, you may choose to prioritize a feature for a big customer earlier, but you should never do this when you wouldn't have shipped it at some stage anyway. However, be cognizant of how often you do this, and whether now is the right time to be shifting your persona focus.

Later on, you can then innovate several ways:

• unpeel your product - you start with the software, then offer API access, then offer better API access, then infrastructure (if you are feeling brave) - by default, start with this reminder: charge for API access appropriately, speak to Annika for help figuring this out. Doing this increases our luck surface area (it means your users will find new use cases).
• features more specific to our ICP (make it more engineering-y, more customization, more power)
• integrate it with our other products (either feature them in the product you just built, or feature your product in theirs)