The new title “Product Engineering” has gained a lot of traction, and I’ve been really confused why it’s gaining popularity. I think I’ve been able to figure out how to express my opinion.
Software engineers are observing that their role in software is evolving due to LLM tools. But how the job is evolving is the question that everybody in the tech industry is trying to answer. As such, a group of software engineers are trying to answer that question by saying software engineering needs to evolve into a new role called product engineering. Simply put, as far as I understand it, product engineering is an engineer trying to address customer problems in a direct way. By this definition, it seems that there is a presupposition that software engineers weren’t solving customer problems originally.
It means your future hasn’t been written yet. No one’s has. Your future is whatever you make it. So make it a good one, both of you.
Doctor Emmett “Doc” Brown
And so I take issue with this position to evolve the role of a software engineer into a product engineer. Being a product engineer ought to still be highly dependent on a technical skillset, and I am afraid that high LLM usage means technical skills will atrophy. The responsibilities of a software engineer are already highly diverse, so adding more roles could hinder software quality. Additionally, I believe that answering customer questions as a software engineer already existed, and there isn’t a need to redefine it. Extending the role of a software engineer into product management will create confusion with product managers. With these previous points, I honestly feel that the attempt to rebrand software engineering as product engineering is just a meaningless distraction from something that already exists.
Disclaimer going forward. I recognize that the reasons I stated are still highly dependent on situations, and I will explain those situations later. As well, I recognize that LLMs are changing the work in great ways, and knowing how to use LLMs still remains in question.
Skills Atrophy
I am a bit surprised by software engineers who proudly profess something along the lines of “I haven’t written a single line of code in X months!” I am also surprised at other software engineers who joke that they don’t remember their way around a code editor anymore. If something that was a basic tool for a software engineer is being forgotten, should that not be a warning for technical skills atrophy? There already are studies that warn of skill atrophy with LLM use. So, if somebody isn’t maintaining their technical skills, I don’t think it is going to serve any customer to be a product engineer while one’s technical skills are being forgotten.
Diverse Responsibilities
I’m at a job that already requires every software engineer to do engineering, testing, quality control, extensive broad documentation, and dev-ops work. This probably could be the jobs of 2–4 different people, but, for reasons that I don’t know, engineers are required to do all those roles. Because software engineers are required to do all those roles, I firmly believe that software quality is lacking at my job. Where there are too many responsibilities for a software engineer, a software engineer is not given the time to deep dive into technical topics that could improve software quality.
Trying to do all those roles at my job is yielding extensive support problems. It’s virtually every other week that my group is stalled from deploying anything because we have so many major incidents that happen. I am so certain that if roles and responsibilities were defined more clearly, then my group wouldn’t have so many major incidents occurring. Granted, this is at my job, but I think this situation would hold everywhere there are many responsibilities to manage.
If I am told to be a product engineer, that is another responsibility to fill as I struggle to maintain quality of code anyway. Giving more responsibilities to an engineer to fulfill is going to be counterproductive, because an engineer’s attention will be divided among all the things that have to be done.
Blurring Lines
Let me get it out right now: LLM technology is just aggravating the relationship between engineers and product managers more, and it may already be a tense relationship. I can’t think of a product manager working relationship that I’ve had that was reasonably good. There always has been a professional tension between product managers and engineers, and it often needs special care to not aggravate. If I am to be a product engineer, what’s stopping project managers from becoming product engineers too? That may not be a good thing.
Engineers aren’t trained product managers, and neither are product managers trained engineers. I have to correct product managers all the time when they try to be too engineer-y. I simply tell them something along the lines, “Just so you know, when you say X to an engineer, it means something that you’re not intending.” And I totally expect the same thing to happen in reverse. A product manager would probably chuckle at the attempts of an engineer trying to coordinate all the details required to advance a product.
Side Notes
Don’t we already have a role that stands in-between an engineer and a product manager called a product owner? From what I’ve looked up, a product owner is the one responsible for interpreting the product requirements into technical details for the team. A product owner is usually an engineering team member of significant experience that can talk with a product manager clearly. I don’t think there is a need to reinvent this role.
The only example I can think of where “product engineering” might be a thing is startup companies. Engineers in a startup are naturally going to have to wear multiple hats. Even then, why invent a new title for something that is probably already understood? However, at bigger companies, there have to be more distinctions on where responsibilities are (hopefully). Things could potentially be more streamlined at bigger companies and allow for higher quality software.
Conclusion
I believe that “Product Engineering” is not promoting something new or novel. It seems to be a new word for something that already exists. Engineers are still going to have to engineer solutions and retain engineering skills, because an LLM still needs a prompt to know what to make. Engineers could already have too many responsibilities to be concerned about any additional responsibilities. Adding more would just add to engineer burn out. Product engineering isn’t going to help the relationship with product managers, I see it increasing the tension of that professional relationship. Being concerned, in a technical way, for customers should already have been something engineers were doing. There is no need to submit a redefinition.