Why 'Product Engineer' is the most fun role I've had in tech

In my career so far (admittedly not that long, though no one mistakes me for a college kid any longer, womp womp) I've done a little bit of a lot of different things. In some rough order I've moderated forums, led customer success, created marketing plans and SEO strategies, built websites and apps, led product at a seed-to-series-A co, coded + ran my own startup, and more. I'm currently a product engineer here at PostHog working on the Growth Team.

Maybe it's just me, but I've had more fun as a product engineer than in any other role, hands down. I'll tell you why.

But first... why does optimizing for fun matter?

For me, it's simple. Having fun while working is highly correlated with my job satisfaction. It sounds obvious, but I've seen many people sacrifice the fun they have for some thing that gives them more money, status, or just the feeling of progressing up the ladder, even if they have no idea where that ladder leads.

When we find activities we enjoy, our brains want us to do them again and again. This has a couple interesting ramifications in a work context:

1. If we're having fun doing our work, we will actively look forward to and pursue it more than normal.

2. When we do things again and again, we tend to get better at them, and thus better at our jobs.

And when you put these two things together, you'll likely find that optimizing for fun in your work results in you wanting to work more and being better at it. This should (hopefully, theoretically) result in the salary increases and promotions that you've been dreaming about all along.

This will, admittedly, be different for everyone. But I will say that I'm specifically not talking about an office that has a ping pong table or that organizes amazing off-sites for its remote workforce. While those things are great, what I'm talking about is the actual work. The things you do for your job that, hopefully, move the company in some direction.

I have found that the critical ingredients for a fun job, for me, boil down to the following:

1. Challenging problems to solve
2. Support from other highly motivated colleagues
3. The autonomy to make important decisions
4. Complete transparency into why my work matters

Many companies and roles assume that challenging problems to solve (#1) is the only requirement for a satisfying (aka fun) job. But, when you look into the neuroscience of fun, it's clear that being with others (#2) and defining direction (#3) with help and context from superiors (#4) are critical aspects of any fun activity.

We've written before about what product engineering is, so I won't bore you with the details here. TL;DR: A product engineer is someone who works with customers and data to decide what should be built, and then goes and builds it themselves.

Critically, you can't do the work of a product engineer without the four essential ingredients mentioned above. But interestingly, you can also find those ingredients for fun in other roles.

So what makes product engineering more fun than those other roles? In my opinion, it comes down to the intensity of each ingredient.

Let's look at two other roles, specifically two that have been combined to create the product engineer: product management and software engineering.

From first-hand experience, pretty darn fun.

We can use our ingredients above and rate the intensity of each to come up with a proxy for fun-ness. Since company culture is so important to #4 (complete transparency into why my work matters), we'll leave it out of our ranking system as it has more to do with the company and less to do with the role.

The others are obviously very impacted by culture as well, but we'll assume our roles here are at a company that doesn't completely suck.

1. Challenging problems to solve – 4/5
   • PMs often need to solve challenging problems around UX, customer needs, scheduling, and politics. The cycle can be slow and frustrating at times, though.
2. Support from other highly motivated colleagues – 3/5
   • Product management is often cited as being an extremely lonely role (and in my experience this is true). You're often the only one in your role on your team, you are constantly fighting battles for budget and prioritization by yourself, and if anything goes wrong with your product launch, the buck stops with you.
3. The autonomy to make important decisions – 5/5
   • This is simply what PMs are there for. Take the given context, decide what to do with it.

Adding this up we get a score of 12/15. Not bad!

1. Challenging problems to solve – 5/5
   • There is nothing like the dopamine rush you get when you've been working through a problem and you finally get it to work. As a software engineer, this happens usually multiple times per day.
2. Support from other highly motivated colleagues – 5/5
   • Software engineers typically work on a team with at least one other engineer. This team aspect is critical to feeling supported.
3. The autonomy to make important decisions – 3/5 (or even 2/5)
   • While engineers can make important decisions about how something is implemented, they're often completely out of touch with making important decisions about the business. Oftentimes this is because they don't have the context, and they are simply told what to build.

For Software Engineering we get a score of 12 or 13/15. Also not bad.

1. Challenging problems to solve – 5/5
   • You get the dopamine rush associated with coding, plus the UX problems to solve.
2. Support from other highly motivated colleagues – 5/5
   • Similar to software engineering, you often work on a team with other product engineers.
3. The autonomy to make important decisions – 5/5
   • Because you're responsible for working with customers and data to decide what gets built, you're inherently making important decisions, similar to product management.

For product engineering we get a score of 15/15. Yes, I made this scale up, and yes I've given product engineering a perfect score. But you did read the title of this blog post, didn't you? I'm obviously biased.

Ah, there is a catch. There is no perfect score for fun without any downsides. One is the concept of a "fun hangover" in children – where they have such a fun day that you know the next day is going to be a complete terror. While slightly different in adults, I'm convinced this concept still applies.

But here's the big one:

It's really hard to operate in a product and an engineering mindset simultaneously.

The former is an external mindset; the latter, an internal one. Switching takes effort, so you need to be conscious about which mindset you're in, and whether it's the right mindset for your active task. Progress becomes slow when you get stuck in the wrong one.

Regardless, I'll take the need to context switch. Because after all, I'm optimizing for fun.