1214 words

The Rise of Product Engineering

The concept of a Product Engineer is new, emerging in the last 2-4 years. In my view, the role is vaguely defined. When talking with other developers or product folks, there is this understanding of the power this hybrid role brings, but getting a clear answer on what defines a Product Engineer can be challenging.

Since I’ve been in a Product Engineering role—or something functionally similar—for half of my career, I want to take a stab at helping set the boundaries for what a Product Engineer is and what I would look for if I were hiring one today.

How we got here

If you don’t really care about the evolution of front-end development, and how I think it led to the creation of the Product Engineer role, feel free to skip this section.

In 2008, as I began web development, Front-End Developers focused on HTML, CSS, and occasionally wrote Javascript, often relying on popular libraries like jQuery to get the job done. You were expected to have some graphic design sense, and your tasks were mostly building pixel-perfect, interactive versions of what a “real” web designer came up with in Photoshop. JavaScript was often reserved for specific use cases like forms or photo carousels. The ideas and capabilities of Web 2.0 were still nascent, so complex data structures on the front-end weren’t as prevalent.

As we got into the 2010s, the web began demanding much more robust, interactive and app-like interfaces. Stuff like Backbone, Knockout, Angular and EmberJS really raised the bar for what was possible for Front-End Developers. There started to be a lot more emphasis on Front-End Engineering, where the role demanded strong Javascript foundations, a deeper understanding of data structures, algorithms and baseline comp-sci knowledge. CSS and HTML became somewhat of an afterthought. Especially for junior folks starting up in the mid-2010s. The “old guard” of Front-End Developers ended up splitting into two camps: those that adapted and dug into javascript and interactivity, versus those that shifted towards product design roles and had strong CSS skills.

In the mid-2010s, the “Full-Stack Developer” role started popping up. This role targetted people comfortable working between the back-end and front-end of web applications, furthuring the idea that front-end development was becoming more respected as an “engineering” discipline. But this shift had a tradeoff; good product/design sense became less of a requirement for Front-End Engineers. The expectation was that the product/design thinking would be delegated to product designers, UX teams and product leaders.

Today, engineering, product and design leaders are starting to see the importance of having Front-End Engineers with solid product/design sense in their teams. By having someone in your team with this overlap of skills, you gain strong product/design/engineering cohesion.

So, what does that role look like?

Framing the Product Engineer role

I see Product Engineering as a hybrid product/design/engineering role. One where the floor is strong competence in each discipline, and the ceiling is mastery in one. It’s also an archetype that requires exceptional communication.

The Product Engineering archetype cares strongly about building something that positively impacts end-users. Their goal is to balance business, end-user and engineering needs. They have compassion for user problems, and actively want to integrate themselves into the design process.

Writing it all out seems like a lot of responsibilities. Speaking from lived experiences, it absolutely can be! How much you deal with is directly proportional to the size of the team(s) you’ll be on, however. In smaller teams, you’ll be filling the seats not already filled (which can be one or many). In larger teams, you’ll execute in one domain (maybe two) but have strategic influence in others.

For anyone looking to hire a Product Engineer, invest time figuring out which skill-set distribution you need on your team. It can be really easy to put out a job post looking for someone equally competent in all three disciplines (product/design/engineering), but that will probably come back to bite you in the ass. Below are team dynamics I’ve encountered and how I’d go about balancing them with a Product Engineer.

If your team is engineering light but has some product leadership, get yourself a Product Engineer who is more of a full-stack engineer with a solid understanding of product/design principles.

If your team has strong engineers but is product-light, find a competent engineer who can pick up work when needed on your front-end but who can spend most of their time helping with product strategy/processes.

Becoming a Product Engineer

Stepping into the shoes of a Product Engineer is like navigating a vibrant chaos. It’s a hybrid product management and engineering role with some design thinking principles weaved throughout it.

If you come from a product management background, read about design thinking and practice front-end development. Spend time learning about systems design once you’ve got a decent grasp on building things yourself.

If you come from a product design background, make sure your UX skills are sharp, refine your product sense and start learning—or dust off—your front-end skills. Learning how to prioritize work and understanding market/user research will need to happen eventually, too.

If you come from an engineering background, learn about design thinking (you’ll be surprised at how similar to engineering it is), and pick-up some books on product management, UX design and behavioural psychology.

A great way to expose yourself to these ideas is to surround yourself with people in the discipline you want to learn more about or feel weakest in. Start by chatting more with the people on your team in those roles. You can go to meetups or events and listen or get involved and tell people you’re interested in learning more about what their jobs are like from their perspective.

In my opinion, you’ll succeed in this archetype if these statements apply to you:

  • You’re curious about “the why” behind people’s decisions
  • You care about someone else’s experience using the thing you’ve created
  • You want the impact of your work to not just be measured by how fast it runs, or how cleanly architected it is, but by how it affected people’s lives
  • You enjoy working closely with product managers/leadership, other engineers, product designers
  • You have opinions about what should(n’t) be built, and more importantly, why it should(n’t) be built
  • You care deeply about communication as a skill, and it’s something you’re constantly trying to improve upon
  • You see how design thinking can be applied to engineering, and how engineering principles can be applied to design

Some resources

This is by no means an exhaustive list! It’s just a few books that I’ve found have helped me immensely in my career. I’m also someone who comes from a visual/engineering background, so my list covers a lot of product and design thinking more than engineering!

The most impactful thing, in my opinion, is trying to work closely with the disciplines you want to skill up in at your current job.

The books

The Amazon links are affiliate links. So, if you’d like to support me in some small way, feel free to use those links. Otherwise, click the link that takes you to the book or publisher’s website :)