Sprint 2 — Do what you do
This post is the second in a series about being an ML PM, that started here.
As a product manager you are all about relationships. You don’t actually manage anyone, unless you are the lead/head/director PM. But to do your daily tasks, you are an influencer, a listener, and interpreter.
As an experienced PM, you have already mastered this in
- the business space (selling your features up),
- the customer space (eliciting feedback) and
- in the Dev space (getting your stories in the sprint).
Now there is one more space: Data Science.
The last article really focused on the skills that I think you need to break into the ML PM space. There are a few reasons for having these skills, one of them is to be able to communicate. You can’t have a relationship with someone that you cannot communicate with. There will be a lot of back and forth.
Example: The DS team have created a model or algorithm that works well but has very complex features that will be challenging to develop and even more challenging to QA. You are really concerned.
Your relationship with them is the only mechanism you have to convince them to simplify the design. Consider, they have put lots of time and effort into their solution and now you are asking them to change it because it does not productize well. This can be a difficult conversation.
This is where you leverage the skills that you have already honed. Use the same skills you use to handle all the other problems you solve.
- Understand the problem.
- Communicate it in a way that it is understandable.
- Listen.
- Be empathetic.
- Work together.
You will be very focused on the productization problem. The DS team will be focused on the problem they are tasked to solve. From the above example, as the ML PM you need to be sure that you understand the solution the DS team is presenting to you, Be careful that you are not assuming complexity, there may not be an issue scaling to production. The complex bit may be two lines in a common python library (so no problem) or 200 lines of a home grown algorithm (likely problem).
