The Product Engineer Era. Best practices and insights

Building software is no easy task. Each year, countless tools, frameworks, roles, and technologies are created. The mediums change, the "how" changes. But there’s one thing that never changes: you build software for people, digital products that users interact with.

And behind that product, there’s a reason, a purpose to fulfill.

It’s been 10 years since Martin Fowler's talk "Not Just Code Monkeys", but today it’s more relevant than ever. That talk changed my perspective on how software should be built and what I should do as a professional. It shaped a way of thinking that I extended to the Engineering team at Paisanos, which I currently lead. The key point: a software developer is not just a coding machine; they are a creative individuals that can contribute to the definition, construction, and measurement of a product.

You see, a software engineer by default is a natural problem-solver. They are constantly drawn to complexity, to challenges, and to the satisfaction of solving them. This complexity is deeply tied to technology, and thanks to their interest, incredible progress has been made. But what happens when this creative and disciplined problem-solving ability extends beyond the technology that must be used and reaches areas that intersect with broader impact? What happens if that engineer, with their characteristics, digs deeper into the "how" and starts to ask "why?"

This is where the Product Engineer comes in. A mindset, a role, a way of building software.

Before diving deeper into the role, there are a few things that are driving the increasing prominence of this role.

A little bit of context

Agents, LLMs and a lot of abstractions:

It’s already clear that we are all being augmented by tools and agents that help us define, design, and code. What used to take us days, we can now do in hours. Just a few days ago, OpenAI announced its o1 model, the first capable of "reasoning" and improving the accuracy of responses, which has dramatically increased the success of code generation.

‍

And if we look at the AI Landscape, the number of possibilities is endless. Tools like Supermaven, Cursor, or v0 are giving us a speed we never thought we’d achieve. All of this translates into a significant boost to the foundation of every professional: their productivity. And when productivity increases across a company, fewer roles and skills are needed to achieve the same objective.
This increase in productivity shifts our work from just coding to validating prompt outputs, improving them, and doing some tasks ourselves that require high complexity.
This is without even mentioning the constant abstractions being created, making it unnecessary to build things at such a low level. For instance, a few years ago, if you wanted to have an app, you had to learn Kotlin and Swift. Today, with tools like React Native or Flutter, you have platforms that provide identical performance while maintaining functional and visual consistency.
ll of this significantly affects how we build software. Not only do we have abstractions that allow us to do more with less, but we also have agents that speed up how we implement those abstractions.
‍

This leads to two possible paths: choosing deep hyper-specialization and becoming an absolute expert in one area to compete on par with an LLM or becoming a more generalist profile.
‍

‍

Outcomes Over Outputs

In recent years, the needs of the tech market have turned companies into Feature Factories—companies focused on building features rather than solving their customers' real problems. The excess liquidity in the market led to a focus on generating features as quickly as possible to achieve market dominance. This resulted in massive hiring or the search for talent with extremely high salaries to acquire knowledge.
Along with this, siloed frameworks or work methods emerged, where engineers were reduced to simple machines that took stories or requirements and turned them into code.
The current lack of money in the market now means that investments need to be safer, and therefore less risky. This requires adapting a work methodology where the output is not the only thing that matters, but the outcome. How are we going to achieve this business objective with what we deploy?

Focusing solely on outputs doesn’t guarantee that we’re delivering value. But by having our team focus on creating specific customer behavior that drives business results, we ensure they focus on the right solution and stay aligned with delivering value.

‍

Back to the roots

The software engineer in the '90s wasn’t just a coding machine—in fact, let’s not forget that the creators of Agile are engineers. Back then, we received the client's needs directly, built something, shipped it, saw the feedback, and iterated.
Today, companies like Perplexity, Telegram, and PostHog have very small teams that interact directly with their customers and are incredibly successful. Some, like Perplexity, have teams of 50 with only two PMs.

So, while technology and methodologies have matured enormously, the needs of companies make the software engineer of the '90s more relevant than ever.

‍

The Product Engineer

To start, I want to highlight two references that perfectly describe the role of a Product Engineer.

On one hand, in a job post from Incident.io, they mention:

"Care more about outcomes and impact than the exact implementation, or the tools used to solve the problem."

Similarly, a tweet referencing something one of the founders of ExtendHQ said:

‍

Basically, Product Engineers or "Product-Minded Engineers" are engineers with a deep interest in the products they build. They are people who want to understand how decisions are made, how people use the product, and they enjoy being part of defining the product. These are individuals involved not only in building actively but also in ideation, definition, monitoring, and continuous improvement, they are constantly seeking the impact of what they do.

If we look at the general way a developer works, most software developers focus entirely on the building and shipping stage. Their job, generally, is to take a definition, build software, generate an output, and repeat.

The Product Engineer, however, takes a step back and a step forward. They are involved in the end-to-end creation process—from when something is defined to when it is shipped and needs to be measured.

‍

‍

Product Engineering per stage

Think and Define: Know the why

The Product Engineer is different; they seek to understand not just the "how" and "what," but also the "why" behind decisions and the purpose of their work.

The first step in this shift is getting closer to the user—empathizing with the person who will use the product. Building empathy comes from direct interaction, without intermediaries, and using the product as if we were one of them. Products are more successful when those who build them are close to those who use them.

Currently, much of your user input comes through PMs or designers who have already spoken with users, creating a bottleneck. The problem is that this information is sanitized and lacks the full context and depth. Engineers may miss critical details that only they can understand or ask about. It's important to gather first-hand feedback.

Just as it's essential to understand users directly, it's also crucial to understand the business model—how the company makes money, what makes it profitable, the market, and the competition. A Product Engineer’s focus is not only on building but also on making decisions that impact both users and the business. To do this, we need to be well-informed.

This is incredibly important to mention because when we combine the ability to understand technological effort and trade-offs with an understanding of the impact that the things we build have on users, we gain a superpower. We can quickly map features on an impact-effort matrix to prioritize what should be released to users. Additionally, we can challenge what's been defined and propose alternatives that deliver the same impact but with much less effort.

Our main objective here is to take ownership of the roadmap and backlog, being the ones who help decide and define what will be built next.

You should divide your time between coding and product-related activities. Find the balance that works best for you—I recommend a 70/30 split (like the Argentine drink Fernet) or 80/20, with 70% or 80% dedicated to coding time.

‍

‍

‍

Build: End-to-end coding powered by AI

Product Engineers have the ability to build software end-to-end independently and autonomously, meaning both frontend and backend. Since it’s a generalist role, it’s important to rely on tools to improve workflow and productivity.

On one hand, AI tools like Cursor or Supermaven—now an essential part of the workflow—allow us to do pair programming constantly with a model that holds vast knowledge. This significantly boosts productivity to the point where some tasks almost become like hitting "TAB" until you need to correct something.

Another important point is for your company to invest heavily in devtools and foundations. It will be very hard to find time to understand the "whys" and analyze results if you’re still doing manual tasks that you shouldn’t be, like setting up infrastructure. Tools like IaC (Infrastructure as Code), for example, allow you to quickly and consistently deploy and update your infrastructure. EAS Build (for mobile) or Amplify (for web) enable you to deploy to stores or the web with just a simple push. Your pipelines and CI/CD process should be razor-sharp so you can start spending your time on things other than just coding.

Often, when we start transitioning into this role, we realize that we could save a lot of time by building a platform to increase our efficiency and effectiveness. Just imagine, if AI gives you a significant boost today, how much more you could optimize by automating the other processes that might create bottlenecks.

It’s also important to note that the complexity can be what really dictates whether you should focus more on being a generalist or a specialist. In fact, time can also be a factor that determines this, as dividing responsibilities can be something to lean on when the business needs to move a little bit faster.

‍

Ship: Experiments and rollouts

Something tied to what we discussed earlier about thinking and defining is that we can view the features we release as experiments on a small, medium, or large scale. And like any experiment, it’s not necessary to cover every case and acceptance criteria before releasing a feature, as this would slow us down. What we need is to release quickly and with direction, and then learn what we should improve.

For this, it’s important to have a solid CI/CD pipeline, which should be the default foundation for development, but you should also embrace A/B testing and feature flags. Both of these are extremely useful tools that will help you deploy experiments safely and continuously, with the ability to roll back quickly if something goes wrong.

Feature flags, on one hand, allow you to release a set of features to a subset of users, focusing on improving a specific metric. For example, you could release a new feature only to the top 30% most active users. As you see positive results, you can gradually expand the reach until doing a full rollout.
A/B testing works similarly, where you can direct different variants of the same feature to the same group of users and evaluate which is the best way to present the feature. This allows you to determine which alternative has the highest conversion rate and is most beneficial to the product.

There are many products that enable this. At Paisanos, we use Posthog, a Product OS that has everything necessary to implement this strategy effectively.

‍

‍

Measure and learn: Continuous learning cycle

A Product Engineer is customer-centered, and their main job is not just to build features but also to track the impact of those features on users.

If we release features without the ability to measure what happens, we're flying blind, with no visibility of the feature’s performance. It’s like driving a car at 100km/h blindfolded—eventually, you’ll crash.

Product discovery should be continuous. As a Product Engineer, it’s crucial to leverage tools like product analytics, surveys, interviews, and usability tests to feed into constant iteration and learning. Gaining insights from your users directly, rather than relying solely on PM definitions, helps you avoid bottlenecks. There are many tools for this. You can use Google Analytics, Hotjar, Amplitude, or more general ones like the previously mentioned Posthog. Additionally, don’t forget about system observability. Logs are important, as are your system metrics, and you will also pull data directly from the database when you need specific insights. Certain outcomes will point in this direction.

Your responsibility goes beyond defining, building, and shipping. You must also ensure everything is measurable, turning goals into a set of metrics that determine whether they’ve been achieved or not.

The idea is to build product intuition, and this intuition develops over time by going through multiple iterations of ideating, experimenting, prototyping, and analyzing the impact of everything you release.

Remember, products are more successful when those who build them are close to those who use them.

‍

Where to start

First of all, the culture and organization of your company may limit your involvement in certain activities (such as defining features). Remember, this role is not for every company, and some may simply not be ready for it due to the type of service they provide.

If your company is focused on generating impact and is relatively small or medium-sized, this role will likely improve how things are implemented. In larger companies, this role can be valuable as a bridge between product, engineering, and data teams.

If you're interested in taking on this role, here are a few tips that might help:

• Develop a product mindset: Start thinking beyond just code. Understand the bigger picture of the product you're building—its purpose, the problems it solves for users, and the business objectives it supports. Learn to care as much about the "why" as the "how." Start by asking the reasons behind certain definitions from PMs or designers. You can also join definition or analysis meetings as a listener. This is key to getting involved in the business context and understanding how your colleagues from other areas think.
• Get closer to your users: Regularly interact with users. Analyze their feedback, conduct interviews, and participate in user testing. The closer you are to the users, the better you’ll understand their needs and how to build features that meet them. Start by joining user interviews as a listener.
• Measure impact: Familiarize yourself with tools that allow you to measure the success of the features you launch. This could include requesting access to product analytics tools, surveys, or system metrics tools like Grafana or Kibana. Being able to track the impact of what you build is crucial for continuous improvement. Start simply by observing.
• Develop fullstack skills: Strengthening your fullstack development skills will give you the autonomy to work across the entire system—both frontend and backend—and manage features end-to-end. Start slow, choose a small feature you'd like to implement end-to-end, and raise your hand to start working on it.
• Embrace experimentation: Learn to treat each feature as an experiment or trial. Use A/B tests, feature flags, and other tools to iteratively release features, gather data, and improve based on real user feedback.
• Make time: Use tools that boost your productivity, like LLMs, platform-specific automation, and CI/CD pipelines. This will allow you to focus on higher-level tasks and ensure you’re not stuck with repetitive work. Remember, you should divide your time in coding time and product time.
• Continuous learning: Stay up-to-date with the latest trends in technology and product management. Learn about frameworks, methodologies, and tools that will make you a more effective Product Engineer.

Lastly, and most importantly, be curious.

Curiosity is the most valuable trait we can have as engineers because it opens the door to discovering things outside our radar. This constant discovery makes you a better engineer and improves your company.

Remember, we work 8 hours a day—some more, some less—and to truly enjoy what we do, we need to have a purpose. Try to make the experience more enjoyable and seek out the purpose behind the product you're building or the service you're providing. It will make your days more fulfilling and allow you to make an impact on many people around you and around the world.

‍

Thanks for reading.

Stay curious.

‍

‍