Two teams. One dataset. Two buying decisions.

By Shane Heddy, Cofounder, CRO, Nth AI. Published 2026-10-14.

One AI pilot became an opportunity for two teams, each with its own budget and questions for the same data. Shane Heddy on why shared data does not mean a shared buying decision, and how to plan for the second use case.

A global technology company came to us with an AI project. During the engagement, the scope grew from one small test into work for two groups.

They wanted to use the same data. But they had different questions, separate budgets, and different reasons to care about the answers.

That detail is what stayed with me. From a technical perspective, it could look like one project getting larger. From a commercial perspective, it now involved two buying decisions.

After 26 years in enterprise sales, I know those are not the same thing.

A second team changes more than the scope

It is encouraging when another team sees a use for what you're building. It suggests the opportunity may reach beyond the original use case.

But interest from a second team does not automatically settle who pays, who approves the result, or which outcome should come first.

One team may need an answer that helps it make a weekly operating decision. Another may need the same underlying information for planning. Those are illustrative examples, not the details of this customer's use cases. The point is that a shared source does not make the business requirements interchangeable.

If we treat the second team as simply another set of questions to add to the build, we can miss the decision that matters: are we expanding the first team's project, or asking a second team to make its own investment?

That distinction deserves an explicit conversation.

Technical readiness and buying readiness are different

In this engagement, we had scoped the implementation work at four weeks. Two and a half months in, security reviews, procurement, and data access were still being resolved.

I would not attribute all of that preparation time to the expanded scope. Those requirements existed in their own right. They are legitimate responsibilities inside an enterprise.

What the experience made clear is that a delivery estimate cannot answer every question about readiness. It describes the work to be done under an agreed scope. It does not, by itself, tell you whether everyone involved has agreed to the same project.

Adding a team can change the people who need to make those decisions, even when the data stays the same.

Agree on what is shared and what is separate

My takeaway is to make the second use case explicit before treating it as part of the first.

There are four questions I would put on the table:

• Who owns each outcome? Name the person in each team who will decide whether the result is useful.
• How will each use case be funded? Separate budgets need a clear purchasing decision, even if some technical work is shared.
• What can actually be reused? Identify the data, definitions, and business rules that apply to both teams. Check permissions rather than assuming access carries over.
• Do both use cases need to start together? Make sequencing a business decision, not an accidental consequence of putting everything into one scope.

The answer may be a coordinated rollout. It may be one team starting first, with a defined path for the second. Neither is automatically right. What matters is that the people funding and using the work agree.

This is how I would distinguish a larger opportunity from an open-ended project.

Reuse the context without assuming the same business case

This distinction also explains why the context layer matters.

Nth AI Nexus™ automates the engineering that brings data relationships, definitions, and business rules into a reusable foundation for AI. When another team needs that context, the technical starting point should not have to be a blank page.

But reuse needs to preserve meaning. Two teams can share a data source while needing different definitions, rules, or permissions. The goal is to carry forward what is genuinely common and make the differences explicit.

Nexus addresses the engineering behind that foundation. The customer and our team still need to establish who owns each use case and what success looks like.

Those responsibilities complement each other. A reusable technical foundation is more valuable when the business knows how it intends to use it.

The question I will ask earlier

When a second team joins an AI conversation, I want to know more than what else we can build.

I want to ask: what can this team reuse, and what does it need to decide for itself?

That is the lesson I am taking from this engagement. The opportunity to serve more of the business is real. Making that expansion deliberate is part of turning interest into a project each team is ready to own.