Antipatterns for product engineers

We always share internally why we let people go for performance reasons, so people can understand why we make the decisions and the kinds of things we look for. Most of what follows is inspired directly by those learnings.

1. Waiting for direction

The worst thing a product engineer can be is passive. This can take many forms, such as wanting to be assigned tasks or lacking an opinion on the direction of the product, but the result is always the same. Passivity sucks energy from other people and product engineers should always be adding energy to their team in some way.

If in doubt, it's always better to present an opinion and hypothesis that people can give feedback on than demand direction. It's fine if your original idea is bad or wrong – it's also fine to state as much when asking for feedback – but a bad plan is better than no plan at all. Better still, ship something to users and see what they say.

2. Dismissing feedback

There's a fine line between disagreeing with feedback and dismissing it out of hand. Whether it's coming from colleagues you're working with, or users of what you ship, a product engineer needs to be able to deal with direct feedback and respond appropriately.

If you disagree, you need to articulate why and understand why you're receiving that feedback in the first place. Ultimately, being a product engineer requires a love of learning, and that starts by learning how to listen and making good judgments about when feedback is valid.

3. Not shipping early enough

It's always best to get something into the hands of users, even if it's a small subset of users. If you're not slightly embarrassed by the early version of what you ship, you're probably shipping too late. Polish comes from shipping fast and iterating, not endlessly refining in isolation.

4. Obsessing over code quality

This is a related problem and both can be broadly summarized as "not shipping quickly enough". Should you ship genuinely bad code that doesn't work? Obviously not, but wanting to prioritize code quality over the impact of that code is a common problem to avoid. There's always a time to focus on quality, but this shouldn't override shipping working code fast.

5. Not talking to users

This is a fundamental failure for a product engineer. Product engineers should be opinionated about what to build, but being opinionated shouldn't devolve into "I know best". And, if you do think you know best, you need to be able to back that up with feedback from real users.

We always say product engineers should have users they're friendly with who they can recruit to test the early version of an idea, or get feedback on their planned roadmap. Hate Zoom calls? You don't have to do them. Often a Slack channel with a customer is enough, though ultimately it's best to use the medium your user prefers.

6. Not supporting users directly

This is a similar but subtly different point. The easiest way to spark joy in users is to fix a problem they've reported, do so quickly, and tell them you've done it. It's not a complicated thing, but it's incredibly powerful. Failing to follow-up with users, by not telling them you've fixed their problem, or having an issue sit on your backlog for ages, doesn't spark joy.

7. Requiring excessive validation

Getting feedback on your work is good, but you can go too far. Once you've decided to build something, it shouldn't be necessary to stop and check with everyone that you're doing it right at every turn. Doing so can devolve into a quasi-approval process, which slows everything and everyone down.

8. Not caring about impact

No one using what you've built is bad, not knowing whether people are using what you've built is worse. A product engineer's job doesn't end when you've shipped to prod. If you don't care about, or measure, the impact of your work, you're failing.

9. Being an asshole

Sometimes when we talk about product engineers, people imagine the tech bro archetype of someone who is just out there doing their own thing, not caring what other people think, and feeling superior because they're "building the future". This is not it at all.

In fact, "low ego" is one of the key qualities we look for when hiring. We want people with strong opinions, but strong opinions become a weakness if they come with a side dish of being dogmatic, inflexible, and uninterested in other perspectives.

10. Failure to iterate

Occasionally we find product engineers who are great at many things, such as working autonomously, shipping fast, and working with users, but nothing ever feels complete. This typically presents as choosing to move onto the next shiny new idea or feature, rather than adding the extra 10 to 20% that's needed to make something spark joy. This creates not great user experiences and a bunch of debt that burdens teammates.

11. Management bias

As noted in an earlier chapter, management should be a part-time activity for a product engineer. Occasionally we see product engineers who would prefer to manage teams than contribute to them, which ultimately means they're a poor fit for the role.

12. Lack of awareness

A product engineer should be able to describe their ideal customer profile or user persona, the high-level goals of their company, and the why behind what they're building. Failure to engage on these points is a clear sign someone won't work out. You can't make good decisions about what to build if you don't know, or care to know, the context in which you're building.

Next chapter: Getting started as a product engineer