In my experience, the vast majority of PMs could not describe the difference between TLS 1.3 and 1.x.
The problems you describe are legit but unless you have extremely technical product managers, hiring more PMs will only make the problem worse.
The problems you describe are legit but unless you have extremely technical product managers, hiring more PMs will only make the problem worse.
Does the vast majority of PMs need to tell the difference between TLS 1.3 and 1.x?
I mean, is that a relevant aspect of the vast majority of products?
If not, why should a PM bother about irrelevant details?
One of the cardinal sins of proponents of this "engineers should rule everything" mentality is failing to tell apart the critical factors from the irrelevant details, and conflate not caring about obscure implementation details with incompetence. Except the cheekiest little fallacy in software development circles is that the purpose of all software projects is not correctness or code coverage or uptime or resilience. The purpose of each and every single software project is to serve their users' interests. That's the critical part of a project, and the thing that PMs focus on for the right reasons. Naturally, PMs prioritize work with the biggest impact. Does TLS trivia fit this requirement? No.
Non-technical PMs tend to gloss over things like that as an engineering-driven feature. Clients don't ask for TLS 1.3 (at least until it's often too late) because they generally aren't considering TLS trivia until it comes time for their next audit.
You see, I don't think that's true at all. If it was, certainly you'd have clients complain loudly enough for the PMs to notice.
But that doesn't seem to even register a concern, both from the client and from the PM point of view.
Convenience is a nice-to-have, and fixing problems that don't exist registers even lower in the priority queue.
> Non-technical PMs tend to gloss over things like that (...)
See, this is where I think we disagree at a very basic level.
There is no such thing as a technical and non-technical Product Manager, because a product isn't technical. A product is something that meets the needs and expectations of its customers. A Product Manager's responsibility is to know their product and manage it to meet its clients' needs, and in the process help guide the development effort to maximize its returns on investment. Whether it's to paint a button red instead of blue, or to tell if they need to upgrade TLS, a PM's job is to read the room and deliver what meets the needs.
Because engineering failed to consider these details. Now I'm the one that has to point out how amateur we look when in some areas we don't require TLS and others we're so strict, we only have 1.3. Engineers (management or rank and file) who can't understand why this is a problem is exactly the reason you need technical PMs.
I don't think you got the point. The point is that no one cares, or think it's important enough and much less critical to justify wasting time with it. Product Managers are there to create value, and spending time on things no one notices is not how you create value.