Want to make better decisions? Follow these 7 questions to solve your next business problem
Written by Aili Asikainen
Most business problems are really about making good decisions. When you’re deciding which project to prioritize next, how much inventory to hold or which ingredients to use in a new product, you’re constantly trading off goals with constraints. Businesses already make these decisions every day. But the question is: Are you making the best decisions you can?
This is where optimization can bring structure. Instead of relying on instinct and vibes, you turn the decision into a system: clear scope and objectives, explicit trade‑offs, and a model that can be improved over time. When you get this right, the optimization framework becomes a lens which you can use to reason about the decisions you most care about.
To make this concrete, I use seven questions that capture the essential ingredients of any optimization problem. Almost all of the questions can be mapped directly to a component of a technical model, but in reality they are at the heart of the business problem. Regardless of whether the final solution ends up being technical or not, if you skip these questions you risk solving the wrong problem, and spending time on a suboptimal solution that no one really trusts.
These questions clarify whether you understand the decision well enough to drive real, measurable improvement. Let’s walk through the seven questions.
1. Decision: What decision are you improving, and why?
Before anyone jumps into solving the problem, you need a clear problem statement in plain language. A good problem statement names the decision and explains why it matters for the business. This helps tie the problem to the broader business context, justify why it’s worth exploring and focus the project on real impact.
For example, you might say: “We need to decide which products to show on the front page each day to maximize sales”, or “We want to decide the best combination of ingredients for this recipe to make it the best product in the market“. In both cases, it is obvious what the decision is and what might change if you improve it.
Notice how the examples don’t say “use AI to…”. This is because the tool is the solution to the problem, not the problem itself. Mentioning the solution in the problem description risks losing focus on what actually matters, which leads to a solution that is technically clever but business-irrelevant. When the frame is sharp and easy to communicate, it’s easier to stay focused as the technical and real world complexities emerge throughout the project.
A practical question to get started: If this project succeeds, what specific decision will be made differently?
2. Objective: How do you measure “better”?
Next you need to understand what “better” actually means. The objective is the way you define success for the decision. It needs to be measurable, and have input from all stakeholders so that everyone can align on what good looks like.
In practice, objectives can be straightforward or complex. Sometimes it's a single number: maximise revenue across the product portfolio while keeping costs low, or hit a target score on a consumer panel metric. Other times there's real tension — balancing quality against cost, or revenue against retention — where improving one metric comes at the expense of another.
This is why defining the objective is so important. The solution can only ever be as good as the objective definition. Making these tradeoffs and preferences explicit is part of the process and helps everyone get aligned on what you’re aiming to achieve.
The solution can only ever be as good as the objective definition.
3. Variables: What levers can you pull?
With the objective defined, you can turn to the levers you are allowed to pull. These are the choices the system, or the team, can make in order to improve the objective. They should be something you (or your business) directly control.
In a production planning problem, the variables might be which orders to run on which machines, and at what time. When improving a recipe the variables are which ingredients to use and how much. The number and type of variables varies a lot by decision. There can be thousands of variables or just a handful and the variables can vary from simple yes-or-no decisions to continuous variables like ingredient quantities, or budget allocations.
It may be tempting to include everything in your control into the variables, after all you can’t be sure the solution is truly optimal if you don’t consider all of the options. However, here you risk running into analysis paralysis and end up spending endless hours developing a perfect solution rather than making the best decision you can within reasonable time and effort. It is often better to start with a smaller set of options and add more only when you run into the limits of the initial set.
4. Constraints: What is off-limits, no matter what?
Real businesses do not operate in a vacuum. Constraints are the way we encode all the rules the system must respect, even if relaxing them would help the objective.
Constraints cover business rules, budget limits, legal requirements etc.. For instance, you might say that the total cost of production cannot exceed a certain amount, that certain types of offers must never be sent to certain customer segments or that the amount of carbohydrates in a recipe cannot exceed a certain amount.
If you ignore constraints, you get “optimal” answers that cannot be executed, that break laws or internal policies, or that would obviously damage trust. On the other hand, with properly defined constraints, you can be sure your constraints are always followed, something humans (and generative AI) often struggle with. In practice, much of the complexity of a classical optimization project lives in the constraints.
5. Uncertainty: What is unknown when making the decision?
Almost all important decisions depend on the future, and the future is uncertain. You rarely know exactly how many customers you will have next week, how a new feature will affect churn or how the cake will taste after it’s baked.
Just because something is uncertain shouldn’t mean that you can’t make an informed decision. It just means that you need to be careful about how you approach the solution. You can use historical data to estimate what is likely, consider multiple scenarios to see how robust a decision is or treat the decision as an ongoing loop of learning rather than a one-off exercise. This is where experimentation plays a big role. You make a decision, observe what happens, update your understanding about the environment, and then make the next decision.
Predicting the future is always difficult, but by explicitly listing the uncertainties helps build confidence and trust that you are making the right assumptions.
Just because something is uncertain shouldn’t mean that you can’t make an informed decision.
6. Model and data: How do we turn this into a repeatable system?
Once you have a clear picture of the problem; the decision, objective, levers, constraints and uncertainties; you can talk about models. At this point, the model is simply the mechanism that takes all of these ingredients and turns them into a decision or recommendation in a repeatable way.
From a technical perspective, this might mean for example classic optimization methods that search for the best combination of levers under constraints, reinforcement learning that optimizes a reward function over time or machine learning models that predict quantities like demand or churn in order to tackle the unknowns.
A common myth is that you cannot automate a decision until the model is almost perfect. In practice, simple and imperfect models are often already more consistent than humans, consider more factors at once, and can be built to learn from feedback. The real question becomes whether the system is good enough to improve decisions compared to what you do today, and whether there is a path for it to get better over time.
7. Action and adoption: How will this change what we do?
Even the best model is a failure if nobody uses its output. The last question is about making sure the work shows up in daily decisions.
In some cases, action means full automation: prices are updated, products are shown, or schedules are adjusted automatically according to the model’s output. In other cases, it means decision support: planners see a proposed schedule, or leadership reviews include model-generated scenarios.
Either way, this needs to be planned from the start. You need to know who will see and use the recommendations, which tools or workflows they will appear in, when should humans be able to override the system, and what does it mean to say that the system “worked”.
You also need a feedback loop. You want to know whether people are actually following the system’s recommendations, whether the decisions driven by the system are improving the metrics you care about, and whether changes in your product, market, or strategy mean the model needs to be updated or even redesigned.
The key questions are how will this project show up in people’s day-to-day work, what has to be true for them to trust and adopt it, and how will you measure impact after deployment rather than only during development.
Setting up for success
These questions are based on common ways optimization and Data Driven Decision Making projects go wrong.
Teams start with a vague brief like “use AI for pricing” without specifying the decision; they optimize the wrong objective or a narrow metric that does not reflect the real goal; they only discover hard constraints when they try to deploy; they treat uncertain forecasts as if they were guaranteed; or they build a sophisticated model without a plan for adoption.
Investing time in the seven questions above not only helps avoid these pitfalls, it also enables the modeling team to deliver results quickly, aligned with clear business priorities instead of guesswork.
If you can get clear, confident answers to the 7 Questions Framework, you are in a strong position to make optimization and automated decision-making deliver real value, rather than becoming just another POC that never quite lands.