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.