Turning a Business Question into an AI or Data Science Project
How to translate your request into a project that technical teams can deliver.
For the last few years, “AI project” has become the catch-all phrase for almost any idea involving data, predictions, or automation. Before that, we called many of those efforts data science projects. The terminology has changed, but the challenge hasn’t.
Someone has an idea and a question. Someone asks whether the data can answer it. Suddenly, the conversation feels highly technical.
It doesn’t have to.
We will cover a lot of ground in this article:
What a data science/AI project actually is and why it starts with a business question, not a technical one.
Why most projects disappoint people, and how setting the wrong expectations up front leads to frustration later.
When to loop in your data science or AI partners and why later than you think is usually the right answer.
How to build a “Project Brief” that turns a vague idea into something a technical data team can actually evaluate (including access to the template we use).
Let’s start by demystifying data science. At its core, a data science project is simply a structured way of using data to answer questions, uncover patterns, or make predictions that help people make better decisions. Sometimes that involves machine learning. Sometimes it doesn’t. Machine learning is simply one tool within the broader field of data science and one type of AI.
Data science has been described as sitting at the intersection of math, computer science, and domain expertise. I like that definition because it reminds us that technical expertise is only part of the equation.
The other part is you.
Whether you’re a founder, marketer, product manager, operations leader, or program manager, you understand your business in ways no algorithm or outside consultant ever will. You know your customers, your processes, your constraints, and the decisions you’re trying to make. That knowledge is just as important as the technical work that follows.
Preparing for a good technical conversation
I led a data science team responsible for developing new data products and methodologies. We spent a lot of time evaluating whether our data could support new ideas that came from our large product organization and our engaged senior leadership team.
Depending on their business question and the data available, the project may have consumed weeks of multiple data scientists and analysts. We wanted to ensure our data science projects yielded the best return on investment. So, we started asking our business partners to answer key questions before anyone started exploring algorithms, building models, or writing code.
Sometimes the resulting discussions led to exciting new products. Sometimes they revealed that we weren’t asking the right question yet. Sometimes they showed us that the data simply couldn’t support the idea. Those were all successful outcomes.
And those conversations became a framework that I found myself using again and again.
Eventually, we turned that framework into a Data Science Project Brief. Just like advertising agencies use a Creative Brief to gather client needs before kicking off a project, we used that Project Brief over and over with business partners to lay a solid foundation for great collaborations and results.
In this article, I’ll share the key elements of the project brief and we’ll build an example together. By the end, you’ll have a practical way to organize your thinking before your first conversation with a technical partner.
A data science project begins with a business question
Kelvin Goods (a fictional business) launched with one beautifully designed insulated water bottle available in three colors. Over two years, it built a loyal following among commuters, hikers, and parents looking for durable everyday products. With sales growing steadily, leadership is considering its first product line expansion: insulated food containers.
At a planning meeting, the product manager asks:
“How can we use our data to predict whether this new product line will be successful?”
Around the table, everyone immediately sees the problem through a different lens. Marketing is thinking about customer demand. Operations is thinking about inventory. Finance wants to understand the investment. And yes, someone inevitably asks whether AI can help.
At this point, many organizations think the next step is to call a data scientist.
Not yet.
Start with the business question
The company’s original question sounded straightforward:
Can we use our data to predict whether our new insulated food containers will succeed?
It’s a reasonable place to start, but it’s still too broad. What does success mean? What are we trying to predict: Units sold? Revenue? Profit? Demand? Repeat purchases? New customers?
The more clearly you can articulate the questions, the easier it becomes for a technical team to determine whether data can help. For Kelvin Goods, the conversation might evolve into something like this:
Should we introduce insulated food containers next spring, and if so, which customer segments should we target first?
The focus now isn’t simply “predict success.” It’s supporting a specific business decision. That’s something a technical team can work with.
Define the decision
Before you think about data, models, or AI, answer: What decision(s) are you trying to improve?
For Kelvin Goods, this project is about helping people make decisions. Specifically, the answer to the above question will help decisions on:
Whether the new product line should launch.
How much inventory should Operations produce.
Which customer segments should Marketing target.
Which retail partners should receive the initial rollout.
How much room for error is acceptable?
A data science project that involves predictions doesn’t remove risk; it changes how you manage it. Before moving forward, spend a few minutes thinking about what happens if the answer turns out to be wrong.
For Kelvin Goods, what happens if estimated demand is much higher than expected?
Inventory shortages?
Missed sales?
Frustrated customers?
Now ask the opposite: what happens if anticipated demand is much lower?
Too much inventory?
Excess manufacturing costs?
Discounting?
Understanding the consequences of being wrong helps define how accurate the answer needs to be. Sometimes “good enough” is exactly that. Other times the cost of being wrong means the project requires much greater confidence before anyone acts on the results.
Know the stage of your initiative
The stage of the initiative will also determine the shape of the data science project. For Kelvin Goods, the same business question might look like this as it progresses through stages:
Exploratory: Determine whether existing customer and sales data contains enough information to support a decision to move forward.
Proof of Concept: Test the technical feasibility of the approach to launch.
Pilot: Test accuracy of customer demand estimates during one product launch.
Production: Build something that becomes part of everyday operations.
Expectations and the definition of success will change depending on which phase you are in.
Define success for this project
One reason AI and data science projects disappoint people is that expectations are often set too high, too early. If you expect your first model to produce perfect answers that remove all uncertainty, you’re setting yourself up for frustration.
Remember, Kelvin Goods is trying to make a better business decision, not precisely predict the future.
What would success actually look like in different stages for this example?
Exploratory: determine that the available data contains enough signal to support demand forecasting at all.
Proof of concept: demonstrate that a model can produce predictions that are directionally useful.
Pilot: the predictions are in use and improve planning decisions.
Production: accuracy, reliability, repeatability, and integration into existing business processes.
Not every project ends with a production-ready model. Sometimes success is learning enough to make a better decision about what to do next.
By this point, you’ve defined the business problem. The next question is whether your organization has the information needed to answer it.
Models aren’t magic
If there isn’t a meaningful signal in your underlying data, no algorithm can just figure it out. The model is not a crystal ball and it does not make decisions. People do.
The model or analysis is another source of evidence you use alongside experience, market knowledge, and judgment. When done well, a data science project will reduce uncertainty, enabling a better decision than you could have made before.
For Kelvin Goods, that might mean narrowing a wide array of product line and target market possibilities into something smaller and more manageable. Perhaps the model suggests customer demand is likely to fall within a certain range, giving Operations more confidence in production planning. Perhaps it identifies that customer demand is likely to be strongest in a particular region or age range, helping Marketing prioritize its launch efforts. Those are all successful outcomes because they’ve reduced uncertainty and helped the business make a better-informed decision.
Can your data answer the question?
Here’s where many projects get their first reality check. The conversation shifts from “What do we hope to know?” to “What evidence do we actually have?”
Identify what data you have available, including history, data source, and gaps. Your operations or technical partners who have access to the data will be a great help here. Kelvin Goods likely has plenty of data: historical sales and customer purchasing records, pricing, marketing campaign performance, website traffic and behavior, product reviews.
Ask questions like:
Do we have enough product launches to learn from?
Does customer behavior for insulated water bottles translate to food containers?
Are there important outside factors like weather or seasonality?
Do we need competitor or market information?
Are there gaps or inconsistencies in our historical data?
Who owns this data, and can we actually access it?
Having a lot of data isn’t the same thing as having the right data.
Sometimes this exercise uncovers an important realization: the first project may not be building a model at all. It may be improving data quality, collecting additional information, or establishing better measurement going forward.
Work within your constraints
Even if the data look promising, every project has practical limits. Answer as many of these questions as you can before engaging your technical team, and then ask them too. Each group will have its own constraints and considerations:
How quickly do we need an answer?
What’s the budget?
Are there privacy or regulatory concerns?
Is this a one-time analysis or an ongoing capability?
Does this need to integrate into existing systems?
While these questions don’t usually determine whether a project is possible, they do influence what kind of solution makes sense. A quick exploratory project might answer the business question without building anything permanent, while an operational system has a very different set of requirements.
What you know vs. what you think you know
Every project begins with assumptions. Make them visible and recognize that they may or may not be true. The Kelvin Goods team might assume that customers who buy insulated water bottles are also interested in insulated food containers, or that previous product launches are good comparisons.
They need to question those assumptions, and identify the unknowns: What makes one product comparable to another? How much will competitive response influence demand?
This practice of separating assumptions from unknowns helps the team recognize where confidence is well-founded and where it isn’t. It also gives your technical partners a much better understanding of the business decision at hand.
Who owns the decision?
Who decides whether this data science project moves forward? Who decides whether it’s successful? Who ultimately uses the analysis or estimates that come out of the model?
The answers frequently are not the same person or team. Marketing might request the project, but Operations owns the decision. Finance would approve the investment, but Product would be managing the rollout. Knowing who owns which decisions helps everyone understand what success actually looks like and who needs to be involved along the way.
Plan for adoption
Now imagine your technical team delivers exactly what you asked for. Depending on the project, that might be a one-time analysis, a dashboard, or a predictive model that becomes part of an ongoing business process.
Great...but the technical work itself isn’t the goal.
Someone has to receive the results, trust them, and know what to do next. Your Data Science Project Brief should identify who receives the output, how often they’ll use it, what decisions they’ll make from it, and what actions are expected to follow.
For Kelvin Goods, suppose the initial project produces an analysis estimating demand for insulated food containers. Marketing uses those results to recommend launching first to outdoor enthusiasts and parents. Operations uses the same analysis to plan an initial production run.
Six months later, if the company finds the approach useful, that same work might evolve into a forecasting model that’s updated before every major product launch. The important question isn’t whether the output comes from an analysis or a model - it’s who uses it, what decisions it informs, and how it fits into the business.
How to scope a project for success
Smaller is always better. The type of data science project you’re undertaking has a role in defining the scope. I always want to know: how small can we make this project?
Warning: this really irritates “idea people” who want to build a rocket ship. Ask it anyway. How small? One product category? One region? One launch? One year of historical data. One business decision. The more targeted your project, the higher your chance of success.
And if this first data science project does succeed, what earns the next study? Success might earn a larger pilot, or another product category, or automation, or the go-ahead to integrate into an existing process. Thinking about the next step helps you avoid treating the first project like an all-or-nothing decision.
Now bring in your data science partners
Because you have done the work, you’re now ready for a productive, collaborative conversation with your technical partners. Note that I said “have a conversation” not “submit a request.”
You have translated a business idea into a clearly defined question that gives your technical partner something concrete to evaluate.
Note: a good technical partner rarely responds with immediate answers. They respond with better questions, and that is exactly what you want. They might point out a hidden assumption, or suggest a different business question that’s actually easier to answer. Maybe they identify a completely different data source you hadn’t considered. These are signs that the conversation is working.
Together, you will begin answering questions like:
Is this technically feasible?
Do we have enough data?
What additional data is needed?
What approaches might work?
What level of accuracy is realistic?
How much effort will this require?
What are the biggest risks?
Your project brief isn’t something you hand to a technical team and walk away from. It’s the starting point for a conversation.
Good technical partners will ask questions you hadn’t considered. They’ll challenge assumptions, refine the scope, and sometimes redefine success altogether. That’s not a sign your preparation was incomplete. It’s exactly how good data science projects take shape.
You’re ready
Let’s go back to the question that started this article.
“Can we use our data to predict whether this new product line will be successful?”
Notice that we spent all of our time talking about the business. We didn’t talk about AI or machine learning or data science. Successful data science projects begin when the business problem at hand is well articulated and the full project team understands it.
Throughout this article, you’ve been building your own Data Science Project Brief. If you’d like our template, which brings those conversations together into one practical tool you can use before your next meeting with a technical partner, you can download it here.
This is a distinction more organisations need to hear.
AI rarely fails because the model wasn't sophisticated enough.
Rather, it's because nobody was clear about the decision they were trying to improve.
Technology reduces uncertainty, but judgement decides what to do with what remains.
That's why the quality of the question still matters more than the sophistication of the algorithm.
Use this:
This is a very practical piece.
What stood out to me is that a good AI or data science project does not start with the model. It starts with the business decision you are trying to improve.
I have seen too many teams rush into “can AI solve this?” before asking the harder question: What decision will change if the answer is useful?
That single question forces clarity. It separates interesting analysis from usable work.
The best technical projects are not born from better prompts or better algorithms. They are born from sharper business questions.