5 ms·
> In my experience, the vast majority of PMs could not describe the difference between TLS 1.3 and 1.x. Does the vast majority of PMs need to tell the differen
by rewmie 3y ago
> In my experience, the vast majority of PMs could not describe the difference between TLS 1.3 and 1.x.
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.
- aeternum 3y agoGenerally it is quite important especially for SaaS. Old TLS will cause SOC2 cert, PCI cert failures and similar. It is the kind of thing that can derail a major deal as often the 'whale' clients are the ones that really care about security certs while smaller companies and startups don't. 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.
- rewmie 3y ago> Generally it is quite important especially for SaaS. 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.
- snapetom 3y ago> If not, why should a PM bother about irrelevant details? 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.
- rewmie 3y ago> Because engineering failed to consider these details. 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.