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.

> "why don't you just rip out Mongo?"

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.

By "working under" do you mean having an engineer report directly to a product manager, where the PM is responsible for the engineer's career growth, compensation, reviews, etc?

As a former engineer turned product manager, I would not advocate such a reporting structure. A PM wouldn't be the best person to help manage an engineer's career growth and everything else. I think it's perfectly fine to be on the same cross-functional team though.

> Conversely, have you ever worked under a non-technical product manager you loved? Would you mind sharing details about your situation?

I've had several.

The key feature is that they bring something to the table: I don't actually need technical guidance on how to build the product -- I (or another engineer) knows enough to solve the technical aspects, that's why the corporation is paying me (or them). But what I do need is help coordinating with other teams, help interacting with executives, help prioritizing tasks, help with the kinds of brainstorming exercises that nucleate the project plan, help with understanding and interpreting customer feedback, etc. Colloquially, the "people side" of the job -- it's just not what my skill set is.

So, I actually prefer non-technical PMs: I want people who complement me, not people who are probably less informed about technical issues trying to micromanage my choices there. A non-technical PM is bring a skill set that diversifies a team of engineers, and helps the team more successfully do its job of interacting with both the corporation and customers.

If the PMs here will indulge a couple questions from me:

1. What skills are most useful in an engineer, and how do we make you look good/help you make us look good?

2. What advice would you give to an engineer looking to move into a role like technical adviser, which more directly interfaces with management and executives?

Love your reflections here!

I'm a non-technical product manager, and I've heard the same sentiment with the engineers that I work with. My engineers want business context and user context - they don't need someone to provide technical guidance.

To address your questions directly:

1) The most helpful skill in an engineer is the skill of speaking up. When I reflect on the dozens of engineers I've worked with, I consistently find that the ones who provided the most value were the ones who would question me constructively.

My specs aren't perfect, because I don't have a detailed understanding of the technical constraints. I love it when engineers tell me why my spec won't work, and then provide multiple alternatives for how to get the spirit of my spec to work.

As for how to help you look good - I really appreciate it when engineers honestly keep me informed about their bandwidth. That way, as I keep stakeholders in the loop, I can accurately set their expectations.

It's never helpful when engineers say "I can complete these 15 tasks by next week", and wind up only completing 2. On the flip side, it's equally unhelpful when engineers say "I can complete only 2 tasks by next week", then wind up knocking out the entire backlog.

2) I can't speak clearly to "technical adviser"-type roles, unfortunately, since I'm not technical to start with. That being said, the technical folks who interface with management and executives are typically managers of managers of engineers.

In other words - the engineers who drive the technical vision of the company are also the ones who are directly responsible for their teams' execution on the tactical work.

>>>> What skills are most useful in an engineer, and how do we make you look good/help you make us look good >>>>

1) I don't think it's technical skills per se (your hierarchy would have reviewed that when you were hired). I think it's more of an attitude. I've lost count of the number of times PMs make a case for a feature to behave in a specific manner and Dev doesn't want to invest the time or effort to even investigate if it's possible/how that can be done. From Dev POV - we already do it this way so live with it. PM makes the argument that is not the best from a functional POV but Dev is simply not interested.

Note: I'm not saying all Devs behave this way, just pointing out a technical way of doing something might not provide the best functional experience and being open to explore or understand what PM is trying to achieve is important.

2) Ability to look at the big picture. Sometimes one is so focused on the immediate tasks and its technical design that they miss the fact that the PM has a road map and this feature or set of features is just one bit on the roadmap. This means that whatever is being built now should if possible make it easier to implement the other features down the line.

I think it's OK to start out as non-technical product manager but over time they should pick up some technical knowledge. Some product managers refuse to learn anything technical which doesn't work well in the long run in my view.

Same for developers. They shouldn't just wait for requirements but also understand their users to some degree.

In the end engineering and product management should develop some competence in the other's area. Otherwise communication is very tedious and error prone.

This is an interesting point. The first several years of my career, I was an engineer working on low level operating system stuff. I later switched to product and my technical chops really helped me earlier in my product career. As I got more senior however, the business, strategy, and product vision components of the PM role became more important and my technical skillset was less "directly" useful. It was more helpful in getting me trust with senior engineers, and therefore transitive trust with executives (because eng directors are often the first people a new exec will turn to to "read" the org in a large company)

Depends what you mean by non-technical. I've worked with product managers who didn't have an engineering background, and thst worked fine as long as they were able to understand the trade offs that we presented to them. I've also worked with product managers who just couldn't grasp any sort of technical nuance. That did not work out well.

I notice you phrase it as "work under", and I wonder if that is part of the issue you've had. Where I've worked, while it was true that the PM was guiding the direction of our work, they weren't our boss- they were simply a part of a team with a different role (in the same way that QA often takes direction from engineers, but they don't work for them). If the relationship you had with your PM was "one way" in this sense, then I can see why you wouldn't like it...

I typically have a good time working with non-technical PM's. I typically have a bad time working under non-technical PM's.

20-years in the industry and counting, and I've never even MET a "technical product manager".

I have met a handful of people who somewhat thought of themselves as technical. Because they did a touch of Visual Basic or something in their first job out of school, before immediately washing out and pursuing a non-technical career. Some of those guys liked to talk loudly about how much they're "one of you", and "get it", etc.

Without exception, that subset of PM's/PO's were absolutely dreadful to work with as a developer. I would ONLY want to work with a non-technical PM/PO, who stays in their lane and is comfortable with their role.

I work at a big company and about half the PMs I work with were developers, myself included (for around 15 years). I have found this to be totally normal both when I was coding all day and now that I'm managing all day. There are no lanes.

You sound insufferable

CS degree and am an engineer now, but I was a PM for ~6 years and hired/managed PM's.

I split technical background into two things: domain expertise and engineering experience. I value domain expertise most, engineering experience second.

Whether it's a dealbreaker really depends. In adtech, I wouldn't consider either matter a dealbreaker even for senior PM's. In cybersecurity, lack of technical background would absolutely be a dealbreaker, and except for junior hires, I would consider lack of domain expertise a dealbreaker too.

One problem domain is much trickier than the other and much more prone to paying the cost later for shortcuts taken earlier. I want to know my PM can navigate that with nuance.

By non-technical do you mean someone who has neither previously been a developer nor have a CS/Eng degree? I've worked with both and have found the lack of an engineering background is not determinant in my opinion of the PM. For the non-technical PMs with whom I've worked, the more important factors are willingness to listen when I explain the impracticality of a proposed change/feature and their own willingness to dive deep into understanding the problem domain and customer pain points.

Depends on the product and the actual functional relationship between PM and engineers. Is the product manager mostly working with designers and customers to see what is needed for the underlying project, and then communicating that equitably with engineers? That's ideal. Is the product manager making high-level technical commitments to management (e.g. "we are going to move our VMs from AWS to Azure by EOW!") because it's what they want to hear and then acting extremely bossy and assholishly to engineers trying and likely failing to meet that deadline? Do they not even do anything other than acting as a second manager who is way less qualified? Then they are actively making the work environment worse. Both situations are possible and honestly technical skills don't even matter that much here.

Now, if you are working on a very software-y product like SAAS or some other thing where other developers are the consumers, then you should not be non-technical (or if you are non-technical you should have a ton of experience being the PM for technical products) simply because you have little hope of understanding the needs of the consumers of the product. But this is a minority of products

The positions I've worked with non-technical PMs has been one with a kind of dual structure - there was a lead developer who was the technical expert as well as largely the PM's equal. The PM was more of an ancillary addition to the team, and any decisions were filtered between the two.

From my experience, a PM being technical can not do harm, but as a PM you work with multiple people: both front end backend engineers, data analysts, designers and maybe sales/ops/etc.

You can't have a background in every talent you work with, so for me as an engineer, if you don't have a technical background, no big deal.

What's important in your behaviour is, as some other comments as stated:

- Don't fake it. If you don't know, say you don't know, it's ok.

- Be (honestly) curious, and do everything you can to understand how things work. You don't need to understand how a specific database scales, but if a specific product connects to 3 different databases, understanding why, and what that implies technically is very important.

- Being honest and curious will build trust with your team. You also need to trust 100% your team. If someone tells you that something you thought would be easy is in fast hard, don't question. Ask questions to understand why and get more context on how your product works. Don't ask to make sure the person is not BS'ing you, ask to know, out of honest curiosity.

- Be on top of 100% of your product. Nobody else should know your product better than you. If you own a complicated onboarding flow, you should know exactly, by heart, all the different steps, situations, how someone gets to what steps, what happens when someone signups with a wrong email, etc etc.

All those previous point are true for engineers, design, data and every other role on your team. You are the CEO of the team. That doesn't mean you have authority, but that means you work with VPs that bring expertise, from it, you make strategic decisions on where to bring the team. So you don't have to have a technical/design/data background, but you need to be broad and curious enough to understand what everyone explains you and what to do of those.

The worst PMs I worked with were the kind of PM who would not make such efforts, ask repetitively the same questions or make the same wrong assumptions because they don't know their products and don't understand / learn / remember when you explains who/why something is hard/not worth it/not possible. The ones that come and say "but why don't you just drop mongo" (see sibling comment).

Oh yes. It is horrible working with a non-tech PM who doesn't understand the issues with engineering.

non-technical PMs are the best. They don't try to do things they can't, they take our word wrt complexity of implementing things and tradeoffs. And they are mostly women, which brings an extra layer of much-needed balance.

A counter point - I've worked with Developers who have told me a load of BS. In those instances I knew it was BS because I was quite conversant with that bit of knowledge (this is not to imply that I'm some astounding developer; but anybody with some basic technical knowledge would have realized it was BS).