From a Recruiter

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 communicate with the dev team.

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 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 new product ideas.  They’d prefer someone who can just take an existing idea, estimate how long it will take to execute, and hand it over to Development.

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. Rather, it’s about identifying, elaborating, and refining new products or features 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 these products and feature ideas is essential to the process.  Anything that side-steps or circumvents the process of this idea 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…?

Previous post

5 Travel Jobs

Next post

A New Battleground for Veterans

Cliff Gilley

Cliff has worked as a product manager for over 10 years in a variety of markets and working on a variety of products, many of which generated over $10M in yearly revenue for the companies owning them. He is experienced in facilitation, mediation, prioritization, and a bunch of other “ations” that are important to the job of a product manager. He has worked to transition several development and product teams from waterfall approaches to Agile practices, with varying levels of resounding success. His approach to product management is one of practical, pragmatic solutions to solving customer problems and wrangling stakeholders as though they were wild cats.

  • Ajin Abraham

    It could also be an issue of having to step out of the comfort zone for a highly technical product manager. He may naturally feel more inclined toward spending greater time on product-aspects, than face customers.

    • Cliff Gilley

      This is a very real risk with highly-technical product managers who don’t also have the non-technical “soft skills” that are required to be a great PM. I’ve seen people break through this bias, and it’s great when they do, but they usually need a good amount of coaching and the proper success opportunities to do so.