Kellogg PM week 17: Nature of machine learning work
In previous week, I focused on the gentle introduction to data science and data analytics for product manager. I learned the simple meaning of analytics: descriptive analytics, predictive analytics, and prescriptive analytics. I rethought about correlation and human bias in data work. All in all, I learned the very beginning of data analytics for a product manager.
In this chapter, we focus more on machine learning since it’s a good foundation for operational improvement. The instructor tauge me types of machine learning including supervised learning and unsupervised learning. I think it is usual for any course to discuss and explain the overview of machine learning. After that he explained the basic process of how a machine learning model is constructed, built, and by whom. The instructor focused a lot of buzzwords in the data world such as jupyter notebook, feature engineering, and job description of each data specialist.
Let’s take a step back, as a product manager you don’t need to know the details of everything unless your product is related to it. Having these buzzwords in mind can reduce frustration and friction when moving into a more sophisticated product that embedded machine learning or artificial intelligence. I think the key is to be able to manage this kind of unknown process, the nature of analytics tasks are different from engineering tasks. Below, I have outlined 3 things I humbly think: data analytics or data science tasks are different from engineering tasks.
First, it’s not linear. Contrary to the engineering world where it’s either linear or a loop of flywheel, some analytics project processes are like a mess. You can’t have a specific timeframe of the work to get done. You can’t expect it to work in the end. From my experience the more ml related the more linear the process would be, on the other hand the more unclear and exploratory it is, the more of a mess. I think this is critical because once you know this nature of work, you can plan, communicate, and set expectations of stakeholders.
Second, it can be outdated real quick. I mean when we first build something it depends on the process of your product once the process changes, customer behavior changes, then the model might no longer be valid with the new set of data anymore. Even if you don’t do anything with the process, customer behavior still can change. This means it requires headcounts to work on it and ensures that this stuff would work properly.
Third, data science and analytics requires teamwork too. You can’t have a single data analyst or data scientist to solve a complicated project alone. You can think of this analogy, when you manage to launch a project or improve a product. You need to have developers, developer manager, quality assurance, devops, or even with ux/ui designer. In the analytics world, you might need data engineering, data scientist, data analyst, machine learning engineer, or even with machine learning ops. A great experienced person in this field might be able to do part of everything herself but you can’t expect one person to handle everything.
Additional Readings
- 5 Machine Learning Case Studies to explore the Power of Technology
- 27 Incredible Examples Of AI And Machine Learning In Practice
- Classical Examples of Supervised vs. Unsupervised Learning in Machine Learning
- Discover Feature Engineering, How to Engineer Features and How to Get Good at It
- The Power of Feature Engineering
