One thing on my mind recently is that I think the term "data products" is probably doomed to become a fad, because the most important part of this—the producty way of working—is all often, simply, missing.

It's becoming another meaningless label—and that's regardless of the debates around the definition of data product.

Why?

There are a few reasons:

1. I occasionally come across DPM (data product management) roles in the enterprise space, and if you took away the words data products or the job title, you'd either assume the role is either some sort of data/engineering role, or a project management gig.
   In other words, the role is a lot more technical and implementation-focused than what a true product manager should be focused on. "Help us get these data deliverables shipped on time. Especially the GenAI ones!" That's the same old job description with a new title—good luck with that! What you're going to do is just attract more technical candidates who want to grab a new title or perceived advancement, but not have to shoulder the responsibility for delivering on UX and business outcomes. Heck—they may not even know what you're talking about with those words.
2. While not all enterprise data products have a heavy UI/UX component, you can't really "do product" without "doing UX design."
   As readers here for some time will note, you can't "not design" the UX. There are no null choices. Every choice, including just letting the UX "emerge" from the data/technical work without intention, is a UX choice. The thing is, this skillset is largely missing in most of the job descriptions, posts, and discussions I see—which would be fine if you assumed or knew that most data teams had dedicated UX design resources to accompany the data product manager. However, that's a big "if"—and it's highly unusual from what I've seen. What sometimes happens with leaders is:
   1. The leader hears about "data products" and is DPC (data product curious)
   2. They might get some training from SVPG, watch some conference talks, read some blogs, hear some podcasts, and start to dial in that "this might be a better way of working"
   3. They start to migrate to the product operating model, including hiring (or grooming) internal DPMs
   4. They deliver some experiments/data products
   5. They begin to realize the UX portion might be a cause of the continued low adoption
   6. They then believe the DPM needs to own that because hiring dedicated UX is either too expensive, they perceive that UX designers won't understand the technical (data/AI) or business domains to be useful
   7. They assign the UX responsibility to the DPMs—with mixed results. You end up with:
      1. Over-confident DPMs who don't know what they don't know—but believe they're qualified to do the UX work (perhaps because they're the best Figma jockey in the house)
      2. Under-confident DPMs who don't realize they might have great potential to add UX to their skills
      3. Indifferent PMs who return to "BAU"—after all, there was no extra time or salary given to them to take on yet more responsibility
      4. Curious DPMs who try to acquire the UX design skills they are missing—or a senior exec/leader realizes that the team needs training if it's being held to these expectations.
         (This #4 is who my seminar is for).
   8. Eventually, the DP leader will realize that UXD, especially on heavy UI/UX-oriented products such as custom applications and dashboards, is really critical—especially if behavior change is required—and so they go to bat to get a job opening for a dedicated UX designer for the data team—so the DPM's time can be freed up for all the other responsibilities they have that just keep continuing to pile on....(and I'll stop here for the purpose of this article!)
3. Value and progress by executive leadership is still measured in metrics that are easy to count: features, products shipped, things in production, JIRA burndowns, and being "on time." In short, "doing" measurable things beats less measurable things: like time spent sitting with, or watching users or teams, and understanding their problems, needs, attitudes, and desires. And, while I am excited to hear about the DPMs and DP teams who are doing this, they sometimes don't know what to do with all the insights. They are told to build "scalable" solutions and get out of the "another custom data product" delivery business, but the culture, team, or manager doesn't foster the necessary environment to help the team capture the research information required to make something truly scalable. In short, they have to rely on "guessing" because they have to maintain the appearance of "doing" because leaders don't know how to evaluate progress any other way.

Now, when you add on new technologies like GenAI and AI into the pantry of technologies that the data team is supposed to own or be the expert on, these problems only compound—because speed + lack of knowledge simply means more misses vs. hits. I think that might be simple math, but you'd probably know better. I mean, you've got new tech (AI, GenAI, etc), new disciplines (UX + DPM), and a changing org/culture around data products. What did you expect?

Am I wrong?

What's your take?

Are you a leader secretly feeling that this is where things are headed for your org with this whole "data product" thing?

Email me and let me know.

Photo by engin akyurt on Unsplash