Building Data Products Your Users Both Use and Find Useful
What works in the world of baseball-themed sci-fi blockbusters from the 90s does not always translate well into reality. In data and analytics, this quip encapsulates a very common misconception that if we engineer something useful, the users will follow. But this isn’t always, or even often, the case.
We think to ourselves: We built something really useful that’s going to help the organization, yet in the end, there’s no line at the door. Even when we’ve followed the playbooks and run the governance meetings, we still hear crickets. Departments should be knocking down the door to be next to gain visibility into their data, from our point of view as engineers. But they aren’t coming. Even when leadership has given a rousing “we will be data-driven!” speech, and we know the dashboards are sound and solid, the value of what we built is null if it isn’t used.
A little bit of forensics reveals that the issue usually isn’t the data or even the dashboard; it’s more often how these tools are positioned, marketed, and embedded into daily business life.
In this blog, I’ll walk you through some of the steps to becoming what I call an Internal Product Manager, and an Internal Marketing Manager (cause you need to be both), for the tools and apps you’ve built or provided.
My hope is that this article will provide you with insight into some strategies for reframing how you approach getting people amped up for analytics.
In this article, you'll learn:
- How-to adopt an Internal Product Manager mindset to make data tools into solutions users actually want and need.
- Why understanding your internal customers and aligning your product with their true goals is key to adoption and impact.
- How to talk to users about what their requirements are so you can build a useable product.
- Lessons from the Segway that show adding features without focus can derail even the best ideas.
Mindset Shift 1: Thinking Like an Internal Product Manager
When you work in data and analytics, you’re implicitly a product manager, even if no one put that job title on your business card.
Your “product” might be a self-service dashboard, an operational data mart, or even an AI-powered forecasting tool. But your bigger job is to think beyond delivery; you must create something that real users want to use because it keeps the promise of making their work easier or, at the very least, less fraught with obstacles.
Your job is to provide a product to an internal customer.
Identifying your internal customer and what they need
When you begin to think of your tool as an “internal product” meant to serve a particular customer (your end user), there are a few things you'll start to notice. For example, often, users will know about your product and how to access it, but adoption remains low because there are no clearly defined use cases or demonstrated benefits: It wasn’t created with them in mind or isn’t aligned to their real goals. You'll see this more clearly, but you'll also have x-ray vision into its remedy.
At its core, being an internal product manager means your job is split into three areas:
- Identifying with your internal customer(s);
- Aligning your solution with their real goals; and
- Building not what they request, but what they need. (This last point might seem a little irreverent, but we’ll get to the why).
A product manager mentality shifts your team and your focus away from becoming a “feature factory” and toward intentionality.
What the Segway Teaches Us About Internal Product Management
Let’s segue into what it means to build a useful product in your new unofficial role as Internal Product Manager.
Think about the Segway. They were supposed to be an energy-saving way to navigate cities while cutting pollution and congestion. The founder of Segway, Dean Kamen, kept adding features he thought would perfect it, making it more and more complex, but all that did was overcomplicate the product (hence the price tag).
Practically, these ongoing additions meant the Segway didn’t work in urban spaces. It was too large for sidewalks, which are designed for pedestrians anyway, and it wasn’t allowed or practical to use on roads with cars and bikes. Plus, it was difficult to carry indoors, limiting its usefulness for commuters going into buildings or stores.
This is a lesson for anyone building data products. Like the Segway, adding more features won’t make your product better if those features don’t solve an actual problem for users. Kamen’s ambition drifted away from the practical goal of making a smooth ride for the city because he lost sight of his use case and failed to consider his actual end user and their environment.
Mindset Shift 2: Avoiding the "Build It and They Will Come" Trap
It’s easy to get starry-eyed over technology. BI can produce polished, interactive visualizations; Qlik can be embedded seamlessly across systems; Databricks and Azure promise scale; SAP can run advanced planning models that really hum.
That’s all great, but users don’t adopt tools because they’re flashy (read: I didn’t say ‘purchase’); they adopt them because those tools save time, reduce headaches, and are embedded into the work they already do daily.
Take, for example, research by the Nielsen Norman Group on software effectiveness and adoption. Their studies broadly show that poor usability leads to user frustration and abandonment, which directly contributes to project failures. They measure this through usability testing with as few as five users; tracking where people succeed, struggle, or quit reveals design flaws that spell trouble if ignored.
If you build it, and it doesn’t work for your user, they may come out of a sense of obligation, click a few buttons, and never return.
Our advice is to spend more time in 1:1 conversations before building.
Too often, teams jump straight to building. But skipping stakeholder engagement leads to misaligned solutions.
Spend time talking directly with users, even 1:1, before building. These conversations surface those “little things” that can quietly tank adoption.
But doing user interviews takes serious time: Properly prepping your questions, and then bringing users into the conversation, are a major time investment. Digging through their answers can also be resource intensive; that’s why planning your questions upfront is really important so all that effort actually pays off.
Before you approach your user, ask yourself:
- What do I need to know about our users?
- How will that knowledge improve our product and inform our design process?
Once you've asked yourself those questions, and you’re ready to initiate user conversations, prepare a question script.
A few of our top tips:
- Try to keep the interview contained within a tight 10 minutes.
- Use simple, clear questions under 20 words and avoid jargon or complicated terms. Your questions make up the discussion guide, which keeps things on track but flexible enough to follow interesting leads.
- Pick your questions based on what you need to learn; if you miss the mark, you might end up heading the product in the wrong direction.
- Bring two interviewers to the interview, in addition to recording the interview: One to speak and one to record the answers.
A couple precautions:
- Don’t ask people to recall detailed past events because memory can be faulty, leading to less-than-true answers.
- Avoid asking users to predict future behavior; they often say "yes" without real insight.
- Use the script as a guide, not a strict rule; explore interesting topics that come up naturally.
- Continuously improve your script based on feedback from real interviews.
This context is the straw you spin into gold.
Mindset Shift 3: The Successful Tool Disappears (into the Workflow)
Once you begin building with context in mind, as the accomplished product manager you are, keep tangible gain (real, measurable value) at the center. This shifts the definition of success. A successful analytics tool isn’t “used frequently”; it disappears into the workflow, so much so that employees stop thinking of it as “new”, and it just becomes “how we work here”.
For example:
- A claims dashboard doesn’t succeed if people admire the graphs; it succeeds if claim reprocessing time drops by 20%.
- A new Power BI supply chain model doesn’t succeed if people log in every day; it succeeds if production delays drop and the CFO sees cost savings.
- A Qlik-based patient flow visualization doesn’t succeed if clinicians say “this looks cool”; it succeeds if average patient wait time drops.
Look for business results, not log-ins. This should be obvious to most, but melding people and processes with your technology is much more difficult than you’d think.
Vanity metrics vs. value metrics
Try shifting your company’s cultural mindset toward metrics that “count”, not just numbers that give the appearance of progress or excellence.
Logins, time on dashboards, query counts: Those are often vanity metrics.
Value metrics are harder, but more telling: Did we cut manual reporting hours from 10 hours a week down to 2? Did that new procurement dashboard contribute to a measurable reduction of supplier delays? Did physicians spend less time clicking through EHR screens and more time with patients?
Those outcome metrics are what keep your product alive long-term.
Some other example outcome metrics:
- A decrease in reopened cases
- Increased self-service through new knowledge base or forum articles
- More time spent resolving complex issues
- Higher satisfaction in post-support surveys
Mindset Shift 4: Think Like an Internal Marketing Manager, Too
Not to put more on you at this point. But you’re the one who knows your data products best, so you’re the best equipped to spread the word about them (even if you’re doing that by proxy, with a team, or through another team).
Even when your product has mighty potential to help its users and is easy to integrate into workflows, its benefits may not be well communicated. That’s harmful to adoption.
Too often, we launch a new tool and assume its value will be self-evident and scores of users will simply flock to it of their own volition, but “if you build it they will come” already failed us; we can’t repeat the mistake after launch.
This is exactly where your inner Internal Marketing Manager steps in. Show your solution in action during town halls. Send short, punchy “Did you know?” emails highlighting specific benefits. Get early adopters on board to share their success stories… peer testimonials almost always carry more weight than formal training sessions. You can even host AMA (Ask Me Anything) or office hour sessions to keep the conversation going and field real questions.
The gist is: Go out into the wilds of your company and make your tool visible.
Mindset Shift 5: Feedback Loops Should be Built into the Process from the Start
Here’s the final mindset shift.
Analytics products don’t launch once; they evolve.
This means building feedback loops directly into the adoption process, such as user surveys, usage patterns, and team workshops. Internal product managers don’t just collect these inputs; rather, they act on them, refining the offering over time.
Much like consumer products, data products only thrive when tested and improved over and over and over again. A Power BI dashboard might cut processing time today, but tomorrow workflows will shift, and so too must your solutions.
Wrap-up
The longer teams embrace this product mindset of engaging users early, measuring value, marketing internally, and iterating continuously, the more analytics moves away from being a feature factory or that weird wrench in the toolbox that nobody knows what to do with, but nobody wants to throw away either.
How DI Squared Helps
DI Squared helps by guiding organizations to think and act like internal product managers for their data tools. We emphasize understanding real user needs through direct engagement, aligning analytics solutions with business goals, and avoiding unnecessary feature bloat. Drop us a line to get the conversation started.
