Tips on communicating data science effectiveness to non-technical stakeholders?

Congrats, you are now an analytics consultant, and you need to sell your self and your work. Start by fleshing out the business problems you can help with, identifying what answers and solutions would be, try to quantify the impact on the business (including creating scenarios, this is key), create simple visuals to illustrate process, and then describe what data you would use to start with simple approaches to the problem with demonstrable WINS and performance indicators, then argue how you could further refine the process. Meet with stakeholders to understand their problems and see how you can help them. Try to wrap the smaller problems that are tangential into larger efforts (this will make people love you). Also remember: nobody cares about random forests and technical complexity except you, so don't bother telling nontechs about the guts of DS. They'll only care if it means it costs them money or time. Good luck :)

Things that get measured, get better.

If you aren't using your data, it's just wasted opportunities.
Right now you have a bunch of data, and nobody using it. One of the reasons is because it takes huge groups of people managing all the data by hand and it wastes a ton of time. Offer to automate parts of this process, or take their manual efforts and curate into something that makes them feel like all this effort isn't wasted.

At the end of the day, your boss decides what is important. So instead turn the question back to him: "I'm really good at digging through data, and figuring out what our customers want/need/etc. I know the tracking system we discussed might not be the right way to go... but what kind of problems DO we need to fix right now?"
They will probably give you an opportunity to work on something that already has a greenlight of approval, or at the very least get them to start thinking about it.

If they can't come up with an answer soon, then they don't know what data science is. Offer to explain 2-3 things you could do with it, and call it an "initiative". Then you can present some of it's findings at an upcoming board meeting or something.

If your boss isn't technical, talk to them from an angle they understand: P/L.

Start quantifying the current day profits and losses associated with some problem. Then try to realistically guess how much you could either increase that profit, lower a cost, or both using your skill set applied to that problem.

You don't need to tell them your method. You don't need to even mention a model. You don't need to get technical at all. In the academic environment you spend a lot of time defending your methods, but in business environment they don't care about your methods because they assume you know what you're doing and it's YOUR ass if you don't deliver.

Lots of data scientists I run into are pretty brilliant, but they suck at explaining why their work even matters from a business perspective. Lots of non-technical people don't buy into DS, modeling, AI, etc and that's fine. Many people think DS teams just go research useless or estoteric problems -- and that's the fault of the DS team for not properly communicating.

If someone can't distill a problem into a simple P/L statement and then show how your work can help that equation.... then that's a problem. I think that's where you should go.

Not sure what non-technical has to do with it. If you're talking in technical terms, you are barking up the wrong tree. What they want is for to explain how what you built (or will build) will contribute to the bottom line. They need to see results in an easy to understand way and not have the process explained.

Hi - at the University of Washington faculty are very interested in improving informatics and data science fluency for non experts. My advice is to start with their problems and ignore the technology initially. Business solutions always resonate and iterating on what's possible with what's useful will help bridge the gap.

To find the projects, you need to deeply understand the problems they are facing. Is it lack of growth? Attrition? Margin? A declining market? Ask them what keeps them up at night. Ask them what their boss is worried about. Dig in, get the details, empathize. Be a partner rather than a corporate function.

Once you have your project and complete your first iteration, how you present is very important. If you have colleagues who can provide feedback before you go to your stakeholder, it can be very helpful both for the feedback and general presentation practice.

When you present to your stakeholder, don't start with the data, but have it in your back pocket to answer questions and illustrate key points. Recap the problem that you tackled for context, and give them your recommendation on what to do. Explicitly tell them your recommendation. Listen to their questions and reactions, and make sure you are keeping an open mind to what they say.

If your recommendation resonates, offer to help them present your recommendation to whoever has the ability to execute on your recommendation. Work with them to justify the recommendation. Team with them. They can help you bridge the gap between the data and the business.

Most likely your recommendation will not resonate during the first iteration. If your recommendation doesn't resonate, try to understand why. Don't throw data at them to try to change their mind. Make sure you understood the problem. Ask them what kind of recommendation they might be looking for (you should probably do this during the initial scoping as well).

Tell them you'll take the feedback and iterate. Repeat until you agree on the recommendation, or you realize your time is better spent on another problem.

Your submission looks like a question. Does your post belong in the stickied "Entering & Transitioning" thread?

We're working on our wiki where we've curated answers to commonly asked questions. Give it a look!

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.