4 ms·

There's a pretty good podcast interview with Eugene Dubossarsky that has relevant discussion about issues with management and data science in general. https://w

There's a pretty good podcast interview with Eugene Dubossarsky that has relevant discussion about issues with management and data science in general. https://www.datafuturology.com/podcast/1 https://www.datafuturology.com/podcast/1 Here are a few of my notes (my words not the interviewee's): - in order to use data science, you have to have creative people thinking about data on the front end - they don't have to be data scientists, but they need to be creative and want data to support decisions and iteration via feedback loops - that creativity and desire will lead to "doing good data science" - management on the receiving end of data science output must be intelligent in terms of synthesizing many inputs and have a strong desire to puzzle through the implications. If management is asking the data science to actually make the decisions - the situation is broken - data science must be done with provisions for decision support and feedback loops; this is the output that is helping drive the business. - Lack of desire for decision support and feedback loops leads to "fancy pets" and management using data science as a means to brag about what they are doing; but the data science might not being doing anything to drive the business meaningfully. - data science that attempts to actually make decisions vs providing decision support is likely in the category of "commodity data science". Corollary : non-commodity data science is the kind that supports decisions in executing higher-level business strategy. Strategy at that level has rather unique attributes and is embedded in unique circumstances for a particular business. This requires a good data scientist to help tackle. (hope this is useful) (edit typos,grammar)

andyidsinga 8y ago
BTW - in listening to that podcast I found a lot of parallels with database design. whenever I'm asked to design a database for an early-stage system (I work in early stage tech ventures), I ask the following: - what are the questions that this database should answer for you? How are those questions supporting your business goals 3,6,12 months out? (I'm trying to get to the business requirements here) - who will be asking those questions (I'm trying to put together some user personas in my head) - how frequently will they be asking these questions? corollary: how often will historical data be needed? (I'm thinking hot vs cold and complexity of retrieval, minimally required performance) - how much data to we anticipate is needed to answer the questions (this is really tricky in new ventures - often the answer is more data than what will actually occur in practice in the first year)? - finally, what systems & tools are people using to ask the questions and be notified of events? (I'm thinking about interfacing, apis) its all an attempt to stay very focused on the questions and business drivers and the people who use the answers.
adam 8y ago
This is a great summary. I think his guideposts are helpful for most decision support initiatives, whether you're using data to try and support decisions, or reaching out to humans. We run prediction markets inside companies and find that if we don't establish a good lifecycle of asking forecasting questions, having people respond with probabilities, then decision makers REACTING to those probabilities in some way (whether they agree with them or not, just acknowledge their existence) the likelihood of the project failing is far higher.

andyidsinga 8y ago

BTW - in listening to that podcast I found a lot of parallels with database design. whenever I'm asked to design a database for an early-stage system (I work in early stage tech ventures), I ask the following: - what are the questions that this database should answer for you? How are those questions supporting your business goals 3,6,12 months out? (I'm trying to get to the business requirements here) - who will be asking those questions (I'm trying to put together some user personas in my head) - how frequently will they be asking these questions? corollary: how often will historical data be needed? (I'm thinking hot vs cold and complexity of retrieval, minimally required performance) - how much data to we anticipate is needed to answer the questions (this is really tricky in new ventures - often the answer is more data than what will actually occur in practice in the first year)? - finally, what systems & tools are people using to ask the questions and be notified of events? (I'm thinking about interfacing, apis) its all an attempt to stay very focused on the questions and business drivers and the people who use the answers.

adam 8y ago

This is a great summary. I think his guideposts are helpful for most decision support initiatives, whether you're using data to try and support decisions, or reaching out to humans. We run prediction markets inside companies and find that if we don't establish a good lifecycle of asking forecasting questions, having people respond with probabilities, then decision makers REACTING to those probabilities in some way (whether they agree with them or not, just acknowledge their existence) the likelihood of the project failing is far higher.