How OR and Data Science Teams Create Business Value

We recently had the opportunity to host Samuel Eldersveld at our office for a workshop titled “How OR/Data Science Teams Create Business Value.” Samuel shared valuable insights from decades of experience leading data science and optimization teams at major companies like Amazon, Walmart, Nordstrom, and Uber. Rather than focusing on algorithms or models, he emphasized the real-world practices that help technical teams deliver measurable business value—by aligning with stakeholders, managing complexity, and communicating clearly.

This blog covers the key takeaways from this workshop for the DecisionBrain Solution Delivery team.

Start with Clear, Concise Requirements

Projects typically have stakeholders at different organizational levels; all with different priorities and expectations. Executives may be concerned with transformational change while managers are looking for efficiency, and front line employees want to minimize disruptions. A project may get initiated by an executive, planned by management, and tested and ultimately accepted by front line employees. Given these different stakeholders and expectations, it’s critical to have a succinct business requirements document to start the project.

A one-page Business Requirements Document (BRD) is the right tool to clearly state:

• What problem needs to be solved
• Why it matters
• What the project’s value proposition is
• What’s in scope and what isn’t
• How success will be measured
• Who the stakeholders are
• What the key milestones are

This document must be short—it’s the best insurance that all key stakeholders will actually read it! It must also be explicit—to avoid hidden assumptions. With these elements in place it should become the project’s North Star, something the team can return to whenever things get unclear or start to drift.

The next level of detail goes into the Product Requirements Document (PRD):

• What does the system need to do?
• What are the key capabilities, use cases, and runtime requirements?
• Should the system respond in milliseconds, or can it run overnight?
• What is the planning logic?

The PRD should be focused on the expected outcomes, decision logic, and performance needs. Shifting the focus from method to outcome is critical for allowing teams to explore the best possible solution based on business goals, available data, and real-world constraints. Locking into a method too early can limit flexibility and lead to solutions that are harder to adapt or maintain.

A six-page PRD becomes the backbone of sprint planning and demos, keeping everyone—including senior stakeholders—aligned. The core content must be short, sharp, structured, and actionable.

Make Sure Everyone on the Team Knows the “Why”

Understanding business value shouldn’t be limited to project managers. Everyone involved—whether they’re software engineers, data scientists, or optimization specialists—should be able to explain how their work connects to the business value and expected outcomes stated in the Business and Product requirement documents. Encouraging developers to explain their work in terms of business impact is a simple yet powerful way to ensure priorities stay aligned. It’s also a litmus test: if someone can’t connect what they’re doing to a business goal, the team may be drifting off course.

Framing work in terms of impact rather than implementation helps messages resonate with business stakeholders, and it reinforces the team’s shared purpose. This practice builds alignment, strengthens communication, and boosts confidence in the value being delivered.

Building Customer Trust from the Ground Up

Building trust at the early stages is critical—and it begins with showing genuine understanding. This means not just listening to what the customer says, but also observing how the work is actually done in the field. Frontline workers hold invaluable knowledge. Their insights can reveal small but crucial details that rarely make it into documentation—and show respect for the people doing the job, which builds trust.

Showing respect and understanding is a strong foundation, but trust is extended when that understanding is backed up with visible progress. One of the best ways to do this is by delivering early, incremental releases that provide tangible value and give users something to test and respond to. This approach allows the business to see quick wins while giving the project team early feedback and opportunities for course correction. The following release schedule is a good example of how this can work in a DecisionBrain project:

1. Descriptive application:The first release can focus on data ingestion, transformation, validation, and descriptive analytics of the business process at stake. This stage delivers incremental value by reducing manual effort, increasing consistency through standardization, improving transparency, and strengthening the shared understanding of current business performance.Understanding the current business performance is critical for evaluating models later in the project. It also deepens the project team’s grasp of the business by aligning field feedback with actual data—helping identify gaps early and avoid costly rework later.
2. As-is process application:The second release could focus on a heuristic or enhanced manual planning process that replicates the current way of working. Similar to the last release, this generates incremental business value through time savings and consistency.Importantly, this phase captures the valuable knowledge from experienced planners that can be used to scale operations and accelerate onboarding of new team members. It also continues to build trust while getting timely clarification on any misunderstandings from the requirements phase.
3. Enhanced process application: With a solid foundation in place, the third release can introduce improvements that are more likely to be adopted and deliver significant value.

The key components to the above release plan is the early availability of real data and the continued engagement and feedback (i.e. testing) from the business throughout the development process.

Get Real Data Early—And Make Sure It Reflects Reality

Data defines the problem. No matter how strong your model is, it won’t create value without meaningful, realistic data.

In many projects, access to quality data comes late—often too late to adjust the model effectively. As difficult as it can be, teams must be firm and raise the lack of data readiness as a project blocker.

Synthetic data can help build a quick MVP, but real decisions require real data. When there’s a risk that available data doesn’t reflect reality, field observations become essential to uncover patterns and inefficiencies that might otherwise go unnoticed.

Testing is Business Validation

Testing isn’t just about checking whether the system runs—it’s about making sure the business agrees with how it behaves. Business validation should start early and happen continuously, rather than being left until the very end of the project when changes are more difficult and costly.

Testing should address key questions:

• Do the system outputs make sense to the users?
• Are decisions reasonable?
• Are business constraints correctly handled?
• Does the system reflect real-world operations?

You need more than functional test cases—you need realistic data, concrete examples, and customer input. If that data isn’t available yet, it’s not a minor detail—it’s a blocker. Testing can (and should) start small: validate a narrow use case first. If it works there, expand from there.

Testing is a collaborative, ongoing validation of business logic —not a one-time technical step before go-live.

Control the Backlog, Avoid Ad Hoc Chaos

Frequent changes and shifting priorities can quickly exhaust teams and erode the quality of their work. While flexibility is a key Agile principle, it’s often misinterpreted as a license for mid-sprint changes—especially in the name of responsiveness. In reality, effective Agile teams thrive on clear focus and stable scope. Support this by setting a fixed delivery cadence—typically four weeks—and locking down the scope before each sprint.

New ideas and requests are natural. A healthy backlog gives them a place to live without disrupting the current sprint. Ideas that seem urgent in the moment benefit from a little time before being prioritized: reviewing them in context, alongside with other ideas and goals, makes it easier to assess their true value and determine when and how to act on them.

Final Thoughts

This workshop was a valuable reminder that creating business value with OR and Data Science isn’t just about models—it’s about process, alignment, communication, and trust.

From clarifying the problem to validating real outcomes, each step matters.
Success comes from starting small, focusing on impact, and involving the right people at the right time.

A big thank you to Samuel Eldersveld for generously sharing his insights, to Vijay Mehrotra for his business acumen, and to the entire DB team for sharing their experiences and best practices.