The Age of the Product Engineer
How the roles of product and engineering are converging in this AI-driven world.
If you’ve ever been involved with a tech company, you have realized that there is typically a tension between the engineering team and the product team.
Product is in charge of answering the questions “what are we building?” and “why are we building it?” whereas engineering is in charge of answering the question “how do we build it?”
As you can imagine, there can be a conflict of interest here. While product is focused relentlessly on the user, engineering is focused relentlessly on what is technically feasible.
Having some tension between the two departments is often healthy, as product has typically been the imaginative minds that push the limit of what the team could build, while engineering grounds that creativity with the real constraints of a business: timeline, technical limitations, scalability, etc. You want a product team that pushes boundaries, and an engineering team that knows where to constrain that boundary.
Product development cycles typically go something like this: product managers work to understand how people use the product and decide what will make a product more valuable (product discovery). They break this value down into features, work with designers to understand the user flows, and then boil the features down into a set of “requirements,” i.e. their vision of what the product should look like. The engineers give estimates of how long each requirement will take, the product team then goes and prioritizes the roadmap. At that point, development usually kicks off.
However, in reality, what happens? Several meetings later, a month after the idea’s inception, the engineering team has not made noticeable progress towards building the feature, asking product questions and clarifications throughout the process. It could be another month before the engineering team finishes the feature that was planned weeks ago.
The problem is that the exchange of information between product, design, and engineering is almost always inefficient. Having the arbitrary responsibility split of the “what are we building” vs. the “how will we build it” (i.e. product does product work and engineering does engineering work) is limiting for a tech organization. By placing your smartest people into cookie cutter roles, they lose context of the overall goals of the company and team, and how they can create value.
Product sometimes brings an idea to engineering, and the immediate groans of “this is an impossible task given the technical limitations” are palpable. It’s too big of a task to get done, and it’s probably not worth the time.
On the flip side, sometimes engineers see a very small change that can be made that either improves the performance of the system, or can easily fix a small bug that affects the user, but cannot get it on the roadmap because they cannot justify the business value to the product team.
In an ideal world, product managers should embrace the tradeoffs between technical complexity and user experience, and be okay with releasing a product that may not create the maximum user value, but creates value in a way that can be iterated on later. On the flip side, engineers should understand that sometimes it’s okay to develop something that is technically imperfect, especially for proof of concept ideas.
The delineation between product and engineering exists because traditional software development is slow and required a lot of people. Engineering is a means to producing the value in software. Product’s main goal is deciding what value to create. But what if there was a technology that could change this?
Enter AI-driven Development
Everything I described above was highly relevant for the past decade plus of software development. However, a big change has been thrown into this mix recently: AI.
AI is already great at writing code, producing documentation, and building beautiful websites.
Today, it is easy for someone with no engineering experience, such as a product manager to leverage AI to build a proof of concept app by vibe coding1. This will become more and more important in the future of building tech. Instead of writing requirements, product managers could instead spin up an early draft of the application or feature. This could become the first step of the development cycle, to prove out value quickly.
While these proof of concept apps can be built very quickly, vibe coded apps often have security holes, scalability issues, and cannot be delivered to users as-is. However, with AI in the hands of a seasoned engineer, it is easy to fix these issues. For example, a small bug may be hard for the product manager to identify and fix without understanding the working code, but someone who knows the technology can identify the root cause and patch the bug.
More broadly, with someone who has extensive experience with application architecture, it becomes incredibly easy to prompt AI to develop a whole system, complete with documentation and tests, tasks that took engineers a huge portion of time in the olden days. It is truly astounding how much quicker a good engineer can develop leveraging these AI tools.
I’ve always said coding is the least interesting part of a software engineer’s job. The more fun things are building the architecture, understanding how systems interact, and ensuring everything functions as a cohesive tech stack. By offloading the tedious coding tasks, it enables engineers to focus more high level on what they are building, rather than how they are building it.
So as non-technical product managers are able to build proof of concept apps using AI tools, and engineers are able to build complex applications even faster, development cycles will speed up.
Because of this, AI will enable founders to build more with a smaller team. While a founder in the days of old needed tremendous resources to start a startup, now they just need a few good people with a diverse skillset, while leveraging AI to its fullest.
I am of the firm belief that due to the advances in AI, we will begin to see small teams create an outsized impact on the world. Look at Cursor, the fastest growing SaaS company in the world. They built an AI-native IDE2 that allows engineers to use the full power of the frontier AI models. They built this company with 12 employees. OpenAI tried to buy them this week, and instead settled for buying Windsurf (another AI-native IDE company) for a cool $900 mil. Instead of taking Sam Altman’s money, Cursor decided to keep going on their own, raising another $900M at a $9B valuation.
Welcome to the Age of the Product Engineer
At the end of the day, the goal for tech companies is the same: to build a valuable product for their users. However, the time it takes to build a valuable product is significantly shrinking. The cycle of gathering requirements, deciding what to build, writing it down as user stories in a tool like JIRA or Linear, scoping, sizing, etc. only exists because it has historically taken so much time to develop products. But with smaller teams, less bureaucracy, and faster development, maybe we don’t need all of the process.
When each feature cycle gets shorter and shorter, and development gets easier and easier, maybe this decision of what to build next doesn’t matter as much. There is not as much weight on the outcome because instead of waiting two months for the feature to be implemented, you only have to wait a week. Or a few days. Or a few hours. At that point, the roles of product manager and engineer begin to converge more and more.
And soon, we will enter the age of the product engineer.
A product engineer is someone who is classically trained in software engineering, but has always had an eye out for how the product works. They understand how the workflows are implemented, or how features are used practically, and can prioritize their work not according to the “roadmap,” but rather the impact to the company.
Some of the best engineers I have ever worked with have been product engineers. They understand the business, understand the team’s goals, and understand the customers. They know what types of changes will be effective and useful, they listen to customers, and they prioritize the quick wins that will save time for the rest of the team. They understand that a big feature can be split up into phases while still delivering 80% of the value in phase one.
In the age of AI, these product engineers can have a much larger impact, because they both know what is easy from a technical perspective as well as what is valuable from a user perspective, and have the AI tools to be able to solve both, quickly.
The reality is that both skillsets from product and engineering are more relevant than ever. And the combination of the two is invaluable. Product managers will begin to vibe code and learn the fundamentals of development, building great proof of concepts faster. And they will still need engineers to help stitch it all together.
The engineers that will succeed in this new world will be the ones that not only understand the technology, but also deeply understand what they are trying to build. Product creativity, typically reserved for product managers and designers, will be pivotal for engineers. It’s no longer enough to be a software engineer. You have to become a product engineer.
I am personally thrilled to think about having smaller teams with faster development cycles, and collaborating across all functions of a company as a product engineer. It’s an exciting future, and I can’t wait to keep building.
Until next week,
Cory
Vibe coding is a new paradigm for development where someone does not write any code for their app. They instead prompt AI to build them an app that solves a problem for them. This method of building websites and apps has gotten very popular, especially over the past few months as AI models have gotten so good at development. Though a more apt name would be “prompt-driven development,” the term vibe coding was much stickier.
An Integrated Development Environment (IDE) is what software engineers use to write, test, and debug code.