Meaningful Conversations with Engineers

I’m not sure if this is an issue which a lot of people have, but I started working as a PM around 1 year ago and one of the main issues I find is that, due to my lack of computer science background, sometimes I feel lost in the conversation.

I feel like this is hindering my capability to do meaningful decisions and having better conversations with my engineers. I want to do better for them and for the company. Anyone feeling the same that would have some advice? Maybe some online course which would explain what a PM should know?


You’re not going to be able to contribute in a meaningful way on how something is built. Not usually. You’ll have to trust the engineering team that they’ll build it right.

You need to contribute on how it will work, who it’ll help, and why it’s important.

And along the way, you’ll need to make cost vs design decisions. All you need from the engineers at that point is the scope of the options.

If you give us more specifics on what conversations you’re struggling with, we can help more.


You’re not an engineer, you’re a pm. Get to know your engineers, lean on your tech lead to make sure the right engineering decisions are being made. If you trust your team, you can let them make the decisions they need to make. Just try your best to understand the basics behind what’s being built on the engineering side.


Mirroring what others have said here, but the engineers that I have worked with appreciate it when you say “would you mind explaining what you are doing here” or “I don’t understand”.

People usually don’t mind explaining what they are doing, especially if they think you are actually interested (which you should be). What people don’t like is someone pretending they know everything.

Engineers know when you are non-technical, no sense in trying to hide it. It can even help to a certain degree!

Be interested, listen, and help where you can.


Plus one on asking questions. It shows that you are humble and aren’t afraid to ask for help, and generally raises engineering’s trust in you.


As a PM you should be focused on what and why not how… that being said being able to have a technical conversation is amazingly helpful. You don’t need to program, but you should be able to understand the basic concepts of programming. Check out CS50, do the first few sessions (all of it if you want) to get the basics down (CS50's Introduction to Computer Science)

That being said, most of what you are likely talking about is more API’s and Database concepts, so depending on on far you want to go doing some intro work on both would be good, and then keep building into bigger concepts of AI/ML, etc. as needed

Focus on the concepts so you can ask the right questions… you don’t need to have the answers.


@Naomi, The what and why part totally makes sense, and yes I agree that some knowledge is always helpful.

The edx course seems super interesting thank you, and indeed I think I need more knowledge on the API and database concepts, any course you might have done that you’d recommend?


I felt this way in my first year or so as a PM too. I tried so hard to follow conversations between engineers, took tons of notes, and tried to pass information between engineers on my team and engineers on other teams.

It was almost all a waste because no matter how hard I tried, I could never know enough to participate in all of those conversations. It’s not your job to understand everything at the same level as an engineer and it’s not a great use of your time to try.

If the team can’t decide between two or more technical approaches, you can help by asking questions that uncover the pros and cons of each approach and weigh in on which will fit the business/user need better. Maybe the engineers are considering a specific option because it’s faster, but if speed isn’t critical then you can point that out. Good questions to ask are things like “what’s the benefit of doing X?”, “Why would someone consider using X over Y?”, “Any downsides to going with X?”

Sometimes I need to be able to talk about how stuff works at a deeper level when I’m having conversations outside my team. In those cases, I’ll talk to an engineer and build a visual mental model of how things work using something like or lucidchart. I’ll usually just make these visuals presentable and rely on them in conversations that require them.

And if an engineer outside your team is asking you technical questions that you don’t understand, have them talk to an engineer on your team instead of playing telephone.


You can learn the tech while serving as the buffer between engineering and other departments, helping marketing and sales, and selling the value proposition of the product.

Leave the “how” to the engineers. Focus on the “Why”.

Don’t be too hard on yourself - you’re only 1 year into the career.

I’ve been a PM for over 20 years and every time a new tech enters the picture, I have the “imposter syndrome” thoughts creeping up and then I have to learn it. Not to the point to being a developer myself, but enough to speak intelligently about it - as in why it matters or the value proposition it provides. You can do the same. YouTube videos, free posts online, blogs, trade groups, conferences, slack channels, GitHub, etc. Remember that as Product Managers, we never stop learning to keep up with our competitors - even after we know our products.

Good luck - I’m sure if you put in the work you’ll be comfortable in no time!


One thing that I intentionally do is precede my comments/questions with “ I know I don’t know what’s going on” or “I’m way out of my scope” or “dumb PM asking a dumb question”. I do it sparingly and only when I feel like I need more technical context or am uncomfortable with a decision. But I also have to remember that I AM actually clueless to technical details and let the engineers do what they do best.


@Heather, Agree, playing dumb is the approach I ended up using the most. My BG is engineering so I had to unlearn and do the « dumb PM asking Dumb question » thing.


I got a lot of mileage out of working really closely with one very patient engineer for about 6 months. We were pretty much just a two man team independently designing a new feature (AI emotional analysis of video clips) and it started out with me just outlining timelines, contributing design elements, coordinating with other departments, identifying needs, etc. But along the way I made sure to ask a question any time I didn’t understand something technical, even if it slowed us down and even if I didn’t really need to understand it to do my job. That’s helped a ton with my general coding vocabulary and ability to talk with engineers! I don’t always know 100% what they’re saying but I know enough now to be able to ask the right questions, quickly understand explanations, or quickly realize it’s something that doesn’t affect my work.

I know six months on a very lax schedule project with a super patient engineer and a lot of freedom is a pretty big luxury, so it’s hard to say that’s the “solution”. But I think trying to replicate that by finding an engineer on your team you get along with and who is patient, and maybe asking them as many questions as you can without slowing things down would help in the long run!

P.S. I also sometimes watch YouTube videos in my free time, computerphile is my favorite (they’re kind of story driven) but khan academy and Tom Scott have some basic instructional ones too. 3blue1brown is a bit more mathematical but I love that one. I don’t always understand the nuance of everything, but it’s kind of like learning a new language where just hearing the terms and immersing yourself into as much as you can helps! I’ll hear a term at work that I’ve heard in various videos and it helps put things together with context clues if I have multiple use examples to draw from.


I genuinely read all the comments but didn’t find the one I looked for.

For sure, you are hired as a PM and you don’t necessarily have to speak the same language, but over time you need to build some self esteem.

I found out following a path like learning an OOP, html, JS builds up some confidence. after you know the basics, I hopped on to a weekend long android project and it did the wonders for me.

Learning the mern stack for the basics is also just fine. it’s not like you will be doing an entire project, but you will get the glossary out of it.

A technical aspect of things is necessarily a part that is sought in pm for the big tech. questions like how does google docs work is even a quite popular question, and kind of a hard one to be honest.

Right now, when I ask a person how can we do this, they usually reply as they like. Of course, there will be the engineering managers who usually walk you through the whole thing. But you know, sometimes you will be encountering people in stress, who may not be able to help you out as much as you desired.

Learning basics doesn’t let you be bossy over these people, it just gets things easier. It’s not like you will be talking over a scientific article, most of the stuff you will ask for will be pretty basic and their day to day activities.

I always encourage associate PMs with no CS background to write a few lines of javascript at least. trust me, that will come handy in numerous occasions.

1 Like

Thank you so much for all the AMAZING and super insightful comments here, I think the main conclusion is that as a PM I should focus on the what and why, and then I should work with my engineering team on the how, being humble, asking questions, being interested and supporting where I have a chance.

Once again THANK YOU SO MUCH ALL!!! :pray:

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.