How Technical Should a Product Manager Be?

Recently, the CrankyPM was in top form with her post about the 6 Types of Software Engineers. That kicked up an interesting response from a developer, who attempted to classify the 4 Types of Product Managers. The response post re-raised the age old Product Management qualification question: “How Technical Should a Product Manager Be?”

There are two big philosophical battles for Product Manager qualifications: level of technical competence, and level of domain expertise. Arguments for more technical include:

  • Less likely to be B.S.’d by development
  • More easily builds rapport with development
  • Understands what is possible

Arguments for less technical include:

  • Won’t be tempted to get “in the weeds.
  • More outside-in than inside-out focused
  • Doesn’t filter requests to development based on own biases of what is possible

I actually started my career as a developer. To the point of the article linked above, I wasn’t a “guru,” but I sought to get out of development because I didn’t want to always be implementing someone else’s vision. I am thankful for that experience today because I do feel like it enables me to speak with developers more on their terms and relate to the challenges that they face. I’m not just a PHB saying “here’s the date – make it happen!” It helps, and as a PM having a good relationship with your team is important. However, it also leads to one of the biggest myths of Product Management…

“Being Technical Enables me to Know When Development is the Schedule.” It doesn’t matter how good your relationship with development is, you don’t know if they are padding the schedule (or rather, how much). Most development teams have no idea of how long a feature will take to build. Even if they did know exactly, unless you are in the code and are familiar with everyone’s workload and skills you’re not going to know.

There are at least two ways around this problem: Evidence based scheduling, which looks at past performance against projected schedules as an indicator of how much to trust a developer’s estimate, and Agile, where you can lock in dates and flex scope instead (which just shifts your problem from dates to scope).

The other knock against being too technical is that you will filter requirements into development based on your own biases of what is possible. A Product Manager should not know or care about how a solution is implemented, only the time and cost to fulfill the requirement. If the requirement is “The lawn shall be cut to 2.5 inches above ground level every 2 weeks” do we care if the solution is a lawn mower vs. a billy goat vs. 75 developers with scissors? No!

It is the job of development to tell us how much something costs, and our job to go into the equation assuming anything is possible. “Man on Mars?” Sure – 100 Trillion dollars and 35 years! “100 MPG car?” 15 Billion dollars and 7 years. “Invisibility cloak?” OK, some things aren’t currently possible (yet). But put in the requirement, because developers get off on a challenge!

Another way to get accurate info from Development is trust. If you have a good relationship with the Alpha Dog developer, they will tell you how confident they are in an estimate or how much they are padding. But beware – I’ve seen junior PM’s turn around a give this info to management thinking that it will get them recognition. Worst. Decision. Ever. The VP hears that the schedule is padded 3 weeks, trims the timeline by the same, and your bridge with Development gets burned down. Poke and prod for details, but keep it “in the family.”

A final note on the “technical” product manager: every minute you spend talking to a developer is a minute you are not spending listening to a customer or potential.

How technical do you think a PM needs to be?

Previous Post Next Post


  • Reply Stewart Rogers September 18, 2008 at 9:46 pm

    Well said Paul! I agree completely that you need a hint of technical juice in you to understand because you cannot avoid face time with the team that does the building and you need to function as peers with them. It is no different than the other teams you need to interact with, you need a hint of sales, hint of leadership, hint of marketing and TON of time.

  • Reply Mindy October 14, 2008 at 10:58 am

    This is a great post and something that I’ve distributed to all of the other product managers on our team. Just curious though…when looking at all of the product management positions out there, I’ve noticed that many (if not all) require that someone have a Computer Science degree. Why do you think the industry is trending this way. I have almost 10 years of product management experience and majored in English Literature. And, I have to say that my English major has helped tremendously in drafting these requirements and in communicating these features across all departments (and of course, to customers). Is someone with 10 years of product management experience AND a computer science degree really that much better?

  • Reply Carole-Ann Matignon December 25, 2008 at 8:53 am

    I agree with your perspective but I wanted to nuance it a bit if you don’t mind.

    If your product is a tool / technology for developers, I believes it becomes a necessity to be more technical. I do not use my technical background so much to reverse-engineer Product Development’s estimates (although it does help sometimes to brainstorm on a design they did not think of — only once in a while though). I do use it every single day when talking to customers. How can I fully understand the challenges of a software developer if I don’t speak the same language?

    All of the PMs in my team do not have the same technical background of course, but it makes a real difference. I think the non-technical PMs tend to list what customers have requested, while technical PMs can drill down into the core problem (which is often different from the solution they requested). Huge value.

    Again, this is only applicable if the product you manage is a technical product ;-)

  • Leave a Reply