Skip to main content

Not technical enough to be a PM


How often potentially great candidates don't apply for suiting product management vacancies because they are afraid to be not "technical" enough? This word became scary for a lot of capable PMs or people who want to break into the field. Product management community is full of discussions on how technical PMs should really be. But perhaps even before that, we need to clearly define what does the word "technical" mean when applied to a product manager? 

I used to write code. I wasn't a developer and wasn't trying to become one. Mainly because I thought I was too stupid for that. So I became a PM where being stupid is not a problem. OK, joking, there is a normal distribution of stupid people in product management positions, maybe little less than in a general population. Thing is, a lot of people will say the ability to write code is enough to consider oneself technical. That's a shaky ground as the scale of ability is quite wide. Yes, I was able to write pretty simple scripts for automated testing but this level of coding was maybe on the level of the most junior of developers. And that was fine. It was the appropriate level for the job. When I transitioned to the PM job, it was still the appropriate level for what my new job required. 

So what does it mean to be technical as a PM? 

I suggest to narrow it down to three major qualities: 

  • Understand high-level IT concepts and roughly picture how things work 
  • Speak the language of developers 
  • Be self-conscious about what you don't know

Let's look into every point separately. 

Understand high-level IT concepts and roughly picture how things work

A good PM would have an understanding of the entire product development process and how the product actually works. Depending on a product you might need to spend more or less time learning the basics. If your product is a shoe, you might want to know how the raw materials being sourced, what processing is taking place and which tools are used to produce the final product. You don't need to be an expert on all development stages, but to have an overview is a must.  If your product is a cloud-based application you need to know its major components, how it's getting deployed and on what external services (tools) it relies. How well do you need to understand those concepts? Maybe think about it like a car. It's useful to know what's under the hood and how it all connects to each other. Even if you don't know the details of how every component works. 

Speak the language of developers

That's probably the scariest for the junior PMs. They dread the humiliation of sitting in a room full of developers and not understanding a word they are saying. Luckily you can learn to speak developer like you learn any other language. And trust me, it's way easier than Chinese. The good news is you'd learn the basic vocabulary by doing the activity above - getting yourself familiar with how your product is getting built and how it works. Then what you need is practise. Every development team is different and you might need to spend some time with them to catch on the language they prefer using. Then throw some fancy words into the mix, like microservices or Markov chains or TDD and you well might be regarded as a native speaker. 

Be self-conscious about what you don't know

Having an understanding of how things are getting built and how they work is great. However, PMs should always remember that their main purpose is different. It's an understanding of customers and their problems. Hence it's important to trust your colleagues to make decisions in their main areas of expertise. You're there to represent customers, a designer/UX person is there to define look-n-feel and developers are there to make technical decisions. 

The chances for product success are much greater when all people on a product team speak the same language and have a mutual understanding of each other areas. 

In sum

No problem if you can't write code. You still could be a technical PM. What you need to do is to spend some time to understand the basic concepts of how your product is getting built and how it works. You need to practise speaking the language of developers. And you have to stay focused on the core values of your role and trust your team to do their best. So next time you see the term "technical" in a PM job description - don't be immediately frighten, you can learn to be one. 

Popular posts from this blog

Product management and operations tools - Jira Product Discovery review

  JPD is a new player in the market of product management software. Jira (and the whole Atlassian suite) has been one of the most popular tool stacks for teams to deliver software products. Now they're adding a missing piece - product discovery.

Product Vision: an elevator pitch for your product

On this blog, I write a lot about making data-driven decisions . But what if you just starting to think about your product? You have a vague idea and nothing more. No point to go for prototyping or even talking to customers as you don't know yet who to talk to and what to talk about. In such situation - start from creating a product vision.

2 simple but powerful filters for your problem and product ideas

Nowadays lots of people and companies want to innovate. They want to generate new ideas and turn them into profitable products. But how would you separate good ideas from not so good ones? How would you make sure you invest only in good ideas?