I was a non-engineering background PM (I dropped out of high school). I can tell you about what I didn't know early in my career that was painful for me then (and something I've internalized hard now): It's ok to say "I don't know". Conversely, saying "I have the answer" when you don't is lying.
The worst thing you can do as a PM is to make a technical assertion that you don't understand to a technical audience. You will instantly lose the audience's respect and trust (and those things are very hard to get back). To my mind, being technical is about actually understanding how things work such that you can make arguments grounded in facts and experience about systems. If you make arguments like "why don't you just rip out Mongo?" without understanding how painful that would be, it's really hard for people to believe in you.
Being non-technical doesn't mean opting out of technical discussions, it just means saying "I don't know" when you don't know. This is something I see PMs screw up all the time.
In reality, nobody knows everything, but pretending you know something when you don't is a verifiable road to hell.
Lastly, product is about two things: intuitive narrative and fact-based decision making. If you can't reason about your product hypotheses from first principles and/or bring established respected metrics to the discussion, you deserve to not be taken seriously.
Related tip: ban the word "just" from your vocabulary. As an engineer, hearing a non-engineer say "can't we just X" is never a positive experience. Just that one word carries so much baggage - it's the shortest way possible to say "I don't value your expertise or expect you to have thought this through".
Sentences with "just" in them always work better if you drop the word.
"Why don't you rip out Mongo?" - now we can have a conversation.
"Why don't you just rip out Mongo?" - you've just started a much more hostile conversation entirely by accident.
To add to your comment, "I don't know" is a critical phrase, and so is following it with "help me understand the technical issues at play here" -- technical people generally love teaching someone who is curious, respectful, and has asked them to help guide a decision that is at least in part technical.
This works especially well when they can see you making a sincere effort to understand, by paraphrasing and repeating back what they've explained to you: "So what you're saying is that this component works like such and such, and one weakness of the approach is xyz? Am I understanding right?"
Also involving them in the business issues at play can help - "I hear you saying this approach will be more robust in the long run, and what you say makes a lot of sense to me. I'm struggling to balance this against business issues of the expected lifetime of this feature and our target ship date. If we are in a situation where we don't expect to use this feature for long and we have ship date pressure, what are your thoughts on the approach that is less robust in the long run?"
Doing the above helps keep people from thinking you're a poser who refuses to understand the issues, and also helps technical people from becoming grumpy about what may look like idiotic decisions that are in fact driven by a business issue that nobody told them about or included them on.
The worst thing you can do as a PM is to make a technical assertion that you don't understand to a technical audience. You will instantly lose the audience's respect and trust (and those things are very hard to get back). To my mind, being technical is about actually understanding how things work such that you can make arguments grounded in facts and experience about systems. If you make arguments like "why don't you just rip out Mongo?" without understanding how painful that would be, it's really hard for people to believe in you.
Being non-technical doesn't mean opting out of technical discussions, it just means saying "I don't know" when you don't know. This is something I see PMs screw up all the time.
In reality, nobody knows everything, but pretending you know something when you don't is a verifiable road to hell.
Lastly, product is about two things: intuitive narrative and fact-based decision making. If you can't reason about your product hypotheses from first principles and/or bring established respected metrics to the discussion, you deserve to not be taken seriously.