The smarter way to build your next innovation

Every enterprise product leader faces the same temptation. You have smart people, deep domain expertise and a backlog of requests. You know what needs to be built. The pressure is to move. The instinct is to start.

The problem is that what you know is almost always a subset of what matters. Internal teams are close to their own workflows but blind to the gaps between them. Leadership has a strategic view but limited visibility into how work gets done three levels down. Customers are articulate about their frustrations but rarely have the language to describe what’s structurally broken versus what’s merely inconvenient.

The result is a product built on assumptions that feel right but aren’t validated. Features that address the symptoms leadership can see rather than the root causes users expperience. Interfaces designed around organizational charts rather than actual workflows. 

In his role as CTO of Global Infrastructure Services, Dan Gray leads global technical operations for over 45,000 technology professionals at DXC. His teams are the people DXC OASIS was built for — not in the abstract sense of a target persona, but in the literal sense that they are the operators, engineers and account teams whose daily work the platform must improve or fail. Dan’s perspective on the cost of assumption is grounded in operational reality: when a platform is built without understanding the delivery floor, the symptoms are immediate. Data is fragmented across 20 systems. Documentation lags reality. The first alert arrives as a support ticket rather than a prediction. The organizational cost — in time, in trust, in the credibility of every promise made to a customer — compounds quietly until it becomes impossible to ignore. 

Human-centered research is not a focus group. It is not a survey appended to a sprint review. It is a structured, phased methodology designed to surface what people cannot easily articulate about their own work — and to translate those insights into decisions that shape what gets built and what gets deprioritized.

For DXC OASIS, we designed a five-phase research program that was, by any measure, one of the most rigorous our organization has ever undertaken. Moreover, this is the kind of research discipline typically seen at the world’s leading product companies. Applying it to an internal enterprise platform, at this scale, is unique. We took this approach not because rigor is an end in itself, but because the stakes required it. We were building a platform intended to change how tens of thousands of people deliver services to customers. Getting it wrong would not just waste investment. It would erode the trust we needed from the very teams whose adoption would determine success. 

What makes this approach different from standard product discovery is three things: the deliberate sequencing (each phase informs the next and skipping ahead introduces blind spots), the breadth of participation (this was not a sample of convenience) and the discipline of letting findings change direction even when that meant challenging internal assumptions.

Dan describes what that discipline looked like versus delivery side. When his teams were brought into the research — not as subjects to be studied but as experts in their own work — it signaled something they had rarely experienced from an internal platform initiative: genuine curiosity about how the work actually gets done. That signal generated more organizational goodwill than any launch event could. And the moment Dan saw his organization’s operational reality reflected back in the findings with a clarity that internal reporting had never achieved — the workarounds his teams had normalized, the friction they had stopped complaining about because they assumed nothing would change — that was when he knew the investment had already paid for itself.

The research surfaced six fundamental disconnects between what enterprise IT customers genuinely expect from their service providers and what existing platforms and operating models actually enable. These are not DXC-specific findings. They are structural patterns in managed IT services that any organization delivering or consuming these services is likely to recognize. 

1. Strategic guidance vs. limited business insight

Customers want data-driven strategic recommendations. Their service teams want to deliver them. But without tools that align technology data with customer-specific business priorities and competitive benchmarks, recommendations default to generic or reactive. The gap is not intent. It is infrastructure. DXC OASIS addresses this by surfacing strategic insights and external industry data within the operational workflow, closing the distance between what account teams know and what they can credibly advise.

2. Unified data vs. system fragmentation

Large service organizations sit on enormous volumes of data. But when that data lives in fragmented systems and requires manual aggregation, it cannot be used for real-time decision making. The data exists. The intelligence does not. DXC OASIS unifies operational data into a single intelligent layer — not by replacing source systems, but by creating a coherent view across them.

3. Cross-customer expertise vs. knowledge silos

One of the core value propositions of a managed services provider is pattern recognition across hundreds of customer environments. In practice, siloed knowledge structures and a globally distributed workforce make this nearly impossible. What one team learns in one geography rarely reaches another team facing the same challenge. DXC OASIS creates connected knowledge repositories that make cross-account and cross-regional learning accessible at the point of need.

4. Reliable documentation vs. inconsistent capture

Outdated or missing documentation creates blind spots for customers and operational risk for delivery teams. The problem is not that people refuse to document. It is that the act of documentation is disconnected from the flow of work. DXC OASIS standardizes documentation workflows, turning knowledge capture from a burden into a built-in behavior. 

5. Embedded partnership vs. limited continuity

Customers want their IT partner to feel like part of their own team. But personnel transitions, account complexity and the sheer volume of contextual knowledge required make deep familiarity hard to sustain. DXC OASIS ensures that any team member can achieve immediate account context through shared, intelligent views — so that continuity is a property of the system, not dependent on individual memory.

6. Proactive mitigation vs. reactive toolsets

Customers expect anticipatory incident management. They want to know about problems before they feel them. Current reactive toolsets cannot deliver this. DXC OASIS uses predictive analytics to surface patterns before they become incidents and automates critical resolution workflows — shifting the operating model from response to prevention.

Research that does not change decisions is theater. The value of the methodology I’ve described is not in the artifacts it produces — the personas, the journey maps, the survey data. The value is in the quality of the arguments it makes possible inside a product team.

Personas force hard prioritization choices. When you have seven distinct behavioral archetypes, each with different needs and different definitions of value, you cannot design for all of them equally. You have to decide who you are building for first, and why. That decision is better when it is grounded in research rather than opinion.

Journey maps reveal the moments that matter most. Not every interaction is equally important. The moments where trust is built or broken, where a user decides to engage or disengage, where a workaround becomes permanent — those are the moments that should drive feature priority. Journey maps make them visible.

And the discipline of tracing every feature back to a documented user need changes the character of internal debate. Arguments shift from 'I think this is important' to 'This is important because our research shows that this user type, in this moment, needs this capability to accomplish this goal.' The specificity raises the bar for everyone.

As we began onboarding customers and our operators were using DXC OASIS, this is the moment we validated the downstream effect. When Dan's teams encounter features built directly from their own input, the adoption dynamic is fundamentally different. They are not being asked to learn a new tool. They are recognizing their own workflows made better. The feedback loop is higher quality because operators can point to specific moments where the platform meets or misses their reality. And organizational trust is qualitatively different when it comes from feeling heard rather than feeling managed — a distinction that matters enormously when you are asking 45,000 professionals to change how they work.

DXC OASIS is an AI-powered platform. Its capabilities include predictive analytics, intelligent knowledge retrieval and automated workflows. But the design philosophy that governs those capabilities is fundamentally human-centered on our Human+ methodology.

This means that every automated capability is designed to augment a human decision. Predictive analytics surface patterns so that a human operator can act on them with context. Intelligent knowledge retrieval delivers information so that a human advisor can apply judgment. Automated workflows handle the repeatable so that human attention is freed for the complex.

This is not a philosophical distinction. It is a product architecture decision that directly shapes adoption. People adopt tools that make them better at their jobs. They resist tools that make them feel redundant. The research made this dynamic visible in ways that no amount of internal debate could have — particularly within Dan’s organization, where the relationship between human expertise and AI augmentation is not theoretical but operational. His teams do not need to be convinced that AI can help. They need to be shown that it has been designed to help them specifically, in the moments that matter to their work. And it is reflected in every design decision DXC OASIS has made.

The specific platform will differ. The industry will differ. The scale of research that is practical will differ. But the underlying principle is universal and replicable:

Before you decide what to build, invest in understanding how your people work — not how you assume they work, and not how your systems assume they work.

This means structured research before roadmaps. It means qualitative depth before quantitative validation. It means letting findings change direction, even when that is uncomfortable. It means building personas that describe behavior, not demographics. It means tracing every feature decision back to a documented human need.

Dan’s closing perspective is worth taking seriously. As someone who leads one of the largest technical operations organizations in enterprise IT, his message is direct: the most valuable thing a product team can do is make the people who will use it feel like they were genuinely listened to. That feeling is not accidental. It is the direct result of a methodology. And it makes every downstream decision — adoption, feedback, iteration, trust — measurably easier. When you are asking tens of thousands of professionals to change how they deliver services, the difference between a tool that was built for them and a tool that was built at them is the difference between transformation and shelfware.