How Technical Does a Product Manager Really Have to Be?

How Technical Does a Product Manager Really Have to Be?

There’s a strong trend in Product Management circles to insist that a good Product Manager must be strongly technical in addition to having strong marketing and communication skills.  And while this approach is well-meaning, it often results in a weak Product Management role that merely supports Development rather than challenge it.

Now, that’s not to say that a Product Manager can be successful without some basic level of technical competency — in order to have honest discussions with development teams, and to build the trust and respect of those teams, you must have at least a passing familiarity with the technologies that are being used by that team.  You have to at least know what the terminology means – not knowing the difference between MySQL and NoSQL at a very high level, for example, can and will negatively affect your ability to write effective user stories.

And therein lies the purpose of technical ability in a Product Manager — knowing and understanding the outer limits of what is possible, given the technology stack that is being used by the company.  But this doesn’t require that the Product Manager know how to actually code, or write queries him or herself.  What it requires is a combination of an overview-level comprehension of the underlying technologies and trusting that the development team can and will fill in the rest when solving the problems that have been posed to them.

What I find more often than not, is that companies who are looking for highly-technical Product Managers are looking to circumvent the whole process of proposing, estimating, and challenging user stories.  They’d prefer someone who can just write a user story, estimate it on their own, and hand it over to Development to execute.

But, this is the wrong way to use your Product Managers, and the wrong way to leverage their interactions with the development teams.  Rather, good Product Managers should challenge their development teams to push the boundaries of the technology to solve and innovate on new and interesting market problems.

That is the one purpose of Product Management – it’s not necessarily to make Development’s job easier; it’s not necessarily to create immediately actionable user stories.  Rather, it’s about identifying, elaborating, and refining those user stories in a way that solves a market problem.  And, the interaction between the Product Manager and the Development team in challenging, refining, and elaborating on stories is essential to the process.  Anything that side-steps or circumvents the process of story elaboration is hazardous to the entire system.

It’s also risky to bring in a highly technical Product Manager, because they often wind up becoming deeply involved in the technical design and development of their own solutions.  Why is this a problem?  It’s simple — it’s a forest for the trees issue wherein a technical PM might rather spend time working with system architects, senior developers, and other technical resources, rather than spending time with and in the market itself.

This is the biggest risk of all – that a technical PM becomes an internal resource, and neglects the actual market and the actual users outside the four walls of the building.  We actually see evidence of this in many companies widely known for their “engineering-driven” culture.  Many of the changes made by Facebook, many products launched by Google, even some of the recent product launches from Amazon — all of these have clearly suffered from a lack of an actual market problem that they were intended to solve.  Constant Timeline changes that serve no real purpose, Google’s fiasco with Wave, and the Amazon Fire Phone are all examples of really interesting technical solutions, but built, tested, and launched without any seeming connection to a valuable market problem.

Product Managers exist to be the conduit and connection between your users, your buyers, and your prospects to your development, marketing, and service teams.  Don’t short-change the “soft” skills that allow them to do this job just because your company is highly technical, or because your engineering team wants “independence”.  A good Product Manager can learn what they need to on the technology front, and brings incredible amounts of market and user insight that will result in higher profits, stronger market penetration, and happier customers.

Unless, of course, you’re not looking for happy customers…?

Back To Top