[fareesh]

Thanks - this validates many of the assumptions I had about this part of the process.

It has been challenging communicating many of these realities to non-technical folks, who seem to be quite misguided about implementing these types of systems as opposed to "non-ML" systems where there is a less imperfect and more predictable idea of what's possible, how well it will work, and how much effort is required to pull it off.

[tel]

In my opinion, there's space for a "ML Product Manager" as a specialization for someone who understands the technical aspects of both software and ML systems, but also can design roadmaps, build stakeholder buy-in, and generally shepherd the project. That feels like a big open space right now.

[samcodes]

Yeah IME expectations with ML are just the worst. Somehow, non-ML-educated stakeholders expect it to be predictable, like they pretend traditional software engineering is... but also to be magical in scope.

[tel]

Honestly, it's not surprising. ML is billed as a tool, one that in the last 5 or so years we've surprisingly "figured out". This is vast overselling, but it still creates the basic mental model for folks without further training: ML is a tool you can apply to certain situations to achieve outcomes that you used to need people for, especially in vision and NLP.

I personally believe this is false, but also false in a way that we're remarkably far away from that. Even more than software, predictive automation is a process. It often relies on particular customization to your own situation to be successful. It can demand vast resources. It's wildly difficult to debug.

So we should be working to retrain those around us. ML is a process.