How to Become a Product Engineer 🎨
A practical guide that includes technical workflows, responsibilities, and psychological tricks.
A couple of months ago we explored how engineering is changing, discussing the trend towards more technical managers and more autonomous engineers.
This shift is giving rise to a new breed of software engineers: the so called product engineers.
In this brave new world, product engineers own entire features, from analysis to post-launch iteration, bridging the gap between a PM and a traditional developer.
I am writing about this trend pretty often, because I believe it is supremely important: today, only a handful of startups work this way, but a few years from now, once AI is everywhere, this will likely be what is expected of all engineers.
But what does product engineering look like in practice? What are the workflows that enable this shift?
Today’s article addresses it from a very practical angle, covering how the best teams are building product, and what engineers and PMs respectively do over the whole feature lifecycle.
The goal is to give you a blueprint of what a product engineer looks like, what they do, and how to turn into one.
Here's what we'll cover:
🚀 Why now? — a quick recap of the rise of product engineering, its benefits, examples, and why it's happening now.
🔄 The product engineering workflow — the core responsibilities and workflows of a product engineer, including feature management, data-driven development, and collaboration with PMs and customers.
🏋️♀️ Overcoming transition challenges — addressing the hurdles you might face when becoming a product engineer, including expanding your skillset, balancing responsibilities, and finding support.
Let's dive in!
To write this piece I am partnering with Rasmus Makwarth, founder of Bucket and ex Director of Product Mgmt at Elastic. Rasmus is one of the most knowledgeable people I know about product, and is at the very forefront of this shift with Bucket.
I am also a fan of Bucket itself, and I encourage you to try it, but as always I will always write only my unbiased opinion about all the practices and services covered in the article, Bucket included.
🚀 The Rise of Product Engineers
Today’s push for product engineers fits a broader trend in making product / tech roles wider and giving people more ownership and autonomy.
So, in a way, product engineers are to engineers what product managers are to product owners.
In traditional Scrum, product owners have mostly tactical duties: they groom the backlog, manage tickets, and deal with short-to-mid-term execution. Today, in healthy teams, a lot of these tasks are delegated to engineers, while product people (PMs) take on more long-term & strategy thinking.
So we gradually went from this:
To this:
This trend is not exactly new — here is how Intercom defined product engineers back in 2022:
As a product engineer, you'll be taking ownership of real customer problems by building smart, efficient solutions to both back-end and front-end systems.
The key part here is full ownership of customer problems — that means, designing a solution + dealing with the whole stack.
The benefits for teams are obvious. Fewer people involved + more vertically integrated equals easier coordination, higher engagement, and higher impact per single engineer.
Today, this trend has only accelerated thanks to AI and better tooling, which together reduce engineers’ cognitive load, and allow them to take on more things on their plate.
Still, it’s a brave new world, and we are still figuring out a lot of stuff: what does a new feature lifecycle look like? How do you bridge engineering and product work so that PMs and engineers work well together?
In other words, what does product engineering look like, in practice?
Together with Rasmus, we discussed the traits shared by the best product teams we know, and we isolated two main ones: adoption of data-driven development + a well-defined feature management workflow.
Let’s look at both:
📈 Data-driven development
There are various types of product metrics that can be used to inform decisions throughout the feature lifecycle. They also differ between different kinds of products, like B2C vs B2B, or SaaS vs e-commerce.
A useful general model, to understand the responsibilities of PMs and product engineers, buckets metrics into two categories: leading vs lagging indicators:
1) Lagging indicators ⬅️
Lagging indicators are outcome metrics that capture the ultimate success or failure of past actions, like revenue, customer churn, or MAUs.
They are typically easier to measure — i.e. via product analytics tools — but harder to influence directly by a product team. Also, they change more slowly and are often only measurable after a significant period (hence lagging).
2) Leading indicators ➡️
Leading indicators are input metrics that predict future outcomes.
They are usually harder to identify and measure accurately, but easier to influence through current actions. They also change more rapidly, allowing for quick feedback and iteration. Examples are measuring a feature’s adoption or specific actions that reveal engagement.
Famously, Facebook used to track how many users added at least 7 friends, and how fast they did so. They figured out it was a reliable leading indicator for long-term engagement.
So, the key differences are about three areas:
⏱️ Timing — lagging indicators show what has happened, while leading indicators suggest what will happen.
🏃♂️ Actionability — leading indicators are more actionable in the short term, while lagging indicators often require long-term strategies to change.
🎲 Certainty — lagging indicators usually provide more certainty about outcomes, while leading indicators offer predictive power but with less certainty.
Why is this model useful? Because it’s a blueprint for how PMs and PEs can organize their responsibilities:
🔧 PEs mostly focus on leading indicators — because they are more actionable and enable fast course correction.
🎨 PMs mostly focus on lagging indicators — which are closer to business and strategy.
🔄 Feature management workflow
Building on the understanding of leading vs lagging indicators, PEs and PMs can employ precise workflows to roll out, test, and iterate on features.
These workflows have three main components: 1) controlled rollouts, 2) experiments, and 3) monitoring. Let’s look at all of them:
1) Controlled rollouts 🚦
PEs use feature flags to release new features only to a subset of users, to get early feedback and measure impact.
This helps in monitoring leading indicators (e.g., initial user engagement) before affecting lagging indicators (e.g., overall user retention). E.g. releasing a new UI to 10% of users and comparing their engagement rates to the control group.
Feature flags are also useful to speed up your delivery, make rollbacks easier, and all kinds of good things.
2) Conducting experiments 🔬
Having reliable leading indicators + a good feature flag infrastructure allows you to run good A/B tests.
You can compare different versions of a feature, roll them out to different groups of users, and make data-driven decisions. E.g. you can test two different onboarding flows and measure their impact on new user activation rates (leading) before seeing effects on user lifetime value (lagging).
A/B tests are not the only way to run experiments. In fact, to be statistically significant, they need a good volume of data, which is not always available. Think of a B2B SaaS setting, where you have a few customers, or the checkout page of an e-commerce, where only (e.g.) 5% of your users ever get to.
In these cases, you want to measure feature adoption and retention, as well as gather qualitative feedback from relevant users, like those who tried the feature but churned.
Screen recordings are another way of making sure that features are used as intended and are not confusing customers instead.
3) Measuring outcomes 📈
Post-launch, product engineers closely track both leading and lagging indicators to assess feature performance.
They set up dashboards and alerts for key metrics, so they can iterate based on real-time data.
Example: Tracking daily active users of a new feature (leading) while monitoring its impact on overall product usage and revenue (lagging).
🏋️♀️ Overcoming challenges in the transition
Transitioning from just writing code in your IDE to owning customers’ problems is not straightforward.
Product engineers I spoke with did so gradually, often helped by a good manager and supporting peers. I believe there are three challenges you should address:
1) Expanding your technical skillset 🔧
As a product engineer, you'll likely need to expand your tech chops. This includes full-stack development, data analysis, and feature management tools.
To achieve this, move gradually. Take on tasks slightly outside your comfort zone, starting with small full-stack features, and possibly pairing with colleagues who have complementary skills.
About data analysis, my best advice is: just pair with your PM. In most cases there is no need to do courses or learn fancy statistical notions. Start with the basics: explore with your PM what success looks like for new features, and how you can measure it. Your engineering mindset is your friend, and chances are you will ramp up rapidly.
I have also found it extremely useful for engineers to just sit on customer calls, to learn what the customers are struggling with in the product. Start by sitting in on calls about specific problems / product areas you own, or related to specific support tickets.
Finally, create a feature management workflow to automate your work: invest in good tools that include feature flags, A/B tests (and in the case of B2B, SaaS metrics, feedback collection, screen recordings), and monitoring.
2) Balancing technical & product work ⚖️
One of the biggest challenges for product engineers is juggling the various responsibilities that come with owning full solutions. You may be unsure about how you should spend your time between coding, measuring, designing, and more.
Here is what has worked for others:
⏱️ Use time-boxing — allocate specific time slots for different types of work, to ensure you don’t neglect either aspect of your role. Possibly start your day with your most important product-related task before diving into coding.
🗳️ Ask for feedback — make sure you receive plenty of feedback about how you are doing. Ask for it intentionally, all the time. This is supremely important to 1) course-correct early, and 2) not let impostor syndrome kick in.
🏃♂️ Win your resistance — you might face resistance from yourself (or others) to non-coding tasks. This is normal and it will take some time to go away. Some advice: 1) stop thinking about yourself as a technology builder, but more as a solver of customer problems. 2) Reframe product activities as crucial for writing the right code. 3) Keep a journal and write down success stories where your non-coding activities led to significant improvements in product outcomes. And share these stories with others.
3) Building a support network and finding mentors 🪴
Transitioning to a new role is easier with the right support.
Look for experienced product engineers in your company or industry and reach out for informal mentorship or regular catch-ups. Then do the same with non-technical peers: seek out product managers and UX designers who can provide different perspectives. Join online communities (😇) and local meetups.
Set aside time each week for continuous learning. For product, my best preferred ways of learning are:
📬 Reading a good newsletter — like Lenny’s.
🔨 Growing a side-project — that forces me to own all the parts of the stack, from growth down to coding.
Becoming a product engineer is a journey, and nobody expects you to ace it on day one. Embrace the challenges as opportunities for growth, and don't hesitate to seek help when needed.
And that’s it for today! See you next week 👋
Luca
I want to thank again Rasmus and the Bucket team for partnering on this. Their ideas about product metrics and the whole feature management workflow where invaluable for shaping my opinions, and this piece.
I am a big fan of what they are building. You can start using Bucket for free below 👇