Thoughts on the “not technical enough” judgement when wanting to become a PM
And some tricks to get around it
While preparing for my first rounds of product manager interviews, I had virtual and coffee catch-ups with other PMs to grab their advice. Almost all of them mentioned that I don’t need to know how to code to become a PM. Instead, I need to demonstrate ‘product expertise.’ That gave me a lot of temporary confidence.
Plot twist: the number 1 feedback I received after the job interviews I sat was not a lack of experience. It was… 🥁🥁🥁… not being technical enough. No, I was not applying to “Technical PM” roles or to work with technically complex architectures.
This repeated while helping aspiring PMs land their first product roles; I heard this type of feedback many other times. Rephrasing a conversation I had with someone from North America:
“They said that they really liked me, and I’m really smart, but given I didn’t come from a product background, they preferred to hire someone who at least came from a developer background. Then I asked again, does this role require coding skills? They said, no. I don’t get it, Doa.”
If the Product Manager role does not require coding skills, then what is the fuss?
Why is hiring an inexperienced PM with a developer background considered to be the “safer” option, in comparison to backgrounds in other roles?
I’ll be blunt about it. There are 3 main reasons.
Psychological safety of the hiring manager.
‘Product expertise’ will rely on being able to understand technical concepts (to some degree).
The technical skills you have will be highly advantageous for execution. And entry-level PM roles rely heavily on execution.
If you are an aspiring PM receiving this type of prejudice, at the end of each section, I will touch on a variety of tips & tricks.
Let’s get it out of the way and start with the ‘psychological safety of the hiring manager.’
Firstly, there are plenty of product leaders who will not favour or discriminate against certain backgrounds over others when hiring a junior PM in their teams. But some product leaders or founders will. This section is for the latter case.
➡️ As a PM, the best teachers I had to help me with technical concepts were developers. If someone is not advanced with their technical knowledge, it is challenging for them to teach/transfer those technical skills to you. It’s easier to hire someone who already comes from a technical background, so the hiring manager only has to worry about coaching them on the other aspects of product management.
➡️ Even if the hiring decision for the Junior Product Manager role was wrong, you can’t possibly blame the Head of Product for hiring someone from the developer community.
Scenario A: If you onboard a tech vendor that has an equal amount of downsides as to the upsides, but it’s the most reputable product in the market, then the business is more likely to see the glass half full.
Scenario B: If you onboard a tech vendor that has less amount of downsides to the product in Scenario A (or is a better fit to your use case overall), but it doesn’t have the ‘market leadership’ (maybe because the team is small, they’re a startup, etc), then the business is more likely to see the glass half empty.
Think of the vendors that “everyone” just goes with, or wants to explore, even when the solution is not the best fit for their problem. Without even understanding the problem-solution compatibility, some people just know (they feel it in their guts) that AWS (or Microsoft, or Salesforce, or any other market leader) is the best.
There’s even a saying about this from yesteryear. “No one ever got fired for buying Big Blue”… where Big Blue was IBM.
Love human psychology! If you used to be a developer, of course, you can work with other developers! Of course, this proves that you are highly intelligent, analytical and data-driven. Therefore, of course, you are the best fit to be a product manager!
Don’t get me wrong, reputations do form for a reason. I’m not arguing that developers are not intelligent or not analytical. I’m just pointing out that these qualities are not reserved for the front-end and back-end developer roles only. However, if a UI designer has difficulty adjusting to their new PM role, the team might jump to the conclusion that it’s because they were a UI designer (instead of a developer).
➡️ There is an assumption that if you used to be a developer, you know what you’re getting yourself into as a PM.
Side note, half of the time, developers don’t know any more than folks from other backgrounds.
On the other hand, if you used to be a marketer, maybe… you think that product is a cool job, and when you get to face the truth of being a PM, you will feel confused and intimidated by the technical concepts, and back out.
➡️ Unfortunately, there is also an assumption that developers are more analytical and brainy than others. Don’t get me started on that. No.
On that point, actually, ‘product’ suffers a bit from ego and elitism. It originated from Silicon Valley, where the first groups of PMs drove huge wins for companies which became unicorns. There is this idea that product managers are super intelligent and unique because they are fast, adaptable, creative, but also analytical, big picture, but also see the finer details, driving the tech, hero of the customers, a bridge to the marketers, like a CEO, but not a CEO, etc, etc.
This way of thinking, unfortunately, results in divides even within product people. Some people get judged for not working in the top 50 tech scale-ups in the country, others can be excluded from groups because apparently, one doesn’t become a real PM unless they have the Senior PM title (based on statistics of the drop-off rates within the first 5 years after someone takes on a product role). Or maybe you are “less of a PM” if you don’t have a “Technical PM” title (judgement towards “Growth PMs”), or if you don’t know how to code, even if you never use that skill in a PM role. Nowadays, this is getting even more bizarre with AI.
➡️ Lastly, while product people are quite good at stakeholder management and working cross-functionally, a part of them really dislike explaining the same concept over and over and over and over to customer support, to marketing, to finance, to sales, because they don’t get it. Sometimes, the conversations go like this:
CS: So, how come the customers need to go through this portal?
PM: As I mentioned last week, and also touched upon yesterday, this is only a temporary problem, due to…
Think of ‘babying’ every concept to customer support for the last 10 years. Would you trust hiring someone from customer support as a PM?
Note: I’m not necessarily agreeing with any of the points mentioned above, but simply laying out the ways of thinking you may encounter.
Tips & Tricks:
Seek help from a developer and ask them to explain your relevant experience.
You would have noticed that developers tend to explain tasks and initiatives slightly differently from how others in the business do. Listen to how they explain business problems and solutions.
Learn.
If you have time over the weekends, it’s quite fun to learn HTML and CSS, possibly the easiest coding languages, which will put you in front of a lot of other PMs. Mock up a basic website as a side project.
Build an n8n flow, or experiment with training AI agents. These are examples of small projects you can complete, not ‘must-haves’ in your portfolio.
Note that it’s not the exercise of coding that will enlighten you, but the process of thinking about how to code, instead.
Having a ‘product expertise’ will rely on being able to understand technical concepts.
The product manager acts as the bridge between tech, business and users. The triangle of PM skills that I referenced in another post exists for a reason.
Owning a product end-to-end and acting as the expert of the product isn’t just about knowing how your users interact with the product.
It’s also about understanding how your product works, the limitations of it, and the opportunities to expand it’s value, functionality and architecture, in a technical way, even if not as granularly as a developer does.
It’s also about giving product demos to other stakeholders, and answering a lot of ‘why,’ ‘why not,’ ‘how,’ and ‘how come’ questions. This is very important to built the trust and confidence of stakeholders across the business. I have seen PMs provide short responses to the ‘why’ questions, like, “we don’t have that capability,” or worse, “our Head of Tech said that this was too complex to execute.” Unconfident, short and vague responses cause stakeholders to go around the PM and conduct their own investigation, which never ends well.
These two points require a deeper understanding of technology. While one does not have to come from a ‘technical’ background, you can see how being an ex-developer can help.
Tips & Tricks:
Demonstrate industry knowledge during interviews, if possible.
When describing product initiatives you were involved in, mention the ‘why’ behind decisions that you made (and ‘why not’ for the other choices you turned down).
This requires you to talk about some form of product experience, whether it’s helping a product team, running your own project, etc.
The technical skills you have will be highly advantageous for execution.
The keyword here is ‘execution’ — successfully delivering a product initiative.
➡️ While the product management skills triangle points at the tech, business and customer, the more junior you are, the more likely you are expected to just deliver/execute on your manager’s direction. These product initiatives will most likely be small tasks, like ‘fix this button.’
That’s the reality of being junior in most jobs. Strategy, negotiation, drafting a roadmap, leading discovery work, etc — these skills are handy in more senior roles. Before you get to that stage, you’ll be hanging around developers a lot.
Stating the obvious, but coming from a technical background will help you to pick up on the language used by your tech team, orient yourself, and understand what’s going on with your product easier.
➡️ Let’s touch on ‘developer empathy.’ I thought I was already quite good at that (based on the feedback I received from tech teams), until I began learning how to build AI agent flows and coding.
“Oh, I thought you would know,” suddenly became, “I’m sure this can be done, let me ask Google to save some time.”
“You’re so protective of your form; it’s the same code, does the same thing,” suddenly became, “no, don’t touch that. It needs to be written that way. Please don’t confuse me. I already have a ton in my mind.”
It’s the little things that changed about me. As I mentioned in my previous post about the necessity of completing a product course, the ability to understand someone else’s feelings, thoughts or experiences by imagining what it would like to be in their situation is generally not an easy task.
“Empathy is so much easier when you understand the day-to-day experiences, processes, language, challenges, motivations, and thought patterns of someone.
It isn’t about stating the ‘what’ (i.e. “this will take a whole week to fix”); it’s about knowing the ‘why’ and sometimes the ‘how’ (i.e. “this may look like just a button, but it has dependencies on… therefore could be risky to… which we will need to navigate around…”).”
It helps when you used to be a part of the tech team.
But why ‘developer empathy’? I believe it is the foundation of productive and collaborative communication.
As a PM, you’ll be hands on, working towards building and shaping products with a designer and a team of developers. You will be discussing problems and solutions to prioritise tasks, capabilities, limitations, whether or not to scrap the idea and change direction. You need to build trust, respect and a close relationship with your team to collaborate effectively.
They need to know that you understand their perspective and can defend an idea when stakeholders question the team’s reasoning. At the same time, they prefer if you can be an equal team player and challenge them back, rather than having the attitude of, ‘you’re the SME in this, I’ll do whatever you say.’
Side note: effective communication and cross-collaboration are skills on their own. While understanding technology helps a lot for a PM, it doesn’t mean that ones who come from an engineering background will automatically have these two skills.
Observing the journeys of PMs with engineering backgrounds (A) vs PMs with marketing/sales backgrounds (B), it seems like Group A has an easier time in the beginning of their product journeys (but a harder time later on), and Group B, vice versa.
Tips & Tricks:
Demonstrate that you are analytical, data-driven, and curious to learn about technical concepts. This is what truly matters for a product person, and you don’t need a technical background for it.
Get product experience before going for interviews.
Volunteer at a small start-up, ask to support the product team in your company, refer back to any entrepreneurial experiences you may have (if that’s your background), or find another way. This will give you the experience and confidence in your product interviews.
Join developer events. Network. Make some friends from the tech team and ask them questions.
While transitioning into my first product role, I didn’t just grab coffee catch-ups with other PMs. I also spoke with a lot of developers. I wanted to understand what makes a great PM from their perspective.
Read. Practise. Just be curious to learn.
Read technical documentation. Watch tutorials on how to build stuff. Look at code. Even by looking at simple code snippets, you can start to recognise patterns. Learn how the internet works, AI, API, what people mean by ‘front end’ and ‘back end’. Read the book, ‘CODE,’ by Charles Petzold. It won’t actually help you to land a product role, but it’s a fascinating book which blew my mind.
If you are intimidated to start, that’s ok. That’s why you need to start. If you are not interested (or bored), then you might want to question why you want to be a product person. Being a PM isn’t about being the expert in every technical concept, but it’s about feeling curious to learn about technology.
To sum this up, let’s strip back to some keywords. What are the best product people associated with? Creativity, innovation, solving problems in unique ways, curiosity, adaptability, etc.
The beauty of Product Management is that many great PMs have roots in roles that isn’t product management. Their roots lay in unconventional backgrounds and diversity. The PMs who stand out can connect the dots in ways that impress and challenge others. It’s the mix and mash and match that results in creative and disruptive ideas.
As an aspiring PM, your career history is not a hindrance for you to hide and forget. It is probably your unique advantage in this new chapter. It is where you have developed some of your wonderful strengths, learned about your weaknesses, and wisened up about business and the wider world.
There are great product leaders who recognise and appreciate that too. They are also aware that everyone’s journey in product is different, and coming from XYZ role does not protect one from the challenges of starting a new role, nor smooth out the learning curve.
To wrap up, I have a story to tell, which might make the marketers smile.
After hearing some feedback from the hiring managers about not having a ‘technical background’ and not being ‘technical enough,’ I caught up with Ant Murphy for coffee. I have to mention, he is a smart, experienced and empathetic coach, and I was lucky to grab his time.
He said, “did you know the root of product management lies in marketing?”
I let out a laughter from disbelief. It sounded bizarre at the time. At home, I researched this. Here is a crash course (or a historical summary), if you are curious.
In the pre-digital world (1930s), Neil McElroy wrote a company memo to describe the role of the ‘Brand Man,’ who should be responsible for managing the product, tracking sales, and promoting the product. In those times, ‘brand’ and ‘quality’ were a product’s main strategic differentiators in the market.
McElroy influenced Bill Hewlett and David Packard, who later introduced an organisation structure where each product group functioned independently and heavily focused on the voice of the customer.
Over the years, marketing-originated concepts emerged to create product differentiation. For example, the 4Ps — having the right Product, in the right Place, at the right Price, and using the right Promotion.
During 1990s, things got a little messy because products were no longer just physical objects. Marketers had to communicate with software engineers about the customer and business needs, without having a strong understanding of the digital technology. More advancements in technology meant more challenges in communication between tech and other business functions, which marketing could no longer bridge.
Eventually, ‘product managers’ were born. Some claim that marketing gave birth to product management, others say that program managers learned brand skills and transitioned into product roles. Either way, a group of people filled in the gap, and most of the time, these people were not software engineers. They were simply people who were curious to understand technology, excited to collaborate with a variety of business functions, and passionate to build meaningful products for customers.
In 2001, the Agile Manifesto was written by 17 software engineers to establish a culture that focused on building the best solution to a customer problem. This enhanced cross-functional collaboration and became the fundamentals of the modern ‘product culture.’
All the images I use have been generated using deepai.org (the pop art generator). 🦸♀️
If this post is helpful to you, it will probably help others too. Share with a colleague, and if you haven’t done so, subscribe.