We sat down and had a conversation with Yetunde Dada, Principal Product Manager at QuantumBlack. We discuss the future of product management within data science, and why it’s essential to have great qualitative insights when working as a technical product manager.Yetu Dada on data science and product discovery
Ben: To kick things off, can you tell us about your role?
Yetu: I am a Principal Product Manager at QuantumBlack, an advanced analytics company that was acquired by McKinsey. I've been at QuantumBlack for the last two and a half years as a technical product manager on a product called Kedro. Kedro helps data scientists and data engineers produce maintainable modular and reproducible data science code. It is the backbone of any data product that you may have. It's also open source and has been receiving a lot of industry-wide adoption because it solves a lot of problems around scaling analytics across an organisation.
Ben: So you mentioned that you’re a technical product manager. Can you paint a picture for our readers about what this entails?
Yetu: It is fundamentally like any other product management role, with scope to think of technical users and with a scope to think of more technical aspects of a product. You still need to understand user problems and decide how you're going to tackle them with innovative solutions, which you do in conjunction with engineers and designers. For Kedro it's a Python framework, so primarily when we look at how we prototype and present things we are doing using Python. You have to be a little bit creative there!
Ben: It seems like product roles are becoming more common in data science and advanced analytics. What impact does a product mindset have here?
Yetu: Well, the MBA answer here would be, “It depends”. It depends on whether you want to build something that's useful. Product management is taking off in this space because too many things are created that have minimal impact on end-users or the business. A lot of literature talks about how 87% of data science and advanced analytics projects fail. One of the primary reasons why these projects fail is because they were not solving an actual problem and didn’t bring any value to users. That is a product management problem and why it is important to invest in discovery.
One of the primary reasons these projects fail is because they were not solving an actual problem and didn’t bring any value to users
Ben: Can you tell us more about your discovery process?
Yetu: Great question. Our product discovery process is focused on answering four key product risks. This thinking comes from Silicon Valley Product Group.
You need to tackle value risk for our users – are our end users actually going to use this thing? Usability risk - can they use it? Business viability risk - do our business stakeholders support this? And, feasibility risk - can we actually build this? We constantly have to ask these questions when thinking about features that we are building in our product. More importantly, during discovery, we can’t be afraid to uncover bad results! The idea for us here is to mitigate risk, so we can deliver something valuable and not waste any time and effort on features that are not useful.
In practice, this looks like a lot of prototyping, but that is preceded by extensive research, so we actually come in with insights that indicate that there is an actual problem for users.
Ben: Is it mostly qualitative or quantitative stuff that kicks off an area of investigation or discovery?
Yetu: It’s both and we do it continuously. Although quantitative insights often can alert you to something. For example, tracking if a user is using your features in your product. But qualitative insights are important when we are trying to understand the ‘why’. It is also pretty important that the whole team is involved, or at least the different disciplines (design and engineering etc). Often the mindset in design is to explore and validate things as much as possible, whereas the engineering mindset is to deliver quickly and throw stuff away if it doesn’t work out. I think getting the balance right is really important, although I would say as a product manager I tend to lean more towards the mindset of exploring to the point where we can identify a solution we as a team are relatively confident in.
Ben: If you could change one thing about how your team works what would it be?
Yetu: This is actually related to the earlier part of our conversation, specifically for technical and platform product managers. You wouldn’t expect this, but there is a very heavy reliance on qualitative techniques for understanding how your product is being used. The tools I have available for product analytics are not very mature and it is actually quite difficult to get good data on usage. A lot of Product Managers who transition into technical product management are astounded by the lack of product analytics available that they might have had otherwise had available to them if they were working on a web application-based product, for instance.
Ben: As a final question, what are you most passionate about when it comes to the future of data science?
Yetu: How we think about ethics and fairness is really important. Particularly in data science product management. I get the feeling that today, fairness and ethics is a ‘checkbox’ activity or something that we think about far too late. I would really like that type of thinking to become ingrained and embedded in the way we do things. When we are confronted with issues like dataset bias or models that could be discriminatory, it shouldn’t be an afterthought. We should do the work to correct these things where we find them.