Building B2B analytics and AI tools that people will actually pay for and use is hard. The reality is, your product won’t deliver ROI if no one’s using it. That’s why first principles thinking says you have to solve the usage problem first.

In this episode, I’ll explain why the key to user adoption is designing with the flow of work—building your solution around the natural workflows of your users to minimize the behavior changes you’re asking them to make. When users clearly see the value in your product, it becomes easier to sell and removes many product-related blockers along the way.

We’ll explore how product design impacts sales, the difference between buyers and users in enterprise contexts, and why challenging the “data/AI-first” mindset is essential. I’ll also share practical ways to align features with user needs, reduce friction, and drive long-term adoption and impact.

If you’re ready to move beyond the dashboard and start building products that truly fit the way people work, this episode is for you.

Highlights / Skip to

• The core argument: why solving for user adoption first helps demonstrate ROI and facilitate sales in B2B analytics and AI products  (1:34)
• How showing the value to actual end users—not just buyers—makes it easier to sell your product (2:33)
• Why designing for outcomes instead of outputs (dashboards, etc) leads to better adoption and long-term product value (8:16)
• How to “see” beyond users’ surface-level feature requests and solutions so you can solve for the actual, unspoken need—leading to an indispensable product (10:23)
• Reframing feature requests as design-actionable problems (12:07) 
• Solving for unspoken needs vs. customer-requested features and functions (15:51)
• Why “disruption” is the wrong approach for product development (21:19)

Links

Wondering if your sales problems or low user adoption might be due to your product's UI design or user experience—but you're not sure?  Stop guessing.

In a 90-minute product strategy session, I'll diagnose whether you're facing a design problem, a product management gap, a positioning issue—or something else entirely.

Schedule a Design-Eyes Assessment with me and get clarity, now.

Quotes from Today’s Episode

“Customers’ tolerance for poorly designed B2B software has decreased significantly over the last decade. People now expect enterprise tools to function as smoothly and intuitively as the consumer apps they use every day. 

Clunky software that slows down workflows is no longer acceptable, regardless of the data it provides. If your product frustrates users or requires extra effort to achieve results, adoption will suffer.

Even the most powerful AI or analytics engine cannot compensate for a confusing or poorly structured interface. Enterprises now demand experiences that are seamless, efficient, and aligned with real workflows. 

This shift means that product design is no longer a secondary consideration; it is critical to commercial success.  Founders and product leaders must prioritize usability, clarity, and delight in every interaction. Software that is difficult to use increases the risk of churn, lengthens sales cycles, and diminishes perceived value. Products must anticipate user needs and deliver solutions that integrate naturally into existing workflows. 

The companies that succeed are the ones that treat user experience as a strategic differentiator. Ignoring this trend creates friction, frustration, and missed opportunities for adoption and revenue growth. Design quality is now inseparable from product value and market competitiveness.  The message is clear: if you want your product to be adopted, retain customers, and win in the market, UX must be central to your strategy.”

—

“No user really wants to ‘check a dashboard’ or use a feature for its own sake. Dashboards, charts, and tables are outputs, not solutions. What users care about is completing their tasks, solving their problems, and achieving meaningful results. 

Designing around workflows rather than features ensures your product is indispensable. A workflow-first approach maps your solution to the actual tasks users perform in the real world. 

When we understand the jobs users need to accomplish, we can build products that deliver real value and remove friction. Focusing solely on features or data can create bloated products that users ignore or struggle to use. 

Outputs are meaningless if they do not fit into the context of a user’s work. The key is to translate user needs into actionable workflows and design every element to support those flows. 

This approach reduces cognitive load, improves adoption, and ensures the product's ROI is realized. It also allows you to anticipate challenges and design solutions that make workflows smoother, faster, and more efficient. 

By centering design on actual tasks rather than arbitrary metrics, your product becomes a tool users can’t imagine living without. Workflow-focused design directly ties to measurable outcomes for both end users and buyers. It shifts the conversation from features to value, making adoption, satisfaction, and revenue more predictable.”

—

“Just because a product is built with AI or powerful data capabilities doesn’t mean anyone will adopt it. Long-term value comes from designing solutions that users cannot live without. It’s about creating experiences that take people from frustration to satisfaction to delight. 

Products must fit into users’ natural workflows and improve their performance, efficiency, and outcomes. Buyers' perceived ROI is closely tied to meaningful adoption by end users. If users struggle, churn rises, and financial impact is diminished, regardless of technical sophistication. 

Designing for delight ensures that the product becomes a positive force in the user’s daily work. It strengthens engagement, reduces friction, and builds customer loyalty. 

High-quality UX allows the product to demonstrate value automatically, without constant explanations or hand-holding. Delightful experiences encourage advocacy, referrals, and easier future sales. 

The real power of design lies in aligning technical capabilities with human behavior and workflow. 

When done correctly, this approach transforms a tool into an indispensable part of the user’s job and a demonstrable asset for the business. 

Focusing on usability, satisfaction, and delight creates long-term adoption and retention, which is the ultimate measure of product success.”

—

“Your product should enter the user’s work stream like a raft on a river, moving in the same direction as their workflow. Users should not have to fight the current or stop their flow to use your tool. 

Introducing friction or requiring users to change their behavior increases risk, even if the product delivers ROI. The more naturally your product aligns with existing workflows, the easier it is to adopt and the more likely it is to be retained. 

Products that feel intuitive and effortless become indispensable, reducing conversations about usability during demos. By matching the flow of work, your solution improves satisfaction, accelerates adoption, and enhances perceived value. 

Disrupting workflows without careful observation can create new problems, frustrate users, and slow down sales. The goal is to move users from frustration to satisfaction to delight, all while achieving the intended outcomes. 

Designing with the flow of work ensures that every feature, interface element, and interaction fits seamlessly into the tasks users already perform. It allows users to focus on value instead of figuring out how to use the product. 

This alignment is key to unlocking adoption, retaining customers, and building long-term loyalty. 

Products that resist the natural workflow may demonstrate ROI on paper but fail in practice due to friction and low engagement. 

Success requires designing a product that supports the user’s journey downstream without interruption or extra effort. 

When you achieve this, adoption becomes easier, sales conversations smoother, and long-term retention higher.”

Transcript

Brian: Welcome back to Experiencing Data. This is Brian T. O’Neill. Today, “Designing with the flow of work, accelerating sales in B2B analytics and AI products.” So, who’s it for? Well, today is really going to be focused on founders and product leaders building commercial B2B analytics and AI products who need clear, measurable adoption, faster sales cycles, and lower churn. So, this is really for people selling data products, software companies, vendor tools, things of this nature. I think you can still learn something if you’re doing internal work, but this is really going to be targeted towards the tools that some of you all use, as well as the tools that some of you all are creating.

And overall, like, what this is going to cover is a practical user workflow-first method to make your product indispensable to end-users, so that the fiscal ROI pitch when you’re trying to show the value of your product becomes super obvious. So, why does user experience first even matter in B2B software and data products? So, you know, the assumption is often that the right data is your key to winning, you know, sales and showing value, particularly now in this age of AI, and everybody’s trying to use AI to solve everything, it seems. Just get enough of the right data, get the right quality, get the right to use it, make sure you have all the SLAs in place and the privacy matters, and on and on and on, and this will unlock financial success because you will have found this niche. I’d like to make the argument for you that solutions need to be focused on solving the pains of both end-users and buyers because the buyers may only see their desired ROI on your product when there is meaningful adoption occurring first.

You likely know that buyers, who sometimes are not the end-users of B2B products, often need evidence of future financial ROI before they’re going to buy your solution. On the other hand, end-users of these solutions are actually asking themselves, “How does this make my job easier or make me look better to my boss or help me achieve my performance objectives so I can get my bonus or my raise or whatever it may be?” Frequently, end-users have different goals and needs than the buyers do, and this is where things can get tricky in the B2B context, especially when there’s a larger sale in place, possibly software that runs on-premise or that you need to connect up to internal systems and it’s not just a single user license, go download, you know, the app, try it out, get a credit card, and you’re off to the races. If you accept that both users and business needs need to be met in order to create a product that sells and gets used, hopefully, this whole podcast will explain more in depth how to design your data product user experience around the tasks and workflows of your end-users such that you can accelerate your sales and retain customers for the long-term. By the way, I will also mention that I have been dealing with this cough and cold for some time, so I apologize for any funky sounds coming out of me or coughs and things of that nature. But let’s continue.

One of the big arguments here, your product’s perceived value therefore—to buyers—is dependent on meaningful user adoption of the solution. Anecdotally, I can tell you from talking to many founders and heads of product that customers’ tolerance for poorly-designed software in the B2B and enterprise space has changed greatly, I’d say, over the last ten years or so. Frankly, buyers and users, they want things to work really smoothly and easily, just like the apps that they use on their phone daily. It’s just changed. It used to be such that people kind of almost expected B2B products to be kind of clunky and all this kind of thing because they usually have grown into behemoths over, you know, decades, potentially, and that tolerance has just gotten lower, and generally, there’s a lot of different options in the market.

So, the tolerance for poor quality is low. If your ROI, or your buyer’s ROI is tied to end-users actually using the solution that they’re paying for, then you really have to solve for this first hump, which is getting meaningful user adoption by making the product indispensable. So, if you solve for this, it should enable an easier sales process. So, if you’re having trouble on the sales side in the conversations and closing deals and this kind of thing, this can help. Why? When there’s usage, there are more chances for case studies and wins that you can cite on the business side, both in your marketing and potentially in a sales conversation.

You can anticipate what the buyers end-users, who, again, are often subordinate staff members, what their complaints, concerns, and their workloads are like, which gives the true impression that you’re not coming up with a quote, “Disruptive solution,” which sounds really good, but rather one that’s actually aligned with the reality of the pains and use cases and situations that this buyer’s staff, or whoever their beneficiaries of this solution are going to be, it’s really aligned with their reality. And thirdly, you’re going to reduce and eliminate distracting conversations about your interface or your user experience during demos, which do sometimes come up, from what I’ve heard on my conversations, because buyers won’t be having to connect the dots mentally between what your solution does according to your demo and how it’s actually supposed to fit into their work. And when they’re looking at your demo or listening to it, they’re trying to imagine themselves in that situation, and we don’t want them having to try to do too much work to connect how you’ve mapped things out the what we sometimes call a mental model; we want the products model to match the user’s mental model of how things should work. And over time, as you improve the design, you should be improving this, your ability to map this, your product, onto the buyer’s mental model of how things should work. And when you’ve done that, then users can really focus on what the value of the solution is and they’re not going to be talking about the design or making offhanded comments about it or looking at it kind of with a confused face as they try to understand, why would I want that? Why would I do that? Why does it work that way? We don’t want them thinking about that during a sales call.

So, just because you can build something with data and AI doesn’t mean somebody wants to pay for it, or that end-users will change their behavior sufficiently to use your solution the way you intended. Long-term value is tied to making solutions that users can’t live without, and experiences that move people along a path from frustration to satisfaction to delight. I’m going to go more into those three things in a little bit. So, next idea: designing for outputs versus outcomes, moving away from dashboard and data-focused thinking. When clients ask me if their design is good or how it can be improved.

I usually qualify this question by asking them, “Well, what are the most important and frequent use cases that it was designed to solve for?” However, what often happens when I ask clients to provide me with workflows and user scenarios, I will often get very high-level statements that we really can’t use to test whether or not our design is improving the lives of customers or not. So, as an example, I might hear, “As a user, I want to check the dashboard for any insights each day.” The reality is that no user really wants to go check a dashboard. That’s really not a use case.

The dashboard is a feature or output, a piece of technology that theoretically will help them solve a need that they have, a need that is part of a larger job that needs to be done, and a job can be thought of as a series of tasks that have to happen, not always in the same order, that collectively form a workflow. So, viewing the dashboard might be a task within a larger workflow, but it is neither the job itself nor the problem. If the game was this simple, then all your team would need to do is generate some dashboard and you could declare victory. But of course, it’s not that simple. The dashboard has to be of some defined quality—and I don’t mean QA quality and code quality; that’s all important too—but there has to be a definition of what quality means to the end-user, and it needs to intuitively fit into the user’s overarching workflow.

So, this gets to the statement that I’ve said on the show before, which is that requirements and feature requests are often friendly lies. Let’s give an example of what I mean by that. “Hey, you know, if you only—if you guys had—if you had this chart filterable by zip code, it would just be so much more useful, and I’d totally be on board,” said the important prospect to you during that sales conversation. Well, sometimes, yes, if you just add a zip code filter to your chart or your table or whatever, then you might unlock a sale or a win. Sometimes.

More often, you may realize that giving everyone the feature or data point that they want just creates product bloat, increasing your product’s complexity. Death by a thousand cuts over time. Long-term, in addition to carrying technical debt and features that few may use because only a couple squeaky wheels requested those things, you can end up creating what one old client of mine referred to as a ‘metrics toilet,’ every piece of data possible, the user just has to put it all together to get some kind of insight. It sounds fancy, but it’s not.

The user is not paying for the data. They’re paying to have their problems go away and to get the benefits that you promise them, so I often say requirements are friendly lies, particularly if the voiced requirement has a solution embedded inside of it. The intention is good. No one’s trying to lie, but they are misleading statements. So, what do you do? You need to reframe all feature requests into a hypothesis that has to be validated first.

So, when you get a feature request that isn’t minor or you're collecting all this feedback, work it back into a problem that they have so that you can understand how it fits into their workflow. It’s much easier to design high-value products around workflows when we understand the problem space and the context that the solution or the feature will be used in. So, let’s use a supply-chain analytics—I made this up based on a recent episode that we had done on the show. It’s totally fictitious. I don’t even know if this exists in the real world, but it’s enough to have a conversation with you about it.

So, supply-chains analytics example. Let’s imagine your supply-chain analytics product, it’s a software application, it’s meant to help cold chain product distributors avoid shipment loss due to spoilage. And you use routing insights and analytics to improve delivery instructions for truck drivers. So, cold chain being, like, imagine, you know, moving sensitive products like medicines or food, things that need to be kept at a certain temperature and can only be out on the road for a certain amount of time, et cetera, et cetera. And let’s also imagine that this product is used by both dispatchers and truck drivers at, say, a pharma company or a pharma distributor of some kind.

So, a sales prospect has asked you to add this zip code feature to your UI in your charts. And it sounds straight enough to send it to engineering and get it into the product so that sales can sell it. However, if you’ve done this before, you might also know that in a month or so, they may come back asking for more, and you might find out zip code wasn’t really enough. You know that this request needs to be turned back into a problem that the team can properly solve. This happens through direct observation and conversations with the requester and ideally the actual users who would be interacting, in this case, with this zip code feature in the UI.

And if we do that work, we might arrive at a much more realistic scenario. We might find out the actual use case, discovered through interviews and observation with users in the wild, through our ongoing product research, we might find out that the use case is much more like this: as a truck driver in New York City or a busy city, I sometimes need to reroute my cargo to a temporary cold storage facility nearest to my location that meets a hundred percent of my tier one cargo’s storage requirements so I don’t get fired for letting these drugs go bad, costing the company a lot of money, or losing my delivery bonus, because I get a little bonus when I when my truck shows up on time or early. The customer—we can just pretend for a moment—has currently made a homemade solution to do this work. Let’s say they’ve made a custom little app for themselves, which is a directory of all cold storage locations searchable by zip code.

And all the drivers have access to this, but it doesn’t have your product's real-time facility information in it, such as capacity, working hours, cold storage methods, temperature control, all these things that need to be matched up to the cargo’s spec, whatever’s on the truck. So, the prospect has asked you to put in zip code because this is how the drivers do it today. And remember, of course they’re adding that nice, enticing sentence, “If you just had this, we’d buy your product.” So, focus on the benefits of solving the underlying problem versus responding to the surface request. By focusing on the underlying and previously hidden need, which is finding a suitable nearby storage facility that meets their cold chain requirements, we might find out that a zip code filter doesn’t even need to be added because the product can use the truck’s real-time transponder location and recommend storage locations in real time that have all the criteria of what’s on the truck factored in with a single button tap. So, there’s no need to necessarily look up anything by zip code and type them into the product while driving.

So, we’ve actually removed some manual steps that need to happen, and we’re still solving for what the actual underlying need was. Over time, as we keep aligning data and feature needs back into the user’s flow of work, your product’s user experience evolves from satisfying to delighting. And when we delight, we’re better positioned for long-term lock in with current customers, easier future sales that don’t have conversations about your UI and your UX at all, which is a good thing, and the potential marketing benefits of word to mouth or that call that you love to get, which is, “Hey John, hey Mary, I recently changed companies, and I want to bring your product in over here now. Can we get on a call to talk about that?” Those are the really easy sales.

The last part of this larger episode—this is going to be a two-part episode—is I want to leave you with this river analogy. The river analogy goes like this: I want you to imagine rivers are like these user workflows. The user themself is like a swimmer on the river, and this river is always flowing in one direction, and your product is a raft. I’d like you to think of a river flowing from upstream to downstream. This river is a job to be done, and the user is a swimmer whose job is to get from point A to point B.

And when they get to point B on the stream, the job is done, and they feel successful. And you could sort of think of, like, the entire length of the river as, like, this person’s entire career, or the entire scope of their role at their company. But we’re getting from point A to B. This is a specific job to be done, if you want to call it that, or a workflow. Now, from A to B, there are rocks in the stream, and these rocks are obstacles to getting their tasks done.

And again, this river only flows in one direction so they got to get through that stuff. Your product should really enter the user’s workstream, like, a raft from the shore. They have that choice to swim alone, or they can get on your raft. And the raft is a new way to get this job done, perhaps with less bumps and getting your feet caught up on rocks and getting scratched up on the way from point A to point B. So, in theory, it makes it more pleasurable and easier to get from point A to point B.

And most importantly, the raft is moving downstream with the flow of the river. The job that needs to be done, it’s moving in the same direction. Why am I saying this? Because your product should not require the user to change directions to try to get on the raft, but now you have to go upstream against the natural flow that they’re accustomed to doing, then maybe take a stop at the shore, and then go downstream a little bit, and then back upstream, and then get out, and then walk down the footpath next to the stream, and then get back in the raft and on and on and on. Your product, the raft, has the best chance of selling it when it delivers a user experience outcome that is at least as good or better than the customer’s status quo.

So, you really want to start with improving the natural flow of the customer’s work before you try to disrupt it and change it. I’m going to say that last thing again: you want to fit your product into the natural workflow of the user before you try to disrupt it and change it because the current is already moving in a specific direction, and the more you’re asking people to change their behavior to get them to use your solution, the more friction you’re actually introducing, the more risk you’re introducing. Even if there is demonstrable ROI for your solution, you have to also think about what kind of change am I asking them to make? What is the risk to both the buyer but also the end-users in doing work a different way using your solution? Are you introducing risk?

These are all factors. It’s not just that data and AI can theoretically solve some problems; they have to care about those problems and also balance what the switching cost is. When we start the rest of this episode, I’m going to talk more about what user experience outcomes are. I love the Jared Spool model of this. If you want to go get a sneak peek, I’m going to be talking about that in the next episode.

I’m also going to talk about those of you out there who are trying to disrupt the market with AI-based solutions. This is very common in the analytics space as well, so I want to talk a little bit about what happens when we introduce AI and it really changes the model of work in a significant way. We can create new problems when we start using AI at a scale that’s not been used before, like, the customer’s work is being impacted in a significant way. I want to talk to you about how to think about that with your product such that you’re not just disrupting for the sake of disrupting, but we’re actually really focused on creating positive outcomes for users.

For now, I’m going to leave it here, and we’ll catch you on part two of this episode about designing with the flow of work so you can accelerate sales in your commercial data product. Until next time, see you soon.