The Product Marketing Engineer
Birth of a new kind of software engineering
This article stems from a conversation that we come back to from time to time. A conversation around the idea that software engineering is changing, and it increasingly requires that teams have a deep understanding of the business side of things as much as they do the technical aspects.
This happens because software development is no longer an isolated practice. What was once a self-contained, somewhat obscure discipline that occupied a select group of initiates, is now a core pillar of our modern lives and is rapidly becoming the most sought-after talent in the world. So much so, that virtually every business, in some way or another, relies on software and information technologies to exist and operate.
Nowadays, technological products and services originate on both sides: engineers create and offer them to businesses, and businesses actively generate demand for software products to address their specific needs. This situation gives birth to a communication problem: engineers and businesses speak different languages, aim for different goals, and often have different views on what is important when it comes to designing and building software tools.
Middle ground to be claimed
A useful framework to get into this conversation is the one proposed by Kenton Kivetsku, former Googler and founder of RocketBlocks, who in this video explains the difference between the role of a Product Manager (PM) and a Product Marketing Manager (PMM).
For the purposes of this article, let’s get rid of the names he uses for these two roles, and explore the general idea of product management tasks and responsibilities that range from being more customer-focused or rather more engineering-focused.
Kivetsku lays out a spectrum where Customers and Engineers sit at opposite ends. As we near either one of those ends, we find that tasks and responsibilities get more tactical in nature, into the specific realm we approach. On one end, tactical action focuses on the engineering side of things (building an infrastructure, developing features, deploying services), while on the other end, they progressively focus on the customer-facing side of the business (understanding customer behavior, designing experiences, spreading the word).
The interesting part, as you can see, is right in the middle. Strategic efforts are not something that can be carried out by an isolated team or manager, but are rather a joint venture that can only be successful when it aligns the goals of each team and the organization, drawing a line that ties the hardcore technical aspects directly with customer needs.
This is key: whenever strategic decisions are made leaning too heavily to one side or the other, products suffer.
A graveyard for apps
Back in 2009, Apple debuted a TV commercial for the iPhone with the catchphrase “There’s an app for that”. There was such buzz around the idea, they were even granted the trademark for it a year later. And everyone jumped on that train.
Not long after, though, it became apparent that, unless you had some sort of leverage that made your app indispensable, there was a slim chance that anyone was going to download it. That is how we found out that the lesson from the dot.com bubble was not properly learned.
Have you ever visited the App Burial Grounds? My guess is you haven’t. Firstly, because it is not a real place, and secondly because no one ever goes there. That’s why the very idea of an App Burial Grounds exists in the first place: there lie the apps that no one ever visits.
The majority of the apps that were conceived during the ‘there’s-an-app-for-that-fever’ now rest in the App Burial Grounds. Why? Because they were ill-conceived, created with the wrong thing in mind. Those apps that now forever rest unvisited, were conceived as solutions in search of a problem.
We’ve all heard stories of engineers who fall in love with a technical feature that no customer resonates with, or product marketers who envision dreamlike experiences for customers that are either technically non-viable or impossibly expensive.
This is what happens when strategic decisions are made on tactical premises.
Rise of the Product Marketing Engineer
To address these strategic decisions around technological products, a new figure arises.
Where Product Engineering is responsible for developing the product and keeping it operating, and Product Marketing is responsible for representing the customers interests within the product team, the Product Marketing Engineer (PME) is responsible for providing a comprehensive and strategic view of the relationship between product and customer that encompasses the full arc: their function is that of seeking balance between feasibility, viability and desirability.
The Product Marketing Engineer combines long-term business vision, a deep understanding of user experience and empathy for end customer needs with a solid understanding of the principles of software architecture, an operational knowledge of every stage in the development process and a basic grip on the math behind effort estimations.
Most teams (the good ones, at least) already bring all of these skills to the table and perform the bulk of the PME’s responsibilities as a whole. But something always gets lost in translation.
Instead of relying on different people, with different pieces of a puzzle, who have to assemble it each time, a Product Marketing Engineer has the skills to form a complete view of the puzzle in their mind, and can act as a natural interpreter. They ease the back and forth of ideas, reduce communication noise and make sure there are no inconsistencies or blind spots in the team’s conception of the problem to be solved and the array of potential solutions to be developed. Of course, this needs careful follow-through and lots of communication in order to scale.
The road ahead
Software is not what it used to be. While the quality of the code and the elegance of the solution is still a hallmark of a good engineer, the context in which they operate is very different. Design, UX and accommodation to customer needs are now an integral part of software development, and pivotal to its success.
The best way to make sure our endeavours steer clear of the App Burial Grounds is to invest in strengthening the link between engineering and customer satisfaction. Or, put in other terms, the link between our tools and our goals.
Until not too long ago, development teams fulfilled these functions as a collaborative effort: some of the people in the team took care of the engineering, and others took care of the customers. They met halfway, discussed and agreed on how to move forward, and organized the work around those agreements.
Today, a Product Marketing Engineer takes over the responsibility of orchestrating the efforts of a whole team, covering the full span of devising technically robust products that delight customers, and facilitating collaboration during the product development process, freeing everyone else to focus on their specific roles.
In the near future, most members of the product team will have the PME’s skillset, as it will be hard to overlook the relevance of incorporating a new role that is capable of orchestrating strategic decisions around the product.
Why not get a head start today?
Originally published in the Manas.Tech blog
