Product engineers

We had just finished a customer conference and on a long, 14-felt-like-18 hour flight from San Francisco back to Sydney. I was sitting next to Jean-Michel Lemieux (“JML” ), our head of Engineering at the time, and we were reflecting on some of the projects I’d worked on recently. The poor guy didn’t know how much I could talk.

We were discussing what made some of those projects successful. I can’t remember everything I rambled on about, but one of the things we landed on was that they all had just the right balance of team members. We were not talking about the perfect balance of job roles filled (like a product manager, designer, engineer etc..) fully staffed projects. We focused more on the different kinds of people, specifically engineers, we had on those projects. It wasn’t about seniority or tenure, it was about their style. A great mix of platform engineers, engineers who just found a way to get anything done, engineers who thought deeply about scaling, performance and so on….

One of those types of engineers I was attempting to poorly describe wasn’t a “traditional engineer”, but rather one who, to be quite frank, could effectively be a product manager. Going back and forth with JML trying to describe their attributes he jumped in: “Oh, you mean product engineers?”. To which I responded: “Product engineers? What’s a product engineer?”. I’d never heard of that term before.

JML went on to describe these characteristics of these product engineers, and I just found myself sipping a glass of red, snacking on some overly-stale United Airlines pretzels nodding in agreement as he went on to explain.

JML now works heading up Engineering at Shopify. In writing this post I reached out to him and asked him if he coined “product engineer” and how, in his own words would describe them:

“Doubt I invented the term, but I did use it a lot. As a young discipline we’ve spent a lot of time working out « how » to build software and that’s a big focus in schools still. But once you have the foundations, you need devs who engage with the « why » actively. Engineers who have a thirst for using technologies to leapfrog human/user problems. Those with empathy to reach for magical experiences. That is what defined a product engineer in my books... Bad product engineers cut too many corners but great ones know that minimum loveable products need the right depth to be considered during the build phase.”

Why should product managers care about product engineers?

Over my last ten years of product management, I’ve come to conclude that product engineers are a critical ingredient to helping you build a successful product, scale yourself and become a better product manager.

I firmly believe that one of our key jobs as product managers, especially in growing teams, is less about doing actual day to day product work and more about building a shared understanding with our teams. An understanding of our customers, their problems, the strategy and the opportunities we have.

In many ways, I’d argue product managers should always have a personal goal of working out how they could make themselves redundant (granted, one might never achieve it). After all, as Ken Norton described succinctly:

…“nobody asked you to show up” in the first place.

Let me be very clear: This isn’t because your time is “more valuable” than an engineers time. You’re not more important than others. This is fundamentally based on the belief that if you empower others with the context they can move faster, make better decisions, be engaged and help you scale the product craft across your organisation.

Characteristics of a product engineer

Let’s get into it. How do you identify and work with product engineers?

1. Strong opinions, loosely held

In contrast to an engineer who is always seeking a spec or asking for a detailed definition of what we’re building, product engineers will often come to you with an opinion on a particular item they’d like to flesh out more.

Your job as a PM: Because they’re opinionated, product managers will need to do more (than usual) work to earn respect and trust. This isn’t a bad thing at all. In fact, if we go back to our job of making ourselves redundant, anything which forces you to focus more on explaining why we’re doing something and how we measure success isn’t good just for our teams and stakeholders but ultimately we help our customers (by making sure we’ve done our homework).

2. Quickly build intuition

Product engineers have great instincts. They build intuition quicker than your average person. You’ll see them do this by taking a learning and immediately extrapolating possible implications for product. This, in combination with your engineering mindset of problem/solution, identifying common patterns and thinking about problems in abstraction helps them take something that might be qualitative and fuzzy and break it down to its first principles.

Your job as a PM: Giving all engineers (and particularly product engineers) direct exposure to customers is the single, most effective way I’ve seen engineers build customer empathy and intuition.

I’ve said this before, but we should never be doing customer research or interviews without our engineers. If you’re getting to the point where they’re telling you “I get it now, no need for more interviews” — you’ll know when to stop!

Something magical happens when an engineer experiences a “light bulb” moment for themselves. These moments aren’t achieved by sharing research reports, presentations or data. They’re often achieved by getting out of the way between the engineer and the customer.

3. Bring healthy conflict

Product engineers contribute to creating “healthy” conflict by considering different aspects of a decision and encouraging healthy debates and challenging the status quo. They’ll often be asking “what if we don’t do this?” and “is this really the most important thing we should be working on?”. They have an endless bucket of curiosity — seeking to get to clarity on a problem which you may have thought you already had well defined and understood (but you don’t).

Your job as a PM: Embrace this. They’re questioning the work, not you as a person. They’re helping you become a better product manager. Their desires come from the same place: to build a product that customers love. So next time this happens, listen. Ask clarifying questions. From my experience, almost every time, it’s not “them”, but it’s actually us. I’ve found these moments incredibly humbling. They’ve often pointed out a gap in our shared understanding, a better way of framing a problem, a bigger opportunity we’ve missed or a lack of clarity on a topic. Start by assuming they’re onto something, rather than seeking to defend your point of view.

4. Wizards at identifying (and minimizing work) on edge-cases

In contrast to some engineers who effectively see the many code execution paths and feel the urge to close them all off, product engineers often elevate the discussion to focus on the majority use case. They’re looking to spend all their efforts on the ideal journey — the path most taken. Their desire to focus on this means they spend their time on the most valuable thing.

Your job as a PM: Building product is all about making trade-offs. The best trade-off decisions are made by someone with the sound knowledge of effort vs value. As product managers — we know zero about effort. Our job here is to bring the knowledge of the value and frequency of use cases. Working with design in journey mapping and building a shared understanding of what journeys we are optimising for and why. Equip them so they know where best to focus their time.

5. An overflowing cup of quick wins

Every time I’ve said (or heard a product manager) use the phrase “quick win”, I cringe. I immediately think of a snake oil salesman. We’re always on the hunt for something to deliver customer value quickly, at a low cost.

There are two parts of this equation that make this work: First you have to understand the value, and second, you need to know what is low hanging engineering work.

Your job as a PM: Instead of spending your time trying to identify these quick wins, spend more of your time building a shared understanding of what customer value is. What’s the outcome your customers are trying to achieve? Let the product engineers, who spend most of their day living in the code, identify the low hanging fruit — they’ll do a much better job than we will.

6. Seek early feedback

Before writing any code, they’ll often be thinking about different ways to validate a concept, gather feedback and do a build-measure-learn loop. In contrast to an engineer who’s talking about building something robust (in terms of code), they’ll be looking to take as many shortcuts as possible to ensure the problem your solving has met its goals before entering a hardening phase.

Your job as a PM: Empower engineers to have direct exposure to those feedback loops. Everything from quantitive to qualitative feedback. You should be spending most of your time thinking about how you can optimize your bite-size deliverables for learning first, before refining and hardening the solution. A handy tactic we’ve had a lot of success with is to empower product engineers with responsibility to triage incoming feedback.

7. Great communicator

You’ll find most of these product engineers are naturally great communicators.

Your job as a PM: Get out of their way and find ways to help them shine. At Atlassian, for example, you’ll find a lot of our product engineers do a lot of internal blogging — sharing the what they’re working on, what the team has learnt or celebrate successes. Some practical ways you could help: encourage them to share their learnings, work on draft content alongside the engineers or give them opportunities to present to stakeholders.

8. Take decisions and own their backlogs

Product engineers are always seeking autonomy and fast decision making.

Your job as a PM: Stay away from the backlog. Seriously.

If you’re doing a good job at building this understanding with your team, they should have enough autonomy to take the day-to-day decisions on their own. If they’re relying on you to create items and drag that Jira card up and down the backlog, have a think about what context you’re not providing to your team. What can you do to empower your team to do this?

Closing thoughts

“I wish engineers spent less time understanding the problem and more time coding” — Said nobody, ever.

If we believe the opposite to be true then we need to ensure that our behaviours reflect this. Building a shared understanding should always be our primary goal as product managers. Do a great job at that and then get out of the way.

Thank you

I started writing a list of names — it was far too big and I kept worrying about who I’ve missed. So instead: a massive shout out to all the product engineers who have taught me an incredible amount, kept me accountable and been an absolute joy and privilege to work with.

Jan 2021 update: I gave a talk to some our internal engineering teams about this topic. If you prefer the video version with a bit more detail, here it is (you’ll have to excuse the #isohair):