---
title: "Traits of product engineers"
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
---

The most effective product engineers at PostHog aren't necessarily the best coders. This doesn't mean coding skill doesn't matter, it obviously does, but being a product engineer really starts from how you think and behave.

It's a classic "make your own luck" argument situation. Successful product engineers spark joy not because they're the best at coding solutions, but because everything they do revolves around finding ways to make a positive impact.

This list could be longer, but these are the most important traits we look for product engineers.

## They're customer obsessed

Product engineers care a lot about the people and organizations using their product. This customer obsession manifests in a few ways. 

First, they [talk to users](/newsletter/talk-to-users). While they work with product managers and salespeople to understand user problems, they don't rely on them alone. They go to the source. A good product engineer has customers they're friendly with and use to validate hunches.

Second, they're more motivated by work that directly benefits users, and getting this work into their hands as quickly as possible. [Fly.io](http://fly.io) defines this by saying:

> "We're ruthless about working on stuff that our users will see and care about. We are not ruthless about shaping and polishing our code into a radiant-cut gem of perfection."

Third, they love jumping on user problems and solving them. Whether it's an papercut they can solve quickly, or a useful feature that other users will benefit from, product engineers live for sparking joy by proactively solving problems.

By being customer-obsessed, product engineers become more open-minded. They care more about solving real user problems than dogmatically following best practices just because "that's how it's done."

## They take extreme ownership of ideas

Product engineers are committed to delivering the full vision of an idea, not handing it off to someone else when they get stuck or lose interest. Getting to 80% doesn't count.

This requires them to own products from beginning to end. [Talking to users](/newsletter/talk-to-users), shipping minimum lovable products, experimenting and iterating constantly.

The things that delight users rarely get shipped at the alpha or beta stage of a product, or even when it's generally available. They also rarely originate from someone with little personal investment in what's been built.

## They ship early and iterate

Product engineers prefer prototypes, minimum viable features, and experiments to briefs, proposals, and presentations because they get them closer to building a great product. 

They learn by taking bets, building, [gathering feedback](/newsletter/how-to-give-feedback), and repeating until what they're building sparks joy in their users. They operate under the assumption it's always best to get something into the hands of a user, and learn from them, than to endlessly polish their work before anyone ever sees it. 

This means they use [feature flags tools](/feature-flags) to [test in production](/product-engineers/testing-in-production), and run [experiments](/experiments) to understand the impact of their changes where needed. This mindset, and a willingness to use tools that enable it, enables product engineers to quickly validate ideas with real users, so they learn exponentially faster.

## They genuinely love building

Product engineers are intrinsically motivated by building useful (and sometimes just interesting) things, more so than career milestones, or status. 

Their love of building means they're more likely to have side projects they’ve built themselves. Some might be former founders or have unorthodox, self-taught backgrounds. They make great teammates in hackathons. 

[Ghost](https://ghost.org/) looks for these people:

> "The majority of our team is made up of former founders, freelancers and self-starters who are confident and comfortable working independently and getting things done."

As does [Supabase](https://supabase.com/blog/who-we-hire):

> "Something we especially value are team members who take on responsibility without asking and without being asked. Founders do this regularly. Clearly these traits are not only found in people who’ve started companies, but it can be an indication. It’s not the credentials that we value most, but the mindset. We expect everyone who works at Supabase to act like a business owner."

Many of the product engineers at PostHog are former founders, or cut their teeth maintaining open-source projects.

<NewsletterForm />

## They have product sense and taste

Building successful products requires a little intuition.

Product engineers use lots of products, think about how they're made, what they do and don't like about them, and how they would improve the apps they use every day.

These habits help them [build taste and product sense](/newsletter/good-taste-great-products) – a gut feel for what a good experience should look like. They still want and need to validate their assumptions with real users, but their intuition makes it easier to go from 0 to 1 quickly.

Rapid validation loops also mean product engineers develop this intuition faster than engineers who operate in a more conventional, structured way. This has a compounding effect on the products they work on. 

Product engineers who ship fast, learn fast. Product engineers who learn fast build even faster. Teams that ship fast improve their products faster. Products that improve fast, grow faster.

The momentum is irresistible.

## They understand and care about the broader context

Because product engineers own their product, they also own the performance and roadmap of that product. This means analyzing usage data and the competitive landscape. They combine this analysis with user feedback, and their own intuition, to figure out what to do next.

Product engineers also understand how their product fits into the business landscape. They understand the businesses using their product, and the competitors working on similar products. They know what makes them special, and can continue to build to expand this gap.

Product engineers love gathering more context because it helps them make better decisions about [what to build](/newsletter/how-we-decide-what-to-build).

## They constantly search for 1% gains

Software isn't made in a vacuum and, more often than not, you're always trying to out ship and outgrow a competitor. Product engineers are aware of this and always looking for ways to work more efficiently, or more successfully.

This takes different forms, such as:

* Dedicating time to automating time-consuming tasks, like tests.
* Improving developer tooling to reduce time to deployment.
* [Testing in production](/product-engineers/testing-in-production) – i.e. as close to reality as possible.
* Experimenting with different tools, agents, models, and frameworks. 

Product engineers are often early adopters of new technologies if they believe they can help them ship faster, or learn some new skill that will help them toward their goal. They love learning for the sake of it, even when there's no specific goal to task to complete.

## They're optimistic

Building successful products that users genuinely love isn't easy, so you need to be optimistic by default.

A product engineer's reaction to any difficult problem should always be "this is solvable", not a long list of reasons why they can't do anything about it. They bring practical solutions to edge cases, and are more willing to tolerate them if the impact of a change will benefit the vast majority of users. 

This doesn't mean saying yes to every problem or request that comes along – product engineers are opinionated about their work, after all. It means having an open mind about what's possible.

**Next chapter:** [Things product engineers need to know](/product-engineer/skills).

<NewsletterForm />
