Most data scientists are brilliant analysts who can do amazingly complex things with data, and increasingly software engineering, and yet they are often clueless about why the business doesn't use/value/request their work product as much as it should.
They often assume the problem is communication: if they could just explain their work better, the thinking goes, non-technical business stakeholders would "get it" and start using data science output to its fullest extent. While communicating effectively is important, it won't solve the problem.
Instead, data scientists should learn to think more like product managers, because their main focus is achieving sustainable business value through 1s and 0s. Data scientists, on the other hand, are trained to acquire technical and analytical skills which they become experts in "applying" in real-world settings.
Many data scientists don't fully appreciate the difference, so to put it another way, I'm sharing 5 lessons every data scientist should learn from product managers to get better at delivering value for the business:
- Product managers focus on solving problems, not developing technology. Data scientists should do the same, but with data. Instead they too often focus on the analysis they can do—or were instructed to do—instead of focusing on addressing a clear business problem. Always be crystal clear about the specific problem you are trying to solve, and how much it's worth to the business to solve it. When you communicate the business problem (not your proposed solution) back to your stakeholders, they should say, "yes, exactly."
- Product managers recognize all business problems are user problems, and they use design thinking to arrive at solutions that improve the user experience. This is the hardest one for data scientists to grasp, because they're not used to approaching solutions from the perspective of their business stakeholder. There's a lot to learn on this topic, but to appreciate the point, imagine you switched jobs and are now in your former stakeholder's role. What does your daily work look like, and how much easier would it be if problem X were solved through data science solution Y? If the answer is anything less than "much easier!", solution Y needs to be reevaluated because it's not really a solution at all.
- Product managers focus on building sustainable solutions instead of one-off fixes. It's almost impossible to generate business value on an ongoing basis when you are jumping from one business question to the next. If you're operating this way it also means you're not detecting the common threads: a hundred one-off questions about business performance is really just a small handful of business problems that relate to understanding performance drivers, for example. Too often data scientists try to answer each question, or prioritize based on what they think they can answer if they work their fingers to the bones, instead of thinking about how to sustainably and efficiently deliver performance driver analytics that solve the underlying problems.
- Product managers prefer to iterate and prioritize using user feedback. Repeat after me: I am not the user, so my ideas for improvement are less important that the user's needs. There are two things going on here. First, data scientists need to embrace user feedback as the ultimate way to prioritize what improvements they make to a model, analysis, or app (this is different from letting users dictate what changes to make... that's what lesson #2 is all about). Second, data scientists need to learn how to build solutions in bite-size chunks, delivering first a minimum viable product as quickly as possible, and then improving that product gradually over time through—you guessed it—user feedback. Working in this way is counter-intuitive to many data scientists, but once you get the hang of it, is liberating and makes work more fun.
- Product managers are ruthlessly attentive to whether or not a product creates value, and they use this information to change course. Data scientists waste so much time trying to convince business stakeholders to use the thing they created, instead of recognizing that the thing they created isn't (yet) solving the right problem or solving it in the right way. Product managers approach this issue fundamentally differently, investigating what would need to be different for the solution to be useful, or what incorrect assumptions they made about the problem. This process leads to one of two conclusions: either the solution needs to be improved to drive uptake, or discarded because it's not useful enough to the business. Either way the business wins, even if that means you walk away from something you spent a lot of time on (congratulate yourself for avoiding the sunk cost fallacy and eliminating future opportunity costs, i.e., now you can do something else of greater importance!). When you try to convince stakeholders they should want to use something that they're not using, you almost guarantee the business loses.
Building these skills comes more naturally for some data scientists than others. The best way to learn them is through mentorship, but I'm willing to bet that the majority of data scientists, particularly those who are still early in their career, aren't working with a manager or peer who can help them develop these skills effectively. If this is your situation, consider signing up for a free or low-cost online course in product management, or even just start watching YouTube videos on product management and design thinking. The biggest mistake you can make is assuming you don't need it.
Biopharma Commercial Analytics & Insights | ML & Responsible AI | Wharton MBA | Fuqua MSQM: Health Analytics
2 个月Great read, Alex. I totally agree with you. Data Scientists are building products many times for “internal” customers and it’s critical to have a customer obsession to find “internal” product-market fit and iterate based on the needs and experience of end users. Spot on!
Delivering on Business Strategy by Interconnecting People, Process and Technology with Data as Common Currency and through Impactful Solutioning with System and Design Thinking
3 个月Agreed, and rather than getting requests from random requesters, identifying the actual Who that directly benefits from the outputs is key for prioritization. Also, Success Measurement needs to be defined from the get-go and focus on value metrics (e.g., driving decisions), rather than vanity metrics (e.g., 50 charts, 100 data users, etc.)
Agreed! It’s only a matter of time before leaders realize that data science is, at its core, software development. Writing and maintaining code to build new capabilities.