As a former sales guy turned PM, I get this question too. Agree with your recommendations. I've seen a lot of junior PMs get hired without a CS background, but they tend to spike in data/growth, business/enterprisey stuff, or design. Even for these PMs, technical chops are important. An interesting discussion is why it matters to be technically curious and how to do it. Here’s how I think about it…

Why it matters:

Being technical as a PM is a means to an end. You’re not writing code, so why is it useful? In my view,

1) it helps PMs gain credibility with their eng partners,

2) it helps PMs make better decisions since they can anticipate constraints and possibilities,

3) it helps PMs ensure a team is building effectively for the short and long term

Technical curiosity, then, is how a non-technical PM develops the same full understanding of their product and their team that a technical PM can mostly intuit.

Some ways to pursue it:

- Participate in purely technical decision-making with engineers. If you’re totally in over your head, just listen, and ask your “dumb” questions afterwards of an engineer you’re comfortable with. Over time, you’ll be able to ask probing questions in these discussions, and not only learn more about your product and its codebase, but also help your team make better strategic choices.

- When working with an engineer on scoping a project and doing costing for it, work to understand why some features are simpler and others more complex. Dig in on the things that will impact performance and load times. Try to get into the weeds so that you start to get a mental map of all the different building blocks of your product.

- Keep an open mind to purely technical work. Of course, your roadmap should be developed with input from all your cross-functional partners. But one area that’s often neglected is non-user-facing projects that can accelerate execution in the future, minimize future distractions, and open up new product opportunities. Investing in platforms and tech debt is always a difficult tradeoff, but be open to the possibility of it being worth it, and let your eng partners help weigh the hard tradeoffs of prioritization with you.

Mostly this is all an exercise in learning how to learn technical things, and learning how to think like an engineer. You don’t need a CS degree for that. Once you can think this way, you just have to worry about all the other things a PM has to do.

PM at Figma, ex Dropbox. Some photos at benstern.co