Do you need to complete a course to transition into a product role?
Thoughts on product courses, being "technical enough" for a product role, and strategic de-risking
Here is an uncomfortable truth: product leaders who operate within the ‘product culture,’* which has strong elements of keeping an open mind, may not have an open mind about hiring an aspiring PM from a non-product (and non-technical) background.
Instead, they may suddenly put up a wall of prejudice and label you as the NBR (the Next Big Risk).
Transitioning into your first product role will require a secondary skill, strategic de-risking.
You can also describe this skill as vibing, blending, or vibrating in the same frequency (oooo….the vibrations). The goal is to present yourself as a product manager without the ‘product manager’ title.
There are a few ways to achieve strategic de-risking, and for the highly ethical individuals who read too much into every word in a conversation, none of these methods include lying.
As the title of this article suggests, taking a course is one way to strategically de-risk yourself in the pool of candidates.
I am not selling a course (and don’t have any plans to sell a course in the future), and I am not sponsored or paid to advertise a specific course.
Why taking a course can de-risk you during the hiring process?
Your knowledge of product management and the tech team will widen and deepen, even if the course is idealistic. This will help your confidence levels. 🧠💪
This one is straightforward. Good courses are designed to give you an overview of the day to day of the role, and some of the best practises used by PMs. Understanding the product lifecycle, how PMs make decisions, how tech stand-ups work, and common words that engineers would use so you don’t have to Google everything (i.e. APIs, tech debt, React etc) will give you a lot of confidence. It’s a whole new world, so you’ll need to learn it somehow.
For full disclosure, I took the Product Fundamentals course by Product David (founder, David Wang). I did not come from a technical background and wanted a product leader to take me through what would be most relevant to a product role (as I was getting lost in tech jargon). His courses were self-led (with a Slack community that you can raise questions) and affordable. Most product courses are quite expensive (over $1,500, and on average, between $3,000-5,000), so I was a bit skeptical whether a cheaper course would be valuable for me. Looking back, I made a very good decision.
General Assembly and Product School also offer courses (both highly reputable companies); they were just out of my budget at the time.
During the course and while doing further research, I remember cringing at my ‘product marketing’ self. Those with engineering backgrounds would know the strange language that non-technical people use to describe tech problems. Examples of the things I’ve heard non-technical people say, to give you the chills.
“I searched online and bought the team llama stickers… Why? You’re always going on about llamas, so I thought that llamas are your favourite animal. No?” 🦙
“Yeah, I think there is something wrong with the backend of the product. You should check out the backend. It gave me an error, but it had some codes on it, so I think it’s got to do with the backend.”
“All good, I didn’t want to waste your time, so I fixed it. I saw the button that had error on it, ‘cause it was coloured orange, and I deleted it. So now, there are no orange marks in the code.”
“Something’s wrong with my keyboard, I think. I’m trying to access article number 400, but it keeps telling me that 404 is not found. I don’t get it. I’m not even trying to access that.”
“We should solve our tech debt problem because there is an issue to fix every week. I’ve been seeing LinkedIn posts on my feed talking about tech debt. So, I think we need a migration.”
Courses and additional research will help you to not sound so…. 😮💨 It will help. Trust me.
You will find it easier to understand tech challenges and communicate with product people and the engineering team.
The best courses will intro you to design as well. This often gets missed, as there is a tendency to worry and focus on closing the technical knowledge gap. Product people work with designers closely, and having an understanding of a good user experience and the design process will make your life so much easier.
As mentioned above, this has helped my confidence levels during product interviews. I didn’t have a whole lot of experience, but I had theory to fall back on. It felt like a safety net. Trust has a mirroring effect. We tend to trust people who trust themselves.
Do technical people need a course? Do BAs need a course? Do people who come from start-up backgrounds, where they wore multiple hats, need a course?
Without going into the nitty gritty detail, if the only function of a course is to de-risk yourself via a certification, then it probably does not make much sense for you to give your time and money. I would not argue that taking a Product Management Fundamentals/Beginners course is the right choice for everyone.
However, you are trying to transition into a new role and this is the best time for you to learn something new. My recommendation would be to focus on upskilling in other ways. For example, you might be a developer, but do you understand the design process, how to conduct user interviews, or how product strategy is made?
Follow your curiosity, perhaps the parts of product management that you don’t know much about, and see where it leads you in your learning journey. Maybe you’ll want to understand product marketing a bit more, or you have a genuine curiosity to pick up AI skills. There are no punishments for learning more. This is something with minimal downside and a high upside.
Tip: I encourage you not to see job applications as dependent (or a following action) on completing a product course. In fact, you can view them both as different learning experiences. The most valuable learning experience would come from practically doing the role. Transitioning into a product role is already quite challenging and takes a long time. Any actions to reduce this time will benefit you.
Because courses will be on the idealistic side.
Product courses and theory books get a bad reputation among senior PMs who have been burned out by the reality of companies lacking a product culture. The theory does not match the practise. I cannot argue against that. That doesn’t mean learning the theory is a waste of time.
Firstly, you will have a clear image of what the “ideal” standards are and set high expectations for yourself to perform. I’m sure that most hiring managers will appreciate you aiming high.
Secondly, you won’t be so absorbed by the company culture, because you can identify unhelpful behaviour. Lack of prior knowledge can lead you to believe in anything that’s given to you, including bad practices.
The reality of being junior in a role is that you probably won’t land in a hot scale-up with the top product culture in the industry. Hint hint; most of the time, the “best” companies will try to get the “best” PMs. The purpose of your first product role is not to nail down perfection anyway; it is about gaining some experience and learning as much as you can.
The problem I see with product people who enter into companies without a good product culture is that they adopt bad habits. For example, they practise creating power points and internal politics more than product strategy and innovative thinking. Or, they grow defensive of their ideas, instead of being data-driven, curious and humble. Worse, they assume that this is what ‘product’ is all about. In that case, some feel disappointment. Others continue to carry their learnings to their next roles and wonder why they don’t succeed in other companies.
Thirdly, you will be able to identify companies with good and bad product culture. This will guide you to make career decisions beneficial for your growth.
Lastly, good product courses will not only teach you the theory, but will also acknowledge the reality to ground your expectations.
Grabbing opportunities and building a portfolio.
The best courses (for almost any subject) will guide you to build a portfolio by giving you practical examples, case studies and mini projects. This would be a valuable experience, especially if you don’t have prior experience supporting or shadowing product teams.
Most courses nowadays also tend to have community groups where job opportunities, networking events, and questions are shared. You can find temporary job opportunities to gain experience via those channels. You could also find your first product role. 😉
Networking.
As mentioned above, by entering into a reputable course, you will learn from experienced product leaders, meet with others on similar journeys, and join a community of PMs. You will find opportunities to connect with a variety of people (sometimes, digitally, sometimes, in-person). This can open a lot of doors for you.
Shows that you are a bit nerdy about the craft of product management.
During product interviews, a few people have asked me, “oh, so you want to transition into product. Ok, what have you been doing so far to learn about product?” Fair, and good question.
I took them through my learning roadmap, the resources I've chosen, and the rationale behind them. My passion to learn, curiosity, and adaptability shone in those conversations.
Therefore, taking a course may be a ‘get out of jail’ card for the “you’re not technical enough” judgement.
Many aspiring PMs who received this feedback have spent long hours unpacking what exactly is “enough.” It seems to represent an invisible threshold that aspiring PMs need to pass.
The bias towards people from non-technical (i.e. software engineering) backgrounds during the hiring process is real. I once got asked, “do you even know how to talk with the tech team?” Coming from a start-up background, where everyone talks with everyone, doesn’t fully save you from this bias either.
Let me unpack what qualifies as being “technical enough.” It is simply having empathy for developers — the people you will work with everyday. ‘Simply’ and ‘empathy’ in the same sentence… yeah, it’s not that simple. I have to put a definition here.
Empathy: the ability to understand and share someone else’s feelings, thoughts or experiences by imagining what it would like to be in that person’s situation.
Empathy is so much easier when you understand the day-to-day experiences, processes, language, challenges, motivations, and thought patterns of someone.
Empathy 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…”).
Stating the obvious, it’s so much easier to understand what your tech team is telling you (and therefore have empathy) when you used to be a part of a tech team.
More advanced or senior PMs who become SMEs in certain processes can even enter into discussions to challenge their tech teams. This makes you a valuable asset to brainstorm, ideate and collaborate with. It will also help you to more confidently bridge the gap between the tech team and other business functions (you may have heard/read the phrase, “fighting for your tech team”).
Completing certain types of courses can give hiring managers more confidence that you understand the world of tech and can work with a team of developers.
Before I wrap up this article, let me clear up some thoughts.
Do I think that enrolling in a course will help you to land a role sooner?
Maybe. This is a difficult statement to make. It would certainly depend on your prior knowledge and experience.
To my knowledge, there hasn’t been a scientific experiment done to measure the link between the number of months it takes for one to land their first product role and whether or not they have taken a product course.
Do I think enrolling in a course is a ‘must-have’ to achieve the outcomes mentioned above and land a product role?
No. There are a lot of ways to get to the same outcome. Taking a product course is only one of those ways.
Note: what I believe is not as important as what hiring managers think. I am not the one hiring for entry-level product roles.
Nowadays, everybody is expected to be their own marketer; your branding will influence your credibility in the eyes of hiring managers. Hence, people use anything to create narratives and strengthen their self-promotion. We live in a world where some people assume you are a ‘product prodigy’ if you have ‘ex-Google’ on your LinkedIn profile. I think that says it all.
Do I think that you should come from a “technical background” to apply for PM roles?
No. In fact, the history of product management lies in marketing. Having a technical background helps a lot, but what makes PMs stand out is analytical thinking skills and curiosity to understand technology (desire to learn/grow continuously). Building trust in your team or leading a tech squad isn’t about knowing every technical concept. There is a lot to unpack here, so I’ll continue this thread in a future post.
So, I don’t think coming from a technical background is a must-have. But some people do, and they feel more comfortable hiring a PM with a technical background (even if the product is not technically complex). When it is already quite challenging to transition into a product role, you may want to do anything you can to make this journey easier for yourself.
*Note: I sometimes joke about the product culture because it carries some ambiguity in its meaning. To be clear, I highly respect product leaders who strive to protect a culture that leads to successful products and team dynamics. I’ve seen and worked with teams where the product culture is contaminated by selfish interests, excessive politics, defensive egos, panic and lack of clear thinking. It never leads to good outcomes. I joke because it’s my style, not to challenge the importance of maintaining a strong culture.
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.


