Building new products, fast

Last updated:

|Edit this page
  • 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.
    • 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
    • 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 most popular 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.

Questions? Ask Max AI.

It's easier than reading through 604 docs articles.

Community questions

Was this page useful?

Next article

Role of a Product Manager

Role of a Product Manager The role of a Product Manager varies enormously by individual and organization, however there are some nuances about what makes a great Product Manager at PostHog and what you can expect from them. Why do we have Product Managers? Product development at PostHog is engineering-led. All projects and features have an engineering owner who is the "informed captain" and makes the final call on everything they build. Product Managers ensure these owners have the company…

Read next article