Last updated:

|Edit this page

How do we name things?

Here's a typical flow:

  • engineer builds cool thing
  • engineer gives it a name
  • design think it should be called something else
  • um

So, how do we name things:

  • engineer builds cool thing
  • sometimes James or Tim realize it's happening and get the positioning right first time around
  • but if they don't / or don't spot it...
  • engineer gives it a name
  • design iterate the name (and adds it to the all hands so we can get everyone else to realize this has happened)
  • everyone - reinforce the name if people are calling things the wrong thing

This has got downside - it's messier from a user perspective, but the upside is that design / "execs" aren't a blocker to getting work out the door. In practise, we rarely push hard on marketing a new thing to users anyway (usually we soft launch stuff) so we think the downside is pretty minimal.

Picking a good name

By default, everything should be positioned as something a user is familiar with, not what is necessarily the most technically accurate description.

For example, when we build new products, we often name them based on what the major competitors are calling themselves.

This means users get it way faster, so we grow more quickly, and it encourages to build the basic features that a given product needs versus trying to innovate before we hit product market fit with a new product in our platform.


Was this page useful?

Next article

Developing locally

❗️ This guide is intended only for development of PostHog itself. If you're looking to deploy PostHog for your product analytics needs, go to Self-host PostHog . What does PostHog look like on the inside? Before jumping into setup, let's dissect a PostHog. The app itself is made up of 4 components that run simultaneously: Celery worker (handles execution of background tasks) Django server Node.js plugin server (handles event ingestion and apps/plugins) React frontend built with Node.js These…

Read next article