In this second part of my three-part series (catch Part I via episode 182), I dig deeper into the key idea that sales in commercial data products can be accelerated by designing for actual user workflows—vs. going wide with a “many-purpose” AI and analytics solution that “does more,” but is misaligned with how users’ most important work actually gets done.

To explain this, I will explain the concept of user experience (UX) outcomes, and how building your solution to enable these outcomes may be a dependency for you to get sales traction, and for your customer to see the value of your solution. I also share practical steps to improve UX outcomes in commercial data products, from establishing a baseline definition of UX quality to mapping out users’ current workflows (and future ones, when agentic AI changes their job). Finally, I talk about how approaching product development as small “bets” helps you build small, and learn fast so you can accelerate value creation.

Highlights/ Skip to:

• Continuing the journey: designing for users, workflows, and tasks (00:32)
• How UX impacts sales—not just usage and  adoption(02:16)
• Understanding how you can leverage users’ frustrations and perceived risks as fuel for building an indispensable data product (04:11)
• Definition of a UX outcome (7:30)
• Establishing a baseline definition of product (UX) quality, so you know how to observe and measure improvement (11:04 )
• Spotting friction and solving the right customer problems first (15:34)
• Collecting actionable user feedback (20:02)
• Moving users along the scale from frustration to satisfaction to delight (23:04)
• Unique challenges of designing B2B AI and analytics products used for decision intelligence (25:04)

Links

• Listen to part one: Episode 182
• Not sure why your product isn't selling like you'd like—or adoption is low?
  Schedule a Design-Eyes Assessment with me and get clarity, now.

Transcript:

This is Brian T. O’Neill. Part two today. Part one of this episode is number 182, so if you hadn’t catched—haven’t caught, I should say—episode 182 yet, please head back over there. The title of today’s episode, “Accelerating Sales in B2b Analytics and Ai Products By Focusing On Designing for Users, Workflows, and Tasks.” So again, this is a continuation. And what are we continuing? Where did we leave off?

Towards the end of 182, I mentioned that we would get really clear about, you’ve heard me use this language of user experience outcomes. I think we all know what business outcomes are: business benefits, benefits to our stakeholders, fiscal benefits, things like this, and outcome is a change that we can see. But what does it mean in the context of user experience? I think it warrants getting really clear about what that means, so I’m going to go over that today as part of this overall theme, and how that ties, of course, to accelerating sales and adoption of the products that we make, and then secondly, I want to talk a little bit about this idea of disrupting the market with AI, as well as the idea of AI changing the work that users do and how to think about that if you are creating a largely AI-powered solution that does seem like it’s going to change the tasks that users do. So, how do you position that well such that someone would actually want to pay to get access to it?

All right. So, why the user experience outcome stuff matters? Because this gets to my overall theme, my first principles thinking around this, which is, if you’re not designing for the people who are actually going to use this, then it’s only a matter of time before, first of all, if for some reason, you convinced a buyer to buy it, and the buyer is not the end-user, which is sometimes the case in B2B, they’re not going to hold on to your solution for very long if they find out nobody’s using it and/or they’re not getting any value from it. So, it’s critical that we think about user experience early in the birth of our products. And the other thing is that by focusing on the user experience piece when we’re creating our solutions, you’re naturally making the solutions more intuitive-feeling such that less explanation of what the solution does and how it works and who it’s for, that stuff becomes self-evident in the solution, and you can get out of convincing mode. Because if you’re targeting the right buyers, and you haven’t taken too broad of a customer or target person that you’re trying to help, if that persona is not too broad, then the product should really be selling itself, or it should be rather easy for them to understand the value of it.

So, before I get to the definitions of the UX outcomes, and then go into, kind of, the AI disruption and the AI changing the flow of work, where should you start if you’re trying to get a B2B analytics and AI products off the ground, and you’re really good at the tech and the data part, but you’re having trouble getting that acceleration there? This is going to dovetail into the user experience outcome space, so let’s start here. Where to start? My suggestion is, focusing your product work on removing observable frustration and risks within your target audience’s current work. So, let me say it again, focus your product on removing observable frustration and risk within their current workflow. That is, if you want people to pay for it.

When we can observe our users' experience improving along a scale of frustration to satisfaction and hopefully to delight, we’re going to accelerate the business outcomes, both for you and your company and your product or your team, and for the buyers. Because if we’re in this B2B context, that buyer is not just looking for—part of the buy might be about them looking better to their boss or positioning themselves personally, but it’s also about being able to show value for the company, and those things are pretty intertwined. So, there’s at least two parties here, or three parties, if you think about the individual end-user, the buyers and the organization who’s paying for this B2B solution, and then your organization as well. We’ve got several different parties here that want to see benefits. But getting to the user, when we can observe our users’ experience improving along a scale of frustration to satisfaction to delight, we accelerate our business outcomes, and the buyers’, and we call these user experience outcomes.

And I want to take a moment right now that there’s lots of different definitions of what experience is in all of this, and I am fully crediting Jared Spool’s work here. I think he’s done a great job of putting this into language that’s easy for non-designers and non-user experience people to understand, and I think this language is great for user experience people as well. It makes it very clear what the purpose of design is, and the purpose of design—the activities that we do—is to move our users along this scale, frustration, satisfaction, to delight. You can think of that as, like—Jared often draws this out as a chart where the Y axes of the chart are these three different feelings. And so, our job is to really move them along that scale.

The chatter around AI—and again, let’s get specific here, language model and more specifically, large language model capabilities—suggest that we might find new ways to help users traverse the path from A to B on the river, or maybe that the river is no longer relevant or the most efficient way to get people from A to B in their workflow. While you want business outcomes, if you’re the team that’s building the product or you’re running the business, you want more sales and less churn, more adoption, you want to be looked at as go-to, this kind of thing, and your B2B customer wants to see an ROI around their investment in your data product, this other success metric you need is to anchor on this idea of a user experience outcome.

So, let’s define it. A user experience outcome, what is it? A user experience outcome is an observable improvement in somebody’s life, in this case, your customer, and I’m going to get very specific and say it’s the actual users of the solution, not necessarily the fiscal buyer of your product, but you can apply this thinking to both of those personas. When something is observable, it’s measurable. And most data, people should like this idea: even if we’re talking about how someone feels about something here, you can still apply your analytical thinking to this and see that there’s a way to measure this and see it, and as such, we can potentially change it, and then we can retest again—or remeasure again—and see where we’re at.

So, in addition to moving the business ROI and metrics forward, or your sales or adoption, however you’re measuring these kinds of business KPIs as a product leader or founder, your goal is also to drive these user experience outcomes, this change in their feeling, from frustration, obviously, all the way up to delight, if you can, with satisfaction being that kind of middle ground. And the market’s going to tell you whether satisfaction is enough or whether, no, I’m already satisfied. You got to delight me here beyond, like, anything I could imagine, to get me to switch. Why? Well, as I stated earlier, you can’t get to the business success if nobody is using the product or they don’t perceive the benefits of it.

And the benefits here have to apply both to the fiscal buyer and to the end-user. Sometimes you can slip one by them, get the sale, get in there, but you’re going to find out quickly whether or not the staff or the people who are supposed to be using it are using it, do they care about it, are they willing to give you feedback on it, all this kind of stuff. We can measure a user experience outcome when we see a user moving from along this scale. As we put product out, we get feedback on this, ideally through observation and ongoing communication, when we can see that our changes are moving them from that frustration to satisfaction and hopefully to delight when they use our product or your product, then you’re starting to move the user experience outcomes, and this should make it easier to move the sales outcomes, which is probably your ultimate goal for listening to this, is getting that adoption, that trust, landing the sale.

So, how do you do this in practice? Let’s talk about some tactical steps to improving your data product’s user experience outcomes. And you could think of it just improving your data product’s user experience, but like—I want you to tie the experience to this idea of outcomes here because it suggests there’s a change that’s observable, that everyone can agree on, and it’s not this very subjective, hand-wavy kind of thing that only designers understand, and it’s kind of like we never really know if we’re doing it right. I want to make this as clear as possible so it’s something that you can try to do on your own, or at least you know what to look for when you’re working with a design team or with an outside vendor or whatever it may be.

So, some tactical steps to improving your data product’s UX outcomes. First, establishing a baseline. Take a single customer problem or job to be done and write it as a clear use case that has a starting and an ending point. And of course, this requires talking to users, ideally, actually observing users doing their work, since verbal feedback isn’t always as reliable as actually observing people, and if you’re not sure what to ask, [I have an article like I’ll link up 00:11:26] with ten sample questions for users of data products that you can use to get this conversation going here. But the focus here is, we want to get a baseline. You could start with one core customer problem, and we want to establish this baseline so that we know where we’re starting from.

The second step here is when you have this problem, so let’s say you’re automating report generation using agentic AI, and it’s going to go crawl the data warehouse, and it’s going to automate this work that analysts used to have to do at the end of the month every single month, right? So, you could get very clear about a very specific type of report that you’re doing and all the work that goes into this, et cetera, and what it’s like for the analyst to have to do that in the old fashioned way, and on and on. The point is, we can actually measure them going through that work. So that’s, like, an example, kind of very high level example here. So, after we have picked this use case, the second step here is to diagram in really low fidelity how a user currently solves for this workflow or this job to be done step by step.

This activity is sometimes called journey mapping. Sometimes that’s at a little bit higher elevation, but it can be really helpful at getting cross-functional teams aligned around their customers current state, so that a better future state can actually be imagined and then agreed upon. And by having it diagrammed out, like you know, left to right, showing all the steps and how people move, and there might be branches and things like that, which is okay, the point is, when you start to see it at a 10,000 foot view, and you’re looking down at this kind of workflow here, it really starts to get you out of this idea of screen thinking and really more into tasks and things that happen over time because experiences literally happen over time, they could involve multiple software applications and tools and online and offline things, and having it diagrammed out really gets you thinking about work happening over time. But there are starts and ends to work, and that’s part of the product game is figuring out, in particular, where does the scope of your product end. But I don’t want to get into that right now.

You can do this with, like, paper and pencil, you can do it on a Miro board, you can do it on a whiteboard. I actually really love whiteboards, and then sometimes getting those into some low fidelity Miro-style thing that you can print out a giant, giant format, like plotter format paper, and get it up on the walls. If your team is co-located, having it visible is really powerful because it helps reorient people about what we’re doing and get kind of out of this single feature kind of mindset. Your map is going to be wide, and again, it may touch the baseline solution right now. It might involve other people’s tools, not yours. Maybe you don’t even have a solution yet.

The point is to just be objective about how they’re doing it right now. It’s not supposed to be an aspirational one about how they should do the work; it should be focused on how they’re doing the work now, based in fact, based on observation, and actually talking to customers about this, but as much as possible, actual observation. So now, great. Number two, we’ve just talked about that. You’ve got this diagram, this kind of workflow design.

You can call it a journey map, if you want. If you want to go learn more about that, you can, but most importantly, your diagram is filled with facts, not assumptions. Your facts come from this exposure time, which means you are talking to customers, and you’re being mindful about the fact that they do have work to get done, and you’re just, right now, simply diagramming how they do it. You’re not judging it. You might ask questions about why they do things a certain way, but the point is, we want to get the facts into a visual format so everyone knows where we’re starting from.

Step three, identify friction points or problems in this workflow that your tech, your data product, can solve for, putting a premium on the problems that they have called out or identified as being really relevant to their situation right now. So, the big kicker on this one is this: you need to focus more on the problems they care about spending money to solve for right now, and not any problems that analytics and AI might solve within their workflow or could solve or that you think they should be doing; they shouldn’t be doing it that way. That doesn’t matter. You need to focus on what they perceive the biggest problem to be. Data and engineering leaders leading product work, in my experience, often tend to get wrapped up in what the users should be doing, often because you’re smart.

And sometimes you don’t have full context, and as an outsider, you might see something that seems really silly, and so sometimes data and engineering people get a little bit judgy about what they’re seeing. I’m sure it’s not you. I am casting some generalizations that’s not always true, but when you’re doing that, you’re not necessarily accepting what the market is telling them—is telling you, rather. So, if you are one of these smart people, then I challenge you to accept that this data—because really, the facts of the market is a form of data, and you said that you’re data-driven, and you think data is the right way to do things—well, then you have to accept this data that the market is telling you something different. It’s saying, “That’s really nice. I could be using AI to do this, but you know what? Right now, I need a dashboard that does X so that I can get Y benefit, and if I could just make that process easier, I would pay for that.”

You got to have your radar open to that, even if you think they don’t need a dashboard, they need this other thing. This is a totally hypothetical example and there might be something else that they need, or there’s a better way to do it, and all this kind of stuff, but from a business standpoint, you got to check some of your assumptions at the door. So, if you’re a data person yourself and you champion businesses making evidence-informed decisions, then you need to eat your own dog food. Their perception is their reality, and if they think that’s going to help them out, and it can help them out, maybe not as great as what your AI product could do, or whatever, you got to check that at the door because you can also think of it this way, maybe you have to give them that dashboard product right now. You need to make some money so that you can keep—and I forget who talked about this, but you can fund the mission tomorrow.

You need to capture that revenue. They want to buy a dashboard. You’re like, “No, you don’t. That’s not what you need,” but they’re saying, “Yes, it is. I need this thing so I can look good to my boss, and I can show them that we know what’s going on in this organization, and it doesn’t take me four weeks every time my boss asks me, what’s going on. I will take your automated dashboard building solution, and I will happily pay you $4000 a month to get access to that.”

Take the money and use it to fund a better tomorrow, to work on a product that would wow them, that would delight them, that might do it in a different way, but when they see it, you had the resources by meeting the market where it’s at, you had the resource to go out and build something truly aspirational that might require some change on their part. But now you’ve got some trust, you’ve got some buy in, they’re doing business with you, and you’ve had this runway. Because you have this revenue coming in. You’ve got the runway to experiment here. Okay?

So, number four, before you even get to, like, working on the second product that’s even better than the one that they’re willing to pay for right now, obviously, once we’ve mapped out the current workflow of users, and we picked this use case, and we’ve picked the—number three was identifying friction points or problems in this workflow that your tech can solve for with that premium on the problems that they have called out or identified as being really important to them, once you have that, it’s time to prototype a solution. And I like to think of solutions and activities that we commit to as bets. And this comes from thinking in bets in Annie Duke’s work. I really like this idea. You can think about the scientific method and hypothesis that needs to be validated, but the prototype is, like, a little bet, a bet that you can solve X problem and that the market or your customers will like the way that you are solving that, and they will find value in it.

So, number four is prototyping a solution, a bet to address the friction points and get feedback from users before committing fully. The goal, whenever possible, is to design with these users, with the market, not for them in isolation, and to keep your bets small. Keep them as small as possible. Why? So, that we’re increasing our feedback loops, we’re increasing our learning velocity here, and we’re learning about customers' current burning needs, and we’re not spending most of our time alone building hypothetical product that is very much unvalidated in the market.

A bet is a proposed design solution that you’ve committed to building that might theoretically solve a customer problem that’s worth paying for, but by thinking of it the solution, this prototype as a bet, a hypothesis that needs validation, you can decrease your risk, and you can build less throwaway tech, and you can create less technical debt that you have to carry forward as well. So, in some ways, the product team’s goal, while ultimately you want to build a monetizable solution here, or one that’s going to create revenue or save cost or whatever the objectives are that you set out, the vision here, part of the product team’s goal isn’t to just speed—well, it’s really not. It’s not just to speed up output creation or to guarantee dates for outputs to ship where the schedule becomes the identifier of success. That’s not actually true. It’s not just about ship something every two weeks. The goal is the speed of learning that’s happened, is happening.

So, how fast are you learning anything with these bets that you’re placing? Are you learning anything such that you are, kind of, moving ahead because you’re not over committing, you’re learning something from the market, and then you’re changing it as you go. So, this sounds difficult. Again, I would say, first of all, I don’t think it’s super hard conceptually. It might take some work activation energy to go and do this kind of stuff, but if you really want to move people from frustration to satisfaction and hopefully to delight, where they’re gladly paying money for the solution because the value is so obvious, yeah, maybe it’s going to be a little hard to get it going, but let’s see if we can make it easier.

So, where could you start? You could start by really focusing on just getting people from frustration to satisfied as they use your product to accomplish their workflows. So, what I’m saying here is you don’t have to necessarily shoot for delight because if you find a burning, urgent problem that’s expensive that someone is really frustrated with, it might be enough to just get rid of some of that pain and get them to basic satisfaction. Maybe you can cut out steps A through G, and now they go A to H, and then they got I, J, K, L, M, N, O, P, Q, R, S, T, U, V, W, X, Y, Z. They got to go through all the way through it.

And they’re not thrilled because they still got to go through a bunch of manual stuff here, but the stuff you cut out of their workflow, or you’ve removed the frustration, and you’ve gotten them to satisfaction. And part of this is understanding, what does it mean to be satisfied versus delighted, and is satisfaction something the market is willing to pay for? My point is, like, designers are always going to want to shoot for delight, and that’s partly what designers are for. Oftentimes, we are the voice in the room for the end-user, with a real heavy focus on that. This is where I always recommend hiring product designers and not user experience designers.

Most people using the product design title understand there’s a business perspective that needs to be met as well. So, little sidebar here, look for the experience first of all because titles can be misleading, but product designers are not just thinking about users; they’re thinking about business viability and also making sure the business model can work with the needs of the user, both the user experience side and what’s feasible with engineering, et cetera. So, you need to have both of these things in mind here, but maybe let go of delight. You might not need to get to delight to show some traction, and delight can become the thing that you start to focus on next.

Designing effective B2B data products is hard. I’m just—if this stuff sounds difficult, I—it’s hard to build really good, monetizable data products and ones that show real, clear fiscal value, even for teams that have lots of product design and user experience research and product management resources to inform their data and engineering teams about what needs to be built, I think it’s hard. These products are complicated, there’s not always a very transactional-type activity that always happens at the end of, particularly, decision-support tools, so it’s hard. I recommend smaller companies who are new to product and user experience design, again, shoot for your product to move people from frustration to satisfaction, and then test out whether or not the market would pay for something that’s doing that. Can you remove enough frustration and create enough value there that that would be something they’re willing to pay for, even if it’s not a full end-to-end solution, and it doesn’t reflect all the things that you could technically do.

Delight? Well, let’s let delight be your aspirational goal. I’d rather see you get going and get from that frustration to satisfaction thing. Don’t underestimate people being willing to pay for something that delights them, and possibly pay a lot more for something like that, but to get started, if you’ve got designer’s block, if that’s a thing, that’s where I would get started, particularly if you’re early stage or you’re trying to get more deals closed or you’ve got a you’re redesigning a product and the usage of it has gone really dormant, as you know, competing tools or homemade solutions, or, frankly, the users just can’t understand what the value of your analytics or this AI solution is, those are the time to really start to focus on just make changes that move people from frustration to basic satisfaction. There’s a transformation there, and that’s your goal with all of your product bets that you place, is to move people from frustration to satisfaction. Not ship the features, but for the features to enable that transformation.

When we can show buyers and a sales call or a demo how our product clearly moves them, or you know, the staff that, if you’re talking to the fiscal buyer, but not the end-user, when we can clearly show how the product is going to move them along that frustration to delight thing, we can accelerate the deal because the value is easier to see now and realize. And hopefully you can get out of a product conversation, and you can get into a pricing one, and a commitment one, and all those good things. So, that’s kind of what I have to say on the user experience outcomes thing. I’m glad I finally got around to defining this.

I mentioned that we were going to go into disrupting the market with AI and how to think about all this. I think I’m going to save that for a part three here, just in the interest of time, but just to give you a little sample of this, right, while some markets may be ready for larger change than others, you may have to accept that users aren’t ready to stop using the river they’re currently on as their means of travel from A to B because there’s no incentive to do so right now. Changing their method, you know, using your new AI powered tool to say, fly from A to B instead of swimming or rafting, if you go back to our episode 182 analogy about the river, changing their method might even impose risk on the end-user, risk that comes with no clear benefit to them. Even if the buyer sees it, the end-user, who might not be the buyer, again, particularly in an enterprise context, if that end-user doesn’t see what the benefit is in it is for them and how it either improves their status or makes their life easier or makes them more money, or whatever their incentives are, if you’re not aware of what those incentives are, then your solution, no matter how technically right it is, it can be effectively wrong because it’s adding risk to them. So, by solving the rafting problem, as I talked about in the last episode, and understanding your end-users needs, their incentives and their challenges, you might just gain the revenue and street cred that you need to stay in the game, develop those customer relationships, and figure out how to get your users to take the big leap and accept that, no actually, it’s time to fly.

It’s time to get out of the river. It’s time to look at AI. It’s going to get you from A to B in a better way, and a faster way, and that pill will be easier to swallow when you’ve shown some street cred, that your product has shown that you can remove frustrations that they care about right now. It’s easier to get them to start changing their work and changing their behavior and to nudge them along because product design never ends. So, over time, you might start to change how they do that work in a very gentle way, but you’re providing value along the way the entire time.

But to summarize this little first part of the AI thing before I call it a wraps for episode two—or part two of this three-part episode, you have to accept that some users aren’t ready to stop how they’re doing things today. They want to change what they want to change. They want to address the problems that they care about right now, not necessarily what large language models and AI or whatever your analytics tech is, not necessarily what’s possible, but what they feel are the things that are blocking them from whatever it is that they want to get. You got to be really open to that because otherwise, you can sink a lot of money into just coming up with a new way to do something that’s theoretically better, but it’s completely devoid of understanding, what is the current resistance in the company or in the organization? What are the dynamics? What are the incentives? Are all those things aligned?

Is your product eliminating the need for an entire department? Like, maybe the fiscal buyer thinks that’s a really great idea or they want to go there at some point, but maybe the people on the ground don’t want to use that because they see that connection there, and they don’t have an objective to do that, to have their department downsized. Or maybe the team that they work with, they work with the procurement team and they work with the sales team or whatever, and they don’t want to see that either. This is why I don’t think the goal is to necessarily just try to disrupt the market with AI. We don’t want to disrupt. We actually want to do the opposite of disrupting the market.

It doesn’t mean there are not new and better ways to do things. It just means you need to be dialed into what people are willing to pay for right now and to understand incentives and the change that people are willing to make because it may not be quite the change that’s actually technically possible right now. I’m going to leave this there for now. The next part three of this episode, I’m going to talk a little bit about what happens when you do have an AI-powered product and it solves one thing, but it immediately creates a new customer problem, or you’ve accelerated the second problem that the customer is used to having, but all of a sudden, problem two is now the thing that they’re dealing with all the time because problem one used to take 70% of the time of that person’s job, and all of a sudden it no longer does, so their work has changed. Or maybe it’s created new problems that never existed before until you had the scale, or the possible impact of what AI can do at a scale that it’s just not been there before. So, what do you do in that situation? That’s what we’ll talk about in part three.

I hope this episode was really useful to you. If you need help designing your product around the flow of your users’ work and you feel like your traction is slow, if you’re not sure if maybe you have a product problem or a product-market fit problem, or maybe, like, it’s not the product, it’s the messaging and how we talk about it, particularly with, obviously, with B2B analytics and AI products, stop guessing. This is something I can help you with, and my 90-Minute “Design Eyes” Strategy Assessment, I’ll diagnose this. I will give you an answer.

Do you have a design problem? Do you have a product management problem or a product strategy problem, or is it a messaging and positioning issue? What is the problem that’s blocking you from getting that sales acceleration or that adoption acceleration that you’re looking for, such that you can now deploy the right resources in the right way to address those issues? If you’re interested in that, just head over to designingforanalytics.com/assessment and you’ll see how it works. You can book it right online. It’s easy to buy and it’s fully guaranteed as well. It’s called my 90-Minute “Design Eyes” Strategy Assessment. Check it out.

And again, I want to say thanks to Jared Spool again for his framework here about thinking about user experience outcomes. Super helpful work there. And we have an interview with him actually way back, and I’ll probably have on the show again in the future. But until next time, thanks for listening to Experiencing Data.