Today’s episode is for all you internal data product leaders venturing into the world of revenue-generating data products. I’ll be discussing the mindset shift required when enterprise data leaders need to transition from an internal IT or “cost center” role to building something you actually need to sell or monetize. This is a tough switch, even for those with commercial software product management experience, because now, you’re not just delivering outputs; you’re responsible for driving business outcomes and demonstrating tangible value to customers.
I am going to hopefully convince you of the necessity of rigorous user research, the importance of adopting an outcomes-focused approach, and the art of balancing technical expertise with market demands. Of course, we’ll also touch on the relevance of UX quality within your product—and how that impacts its viability. Ultimately, I want to help you avoid common pitfalls and set your data product up for success in a commercial context.
As a companion to this episode, you can read my original article on this topic here once you finish listening!
Highlights/ Skip to
- Understanding that creating revenue-generating data products is hard (5:48)
- Knowing the difference between observing and discovering problems vs. listening to what people say they want (8:01)
- Doing user research to understand what not to do / not to build vs. what you need to build (9:56)
- Transitioning to the outcomes mindset—because irrational buyers like to buy based on their emotions (11:47)
- Letting go of what you believe a customer should find valuable vs. aligning your solution to a problem somebody is ready to spend money to solve (13:39)
- Realizing design and user experience of a solution will quickly become relevant as tolerance for bad UX decreases—even in enterprise software (16:49)
- Adopting a “startup culture” mindset inside a large, not-so-innovative enterprise (21:18)
- The challenges you may face doing the creative, messy, product innovation work that isn’t simply about technical delivery (23:31)
- Making the product’s value evident from the start (26:18)
- Changing your mindset to see product launch as the start—not the end—of the race (28:41)
- Why design, UX, product, and market positioning are so critical if your buyer is non-technical (30:49)
- Letting go of the idea that data is the solution to your customers’ problems (35:11)
Quotes from Today’s Episode
- You need to understand that you’ll need to do a lot more user research than you’re probably used to. It’s not just about figuring out what to build with commercial products; it’s equally important to understand what *not* to build. There will be a flood of opinions, and you can’t act on all of them. Remember, building the wrong thing has a real opportunity cost. Part of becoming a mature product manager is learning to say “no.” You need to define boundaries. To find product-market fit and gain traction, discipline is key: you need to know what to cut. This skill comes from practice, not just theory, so you refine it by doing it. And by doing it, you refine your vision and identify the essential features versus the nice-to-haves. (9:57)
- You have to adopt an outcomes mindset when developing data products you want somebody to pay for. It might feel counterintuitive if you come from a technical background, but remember that buyers can be irrational—even when it comes to purchasing data products. If you’re spending 90% of your time on technical delivery and project management and only 10% on UX design, marketing, and sales, you’re doing it wrong. People don’t care about the outputs; they care about the benefits your technical solution provides. Delivering a project on time is irrelevant if it doesn’t actually provide any benefits to the user. This mindset needs to be adopted by the entire team, especially the product management leader. You need to create a product that people actually want and are willing to pay for. (11:48)
- You’re now creating something new, and it’s easy to get discouraged. You pour your heart and soul into a project, and sometimes, you’re met with rejection. People might say, “No thanks,” or worse, they might not even give you the time of day. This product is your baby, and it feels personal. But here’s the thing: you can’t take it personally. You have to remember that people aren’t rejecting you. They’re simply not seeing how your solution idea benefits them. Creative work is risky. There are no guarantees. You have to iterate, adapt, and keep developing your idea. Rejection is part of the process; recontextualize it as a chance to “capture data.” So, embrace the messiness of creation. It’s normal. Shift your mindset. (23:33)
- Once your data product is live, the real questions begin. Are users sticking around? Are they churning? Are they finding the value they expected after exposure to your marketing, prototypes, and finally, the actual product? This is where the game truly starts. Internal data product teams pivoting to commercial products need to shift their perspective. Product development isn’t just about shipping something and moving on. It’s about owning the problem space, securing ongoing funding, and continuously improving the solution. If you’re coming from a large IT organization, this can feel very different. You’re used to closing tickets and handing things off. But with a commercial data product, you’re responsible for delivering benefits and outcomes that users actually care about. It’s about impact, not just output. So, don’t overblow the launch. Focus on the long game. (29:13)
- Data itself isn’t always the solution people are willing to pay for. For example, you might have this amazing AI-powered tool or capability you’ve created, but customers might only be ready to actually *buy* a basic analytics solution to start. Sometimes, the fanciest tech isn’t what the market needs right now. They might not be ready for the advanced stuff. Your amazing in-house IP that everyone loved? The market may not find this to be a solution they want to pay for right now—not because it has zero value, but because it’s not solving their biggest and most urgent problem right now. Your technical training and analytics skills might not be as directly applicable in this creative, zero-to-one product development process, so you need to leverage different skills when doing discovery and design work. The “product” side of things can be messy, fast, unpredictable, and even emotional. But that’s the environment you might have to embrace to build data products that people will actually pay for. (35:24)
Links
Transcript
Brian: Welcome back to Experiencing Data. This is Brian T. O’Neill. Today, I have an episode for all of you internal data product leaders out there, and the challenges that you’re going to face the first time you try to create a revenue-generating data product. So, I’m talking about something that’s actually externally facing. Perhaps you created some really cool IP, you want to spin it off as an application that you might be able to sell externally. Maybe you’re a data science or analytics consulting firm, and you’re starting to move into the product model and seeing, hey, this tool we built for our clients, could be a SaaS product or something similar.
So, there’s a mindset shift that needs to happen, in my opinion, and just kind of thinking about the general biases I tend to see when someone has been in an enablement organization, such as, you know, part of an internal IT team, or quote, “Cost center” inside of a large organization, there’s just some mindset shifts that have to happen. Part of this episode is influenced by. I put up a post on LinkedIn last week—or, I don’t know, a couple weeks ago—and I sketched out a visual showing when I talk about data product management and adopting this, like, product operating model, what I’m talking about.
And for a lot of teams, I know the gamut of the responsibility is primarily in building the platform. So, of your source systems, and then you’re creating this platform, which then is going to have a catalog of data products, which are what I actually call data assets. These are partially refined assets that can then be consumed and refined further downstream by yet another developer, engineer, data scientist, analyst, sometimes a business user. This isn’t really what I’m talking about—and it’s okay to do that. I don’t have any issues with that, and I think you can sort of apply the product ecosystem to doing that.
In my book, that’s not really adopting the full data product management life cycle and model because the delivery is still a technical output, and we’re still relying on a downstream party to then turn that into some actual value. So, these assets alone haven’t really created any inherent value; they’re dependent on a further stakeholder downstream, usually a technical builder of some kind to take that and do something with these assets. So, for me, the diagram kind of shows that a lot of the community talking about data products is really focused on that portion of it only. And my sketch or diagram of this is really much wider. For me, at the highest levels of maturity, these data product managers are really truly looking end to end.
So, they would be building or having responsibilities for one or more—maybe even a portfolio—of data products that are truly end to end, meaning the last person using them is either an actual business consumer or, even better, it’s a downstream customer. And that’s not always relevant because a lot of times our customers are internal, right? But the idea is that we’re focused on delivering some kind of benefit to the actual paying customers in the organization. Yes, there’s always cost cutting in some of these things where, you know, the actual paying customer may not see how we’re cutting costs, and changing our supply chain, or something like this. You know, maybe long-term, they might see some impacts from that, but the gamut is much wider.
And when you have that wide viewpoint, this actually allows you to start thinking about things like spinning out something that’s actually a revenue-generating product or a new line of business or something along these lines. So, I just wanted to talk about some of the challenges that I think the—I hate saying the average data product leader, but someone who’s primarily been in an IT organization, probably with mostly responsibility for delivering technical outputs and assets on schedule and not necessarily having business value, but now they’re moving into a space where they’re either being asked, or for their own career reasons, they want to be able to show the impact that they’re having, ideally both on customers and users, delighting them, and also being able to show some kind of fiscal impact. So, let’s jump into it with that kind of intro there. You can go on LinkedIn and see the diagram. This generated a l—[laugh]—a lot of commentary, ironically, a lot of people saying how much they agreed with this, but then in practice, I see that model very infrequently in the wild, and it’s somewhat aspirational.
So, I found that to be one of the most interesting things is, the loudest voices commenting on the diagram were advocating for that approach, if I recall correctly, but that’s not what I often see happening. So anyhow, that was—it’s interesting. Go check out my LinkedIn if you want to find it. And I always do enjoy connecting with listeners of the show anyway, so feel free to reach out, drop me a little note, and mention the podcast, and I’d be happy to connect with you.
So, the first thing I wanted to say is, this is a hard environment because you’re almost, like, jumping into startup world. It’s almost like creating a little business here because now there’s a revenue responsibility here. So… this is hard. So, that’s the first thing to understand. Even if you’ve been in actual commercial product management leadership or product design for a while, it’s a hard game. It’s a harder game.
There are some pros, though, there’s some pros and cons. While there’s some biases you might have to work through, there are some benefits too, to being able to do this kind of work in the safe environment of a large enterprise or organization that ha—you have support resources, you have a salary, all this kind of stuff. So, I do think, though, that you may have more struggles if you’re in a really large enterprise that’s used to rigid processes. The company is very risk averse and default no to almost every change that’s proposed, or it has a culture that really demands assurances when you can’t possibly have assurances when you’re creating something new. Otherwise it literally would not be innovation because innovation is literally the practice of coming up with something new in a face of uncertainty.
This gets even worse if the organization thinks that it’s nimble and innovative, but the actual culture is completely not that. So, that’s a tough environment to do this in here, but hey, that’s the game, right? If you want to be able to really show the value here and do amazing work, most of the time, it’s hard. It’s pretty rare that there’s just some easy things sitting out there and building it as simple, finding someone to pay for it is easy, and people are just ready to sign up and buy it. For every one person, or one company, one team that gets lucky with that, there’s probably 999 other ones that do not have that experience, and so watch out for survivor bias and all of that, if you’re reading about that.
This stuff is hard, so I just wanted to put that out there first. But here’s ten ideas that I hope you’ll be aware of as you jump into this pond, and the water is beautiful, but hey, there’s no lifeguards on duty here. So, I think these are also true whether you’re building a platform product, an AI solution, or a traditional analytics SaaS, something like that. So, without further ado, let’s jump into these.
So, the first one, in the past, if you’re working internally, you’ve maybe had a handful of stakeholders, you know, and maybe under that, there’s tens or hundreds—maybe thousands in a few places—of users downstream from that, but really, you’re serving a fairly small audience of internal colleagues and stakeholders. Well, now you’ve got thousands, probably tens to hundreds of thousands, of possible addressable market or prospects out there, maybe even in the millions. And this wider pool of prospective customers can seem really inviting at first because there’s so many more of them, until you realize how unique individual people are, and how much noise each opinion can put into your product backlog if you’re not managing what people say that they want, and understanding the difference between observing and discovering problems versus just listening to what people say that they would use or what they want to be built. There’s again, pros and cons here. It seems like there’s a much bigger market to possibly buy or use the solution that you have, and maybe, again, it resonated really well internally, and you might think that the whole rest of the world—let’s say you’re in banking, and you built some application for tellers or something like this, and you’re like, man, every bank would want to do that, until you realize every bank’s teller department doesn’t quite work like that.
Not to mention, what are the tellers’ incentives? What is the management of the tellers’ incentives? There’s just so many different things going on here. So, seems wider, seems like there’s a lot more, and it’s true, there are a lot more people now in the addressable market, but you got to sort through the noise and figure out what’s actually resonating here in our research? What are we actually learning as an expensive, urgent problem that someone would really want to pay money to solve for?
Second one, you’re going to need to do a lot more user research to understand just as much what not to do and not to build versus what you do need to build because the opinions out there will be many, and you can’t build everything, and there’s an opportunity cost when you build the wrong thing. So, startups know this really well because they’ve got a funding runway, and they literally call it burning it down: the burndown, right? You’re burning cash, and you want to be able to show traction as soon as possible here. And so, part of this product management maturity is knowing what to say no to. How far do you go with this feature?
How far do you—you know, if you’re building some kind of AI solution, well, where are the boundaries, especially if it’s a GenAI solution? Where are the boundaries on this product going to be? What is acceptable risk, both within the product, but also within your little emerging business? What levels of risks are you going to be comfortable with—and not—such that you can try to get to some kind of product-market fit sooner than later, and start showing some traction here? And so, it takes discipline to know what not to do, just as much as it does to know what to do.
And I think a lot of that is probably informed by practice and actually doing this, and it’s not something you could just inherently be taught to do, although I think these days, it’s gotten really interesting what we can do with the large language models to challenge our positions and to feed a bunch of assumptions in, and then ask it to argue that the counter opinions to whatever it is that you’re advocating for, and to really get some different ways to think about the product that you’re trying to build, and maybe what is really, actually necessary or absolute minimum requirements versus what’s, kind of, nice to have. So anyhow, so that’s number two.
Number three, you’re going to have to transition to this outcomes mindset—and you’ve heard me talk about this before on the show—but really early in the journey and start to realize that irrational buyers buy on emotion, even when it comes to data products. So, if you have a technical background, this is probably going to be a hard shift to make, particularly if 90% of your effort goes into product management, project management, technical development, all that kind of stuff, and you’re spending maybe 10% of your time on user experience design, marketing, sales, kind of like all that other stuff that feels like, oh yeah, we got to do all that other stuff too. If that’s the balance of those two things there, you’re probably going to have a real challenge with this because people aren’t rewarding the outputs; they’re rewarding the benefits that the outputs provide to them, and so simply putting something out on time, this is really irrelevant if there’s no benefits associated with the thing that you’re building. So, that transition—and this is really ideally something that the whole team will have, and it’s usually not something early career people have because they’re very focused on skills because that’s what we teach in school, is technical skills and passing the test, getting the right answer, all this kind of stuff, they tend to be very attached to what the skills are that they have and deploying those skills against problems. And that’s fine. You still need skills, but if you’re trying to create a product here, there’s other skills besides just the building part that need to be present in order to make that thing something somebody wants and is willing to pay for. So, this outcomes mindset is really the overarching theme that the team needs to have, and particularly the product management leader that’s behind it.
Number four, you may think that your job is to build a data-driven insight solution, and maybe you’ll resist heavily when the market says, “Hey, we want this thing over here. Can you do that?” And over there may be a viable product, but your team will miss it if they think, hey, our job is to make the models, the pipelines, the platforms, whatever that output is. So, what’s the key insight here of number four? It’s letting go of what you believe would, should, or could benefit the customer as a commercial data product, and instead accepting the reality of what their words and actions are actually telling you, the thing that you’re actually observing in the wild here.
And this is really hard if you’re an expert in one of these particular technical domains. Let’s say you’re really good at fraud detection models, and you feel like, hey, this model is something that we could, again, sell to banks or something like this. And then you find out that this audience that you thought should really find this valuable because how could they possibly not, yet, when you go out there, you find that they’re just really not that interested, or they kind of give you some compliments and tell you how much they think it could be awesome for the industry, but personally and individually, not a single one of them is willing to exchange some cash, or some other form of value, another conversation referring you to another customer—these are all the from the Mom Test—these ideas of is the prospect willing to exchange something of value, either money, reputational risk, or more of their time to learn more about what you’re building. This is really hard if you’re an expert in that field because you might feel that your identity is in question. And maybe you’ve spent a decade creating fraud models, or something, fraud detection models, and you’re finding that this addressable market out there just isn’t that excited about it.
And so, this is really difficult to let go here. A lot of people, especially really technical people in very technical domains, tend to have, at least in my experience, they have a strong identity with their career and their technical background, and so I think it can hit a little bit more personally. And part of this product thing is really not getting so in love with the solution side, but really falling in love with the problem side. And that’s, again, this is one of those mindset shifts that has to happen. So, we really need to let go of the would, should, and could mentality because again, you might think it’s the greatest thing, and they should want this, and how could they not possibly see the value in this, but if the market’s just not responding to it—it’s possible it’s your messaging.
It could be in the marketing and the messaging that you’re using, that’s always a possibility, but it may simply be that you’ve got some bias. You’ve lived in that world forever, you’ve gotten praise, you’ve seen the impact of your work in the small ecosystem, but that ecosystem may be very unique, and it’s just not something that the market overall—it’s not replicated in the market as much as you think it is.
Number five, you will likely realize that the design and the user experience of the solution, particularly if it is a technical type of solution, will quickly become relevant unless you’re doing something so groundbreaking and revolutionary that customers are willing to tolerate high levels of initial complexity and difficulty just to get the value that the product promises here. So, the thing is, like, shortly after you showed traction here, you may find that there’s a competitor on your heels, and they don’t have all the technical debt you went through, and they’ve got a user experience and proposition that’s super crystal clear, and it’s simple, and the UI looks better, and the user experience is so much smoother, and they’ve obfuscated a bunch of the technical stuff there that maybe didn’t need to be, you know, delivered directly in the interface to begin with. You know, that CLI interface might have seemed so powerful until a competitor’s app comes out, and all of a sudden, non-technical users can also get value out of the data and the insights here. So, the point here is that, broadly speaking, even with enterprise software now—and this has been true for a decade, probably, if not longer—tolerance for bad design—and I’m talking about not colors and fonts, but really the entire user experience, the complexity, the level of effort required to get some value out of the solution—in general, the whole industry of product, including B2B products, has gotten better at this.
The bar is higher. There’s less tolerance for hard-to-use stuff. I’ve seen this with consulting projects myself, where a company may be selling an API endpoint to access some proprietary AI capability, and even when they’re selling to a fairly technical, knowledgeable audience, it’s hard to sell that API endpoint unless you can show the customer, well, here’s what you could do with this API endpoint that we’re selling, and these machine learning or AI capabilities that are behind it. They needed to show examples of that. And as you start, even these examples could start to become a SaaS version of the product.
One of the clients I was working with, that was the thinking, is that, hey, we think some of our customer base actually would rather not even have the API; they would rather have the more limited SaaS version of the application there because they’re getting a lot of the value out of it right there without any of the build lift. And this SaaS product, this demo that was intended to show the capability of the API actually itself, started to feel like a version of a product that they could sell. And so, the point here is that the user experience, even to technical users and B2B buyers, they’re also considering this, and they probably have other options out there. And so, this is more important than it used to be. Tolerance levels are simply lower for bad design.
People are so used to apps working on their phone, things being easier to use than they used to be. If you’re really relegating design and user experience as a second-class citizen in the product you, well, good luck. And there are places where, yeah, it doesn’t make sense as much to invest heavy amounts of time there, but even technical products for developers and data scientists, those can be well designed. An IDE, a coding environment can be well designed or poorly designed. And I’m sure most of you have all experienced this personally in your own two tool sets.
So, something to keep in mind there, you probably are going to need to invest in this more than you did before, especially when there’s multiple options out there for the market. Unlike when you were in your internal data product management role, where maybe you had the only solution and everybody had to use it, and it’s like, well, if the sales team or the marketing team doesn’t really like it, well that’s all they got because we’re in enablement, and this is the official data product that everybody is supposed to use, and so while there is a business impact, if people can’t use it, won’t use it, don’t like it, or it takes a lot more time, you are hurting the business in a way, in that sense because the product is actually creating friction. The difference here is they can’t just go buy a different solution. Well, in the commercial market, where you’re asking for money for your thing, there probably are other solutions, including no solution at all, or the status quo.
Number six, if you’re in a big, slow, wealthy enterprise, you’re probably in a culture that does not support innovation, even if they have a department with that name that maybe it’s been shut down, maybe it hasn’t. I think you all know what I’m talking about here. Look, the culture wants to avoid risk and follow processes, things that don’t really pair well with lowercase agile product development. Most of the people are in the organization, are there to follow the process, and outcomes and results are somebody else’s problem with the higher pay grade, and the whole culture can get kind of wrapped up in this. So, to counter this, you may need to imitate the grit and flexibility of startup culture, flexible teams who really love the customer problem, as I was talking about earlier, and they take on the role that is needed by this emerging business, and the users and buyers, the customers, within this business, and they’re relentlessly focused on finding that product-market fit here, and listening to what the market is actually telling them. The challenge is trying to work like this inside of that default culture that you’re part of, resisting it when it’s at odds with what you need to do in order to push out this commercial product here, and also realizing you have some assets on your side as well, some pluses.
And I mentioned this in kind of the opening section on this opening segment on this podcast, but like, you have a salary, and maybe you have the marketing and branding of the parent company that you can attach to this thing, which gets you phone calls that you might not otherwise get quite so quickly. And maybe you have internal QA resources, you have a security team to audit everything that you’re doing, you’ve got development resources, you have a marketing team. It’s just, there’s a lot of benefits that can come with this as well. So, I think it’s really figuring out, how do you tap into the benefits without letting the de facto culture of many large enterprise organizations apply to this commercial data product that you’re trying to put out? Those two things can be at odds with each other.
Number seven, you may find it hard to adapt to the creative work required when you’re building something new. Examples: feedback that says, “No thanks.” Or, as I said earlier, “Yeah, that’s amazing. I could totally see the market why—I could totally see data scientists working on X, Y and Z, finding this really amazing. You should go talk to so and so. Have you guys thought about talking to this type of organization?”
Or worse, you get silence. You’re not even getting these phone calls. You’re not even able to get a research interview with a target customer, so you’re feeling rejection. And it’s easier when it’s not your baby—and again, if you’ve got that comforting culture of you’ve got a salary and you’ve got other roles, and this is kind of like a spin off project or something like this, that can help soften some of this, but if you’re not used to that rejection—and this gets back to some of the identity things we were talking about earlier—this can be really hard because it feels like it’s your baby. It’s difficult here, and hearing no thanks, or silence, it can tap you in a difficult way.
So, I think realizing that it’s not you or your skills that are being rejected, it’s this idea is not giving me any. Benefits. I’m not connecting what you think is amazing with some problem that I have that would benefit me in an obvious, quick, or immediately relevant way. And there’s nothing personal about that at all. So, learning to reject the idea and not take it as personal rejection, I think that’s a really important thing.
And there’s creative work here. Like when you do creative work, there’s no guarantees. It’s called creative for a reason. We don’t know where it’s going. We have to create nothing from something. Chances are, the first thing is not going to resonate. It’s going to take iteration, and change, and development, and that’s actually normal. So, if that’s what you’re going through, then you’re living in the normal way. So, take comfort in the fact that all of that mess that goes into product is normal. That’s normalcy.
We need to adopt a creative thinking, a creative way of approaching the work here, and we can’t just be in this delivery mindset. I live in a factory. I just assemble the products to the requirements, ship it out, and then I move on to the next thing. There’s nothing wrong with that work, and there’s times when that kind of work needs to be done, but that’s not product leadership work; that’s not creative work when you’re giving birth to a new thing, and you’re doing zero-to-one type of work.
Number eight, you’ll soon realize that getting people to commit to paying you monthly or even annually for your data-driven solution is a lot harder unless the value is crystal clear and relevant, right now. You’re going to be confused when they aren’t super excited for the, you know, the very first time you tell them about your baby and you asked to set up a call, and you’re wondering why they don’t see the obvious value that your whole team does. Or maybe you’ve had a couple previous sales calls or discovery calls or research calls, and the value did seem obvious. Well, the wise product leader here is going to welcome these challenges, pushbacks, complaints and feedback. The more volume of that stuff you’re getting, the better because this is all ammunition and insight to make a better product.
Think of it as gathering data. You’re actually getting data back so that you can factor all that stuff into building a better product or a different product that’s actually going to have impact. So, it’s just information, it’s not judgment, and it’s certainly better than silence. So, getting someone to put down money for it, it’s hard, as we talked about. And the other aspect of this number eight here is that it’s relevant, but it’s also relevant right now.
So, I’m sure you’ve got long-term projects in your house. There’s a hole in the ceiling and there’s a little draft coming in, and maybe pests or rodents can get in there during the summer season. And yes, it should be patched up, but it’s been there for eight years so far. And maybe there’s a product out there that’s specifically for rodent-based holes in ceilings in Florida.
Are you going to buy it? Well, again, it’s a relevant product, the benefits are obvious, but the question is, is it relevant right now? Is it something the buyer needs right now? Where is it in their priorities of all the other stuff going on their life is filling that hole with this plug specifically for Florida homeowners that live near the beach, blah, blah, blah, is it relevant right now? It’s again, hard work, but this will change how you approach the work when you realize it can’t just solve a problem; it’s got to solve a problem that’s important right now.
Number nine, you won’t realize that a lot of quote, “Product” happens after you ship the first thing and not before. So, launches can tend to get way overblown, and really, for mature product teams, the launch is the beginning and not the end. The launch is, it’s out there; people can actually buy it and pay for it. Okay, here’s my credit card. Here’s my contract I sign. Give it to me. Let me play with it. Let me see the value here.
Now, it’s real. Now, the question is, are they sticking around? Are they going to churn? Are they actually getting the actual value that they saw in the marketing, and the conversations, the design prototypes, all that stuff that you were doing, and maybe they were part of that. This is actually the beginning of the game.
And so, I think the internal data products management organizations, especially those that are not looking at product as this is a problem space that needs funding, and we need someone to own that product space because even if we ship stuff out, the problem’s not just probably immediately going away, it’s on a continuum of getting better, and the question is, how much better should it be? Is that something we should do right now? It’s an ongoing thing. There’s probably new features, stuff you need to turn off, stuff that didn’t work right? It’s a continuum. The launch is just a point in time. It’s really the kickoff of the race. It’s not the end of the race.
But if you’ve been in the large IT data organization, it may feel like the end of the game because you get to close the Jira ticket and move on to the next thing, and now it’s somebody else’s problem. And it’s somebody else’s problem if you’re not responsible for benefits and outcomes, and instead you’re just responsible for outputs on time. And that’s that core difference I was talking about: outputs on time versus benefits at the right time, benefits people care about, benefits that can be observed in the wild, metrics that you can actually measure. So, don’t overblow the launch.
Number ten—the last one here—if you’re technical and your buyer is quote, “On the business side,” you’ll probably learn the hard way why design, UX, product, and market positioning is so critical, even if the solution is intended for technical audiences. The actuaries there, well, they might think that your new risk calculator model majigger thing is unbelievable, and that’s who you built this for because you were an actuary, or you worked with actuaries for a long time, and you’re like, man, I could see actuaries all over the place needing this thing. And then you realize the CIO sitting two, three levels of management above, well, they’re your fiscal buyer. There they be. They’re the ones writing the checks. And they’re still not quite sure what’s wrong with the way they already do risk calculations.
So, this is a really expensive platform, it’s going to take a long time to wire it in before we could even get any value. There’s also some things that are really hard to undo if we have to take your product out of here. So, what am I getting here? I could just leave this alone because the work actuaries are doing, well, it’s kind of hard to measure anyways. We know we need them, but it’s sometimes hard to measure the counterfactuals there, so like, why should I make a change here? Should I put my reputation on the line for this? What’s the benefit to me going to be if I sign a check for this thing?
Yeah, okay, fine. We’re going to save a little bit of time, and they’ll spend less time doing, you know, hand calculations or spreadsheet calculations because now they’ve got your fancy model majigger thing. I’m playing out a story here for you, but the important thing here is realizing that your end-users and your buyers can be two different people, and you may need to really satisfy that fiscal buyer, and the way we talk to them and talk about the product and show the product may be a bit different, and that B2B sales can be more complicated here. I’m sure you’ve all used software if you were not the buyer, where you had a tool imposed on you.
We’re a Microsoft Teams company. We are an Outlook company. We are a Notion company. Somebody made a decision that you’re a Notion company, that you’re a Teams company. And maybe you’re like, “Why the heck would we do this? This is such a waste of time. The last company I was at used this, and we like halved the amount of communication time when we switched to Slack.” I’m just making stuff up here. The point is, someone made a compelling argument to the CIO about why being a Microsoft shop was better than not being a Microsoft shop or a Google shop, and that’s how the company was going to work, even if all the audience maybe was kind of like, ugh, we don’t really want to use this solution. We don’t want to use these tools.
That’s part of the game of product is figuring out, can you make a product that all the end-users are champions for it, and the value is very obvious to the fiscal buyer, if you’re not actually selling—if a data scientist working at a bank, or an actuary working at a bank, an insurance company, if they’re not actually the ones writing the check for it, then you can’t just make them happy. This is one of the challenges sometimes that I’ll just—a little side note here, with working with less experienced user experience designers, especially those that are not really product designers, they get really emphatically hooked on the user experience. And yeah, it’s in the title, but only making the users happy does not necessarily get you a product that’s worth paying for right now.
And product designers tend to be wider gamut. They’re thinking about the ecosystem that the product lives in, and who are all the different stakeholders, and the team’s mentality, and understanding the buyers the way we talk about position, even design the product, the way—you know, there might be different screens in the product because the way it’s being sold is differently than the way the end-users are going to use it. Because the CIO needs a management view, even though this is an operational tool that’s going to be used by the Actuaries, so maybe you need to have a different product face, front face for the product, a dashboard or whatever because of who the buyer is. And so, that’s designing with a more product mindset, versus factoring in user experience only.
And so, that’s it. Those are my ten ideas. And if you got this far and you’ve been tasked with making your first commercial data product, look, somebody already believes in you and/or your team. That’s awesome. Just the kicker is that you may need to let go of this idea that data is the solution. It might not be. You might end up building a rudimentary product, you might have come in with this amazing AI-powered agentic something-or-other, and you’re like, “Man, they don’t need any of this.” Or like, what they want to buy right now is a very basic analytics solution that does not need any predictive analytics. It doesn’t need this. They’re not even ready to stand up yet, let alone run, or walk. But that’s what they need help with right now.
So, you might need to let go of data as a solution, this amazing IP that we’ve created in-house is the solution? Your technical training, your analytics skills, some of those things are not going to be as helpful to you when we’re in the creative part of this product process, this birthing process, this zero-to-one creative work that happens if you’re trying to put something out into the market. You know what a bad technical strategy looks like when you see it. The thing with data product creation is that the data part and the product part require different skills, and you’re likely going to be biased towards the former. And that’s normal because of where you came from and the work you’ve been doing.
The latter work, the product part can be sloppy, fast, unpredictable, messy, sometimes irrational, sometimes emotional, but that might be the environment you’re going to need to play in for a while if you want to build indispensable data products that people will actually pay for.
That’s all I got for you today. If you need help with this kind of work, I love doing zero-to-one work with startups and companies that are trying to put new things into the world, and visioning work, and things like this, so feel free to reach out to me. The best way is you can contact me at designingforanalytics.com/contact—the word contact, C-O-N-T-A-C-T.
You could set up a free discovery call with me there, and we can look into what it is that you’re trying to bring into the world and see if there’s a way I can potentially help you with that. So, until next time, thanks for listening to Experiencing Data. I hope you’ll leave a podcast review in Apple podcasts. You can do that by going to designingforanalytics.com/podcast. That’s also a place you can get on my weekly insights mailing list, where I leave one-page summaries of all these episodes if you don’t have time to listen to the whole thing, as well as accompanying articles that sometimes go with these podcast episodes, and my other weekly insights and dispatches that I put out about designing amazing data products. Take care.