How to converse with a non technical PM?
We are working on a technical product solution which provides APIs in a B2B fashion. We do not have any interface apart from these APIs. There are some internal tools which replicate this functionality (web dashboard) for us to view the data and some smaller B2B Companies to use, but is outside the scope of our Product / Team as it's just parity that is maintained.
Our PM is not a technical person and sometimes it gets very hard to explain the reasons why something cannot be done. Or their suggestions completely miss the point / question I was asking.
They view it from a visual perspective and suggest things that require a lot of back and forth to explain why it isn't feasible.
I've tried in the beginning to help them get setup with basic Postman collections of our API to see the flow. Our EM is also doing their best to prioritise tech vs product.
I feel some of this is reactive and not proactively helping as I feel a bit frustrated to what seem quite obvious which isn't helpful at all.
What do you suggest one can do to better improve communication or even how to view things from their perspective.
The one con is as a PM their calendar is always full
Discussion
(1 comment)- 42 years agoRobinhood, Meta, Course Hero, PayPal
I spent a lot of time working with PMs and designers who aren't technical, so I'm happy to chime in here and see this question (as it's something a lot of engineers will run into).
So I'm going to start with someone you probably already figured out: 98%+ of PMs are not going to be technical.
What's more important than that statement is that you shouldn't expect PMs to be technical or become more technical. Of course, it's great if they are able to do that, but their job is hard enough as is - I think it's an unreasonable expectation.
Given that, I don't think doing things like helping them set up a Postman collection is the right thing to do. That's way too in the weeds, and Postman collections can be finicky as you need to keep updating them and know how to put in parameters and whatnot.
What do you suggest one can do to better improve communication
My main piece of advice is to talk in terms of high-level, easy-to-understand patterns. Based on this question, I assume you are probably "giving them fish" as opposed to "teaching them how to fish". This translates into:
- The PM proposes something that isn't technically feasible.
- You explain why in this specific case it isn't technically feasible.
Again, the PM isn't technical and you shouldn't expect them to be, so in this operating model, this process is going to repeat infinitely as the PM continues to come up with the new ideas (which is literally their job).
So let's go back to my advice and how to do this better. Let's say a common pattern is: It is much easier adding a new endpoint instead of editing an existing endpoint.
If you teach this pattern to the PM and there's an accessible resource explaining all the current endpoints and what they do in plain English, they now have the tools to figure out on their own if their idea is difficult or not and they don't need to run the above awkward 2-step interaction with you repeatedly.
Figure out what these patterns are and share them with your PM - Better yet, put them all into a common document that they can access at any time.
You should also weave this behavior into how you answer their questions as well. For advice on how to do that, check out this in-depth Q&A on how to answer questions effectively.
Lastly, to better understand their perspective, I recommend trying to figure out their day-to-day. You can ask them that directly and/or observe them closely (what docs are they making, what meetings do they have, etc). Of course, listen deeply when they're talking with you as well, which I made a video about here.
