4 Questions To Ask Yourself When Writing Data Science Business Use Cases/Applications

I write this in order to help data scientists work on problems they are passionate about in corporate and want to make their work more impactful than a simple 9–5. Personally — I think data science applications are bounded by creativity and knowledge of existing tools. Hence, this is a guide to help people who want to work on passion projects but at work. Please feel free to message me with questions if you have any.

So generally — what are managers’ looking for? I have also put the questions in order of importance because to me, the biggest difference between success and failure is how quickly you get to work on it. I am sure none of us want to wait 12 months before we can work on something we genuinely have a vision in.

Question 1 — Why is it urgent?

Understand urgency and the ideas of business. Expect your managers to have 20 different things that needed to be done so why should your idea be the one that they prioritise? If you believe something needs to be done — make it sound like it needed to be done yesterday. To ensure success pitching your business use case, here are a few dimensions you should consider when it comes to this:

• If competitors are doing it — you probably should as well if it is core functionality. For example — are your competitors using better fraud detection to boost sales by a million dollars? Are we doing that?
• Explore magnitude and importance — who will this business decision effect? What is the likely magnitude of your project? By improving your artificial intelligence powered search engine — will you end up improving search relevance and sales by a significant amount? Think revenue, cost optimisations (core to any business). Will your customers have a significantly improved shopping experience?
• Are there any recent events to fuel why something needs to be done? Perhaps a pandemic has caused everyone to stay inside and you need to build a tool for the team to work remotely? This will require proper discussion with the team about what would work best.

Question 2 — Why you/your team?

This can be difficult and varies depending on your organisation’s expertise. Ideally, you try and build as much out-of-work experience in this as possible and then suggest you can do the same for work to significantly improve the team’s work. Also consider what assets your team have — do you guys have a data tracking tool to allow you to examine success? Do you have knowledge about something that no one else has? Have you guys done similar projects in the past? Similar to building a competitive advantage in startups — what is something that will take other teams a long time to learn and understand that you can do straight away? Build a business use case that makes you guys sound like the perfect team to solve a problem!

Question 3 — How do you plan to implement this?

Self-explanatory question. Dimensions to think about here include:

• What is the expected length of the project? (Including testing)
• How much resources will be required?
• What kind of expertise will you need and in what areas?

If you are pursuing this because this is something you believe in — you need to be willing to put in extra hours to make your idea come to life. Nothing comes for free and so you should try and factor this in when making your decision. I don’t recommend pitching business decisions unless you are truly passionate about what you are building or doing for the team.

Question 4 — Is your presentation going to be understandable immediately?

For business presentations — a safe rule of thumb is to assume that your manager will look at your presentation only once and will not spend more than the time of your meeting to explore this. Therefore, have graphs that people can understand in less than 3 seconds. Have icons that are directly relevant to the problem at hand. If even 1% of your presentation is irrelevant, then it is going to be discarded. Furthermore, data scientists have a problem with being technical — please avoid jargon as much as possible. Do not mention you are using “Bert”, just say “model” unless you are discussing implementation.