Leveraging Product Concepts in the Data Science/Analytics Space

If someone were to ask you to explain the purpose of a machine learning model what would you say? For a long time, my response was that the purpose of a machine learning model is to generate predictions based on the patterns that have been recognized and captured from a specific set of data. Technically speaking, this is an accurate response and for a good deal of my career, my focus was on ensuring that my team was able to develop and deploy these models as requested by our clients. However, by viewing the scope of my job solely through the lens of developing a model and generating a prediction, I was ignoring the core purpose of a machine learning model which is to ultimately enable a decision/action.

Though building an accurate & production-ready model is an essential step in enabling decision making, a customer doesn’t need to end up leveraging the end model. Ultimately, business owners end up leveraging tools & solutions because they fit a specific need and because they are accessible/usable regardless of their sophistication. As such, to drive more consumption of their end solutions, data science teams have begun to view themselves less as model development teams and more as product or solutions teams. The end idea is that by viewing analytical solutions as products, an emphasis will be placed on the teams to develop a solution that fits a core market need, is accessible & usable by the end customer, and has been refined through continuous feedback & iterations with the customer instead of a shot approach.

Having become an engagement manager in 2020, my responsibilities grew from simply maintaining quality delivery to ensuring end consumption. As such, I was quick to embrace the idea of viewing data science solutions as products and took numerous online courses in Agile, Design Thinking, and Product Management to see what could be learned and leveraged. The following tools & techniques have proved to be especially useful for myself & my teams in developing consumable solutions and hopefully, they can benefit my readers as well.

1. Focus on developing Personas to understand how customers view the problem and solution.

Often what happens is once an analytical solution is developed, the project sponsor will rarely mandate the use of the solution, instead of leaving it up to the project team to convince end-users of its use and value. To ensure this process goes smoothly it’s important that from the beginning the project team focuses on developing strong personas and user stories.
For example, take a solution built for account managers, which is meant to help them identify customers at risk of churn. For the data scientist creating the model, the results are a reflection of what the data & their algorithms are telling them. However, what customers the account managers perceive as being at risk are based on what their eyes & ears are telling them based on their interactions with their customers.

Being able to bridge the two worlds is difficult, and there are numerous things for the Solution Design team to know about the AMs to properly sell their solution:

· The language/terminology account managers use to describe their business.

· What drivers they look for in terms of understanding the health of their customers.

· Why they might be willing to let some customers churn due to incorrect fit.

· The political sensitivity around describing certain customers as likely to churn based on the overall impact it will gave on the business.

However, should the above knowledge be ascertained and incorporated into the solution design early, Account Managers will be more motivated to use the end solution making driving consumption a less difficult task than if the exercise wasn’t done.

2. Use Storyboards to better understand how your solution integrates into your end user’s journey

The virtues of using storyboards are numerous, but one value add comes in understanding when, where, and how a user will end up employing the analytical solution you have helped develop. Say for example you have been tasked with a tool which based on your inputs can out the optimal combination of pointing offerings, cash-back, annual fees, & promotion strategy to market a credit card aimed at loyal customers. While on the surface it may seem useful, it begs the question as to where this comes into the large product planning strategy.

· Is it used once a year at the annual planning meeting?

· Is it among the first steps to identifying the optimal product from which deep dives will be built upon or is it used to validate existing hypotheses?

· Is the tool used to complement other analyses, or will it be presented as the primary piece of evidence?

· Does it fit the need of product managers to be able to re-adjust their strategy mid-way through the fiscal year as they gather more inputs?

All these questions will help inform decisions on how to develop and market the solution and by storyboarding the customer journey out, it will help enable more accurate & usable decision making.

3. Leverage the help of UX & UI design specialists to create your front end

It’s quite remarkable how versatile those who work within the data science & analytics realm are at leveraging multiple tools, data visualization tools amongst them i.e. tableau, power-bi, QlikView, etc. However, knowing how to create visualizations is not the same as knowing when & where to leverage certain visualizations and how to position them within the overall front end.
When building out a UI there is a set of high-level criteria to ensure an optimal front end.A good UI needs to be the following :

· Natural
· Friendly/Accessible
· Consistent
· Follow a step-by-step information flow & visual hierarchy
· Interactive

Understanding how to ensure the above principles are being factored into the design of a UI is typically not within the skill set of a data scientist or business intelligence analyst. As such, I would highly recommend investing in or leveraging someone with proper UX training to ensure your solution is being built with the most optimal front end possible.

4. Follow an agile process flow for developing data science models to ensure consistent feedback

With data science solutions, it is exceedingly rare that you will build a solution as initially proposed. As you deep dive into the data, validate its quality, test hypothesis, and build out models, the results will often appear different than initially conceived. This is not due to any technical deficiencies but more so to the fact you cannot predict the insights your approach will tell you nor alter them, but rather you must be able to adapt to what is revealed.

For example, as the end consumer, I may have visualized my end solution being a model that would not only classify the risk of my accounts churning into high, medium, and low risk but alongside that, I would be able to attribute churn to key drivers such as lead time, number of complaints, price adjustments, etc. However, simply because I desired this outcome does not mean that my initial selection of drivers has any impact at all on churn. Even more so, based on the available data out there, my model may predict likely hood of churn to range from 10%-30% making it hard to use my initial approach to classifying accounts based on the risk of churn.

As such, building out a model development flow with numerous touchpoints where you validate insights & strategy with the consumer is essential. This will ensure that you are building out a solution that stakeholders will ultimately accept having been a part of the development journey from the beginning.

The Wrap:

Hopefully, you have found some of the advice to be useful. At the end of the day, I still have much to learn about product concepts particularly as it applies to the data science/analytics realm. Would appreciate any feedback both on my writing style and content!
Thank you for reading through my second Medium post. Let me know in the comments or message me directly if this was helpful and/or what topics you want me to dive into next post. I am open to discussing any topic, not necessarily related to work