Sprint 2 — The Team
I am an ML product manager sharing my perspective based on my own experience in software products. This is part of series to explain to aspiring Data Science professionals what is like to work in a product role. The start of the series is here.
As cliché as it is, no one does it alone. Not even the super techie with the unbelievably good idea that makes a bazillion dollars. To get a great idea into a product that will make customers glad that they bought it, takes a lot of talented people. With respect to this article, The Team are the people involved in launching and maintaining the software product. I’m hoping you will have a better understanding of the roles after reading this.
Data scientists (DS) can have a variety of responsibilities. Yes, the job is often ill-defined and varies widely between companies. I am going to talk about The Team from the perspective that the DS is primarily focused on performing exploratory data analysis, model design and validation. Its not that way everywhere but often can be, particularly in large companies. ( Also, I’ll say “model” in a general sense as any machine learning or algorithmic solution that processes data and generates an output.)
A software product will have a lot of different features. The DS is often contributing to some calculation or decision making feature(s). However, product features also include user interface, workflow, and also there’s the architecture, logging, security, data cleaning, processing, and transformation just to scratch the surface.
So who is doing the rest? From a very high level:
- Product Manager- Specifies the product feature that is required to solve the customers’ problem. Works with the team to ensure the implementation matches the specified solution.
- Dev team- Focuses on the implementation of the product feature, including the model as part of the solution.
- QA- Ensures that the implementation is built right.
Each member of the team has different objectives but they are all important to ensure that the product feature is delivered correctly.
The PM must understand what the customer needs and how the feature fits into the existing product. This person will often describe the problem to the DS along with context, constraints and what will constitute success in the solution. Sometimes the first iteration of the model must be simple and may give less than optimal performance due to the constraints. The PM may decide that the feature will be implemented in phases with improved performance and more sophisticated models provided in the future.
The Dev team consists of may types of developers including front end, backend, DevOps… and if you work for a highly specialized team there will also be titles that include Data Engineer, MLOps, Machine Learning Engineer. Think of the Dev team as the infrastructure specialists. They are concerned with:
- optimization of code for performance (speed, error catching, etc.)
- design patterns for re-usable code
- testable code
- maintainable code
- monitoring performance
- security protocols…
The PM specifies what needs to be built but the Dev team executes. (Think of it as What vs How.) The DS has created the proof that it can be done and the Dev team takes it from there.
But that is not the end of it. QA tests the Dev team’s code to catch bugs and ensure that the implementation passes the acceptance criteria. They work with the PM to make sure they understand the objectives and the specification so that they can do their job well. They often work with DevOps to set up a test environment specific to the product they are testing. Sadly their work is often given too little because they are the last in the workflow before the feature is released.
All of these roles exist in software products without models, but when you add the ML component the complexity can balloon. This image illustrates what is required to support the model in code, note that the ML code is the tiny black box in the middle of the diagram. I highly recommend reading the article on the hidden technical debt
In short, as a DS in a product team you will be delivering a component that will make the product feature better (or perhaps possible at all). Your role will be to create the model and communicate its potential and failures, areas for improvement, ways to monitor, and future enhancements. Its your creation and you will know it better than anyone else. With this insight, you will enable The Team to let customers enjoy its benefits.
End Note: I know that some of you DS are doing combined roles such as data engineering + DS or PM + DS, or other. Kudos to you. Perhaps in a future article I can vent about DS job descriptions that describe a unicorn…that person that will fill all roles.
