I have been to a sprint review where the team demoed an application built for a very specific domain. They were showing exactly the right features for that audience.
But the data on the screen made no sense to the people in the room.
The stakeholders weren’t sure what the information they were seeing on the screen meant; it didn’t connect with the knowledge in their industry.
The team kept saying, “Oh, ignore that. It’s just test data.”
But you can’t un-see confusion.
Every Translation Creates Friction
Here’s what I learned: every time someone has to mentally translate what they’re seeing into what it should be, you create cognitive friction.
The stakeholders weren’t thinking about the features anymore. Or the problems they’re meant to solve. They were thinking about why the data was wrong. They were distracted. They were confused.
And once you lose people’s attention that way, it’s hard to get it back.
The Data Matters as Much as the Features
We spend so much time making sure the features work. We test the logic. We check the edge cases. We make sure the buttons do what they’re supposed to do.
But then we load the demo environment with whatever data is easiest. Sample data from a different project. Random names and numbers. Placeholder text.
And we wonder why stakeholders don’t engage.
The information is part of the experience. If it doesn’t make sense to the people in the room, the demo doesn’t land.
It’s Not Just Wrong Data: It’s a Knowledge Gap
Here’s what’s really happening when a demo goes sideways.
It’s not just that the data is random. It’s that the information and knowledge don’t align.
Data becomes information when it has context. Information connects with knowledge (what the people in the room already know) to create understanding. When that chain breaks, you lose the conversation.
Imagine a customer record showing an outstanding balance of $100 next to a customer name of Bruce Wayne. Technically, the field is populated. But anyone who knows who Bruce Wayne is knows this doesn’t compute. A billionaire, $100 outstanding? That’s not information. That’s noise wearing a suit.
It sounds absurd. But the same dynamic shows up in business contexts, too.
Show a General Ledger to an accountant with account balances arranged in a way that violates basic accounting principles. Watch what happens. They stop evaluating the feature. They start thinking about what’s wrong with the ledger. “That’s not normal. That should never happen.” That thought is now stuck in their head, and you’ve lost them. The same accountant looking at the screen on the silly image above might also ask, “Why is it that the amount owed shows in green? I’d expect red.”
The people in the room bring knowledge. When the information on the screen conflicts with that knowledge, the friction is immediate and hard to recover from.
Know Your Audience, Load the Right Data
Now, when I prepare for a sprint review, I think about who will be in the room.
If it’s healthcare stakeholders, I use healthcare information: realistic diagnosis codes, insurance provider names they recognize, and identifiers formatted the way they appear in their systems. Not “Patient: XYZ-001” but something that looks plausibly real. Even if it’s entirely fictional, it needs to feel like it belongs in their world.
If it’s finance stakeholders, I use financial scenarios. Account numbers, transaction types, and regulatory terms they know.
If it’s produce distribution, I use produce orders with real vendor names and seasonal products.
It sounds obvious. But it’s easy to overlook when you’re focused on just getting the demo working.
A Real Example
I was working with a team building software for a produce distribution company. We were demoing new features for buyers.
Before the sprint review, I spent time loading the database with realistic data. Vendors, they actually work with. Products that were in season. Pricing that made sense for the current market.
During the demo, one of the buyers said, “Oh, that’s exactly how we’d use this. I can see myself doing that tomorrow.”
That’s the reaction you want. Not “ignore the data” but “I can see myself using this.”
The data made it real for them.
It’s Not Just About Realism
Some people think this is about making the demo look polished. Like we’re trying to impress people with fancy data.
That’s not it.
It’s about reducing the mental effort required to understand what we’re showing. If stakeholders have to translate random data into scenarios in their heads, they’re not thinking about the features. They’re thinking about the translation.
We want them to think about the features. About whether it solves their problem. About what’s missing or what could be better.
But there’s a higher goal than just realistic information: insight.
When the information on the screen connects with what stakeholders already know, and shows them something that helps them see a possibility they hadn’t considered, the conversation shifts. They stop being observers and start being participants.
“Wait, can it do that? That would change how we handle this.”
That’s the reaction you’re designing for. Not just “ignore the data” or even “I can see how I’d use this.” Something closer to: “This changes things.”
The right information, in the right context, doesn’t just reduce friction. It creates momentum.
Preload Mid-Sprint
Here’s a technique I use: mid-sprint, as features start working, I sit down with a developer, and we load realistic data together.
We don’t wait until the day before the sprint review. We do it as we go.
This has two benefits. First, it makes the sprint review prep easier. The data is already there.
Second, it helps us catch issues earlier. Sometimes loading realistic data exposes edge cases we didn’t think about. Field lengths that are too short. Dropdown options that don’t cover real scenarios. Validation rules that don’t match actual business logic.
Better to find those mid-sprint than during the demo.
Design the Data Like You Design the Features
I’ve started thinking about demo data the way I think about user experience design.
It’s part of designing the sprint review experience. Just like we choose which features to highlight and how to tell the story, we choose what information to show.
Think about what will make sense to this audience. What will connect with what they already know. What will reduce friction, and what might spark insight.
All of it is in service of the conversation. And the conversation is what matters.
How much thought do you put into the information experience you’re creating for your stakeholders?
Leave a Reply