Ask A Good Product Manager

Your product management questions answered

How technical should a product manager be?

Posted on July 7, 2010 · 18 Comments

Question: Do product managers of technical products really need to be technical?

I am a Project Manager by trade, but have recently got a new job as a Product Manager, working on an existing product in a new company. I enjoyed working as a Project Manager, but one of the issues I had was it was quite a technical role, and I don’t really enjoy that, even though I am working on online products.

My new role had zero technical questions in the interview, but my question is this: How technical do you think a Product Manager should be?

Answer from Derek Morrison of All About Product Management:
How technical do I think a product manager should be?

The day-to-day work of an online Product Manager can be quite varied depending on the company you work for — it can even vary considerably in different teams within the same company. The department (e.g. sales, engineering, marketing or product management/marketing) or to whom the Product Manager reports to will also have an influence on their day-to-day activities. So let’s start by looking at what Product Management is — then what Product Managers do — in order to help us answer the question “how technical do I think a product manager should be?”

What is Product Management?

In his book The Product Manager’s Desk Reference, Steven Haines states that “Product Management is the holistic business management of the product from the time it is conceived as an idea to the time it is discontinued and withdrawn from the market.”

Wikipedia gives a little more color to the definition by stating that “Product Management is an organizational lifecycle function within a company dealing with the planning or forecasting or marketing of a product or products at all stages of the product lifecycle.”

What does a Product Manager do?

Again Steven Haines writes that “the Product Manager is a person appointed to be a proactive product or product line ‘mini CEO’ or general manager.”

Marty Cagan of the SVPG gives a bit more detail when he says that “discovering a product that is valuable, usable and feasible … is the primary responsibility of the product manager, and that product discovery requires collaboration between product management, user experience design, and engineering/architects.”

We can deduce then that Product Management is a function that exists with in an organisation and caters to ALL aspects of the product from the cradle to the grave. The Product Manager is responsible for ensuring that all these aspects get done, that all departments and functions are kept in the loop and are updated. This is done best when the Product Manager effectively collaborates with stakeholders and successfully leads a cross functional team to envisage, develop, launch and maintain the product.

Taking this into account we could restate the question by asking “how technical do you have to be to effectively collaborate and successfully lead a cross functional team?”

The answer depends on two scenarios:

  1. What type of products are you developing and managing, and who are your users?
  2. What is the structure of your team: who defines the ‘WHAT’ and who defines the ‘HOW’?

1) What type of products are you developing & managing and who are your users?

If you are managing a technical product (e.g. developer tools, debugging tools) for a technical user base (e.g. software engineers, system analysts) then I would say that the Product Manager need to be technical enough to use every aspect of the product in the same way as the end user will in their daily jobs.

What is the structure of your team: who defines the ‘WHAT’ and who defines the ‘HOW’?

The Product Manager should be the voice of the customer in the Product Management process. S/he needs to be able to effectively connect the wants and needs of the customer (and user) and the business directly to the development team(s) without having the customer (and user) dictating what the product should be. Henry Ford said “If I’d asked my customers what they wanted, they’d have said a faster horse.” For Product Managers working with online products it’s important that they define products that will give the user a good user experience. This skill warrants a bias towards design and usability as opposed writing code or being deeply technical. Reading “Don’t Make Me Think” by Steve Krug would be a good starting point for anyone wanting to acquire design and usability skills.

That said you need to have a good appreciation and knowledge (not necessarily the ability to write code) of online technologies and how they can be used to provide a great user experience. For examples you should know what web technologies — such as Ajax, HTML5, RSS, Java script, CSS, SOA, APIs — are used for, and you should appreciate some of the benefits and trade offs. You should keep abreast of the latest technologies that are coming onto the market. (See my blog post “How do Product Managers Keep up with Technology.”) That said, there’s a fine balance between using new technologies just for the sake of it and using new technologies in order to solve problems and build competitive products and features that the end user will appreciate.

The Product Manager needs to lead the product discovery process: WHO the product is for (communicating this using personas and segmentation) and WHAT the product will do (using artifacts like use cases, user stories wire-frames). The developers and engineers, in conjunction with architects, are responsible for HOW the product will do it.

I started off by stating that the job of the Product Manager can be quite varied depending on what company, team and/or department you are in. However, one thing is pretty much consistent irrespective of your situation — you’ll need to work very closely with the development team(s). Therefore, the more you appreciate their world the easier you’ll find your job. Working as an online Product Manager necessitates that you understand web technologies and keep abreast of new technologies as they arises. The online Product Manager should know what the different technologies do, what are some of the benefits and trade offs and how they can be used to discover and create products and features that customers & users love and enjoy.

Having a strong technical background does not automatically mean you’ll be a successful Product Manager whilst not having a technical background does not automatically mean your be a failure (two extremes, I know). The key prerequisites for Product Managers are (a) having the ability to communicate with technical and non-technical people in order to drive the product through each stage of its life and (b) being willing to learn the appropriate technical and non-technical competencies in order to communicate with all types of stakeholders.

Finally, there could be many reasons why you where not asked technical questions at the job interview; please do not take this as a sign to ignore technology.

Suggested further reading: Pragmatic Marketing framework

18 other answers so far ↓

  • Adam Bullied // Jul 8, 2010 at 7:57 am

    As usual, a great post Jeff!

  • Larry McKeogh // Jul 8, 2010 at 8:35 am

    I agree that it depends on the position. My personal preference has been to try and retain as much technical knowledge as possible. Believing it is easier to have a level conversation with both engineering and the customer side of the equation.

    Good points though and nice management of the spectrum.

  • Derek Morrison // Jul 8, 2010 at 8:57 am

    I agree with you Larry – irrespective of what situation you find yourself in it’s always better to have the technical knowledge than not to have it – the only proviso is that the Product Manager should not try and tell or dictate (but should rather suggest, ask and probe if and when appropriate) the dev team on applying technology to solve problems and build great features.
    I know of at least one guy who was very technical – was hired as a product guy to work with the devs, architects and dev manager to solve problems – needless to say it didn’t work out. Key point let the technical team do what there’re good at.

  • teaneed // Jul 8, 2010 at 9:07 am

    A good product manager does indeed some technical expertise in order to understand product limitations and how to best solve user facing issues. A good PRD will benefit from the PM’s knowledge.

  • Jeff Zimmerman // Jul 8, 2010 at 4:14 pm

    Good post. I would add a few points. When interacting with dev teams, it’s useful to have enough technical knowledge to know much work will be required to build what you ask for. Will it take days, weeks, months or years? On the other hand, you need to first think like your customer (not a programmer).

  • Derek Morrison // Jul 9, 2010 at 8:42 am

    Hi Jeff – it’s good to know if something is going to be S, M or L – that’s why scrum encourages the use of an estimated backlog for sprint planning. The dev/scrum team can then firm up the estimates using poker cards – story points etc…

  • Brenan // Jul 12, 2010 at 7:51 am

    Great post.
    I’m on the technical side, which has some benefits when judging estimates and looking out for scope/schedule risk and making sure the costs of development don’t outstrip the value I am bringing to the market. But having come from the development side of the house, I’m constantly needing to learn in the UX and marketing areas that my role covers. It helps me to know what I don’t know, and to make sure I’m asking questions when I’m in an area in which I don’t have 10 years of experience.

  • Sridhar Oruganti // Jul 13, 2010 at 11:42 pm

    More importantly, it would really help if the Product Manager has the domain expertise ( unless ofcourse the product is a ecom site ).

  • jefflash // Jul 14, 2010 at 7:30 am

    @Sridhar — See this post on my other blog “How To Be A Good Product Manager” which deals with how much domain experience product managers should have: Understand your product’s domain

  • Sridhar Oruganti // Jul 14, 2010 at 8:11 am

    Ah thanks for the link Jeff .
    So could we say that in niche areas ( Biotech as you rightly mentioned in the other article, CAD ) domain expertise trumps the technical expertise ?

  • bob corrigan // Jul 22, 2010 at 9:27 am

    I was very pleased to read were Derek’s two wrap-up observations of “The key prerequisites for Product Managers are (a) having the ability to communicate with technical and non-technical people in order to drive the product through each stage of its life and (b) being willing to learn the appropriate technical and non-technical competencies in order to communicate with all types of stakeholders.”

    That’s PM in a small basket. PMs harmonize organizations, and you can’t do that if you can’t speak with confidence and listen with humility to all the different constituencies in that organization.

  • Saeed Khan // Jul 28, 2010 at 8:17 pm

    Let’s not forget that there are different roles that should be defined with Product Management organizations.

    If there is a need for deep technical expertise within the PM team, why not define the role of Technical Product Manager (TPM) and staff it appropriately (e.g. a technical SE or an engineer who wants to transition to PM).

    Pair the TPM with a more business focused PM (PM) and now you’ve got a great team whose efforts can extend from technical to business quite easily.

    It is important to get away from the Superman model of Product Managers who can do it all.
    It’s not a scalable model and often prevents the PM from truly being successful in the role.

    Saeed

  • Nishant Pradhan // Aug 10, 2010 at 12:28 am

    Product manger according to me is a jack of all trades. He just cant be master of one. So being technical wont help yet not understanding what your technical developer/technical program manager is saying would do you no good. For eg., in my personal experience, if I didn’t know what are the advantages of choosing ruby on rails over Java or how HTML 5 is different from XHTML 1.0 or do I need CDN for my existing cloud computing environment, I would have been taken for a ride. So its important to get in to a fruitful discussion with your technical team. Bring on board a different point of view keeping in mind the business objectives. Even if you are not good with technical terms, make sure you take a perspective from a different technical manager. But do this very carefully without hurting the sentiments of your technical team!

  • Tom Leung // Sep 7, 2010 at 8:34 am

    Totally agree with Saeed. Even if you have people that can do it all, they don’t have time. Splitting the role between technical and business product managers makes a ton of senses. At Marchex, we have a Product Manager and one or more Program Managers per core team and that seems to work really well. On a related topic, I recently wrote about the right Engr:PM ratio here http://bit.ly/cHJ8nm

  • Ross // May 21, 2011 at 9:37 am

    The answer to your question really depends on what your company think the PM role is and who you have working beside you. More often than not, a PM tends to be a jack of all trades. Tasks needing done that don’t fit into other job roles tend to fall to the person who has a wider remit.

    If you are luck enough to have a technical architect or similar to work beside you, then you can probably afford to be less technical. I have found however, having started my career as a developer, it is always useful to understand the challenges that your dev team face. When tasks come back with a larger estimates than you think, it usually turns out that the requirement is misunderstood; catching this up front saves a lot of pain later. If you don’t have a technical lead working beside you to catch this, then it will fall to you to pick up.

    Ross

  • BB // Dec 11, 2014 at 9:08 am

    Hello! This thread is a few years old so I’m just crossing my fingers that someone sees this. I currently lead the product team in a growing startup, do not have a technical background but have a deep knowledge of our userbase, and hired another product manager this summer who was a developer before going to business school. One of the qualities that I believe we should leverage is his technical knowledge that he skillfully weaves into understanding the user requirements. Recently, he asked for access to github to have more visibility into the work being done on his product, and our CTO was quite resistant, reminding me that “dev has no say over business objectives or what the pages will do, but we expect to be able of picking how we do it” and had jokingly brushed off the request by telling my PM that “he knew too much to have access to github.”

    Putting aside some trust issues that I’m sure are obvious by these scant details, does anyone have guidance on this type of situation? Assuming that my PM is not trying to dictate the development process but rather trying to better understand someone’s thought process to streamline communication, is this request unreasonable, or a no-no in product/development relationships? I’m trying to understand both sides and continue to build trust rather than create a biz/dev divide, and would love some guidance on what may be a boundary I’m trying to cross that I should leave alone.

  • Bob Corrigan // Dec 15, 2014 at 3:15 pm

    Hey BB:

    First, it sounds like your developer-first, product manager-second hire is still thinking like a developer. The PM’s job is to define what, when, why and who. Dev’s job is to hear that and propose “how” options and the timeline and strategy impacts associated with the options. They work together to deliver products that people want to buy.

    It’s nice that you’ve got a tech-savvy PM. But unless the PM is the product owner, the PM should focus on the market and communicate requirements & backlog priorities to the product owner, and leave the mechanics of software dev to the dev team & its managers.

    Second, the CTO is right. This isn’t a trust thing – it’s a roles and responsibilities thing. Your PM doesn’t need access to GitHub to streamline communication or better understand thought processes. In fact, your PM should not be talking to developers at all. He/she should only be talking with the development manager and/or the product owner. I’m a little surprised that you as the most senior PM didn’t realize this. You may now have the deeper problem of the CTO questioning whether you understand the way commercial software gets built.

    If you’d like to actually, you know, TALK about this on the phone, drop me a line. Old forums are an awful way to find answers to challenging workplace issues.

    bob

  • JS // Dec 16, 2014 at 3:58 am

    Hi BB,

    I too started in software development, then went to business school and was the prototypical accidental product manager.

    In 10 years, I have never found it valuable to dig into the code. But I always understand how the data flows and the logical architecture. And when the product is highly mathematical, I spend a lot of time understanding the model and which conclusions can be drawn and which cannot. Essentially, I want to know what are boundaries and the hurdles to the next step, be it a new feature or scale.

    But the key point is that I do this by speaking to the developers and/or the data scientists. And while I agree with Bob on most points, I think it is very valuable to spend time with everyone, not just managers. Of course this does not mean you can pepper them with questions constantly, they do need to get work done, but in a conversation you can learn a lot, they can learn a lot, ideas flow, and a relationship/understanding is developed.

    Product management is about communication. And his technical background is going to help massively in these conversations as lot can go unexplained or can be short cut.

    Regarding the trust issues, which is your bigger problem. Your PM will find that he can be most influential by partnering with development, not trying to manage them and not trying to be one of them. He should avoid assumptions and ask questions when he does not know something as he is not required to be an expert on all things. I find that people don’t mind explaining their work, but they hate explaining it multiple times. This is where his education and skill set will serve him well and where he can best partner.

    John

What do you think?