PostHog Handbook Library

403 words. Estimated reading time: 2 min.

# How we make users happy

User happiness is fundamentally important. How do we achieve this?

### Building products that people want

First, someone internally will suggest an idea. Sometimes this will come from James and Tim, but it has, just as frequently, come from anyone else on the team.

If it requires a new team to build it – which it usually will – we'll start by hiring an ex-founder who is technical. We'll onboard them into the existing team that has the most overlap. This helps get them used to working with our codebase, as well as with the culture we look for from each team.

That person builds the MVP, and the only goal is to figure out if anyone will use it. With some products, the MVP may have more scope if we feel especially confident. Once the new product is in a non-embarrassing state (that won't harm our brand), we add pricing to it and put it on our website. This drives more demand. At this stage, the goal is to get the product to product-market fit in PostHog's platform, which means working with customers until we have five delighted, paying customers.

Once all this is done – which we'd expect to take a few months – we can start to innovate. This usually means some kind of platform play, such as extending the product to enhance everything else we're working on, or shipping another new product that would work well with it.

### Engineers talk to users and provide support

You should be _as close as possible_ to your users, feeling whatever they feel, so you have as much information as possible to make the product great.

For established products with a lot of usage questions (how do I create an insight that does X, for example), Customer Success helps with support.

Before a new product is even made, we'll add it to our public roadmap. Once it ships, we'll use our own tools to get customer interviews, feedback, and data, and we'll always aim to "close the loop" with users - coming back with: a pull request, a GitHub issue they can follow in the open, or an explanation of why we can't make a feature they've asked for.

This means the product improves, users are impressed and recommend us to others, _and_ we show users that we listen, encouraging them to keep going through this loop with us, faster and faster.

Canonical URL: https://posthog.com/handbook/making-users-happy

GitHub source: contents/handbook/making-users-happy.md

Content hash: `87f2e2bf9043b11f`