The “Product Engineer”

In recent years, the software industry has started to adopt the term product engineer to refer to a customer-focused, full-stack engineer who blurs the lines between product and engineering roles. In this post, I share my journey of becoming and being a product engineer, provide some advice, and discuss my views on the future of the role.

Product engineering has been an established role in manufacturing for many years. It’s unclear exactly when people started using the term in software. The earliest references I could find date back to 2016, but it seems like the title has started to gather steam recently. As a data point: the percentage of Hacker News Who’s Hiring? listings that mention “product engineer” went from 2% to about 5% in the past two years.

Some startups and even larger companies have started to explicitly hire product engineers. But because still it’s an emerging title, information about the role is lacking. Other than a handful of blog posts, there’s not much out there.

In this post, I’ll cover three questions that I thought were unaddressed by the existing articles I’ve seen:

• How do you become a product engineer?
• What’s it like to be a product engineer?
• What’s the future of product engineering?

A quick definition

I’m not going to dwell on defining what a product engineer is in this post. There are a number of other resources I’d recommend on that subject (1, 2, 3).

But it turns out there’s a lot of ambiguity on the topic of what makes someone a product engineer, so I want to put down my definition to avoid confusion.

In my mind, a product engineer is a generalist software engineer who can be given a highly ambiguous problem statement, define a solution to it in direct collaboration with users or customers, lead hands-on design and implementation of that solution, and fully deliver the solution—validating that it actually solves the originally stated problem.

This requires a skillset that spans across many traditional functions: product management, design, backend and frontend software engineering, and maybe even a bit of sales or marketing. A product engineer is unlikely to be an expert at every single one of these functions, but where they have skillset gaps, they’re able to work with others to overcome them.

Origin stories

The very first thing to realize about product engineering is that’s less job title than an orientation. I know dozens of people I’d call “product engineers” according to the definition above who have never held the title formally—myself included.

What they have in common is an orientation towards thinking primarily about the users of their software, and using this orientation to guide their work.

I also think that most product engineers share an origin story like mine.

When I first started working in software about ten years ago, I consistently had a baffling experience: I’d show up to an internship or job, ask questions about why I was being asked to work on something, and discover I was seemingly the first person to ask that question.

In my first internship at a financial services firm, I was assigned to take a senior engineer’s abandoned side project and add some features to it.

“But who’s using these features?” I asked.

Shrugging, my manager pointed me to the internal team the software was made for. On my very first day, I went and talked to them.

“Oh, that thing? Some guy installed it on my computer a few months ago. I’ve never used it,” said the first user I interviewed. Everyone else echoed the same feedback.

Perplexed, I went back to my manager. I had ideas for what the users might actually need, but I was completely new to this and wasn’t sure if I was doing something wrong.

My manager seemed a bit annoyed that I’d immediately poked a giant hole in the premise of my intern project. I ended up spending a few weeks researching what my users might actually need and pivoting my project to something they’d potentially use.

But fundamentally, I knew I was in the wrong place. I didn’t find the work motivating, and I was only evaluated by my technical output, which was honestly quite lackluster at that stage in my career. I didn’t get a return offer.

I’ve fortunately been able to find better work contexts throughout the rest of my career. But the feeling of being on a different wavelength from others around me has been consistent.

Generalists and specialists

Suppose the story above resonates with you. You intuitively think about the users of your software and you want to exercise that intuition more. What’s the next step? How do you actually become a product engineer?

Unfortunately, there is no well-defined track. Although there might be some companies out there now that explicitly mentor junior product engineers, I have yet to experience any firsthand.

The only path I’ve seen is to find an opportunity to work in a fast-paced, flexible environment with a strong engineering culture. And once you’re there, go out of your way to learn as much as you possibly can.

While doing so, I believe it’s crucial to spend equal time learning from generalists and specialists.

Generalist engineers are role models for who you could be someday. Ideally, they’re already acting as product engineers, engaging with the business and product side of an organization while also being deeply engaged in the actual building of the software—architecting systems or writing and reviewing code on most days.

As a junior engineer, once I saw someone like this in action, I never saw things quite the same way again. It was inspiring to see that one person could tackle such a diverse set of challenges while maintaining excellence on all fronts.

But the biggest mistake I’ve seen product engineers make is to get overly attached to being a generalist. It’s easier to just hang out with other generalists all the time. After all, they’re the kindred spirits around whom you feel understood. And around specialists, you might feel impostor syndrome. “I’m never going to be as good at <skill> as <specialist>,” you might think.

If you adopt this defeatist attitude, your self-criticism will become self-fulfilling. You’ll never acquire any depth. You’ll become the worst kind of teammate: the person who knows enough to complain about everything, but not enough to actually contribute anything.

Over my career, there have been dozens of highly-specialized engineers, product managers, and leaders from whom I learned many specific skills and mental models. If you set aside impostor syndrome and just try to engage wholeheartedly, you’ll end up learning faster than you might expect.

Over time, you’ll be able to hold your own with a specialist even within their particular niche. And at the same time, you’ll be able to contribute in ways that complement them—bringing the best out of the specialists around you.

Experiences

What is it like to be a product engineer?

To summarize it in one word: weird.

The root problem underlying the weirdness is that the “product engineer” job title is still exceedingly rare. This means that most people doing product engineering are sort of sneaking around in job titles that don’t reflect what they actually do, like “full-stack engineer.” I’ve been a “PM who codes” for 5+ years.

This fundamental mismatch spans every aspect of the job—ranging from recruiting, to day-to-day work, to management and progression. I’ll touch on each of these issues below.

Recruiting. I have yet to see a hiring process that effectively evaluates product engineers. I’m sure one exists somewhere, but my experience has been consistently negative, mostly because I’ve been forced to apply for other job titles that don’t reflect my skillset.

The software industry has had a long-simmering backlash against whiteboard coding and algorithms interviews. Many companies have started evaluating software engineers through “take-home assignments” or “work trials” which more accurately represent an engineer’s day-to-day job.

This is a great step forward, but engineering interviews rarely focus on an engineer’s product instincts or ability to interface effectively with users or customers. And it’s rare that a product manager would interview a prospective engineer, or that an engineering candidate’s product instincts would be weighed as highly as their technical abilities.

Of course, if a company doesn’t already have strong product engineers, it’s unclear who’s even qualified to evaluate incoming candidates.

The day-to-day. As a product engineer, what should I focus my efforts on each day?

In some sense, the answer to this question is easy. I have a diverse skillset and I can work on many things, so I can globally prioritize across product and engineering work and focus on whatever’s most important. In many ways, this is the primary value of product engineers: we reduce communication overhead between teams and streamline development.

But on the flip side, it’s harder to avoid oscillating between very divergent sets of responsibilities. In most software teams, the product manager represents value—the voice of the customer and the market—while design and engineering represent quality and aesthetics—making something excellent down to its very core.

Product engineers hold both in their head at the same time. My brain tracks minute details about my product’s database schema in addition to the context around an upcoming customer interaction.

Working in this way is incredibly rewarding, but at times, it can also feel uniquely exhausting.

Management and progression. Should product engineers report to product or to engineering? By definition, neither fits very well.

If you report to product, your engineering skillset may be taken for granted or unappreciated. Excellent PMs can tell whether you’re a great engineer, but they can’t really mentor you or guide your engineering growth. The inverse is true if you report to engineering. And I have yet to see a dedicated “product engineering” reporting chain, although I’ve started to see job titles in this vein recently.

As a result, it feels like growing as a product engineer always requires taking your own initiative, seeking out disparate resources across two different disciplines. I haven’t felt like I had a mentor or anyone to look up to in many years.

What kind of role does a product engineer ultimately grow into? While writing this post, I wrote down a list of 20 of the best product engineers I’ve worked with. Here’s the distribution of their current job titles:

• (Founding / Full-stack) Software Engineer (10)
• Founder / CTO (5)
• Indie Developer (3)
• Left software (2)
• Product Manager (1 - me!)

It’s relatively rare that product engineers end up moving up the management chain at larger companies, probably because those chains are subject to the product/engineering split I mentioned previously. Besides that, I think most product engineers get antsy when they’re not working hands-on to ship something useful to users on a regular basis.

The future

What’s the future of product engineering?

I think there are a few ongoing tailwinds that will result in the “product engineer” job title achieving greater adoption and recognition in the coming years.

First, the end of ZIRP (the “zero-interest-rate phenomenon”) means that companies of all sizes want to do more with less, as amply evidenced by massive tech layoffs over the past few years.

Simply put, money is more expensive now.

I think workers in tech have yet to fully internalize how profound of a shift this macroeconomic change will create, since many of us entered the industry over the past ten years.

Large, established corporations with healthy profit streams will continue to thrive, though they also seem keen on increasing profits by downsizing. But for small companies, this means that raising gratuitous amounts of Series A and Series B funding just won’t be as common as it used to be. There’s now a strong incentive to keep teams small and streamlined.

In this context, hiring generalists who can bridge the gap between product and engineering becomes increasingly desirable.

Second, the golden age of DevTools has arrived.

The landscape of tools available today for software engineers to quickly design and develop new products is staggering compared to what existed ten years ago.

Back then, you needed specialist engineers at every layer of the stack. Building and maintaining a few HTTP services required a team that could own delivery of those services, often rolling out their own observability infrastructure. The same was true for any complex, interactive frontend products, where toolchains were far more complex and brittle than they are today.

Web-based design tools, cloud FaaS platforms, edge deployment networks, off-the-shelf observability platforms—all these tools make it so that a very small team of generalist engineers can accomplish what would’ve taken dozens of people in the past.

Smaller companies simply don’t need to focus on infrastructure as much as they used to. Of course, all the companies that provide these platforms need to be healthily staffed with specialist engineers who can build and maintain them.

But even at DevTools companies, who’s better suited to empathize with customers and users, and help prioritize development, than product engineers?

Lastly, I’ll call out the rise of LLMs as a final tailwind.

Some people speculate LLMs will enable the creation of autonomous agents that can replace all sorts of human labor. If that happened, it would certainly allow generalists to accomplish more with less effort, but I’m not banking on this speculation to pan out.

Rather, I think LLMs as they exist today can already help generalists ramp up on new topics quickly.

Research about the impact of generative AI on productivity (1, 2) has shown that using LLMs provides a greater boost to workers who are less experienced at a particular task, while experts see more modest improvements, if at all.

This makes perfect sense. LLMs are uniquely suited to helping people learn about new topics, as I’ve written about previously.

Part of what makes specialist engineers valuable is the esoteric knowledge specific to their niche—the vocabulary, arcane workflows, and ability to debug cryptic error messages that can frustrate a newcomer.

But recently, whenever I’ve encountered technical roadblocks with a new programming language, framework, or library, it’s been easy to get myself unstuck thanks to GPT-4. The implication is that it’s easier than ever for generalist product engineers to ramp up on new subjects.

I’ll caveat that inexperienced engineers could end up naively copy-pasting something GPT gives them without understanding its full implications. In some ways, LLMs could hinder junior product engineers. I don’t think LLMs will replace the need for mentorship or allow junior developers to learn everything without human guidance.

But if you think of LLMs as an infinitely patient copilot who you can ask your dumbest questions to when you’re getting started on something new, then the productivity benefits are clear: generative AI can help you get to a point of basic competence in new domains independently. This disproportionately benefits generalists.

---

What would it look like if companies fully embraced product engineering? I think it would mean...

• PMs bringing engineers to interact directly with users and customers as a standard practice.
• Engineers ensuring that the software they’ve built is creating value in the real world—never just implementing a feature and throwing it over the fence.
• Hiring processes that capture a candidate’s full spectrum of abilities, weighing product and engineering skills equally.
• Engineers taking product management seriously as a discipline, and treating it as an exciting way to progress in their careers.
• Structured learning opportunities for junior product engineers, so that the next generation wouldn’t have to struggle through all this alone.

Truthfully, I think a number of companies have already operated in this way for a while, just without using the “product engineer” term. This is often what's going on when a company says they “don't need product managers.” If that's the case, does it matter what we call the role?

I think accurately describing what people are really doing is crucial to resolving the weirdness in hiring, management, and progression that’s existed so far. And it’d reduce the feeling of isolation that people like me have had to deal with.

If nothing else, I think it’s high time that product engineers do more to connect with and support each other. In that vein, if this post resonated with you or you’d just like to get in touch, please feel free to reach out to me.