Product Managers Need To Be Technical

In the 1930's the consumer "brand manager" role was created by Proctor & Gamble to manage consumer product lifecycles by studying, experimenting, and understanding the "voice of the customer". (Technically, they were called "brand men", but even though I'm a huge fan of Mad Men, let's not perpetuate the sexism.)  Brand managers didn't need to understand how a product was made. They just needed to understand what a customer needed the product to do and why in order to properly promote and sell it. (They were essentially the OG product marketing managers.)

In the 1940's, Hewlett-Packard refined the role to better-fit the technology industry and formalized the role of "product manager" to be the bridge between engineering and the customer. While product management became a distinct, formalized profession at this point, it remained in the engineering department, and most product managers were engineers who were moved closer to the customer to be their true voice in determining how a product should evolve to better-meet customer needs. In essence, the product manager was given decision-making power on 'what' engineering built (technical requirements) so that engineering could focus on technical execution ('how'), which is not to say product managers had no input into the 'how', but I'll get to this later.

During the rise of consumer software around the turn of the last century, software moved from niche technical tools (mostly B2B) to mass-market consumer products (B2C). Then The Agile Manifesto (2001) shifted the PM focus from writing detailed technical requirements to iterative collaboration & discovery. And then the "MBA Wave" in the 2010's saw the PM role evolve into a strategic business role, rather than a technical one (not in addition to). The impetus for this MBA wave was the sudden realization that a lot of existing product managers weren't strategic, which is absolutely necessary for the role. However, people seemed to think that technical vs strategic abilities was somehow binary, which is a ridiculous notion - it's as ridiculous as assuming a person's degree absolutely guarantees where their main aptitude lies. An MBA doesn't even guarantee that a person is strategic. It just guarantees that the person was taught strategic frameworks. (I also have the unpopular belief that you can't teach a person to think strategically. They either can or they can't. It's like teaching creativity - you can't teach it; you can only nurture it. But I'll unpack this later in a separate post.)

So at some point between the turn of the last century and today, a school of thought formed claiming that product managers did not need to be technical (and some even claimed that being "too technical" was actually a liability). I give this school of thought 0 out of 5 stars: do not recommend. I do actually believe that not all engineers make good product managers, but this has absolutely nothing to do with their technical aptitude, and that's where the confusion lies. Somehow the idea that being "too technical" meant someone was always way down in the weeds and incapable of seeing the big picture, but the ability to see the big picture (or not) has nothing to do with technical aptitude. In fact, some of the best engineers are super strategic and those engineers can make great engineers AND great product managers.

Ironically, the current rise of GenAI has led to the argument that PMs now need to be more technical due to the complexity of the technology. This is especially ironic due to the thought that GenAI will replace a lot of jobs, including those in software. If you read my post on who AI will really replace in tech, you'll notice that product management is the one software company role that AI will not replace, and the reasons for this has nothing to do with technical aptitude. In fact, I could almost make the argument that GenAI could potentially help bridge the technical gap a non-technical PM would have, but I honestly don't think it could because the tools to do this aren't out there. Yet. Regardless, the technical complexity of GenAI isn't the reason PMs now need to be more technical. They always needed to be technical. The new scramble to build AI stuff is just highlighting a need that always existed that has been masked by certain PM roles and the ridiculous notion that you can't be technical AND strategic.

For Early-Stage Startups, No Product Manager is Better Than a Non-Technical Product Manager

At a startup, every line of code is a precious resource. If the PM can't evaluate the opportunity cost of a technical shortcut versus a robust buildout, they will destroy engineering's velocity. A non-technical PM will also have difficulty effectively defining an MVP if they don't understand the technical implications of each feature. Defining an MVP includes assessing technical viability in addition to functional viability and then being able to make technical and functional tradeoffs to get to true MVP.  For an MVP not yet started, this also includes being technical enough to understand tradeoffs between different technologies themselves and how they affect not only the MVP, but the things you want to build post-MVP.  Technical PMs understand the underlying capabilities of the tech stack (or potential tech stack), allowing them to pivot the product strategy based on what the tech allows cheaply and quickly.

The 'Feature Factory' Culture

The non-technical PM era led to a 'feature factory' culture where PMs threw stuff over the wall at engineering without understanding the tech debt, scalability, or actual feasibility of what they were asking for. The wall itself was probably created because there was no opportunity for any meaningful collaboration. Engineering was the code factory that just built what product told them to build. But product and engineering need to be partners. Even the best product manager needs the sanity check that engineering can provide. A truly great PM wants an engineering team that will tell her when something she's asking for is ridiculous or won't work. Engineering should feel ownership over the product. An engineering team that feels no ownership will build shitty products, even (especially) if they do exactly what product management tells them to do with no questions asked.  This is why I firmly believe you should never outsource engineering, at least not for any net-new or core functionality, but more on that in a later post.

In B2B and SaaS, this willful ignorance of the tech stack that the non-technical PM movement promoted caused a bunch of unnecessary friction points:

• The credibility gap with customers: in B2B, users are often technical (admins, engineering, IT ops). A PM who can't speak their language, can't understand their workflows, or can't understand how to address API requirements and constraints loses the room immediately. Even for non-technical users, if a PM can't determine feasibility and/or give a ballpark LOE of a feature request in a customer meeting, they might not lose the room the first time, but they'll eventually lose it by the 3rd or 4th time it happens.
• The engineering 'black box': Non-technical PMs often treat engineering as a black box. If they don't understand how anything works, what they think is a 'simple' UI change might actually require a massive backend refactor. Then, when engineering tells them it'll take 5 sprints they aren't able to understand why, resulting in 1) probably thinking engineering is bullshitting them; and 2) not learning enough from this to avoid having this issue again.
• Discovery blindness: If you don't understand the underlying technology, you can't spot opportunities for innovation. Maybe that new infrastructure capability that engineering built for feature X could unlock a totally new product or feature that extends your product into new markets. Most non-technical PMs wouldn't even know about the new infrastructure capability because they only cared that feature X got built. They didn't care how it got built.

PMs Don't Need to be Software Engineers

Even though I believe PMs need to be technical, I don't believe they need to be software engineers. If you recall, from one of my first posts, I wasn't a software engineer before I started my PM career, but I had taken programming in college. More than that though, this helped me pick up SQL quickly and learn how relational data is structured, which is key in understanding how data structure drives functional capabilities within a product. Understanding relational data structure then helped me quickly grok the difference between OLAP and OLTP and the difference between structured, semi-structured, and unstructured data. In a real-world, example I took on a product that had some BI functions on the data the product created, but queries were agonizingly slow. I immediately and correctly assumed we were querying the transactional database to pull these analytics, rather than writing to and storing certain data in an analytics data structure. If I didn't understand this nuance, I wouldn't have been able to work with engineering to determine if better indexing and query optimization of the current datastore was enough or if we should look at creating a separate analytics database. More than that, I knew that if we wanted to add additional queries on other data, we should definitely do the latter. If I wasn't technical, I would probably have no idea that better indexing and query optimization were things, but even if I did, I wouldn't know if engineering was trying to bullshit me down that path or not.

On top of all that, it's in a PM's best interest to be technical enough to understand the overall tech stack of their product, including (and perhaps especially) its limitations. The ability to tell the difference between whether engineering is sandbagging you or legitimately pushing back because you are asking for something ridiculously difficult to build is a core PM skill that requires technical fluency to develop.

Regardless, I touched on this before, but not all PMs need to be uber technical. Sometimes "technical enough" to not fall prey to the major obstacles being non-technical creates can suffice. The technical floor isn't uniform across all PM roles: consumer/growth PMs maintaining existing products sit lower; new feature development sits high; platform, developer-facing, and infrastructure PMs sit at the top. But here's where I expect the rub to be: product leadership always requires a large degree of technical acumen, regardless of what ICs are doing because resourcing, hiring, and architectural tradeoff decisions happen at that level and you cannot make good decisions on those things from a position of technical ignorance.

The Hidden Tax of a Non-Technical PM

You can't quantify the relationship damage done between PM and engineering teams when the PM can't grok the technical implications of what they are asking for. It creates unnecessary back-and-forth and unnecessary engineering overhead to try to untechify technical concepts in ways that a layperson can grok (that is, if they haven't already gotten so sick of your shit that they just make up excuses - I've had engineers tell a PM, "the flux capacitor drives those things and it would take months to change it."). This credibility gap turns into blatant mistrust that just continues to snowball into bitterness and spite until the PM either escalates everything and pushes the blame up or issues demands without consulting engineering at all (or both), resulting in engineering just going off on their own and building what they want and half-assing everything else.

The cost of a technically illiterate PM almost never shows up in a post-mortem. If it does, it shows up as "need better requirements from PM" or "need better engineering estimates", neither of which address the root problem so they can never really be solved. Ultimately, the cost shows up as unexpected delays, tech debt, mistrust, team attrition, and sometimes: abject failure.

The Myth of What vs. How

Engineers don't resent PMs who understand their world. They resent PMs who don't and still act like they do.

The what/how separation between product and engineering is a protective fiction written to shield engineers from bad PMs. It's not a best practice for good ones. A PM's first job is to ask, 'why' - Why should we build this? Why did a stakeholder ask for this? - in order to get down to the actual problem being solved and identify the real 'what' to build. A skilled PM is forming both the 'what' and a potential 'how' simultaneously while they are asking 'why'. This isn't to dictate implementation. It's to give engineers something to start with and potentially push against. Creating 'something' from nothing takes a lot more grey matter than reacting to a hypothetical 'something'. Seeding the conversation with a hypothetical 'how' also shows that you understand the problem deeply enough to have thoughts about the how to solve it. This is what builds credibility and trust with engineering over time. I always come up with a potential 'how' to everything I put on a roadmap. Sometimes it's solid (here's the logical data structure for implementing RBAC). Sometimes it's half-baked (I think we might need a new datastore to build these analytics). Either way, I always encourage engineering to poke holes into my hypothesis. I don't say, 'Do it this way.' I say, 'Here's what I was thinking. I don't expect you to do it exactly like this, but it gives you an idea of what I'm looking for.'

The idea that PMs are solely responsible for the 'what' and engineering is solely responsible for the 'how' stems from bad PMs who want to micromanage the engineering process. Sometimes they are not technical enough to effectively define the 'how' (but they think they are). Other times they are super technical and think they know best - it's likely that these PMs spurred the non-technical PM argument. So I guess I'll revise my opening statement to this section to say: Engineers don't resent PMs who understand their world. They resent PMs who don't and still act like they do. They also resent PMs who think their understanding gives them authoritarian control over their world.

But even though ex-engineers who became non-strategic, dictatorial PMs may have been an impetus for the non-technical PM movement, a PM who can't read a system diagram or understand a data schema is a liability and not an asset.