Product Engineer

In a previous job I was onboarding a senior product person. I complained that some important task shouldn’t be mine to do. The senior product person said, in effect,

“Douglas, get over yourself. You’re in product. Make the business successful - that’s what matters.”

That compass stuck with me.

What does a product engineer look like?

“Product-oriented” engineers aren’t better, but they are different - in their motivations, skills, and experiences. Product-oriented engineers prioritize business impact at the cost of working on less “technically interesting” problems. They end up making product decisions, especially the small details.

When I look at an engineer’s resume, I look for prioritizing impact over working on interesting tech. Here are some indicators:

When I interview engineers, I use this question to see how “product-oriented” they are:

How do you prefer to get specifications for the things you have to build?

There’s no right answer - it’s a spectrum. For example:

  1. Do you prefer to get user stories from a PM so you can focus on architecting and building the solution?
  2. Do you prefer to get high-level requirements from a sales-person so that you can work with them to turn it into specs?
  3. Do you prefer to get raw feedback from end-users so you can figure out and prioritize what features to build?

Where do you fall on that spectrum? Can you give examples?

A “good” answer is when the candidate matches what the team needs. A product-oriented person might have a bad time solo refactoring a data pipeline. Someone on the other end of the spectrum may struggle on a user-facing team without a Product Manager.

An “experienced” answer sounds something like, “I’ve done them all. I’m best at #3, prefer #2, and avoid #1.”

Story #1: My mistaken investment (click to expand)
Healthcare systems in a foreign country? Doctors, nurses, hospitals, gp practices, rota management... I worked in this company, but I had no interest in this domain.

I wanted to improve transferrable skills. I expected product managers and designers to hand me specs, so I could focus on architecting and building. That kinda worked out, but when our team met the cofounders for strategic discussions, I couldn't contribute much. I could estimate the effort involved in building a mockup, but I couldn't propose an alternative with 2x value at 0.5x cost. Others could smell my lack of enthusiasm for the business - especially the cofounders, who lived and breathed it.

Your colleagues want you to care about the team and company. People who care want to work with other people who care. When you prove your investment in the business, others will reciprocate, investing more in you. I could have accelerated my growth in responsibilities and position if I displayed more enthusiasm for the product and business.

Five years later, here I am working in that same business domain and a different technical one.

Story #2: Maximum productivity: a product team of one
I once kicked off a project composed of just one engineer and the users of a narrowly-scoped service. We set the goal to be, "make the most impactful improvements possible within five weeks."

The developer onboarded to the problem space as and when needed. The users and developer prioritized ruthlessly. They met ad-hoc every couple days to review the latest iteration and reprioritize. They shipped and shipped.

The entire problem space, solution space, priorities, and project plan lived in the brain of one person. There was little-to-no communication overhead, waiting, or blockers. It was an exceptionally productive and fulfilling project for everyone involved.

Story #3: Product engineers without product context
I once joined a team that needed its engineers to behave like product engineers. They didn't.

The developers only met with their users when directed to, even though their users worked at desks a few meters away. The developer team waited for decisions to come from product managers and designers. The service they worked on was just a piece of a much larger product, about which they had little context. Decisions happened to them and they weren't in control of their future. Their projects went off-track and got cancelled. They often built the wrong thing, and how could they know what the right thing was? They barely grasped the much larger puzzle they were a part of.

Of course, these circumstances came from mismanagement, blitz-scaling, and recent bad experiences - not the developers themselves, who were mostly new anyways.

The PM expressed that the developers were always invited to interact with users, but didn't really participate. During onboarding, I did some user interviews to build context. Afterwards, I seeded FOMO by sharing how I interviewed our users, gaining key information and relationships necessary to make better technical decisions.

One month in, my first project on the team was set to begin bridging two products. Over and over, the team resisted a solution because we had a fear of imagined risks. We ended up going down the "low-risk" path that incurred tech debt - we spent six developer-months on a project and didn't ship it. We scrapped the solution and we redid it properly later when everyone had sufficient context.

Thanks to Manon for reviewing drafts of this.

28 Mar 2021