---
title: "Product Positioning"
source: PostHog Documentation
source_url: https://github.com/PostHog/posthog.com
licence: MIT
domain: data-and-analysis
subdomain: posthog-docs
date_added: 2026-04-25
---

_How_ do we name things?

Here's a typical flow:

* engineer builds cool thing
* engineer gives it a name
* design thinks 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 iterates 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 a 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 practice, 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 us 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.

## What positioning actually means

Positioning is more than just picking a name. It's about understanding how users will encounter, understand, and use what we're building.

It also means being clear about **what problem we're solving** and **who it's for**. Are we building this for someone debugging an issue right now, or for someone planning next quarter's roadmap? The same feature might be positioned differently depending on the context.

We also think about how new capabilities fit into the **broader PostHog story**. Every new product should reinforce our core positioning: one platform that gives engineers everything they need to build successful products. 

## Positioning is dynamic

The reality is that positioning changes as products mature. Early on, we might position something narrowly to get feedback from a specific user segment. As it grows and we understand usage patterns, we can broaden or refine that positioning. 

We're comfortable with this iterative approach because it means we're not overthinking positioning before we know what users actually want, and how the product fits into the broader market.
