Data Science + Magic = Profit

A presentation at DevOpsDays Chicago in in Chicago, IL, USA by Lilia Gutnik

An alarm goes off in a nuclear power plant

An alarm goes off in a nuclear power plant

Then another. And another.

Then another. And another.

The first was a small mechanical failure

The first was a small mechanical failure

Cascading failure

Cascading failure

Cascading failure of humans

Cascading failure of humans

Everything Else vs Data Science

Everything Else vs Data Science

Part 1: Identifying Customer Pain & Designing a Potential Solution

Part 1: Identifying Customer Pain & Designing a Potential Solution

People don’t pay for algorithms. They pay for solutions.

People don’t pay for algorithms. They pay for solutions.

Interviewing Users

Interviewing Users

“Tell me about a time when…”

“Tell me about a time when…”

“Imagine the ideal situation…”

“Imagine the ideal situation…”

Product Vision: Imagine a good place

Product Vision: Imagine a good place

Product Vision: Ambitious future

Product Vision: Ambitious future

What is your product vision?

What is your product vision?

Predicting a value? Suggesting an action? Recommending something?

Predicting a value? Suggesting an action? Recommending something?

Supervised Machine Learning

Supervised Machine Learning

Supervised Machine Learning: Classification

Supervised Machine Learning: Classification

“Using ____________ data I can predict (classify) __________”

“Using ____________ data I can predict (classify) __________”

It appears you are experiencing a nuclear meltdown

It appears you are experiencing a nuclear meltdown

It appears you are experiencing a nuclear meltdown

It appears you are experiencing a nuclear meltdown

Part 2: Finding Data, Prototyping, and Testing

Part 2: Finding Data, Prototyping, and Testing

Finding data

Finding data

Finding data

Finding data

Can we find the data elsewhere?

Can we find the data elsewhere?

Collaborative Filtering

Collaborative Filtering

Mini version of the vision

Mini version of the vision

Part 3: Measuring Success, Iterating on Design, and Shipping

Part 3: Measuring Success, Iterating on Design, and Shipping

Explainability v Complexity

Explainability v Complexity

Explainability v Complexity

Explainability v Complexity

Explainability v Complexity

Explainability v Complexity

Juggling requirements

Juggling requirements

Juggling requirements

Juggling requirements

Final Thoughts

Final Thoughts

Data Science + Magic = Profit

Data Science + Magic = Profit

Data Science + (Well Understood Customer Pain + Thoughtful Design) = Profit

Data Science + (Well Understood Customer Pain + Thoughtful Design) = Profit

Data Science is part of the solution

Data Science is part of the solution

Data Science is not the entire solution

Data Science is not the entire solution

References

References

You can’t throw a rock without running into a talk about the basics of data science and best practices for data hygiene. What’s next? Shipping a data science-powered feature takes more than data collection, experimentation, and analysis - it takes magic. This talk will teach the magic based on the many ~mistakes~ learning opportunities that my team has experienced so that any team will feel inspired to build a customer-facing data science-based feature.

What is different about designing, developing, shipping, supporting, and going on-call for a data science-powered feature? How can you deliver customer value and, yes, make money with data science? Data science models provide insights; a product provides value. You don’t have to be a data scientist to develop a data science-based feature. You’ll leave this talk inspired and prepared to build a successful data science-based feature with these five crucial considerations:

What are potential features your team could build that use data science and deliver value to our customers?

What does it take to productionalize a data science model?

How do you go on call for a data science-based feature that is (by nature) different for every customer?

What are the design considerations for a feature that has unpredictable (non-deterministic) behavior?

How do you develop a feature that relies on math you (probably) do not completely understand?

Video

Buzz and feedback

Here’s what was said about this presentation on Twitter.