"Just because you build it doesn't mean they’ll come."
- every frustrated data team, eventually
--
Most data teams have been there: you’ve worked hard on a dashboard. You wrangled the data, built something elegant, powerful, insightful.
You share the link.
One stakeholder opens it.
Maybe. And then… nothing. Silence.
The dashboard gathers dust. The adoption rate sits at zero.
It’s demoralizing. Worse: it’s a massive waste of time and resources.
So what happened?
You didn’t have a distribution strategy.
And that’s the problem nearly every data team keeps repeating.
The Goal of This Newsletter
This newsletter is a call to arms for data professionals - analysts, engineers, scientists, and especially leaders - to stop treating data products like internal tools and start treating them like real products.
Why? Because data products are products. And if they don’t solve a clear problem in a way people understand and care about, they won’t be used. Ever.
Understanding this - and fixing it - can be the difference between a data team seen as a strategic asset and one viewed as a cost center.
Let’s get into it.
The Problem: Build It and They (Don’t) Come
Most data teams operate with a dangerous mindset: “We’ll build it, and they’ll come.”
This comes from a good place. We assume that if we deliver something useful, people will naturally use it. Unfortunately, that’s not how humans work.
The result?
- Dashboards that are opened once and then abandoned
- Reporting tools that are never adopted
- Models that no one trusts
- Time wasted on “data initiatives” with zero impact
I made this mistake, too. I assumed quality and usefulness were enough. I thought distribution was only for marketing people. I was wrong.
What I wish someone had taught me earlier: every data product needs a go-to-market strategy.
Just like real products.
The Solution: Treat Data Products Like Real Products
Product managers obsess over distribution, messaging, user research, activation, and retention. They launch products, not just build them.
Data teams should do the same.
And one of the best frameworks to help us do that?
The Jobs To Be Done (JTBD) framework.
Let me explain.
What Is Jobs To Be Done (JTBD)?
JTBD is a framework for understanding why people adopt a product or service.
It was popularized by Harvard professor Clayton Christensen and innovation expert Bob Moesta. It comes from a deceptively simple insight:
People don’t buy products. They hire them to make progress in their lives.
And one of the most famous JTBD case studies starts with… milkshakes.
Milkshakes and Morning Commutes
A major fast-food chain wanted to increase milkshake sales. So they made them thicker, tastier, cheaper.
It didn’t work.
So they brought in Christensen and Moesta to investigate. They discovered something unexpected:
Most milkshakes were bought in the early morning.
Why?
Interviews revealed that many customers had long, boring commutes. They wanted something to:
- Keep them full until lunch
- Be easy to consume while driving
- Not make a mess
- Feel a little indulgent
The job these commuters were hiring the milkshake to do was make their commute more bearable and keep hunger away. Once the fast-food chain understood this, they stopped marketing the milkshake based on “taste” or “price” and started positioning it as the perfect morning commute companion.
Sales went up.
Applying JTBD to Data Products
This insight applies just as much to dashboards and reports as it does to milkshakes.
Your data product needs to solve a real problem for your user in a specific situation, in a way that makes their life measurably better.
Let’s break down the JTBD framework into 3 parts you can use:
1. The Situation
What is the context your user is in?
→ Are they trying to prepare for a board meeting? → Are they a growth lead being pressed on CAC? → Are they unsure where the marketing budget is going?
Data example: “We’re trying to scale growth, but our Series A investors are watching cash burn like hawks. We need to know if our marketing spend is efficient.”
2. The Desired Progress
What transformation are they hoping for?
→ Do they want to stop being surprised by poor performance? → Do they need to answer questions from execs faster and with more confidence? → Do they want to feel in control?
Data example: “We want instant feedback on whether we’re burning money in a specific channel, so we can stop the bleeding before it kills our runway.”
3. The 4 Forces Driving (or Blocking) Adoption
This is where it gets real. These four forces help you understand why someone might or might not adopt your dashboard or report.
→ Push (pain of the current state)
Milkshake example:
- "I don’t have time for healthy breakfast AND arrive at work in time."
Data examples:
- “I just spent 100k on paid ads with no idea if it worked.”
- “I spend 5 hours every week making investor reports and still get yelled at.”
→ Pull (attraction of the new solution)
Milkshake example:
"A milkshake saves time and is healthy and makes me full."
Data examples:
- “If I immediately see every marketing initiative that is burning cash, we can stop it today.”
- “If we automated our investor reporting, I could use those 5 hours to actually improve performance.”
→ Anxieties (concerns about the new solution)
Milkshake example:
"I’ve never tried milkshakes and I probably don’t like them."
Data examples:
- “I don’t trust these numbers, where are they even coming from?”
- “The data team wants me to use Power BI, and I hate learning new tools.”
→ Inertia (habit and comfort with the status quo)
Milkshake example:
"I’ve gotten so used to get into the office hangry."
Data examples:
- “We’ve been doing it manually forever. It works okay.”
- “I kinda like pulling numbers myself, I feel in control.”
What To Do With This Insight
Once you know:
✅ The user’s situation
✅ The progress they want to make
✅ The forces driving or resisting their behavior
then:
→ you understand problems on a deeper level
→ you can design better products and services
→ then you can improve your marketing and messaging on outcomes instead of features
→ you can collect feedback like product teams:
- “What are you using this dashboard for?”
- “What do you wish it helped you do?”
- “What are you afraid will go wrong?”
👉 Without this, you risk building something nobody cares about.
The Bottom Line
If you take one thing away from this newsletter, let it be this:
Every data product needs a go-to-market plan. And that plan starts by understanding the job your stakeholder is trying to get done.
The JTBD framework gives you the language and structure to do just that.
Stop measuring success by dashboards shipped.
Start measuring jobs completed and adoption achieved.
That’s how your work drives impact and how your team becomes essential.
Action Steps:
- Pick one of your existing data products / dashboards.
- Interview 2–3 users: What situation are they in? What progress do they want to make?
- Map the 4 forces. Push, pull, anxiety, inertia.
- Update your data product, documentation, and comms to reflect the job, not the features.
- Re-launch it like a product, with messaging, onboarding, and a feedback loop.
Your dashboard isn’t done when the data works. It’s done when someone uses it to make progress.
Hope this was helpful. See you next week!
Cheers,
Sebastian
P.S.: I teach this and many other lessons from 17 years of building data teams all over the world in my masterclass "From dashboard factory to strategic partner." Join our 10X Data Team Collective to get access to the full masterclass and an active community of peers who are building the data teams of the future.
