You don’t need to learn how to code to feel confident as a non-technical PMFeatured

I’m a software engineer and I tech mentor product managers.

If you're a non-technical product manager who struggles with feeling confident about your technical skills, taking a coding class won't make you feel more confident. In fact, it'll probably make you feel overwhelmed and confused.

Let me explain.

In the past decade, I've worked as a developer at numerous companies of varying sizes and industries including entertainment, pharmaceuticals, advertising, and finance. Before I became an entrepreneur dedicating myself full-time to making technical literacy more accessible to non-developers, I worked as a software engineer for 3.5 years at Amazon, first in display advertising and then on their internal tools team. Before that, I was a software engineer at a mid-sized personal finance startup.

Suffice to say, I have a decent amount of experience working with product managers building websites and software in various work environments. And one of the things that stood out to me is how common it is for a product manager to have stumbled into their role from an entirely unrelated background. This means many PMs don't have an engineering background or have never received any technical training.

While I've enjoyed working with the majority of product managers I've had the pleasure of being on a team with, as a software engineer I admittedly often find myself having difficulty communicating with product managers about the limitations of my work, why I can't deliver a feature/product within their ideal timeline, and get frustrated when user stories, mocks, and business requirements are not crafted in a way that enables me to do my best work (often even hindering it).

Communication and collaboration between PMs and engineers are notoriously tricky to navigate and while there are numerous contributing factors, a lack of shared common technical knowledge and understanding is almost certainly one of them.

It didn't dawn on me how common it was for product managers and other non-engineering roles to feel unconfident about their technical skills while feeling unable to ask questions for fear of looking "stupid" until one of the product managers I worked with at Amazon approached me and opened up about her struggles.

Wanting to help, I started "tech mentoring" her on fundamental terms and concepts in technology and software and the technical ins-and-outs of our app. We met every 2 weeks for half an hour, but also on an as-needed basis, like before and after engineering-PM meetings to prep and/or debrief, and when she worked on business requirements and user stories.

Within 5 months of tech mentorship, not only was there a noticeable difference in the quality of her business requirements and user stories, but the team noticed the improvement in her ability to ask well-informed questions during meetings, and on occasion even offer solutions to technical problems!

Through the experience, I got an intimate understanding of what technical concepts were and weren't obvious to product managers. This includes concepts as ubiquitous as APIs, servers, data types, and even the difference between Git and GitHub.

Our working relationship also improved through our consistent bi-weekly meetings. I learned a lot about the product management discipline and perspective through our mentorship meetings and her vice versa with the engineering perspective.

Looking back, the mentorship experience was one of the most rewarding things I ever did in my career. It really opened my eyes to how we can bridge the communication and knowledge gap between product managers and engineers.

I'm sharing this story because I want to illustrate how as a product manager you can feel more confident about your technical skills without ever taking a coding class. The reason is simple but not obvious or talked about. And that is coding and being technically literate are two separate skills.

That's right. I've met plenty of junior engineers who can code, but ask them to evaluate different system architectural styles and they wouldn't be able to. Or ideas on how to improve latency and browsing speed time for an app, and they'd struggle to come up with viable options. Or even how scaling in cloud computing works and how we can leverage it in different business scenarios and they'd likely draw a blank. And these are the sorts of real conversations engineers discuss during meetings you sit in.

Engineers don't talk about how to assign a variable, or write a for-loop, or the difference between a hash map or a linked tree during meetings, but that's what you learn taking a coding class. In a coding class, you're learning how to code in a very specific programming language. But building great software involves so much more than just coding.

Plus as a PM, designer, customer success, sales professional, etc. your job is not to code. Your job is to understand enough about technology and software so that you can work with and communicate effectively and cohesively with engineers to create a feature or product that will delight customers (and leadership!).

So, if you don't come from a technical background and want to feel more confident in your technical abilities and/or work better with engineers, here are 3 tips to get you there:

1. Find a tech mentor

Similar to how I tech mentored the product manager I worked with, you can also find a tech mentor to personally help you on your journey to gaining confidence in your technical skills.

Tech mentorship is cross-functional mentorship with someone that possesses a technical background and experience – usually an experienced developer or technical product manager (TPM). If you're a current product manager, I recommend an engineer or TPM on your team as a tech mentor. This is the best option since the engineer or TPM has direct knowledge of the product, the business, the customers, and team/org culture. Only team members can answer questions about a specific product or use case. Having a member of your team as a tech mentor also helps with collaboration by building trust through consistent communication.

I suggest meeting regularly (i.e. once every other week) for 4-5 months and on an as-needed basis. After 4-5 months, you can choose to keep it going or switch to just an as-needed basis. Use technical resources as a facilitator during discussions (i.e. software diagrams, API documentation, tech docs, articles, playing around with the product). It's also important to ask open-ended questions during mentorship sessions (i.e. why certain decisions were made, alternative solutions, etc.).

2. Focus on acquiring broad knowledge across the following technical topics

Unless you work on a team where you need deep domain knowledge, I highly suggest focusing on building the fundamentals broadly across the most important verticals in software first. To make things simpler, I suggest focusing on learning the following topics and concepts:

  • Client-side & Server-side (Frontend & Backend)
  • APIs (and their components)
  • How programming languages work (Compiling)
  • Cloud Computing (Understand scaling)
  • Architecture (Microservices & Monoliths)
  • Data Structure, Databases & Database Schemas
  • Software Development Lifecycle
  • How software is deployed (CI/CD)

3. Get technical training through courses, newsletters, and cloud tutorials

It's a good idea to get some technical training to build a solid foundation in software fundamentals. There are a few ways to do it.

You can take a technical literacy course created specifically for product managers like Skiplevel and/or subscribe to newsletters that teach technical literacy in simple terms like Technically. Cloud computing companies also offer lots of beginner, intermediate, and advanced tutorials across many of the topics I noted above including in frontend and backend, data, APIs, infrastructure etc. Here are 4 beginner Cloud tutorials from popular cloud companies like AWS to get you started.

And most importantly, remember: with the right mindset, dedication, and resources, you can go a long way in building confidence in your technical skills and knowledge!

This is an amazing piece, thank you for sharing!!! I am a designer and always have felt this need to learn coding to form better relationships with the engineers, but this is a new perspective that I might just need some tech mentoring!
You're welcome Michele! Having courage to ask "stupid" questions already goes a long way in building confidence in your technical skills!I suggest reading this Twitter thread I wrote about this topic:
Also, I'm hosting a webinar on "How to Master Technical Literacy for Product Managers" on Wed, May 10th. Please register if you feel you'd get value from the webinar! There are only 200 spots and we're already at 176 so register soon. Here's the link:
This is great insights, I am an aspiring PM and one of the gaps in trying to address is how to be more technical or have a better understanding of technical concepts to be able to effectively communicate with the technical team. I love that you shared some topic suggestions!You mentioned that sometimes the way user stories, mocks and business requirements are not crafted in an effective way that helps you. What would you like to see more of / what needs to be incorporated to help you succeed? What are PMs leaving out and how can they fix it?Thanks!Vivian
This is an awesome question Vivian. I have a lot of tips for how to write user stories and business requirement documents and can't really share them all in here, but I write about them via my newsletter and on my social media. I highly suggest you subscribe and follow me on both:Newsletter -> https://newsletter.skiplevel.coTwitter -> -> the meantime, here are a couple of articles and social posts that answers your questions.3 Tips for writing business requirements for your engineering team -> product managers get wrong about user stories: impact in a PRD:
great i'll check them out! thanks irene
Also, I'm hosting a webinar on "How to Master Technical Literacy for Product Managers" on Wed, May 10th. Please register if you feel you'd get value from the webinar! There are only 200 spots and we're already at 176 so register soon. Here's the link:
I hope that once I land the job I have devs as generous as you! Thank you for the resources.
You're most welcome!
I'm hosting a webinar on "How to Master Technical Literacy for Product Managers" on Wed, May 10th. Please register if you feel you'd get value from the webinar! There are only 200 spots and we're already at 176 so register soon. Here's the link:
Thank you for sharing this perspective. I came into tech from a liberal arts school and thought I needed to code, but I didn't get the hang of it. I didn't need to code in order to do application support, or technical writing, or governance work, so I learned about different parts of tech from listening to more technical peers and a lot of repetition. The pieces of the puzzle started coming together and I realized where there were gaps and where I could learn more.
This is amazing perspective Erin! And yes, this is completely right. Coding is very hard and it's a separate skill from being "technical". You can be technically literate without learning how to code. On the flip side, there are lots of engineers who know how to code but really are not technically literate.Check out ( if you want to fill in your gaps with more formal education. I created the program to be comprehensive with hands-on exercises!
Also, I'm hosting a webinar on "How to Master Technical Literacy for Product Managers" on Wed, May 10th. Please register if you feel you'd get value from the webinar! There are only 200 spots and we're already at 176 so register soon. Here's the link:
Great post, thank you!
You're most welcome :)I'm hosting a webinar on "How to Master Technical Literacy for Product Managers" on Wed, May 10th. Please register if you feel you'd get value from the webinar! There are only 200 spots and we're already at 176 so register soon. Here's the link:
Thank you so much for this!! I am a PM taking a full-stack course right now... and this truly resonates. While I've enjoyed the course so far (its great for exercising the language-learning side of my brain), I think you are so right that there are better ways to feel more technically adept within my role. Excited to explore the resources you've shared!
So glad the tips I shared are helpful for you!I'm hosting a webinar on "How to Master Technical Literacy for Product Managers" on Wed, May 10th. Please register if you feel you'd get value from the webinar! There are only 200 spots and we're already at 176 so register soon. Here's the link:
I'm hijacking this thread to ask : If you already ARE technically literate as a PM, how do you communicate this to the people (likely not engineers) who want to hire you? I don't have a technical degree, and I don't have a lengthy portfolio of side coding projects to share, but my biggest strengths as a PM are that I know what the engineers are talking about and can ask competent questions. I've even wound up more than once being the person to fight back against the rest of the PM team or other business people when they make unreasonable asks of the engineers. But when I apply for stuff, I don't feel like there's a great way to signal that I have this competency. Everything I write in a resume or cover letter just feels generically like "Yup, that's what a PM does," and I get no bites. Or I get an interview, and the questions seem more focused on how I would format my list of demands to present to the head code monkey rather than building something collaboratively and I nope on out. Then I come hang out here and on reddit, and I see posts like "Hey guys, I've been a PM for two years at Major Famous Company X. Can someone please explain what an API is?" and I just bang my head on the desk. I don't mean any disrespect to the PMs who got where they are without technical knowledge, because I agree it's a different skillset, but it's frustrating. Any thoughts on how to sell myself as "the engineer's PM"? Or am I just being naive that that's even something a company wants?
Also I'm hosting a webinar on "How to Master Technical Literacy for Product Managers" on Wed, May 10th. Please register if you feel you'd get value from the webinar! There are only 200 spots and we're already at 176 so register soon. Here's the link:
Also interested in answers to this!
This is a great question and unfortunately there is no simple answer. You might've noticed that many product manager job descriptions ask for past coding experience. This is actually a placeholder for asking for a product manager who is technically literate and can communicate well with engineers, not that you'd necessarily need to code on the job. I suggest mentioning this to the hiring manager(s) when interviewing and adding bullet points to your resume under your past job responsibilities suggesting your close and effective communication/collaboration with engineers.The other perhaps more convincing way to show that you're technically trained is to have a certificate showing you've gone through formal technical training. My technical training course for PMs ( provides a certificate once you've finished the program. Here's an example of the certificate: @sarahclarke
Thanks! Do you have any suggestions for wording to describe this effective collaboration? If I just chuck "effectively communicated with engineers" on there, it sounds silly, but any time I try to add specifics it's like "to deliver blah blah product" etc, which just sounds like anything any PM would say.
Enlightening and reassuring, thank you!
What an amazing post! Thank you so much for taking the time to write it and also to tech mentor people! I am a non-techie and after many years of experience I've become comfortable conversing over developments with my techie colleagues but - omg - you just gave me the best idea for how to get my team to that point without much quicker than I did!!! Thank you. It seems to obvious now! 😂
Amazing! Glad that was helpful Sarah :)
Isn't it funny how people on all sides of a team hinder themselves by not wanting to ask questions due to fear of appearing ignorant. The fact is design, engineering and product are all different disciples each with deep wells of complexity and no one single person on the team can know everything about each. Hence why cross-functional collaboration and communication are so important. And the fact is each person on a team should be mentoring each other in learning more about the reasons behind their work as part of the process. As a designer I thought it was always funny that it was considered more appropriate for me to want to become more technical, but rarely did I hear anyone one the engineering team say they wanted to learn more about design. Every successful team needs all the disciplines to work together to communicate and educate each other as to why decisions are made and the time it takes to get things done. This should be a given and certainly something I'm aiming to create a culture of on my current team.Great highlight of the issue though and kudos for sighting the problem and seeking to fix it.
If anyone want a fast and comprehensive way to immediately boost your technical knowledge, check out the Skiplevel program ( I created. I have a lot of knowledge and industry experience having been a software engineer working with and mentoring product managers for 10 years and I included all of my expertise in the program, including hands-on exercises with industry-standard tools.Feel free to reach out and add me on social media if you'd like to learn more! My handle on all social platforms is @iamireneyu.