If you haven't already listened to it, check out Part 1 (Episode 187) first.

I’m continuing my exploration of a hard truth many leaders of analytics software companies run into: deals don’t stall because the tech is weak. Instead, they stall because prospects can’t see the value soon enough or the risk of changing the status quo is too high. This is often a product problem, not a sales one, and obtaining Flow-of-Work Alignment (FOWA) may help you start closing more evals and deals. So what is FOWA? The idea is simple, but demanding: stop showcasing features and start designing experiences that fit into how customers already do their work, create value, and add delight when your product is added into the loop.

Getting to FOWA means tailoring demos with realistic, industry-specific data, reducing mental translation, and minimizing behavior change. In this scenario, improvements become small, testable bets tied to outcomes, not feature checklists. UX and usability are not cosmetic; they should shape trust, adoption, and buyability.

When prospects can clearly see themselves succeeding with your product, value feels obvious, evals progress, and deals close.

FOWA solves the workflow side of a larger product problem:

If users like the idea of your product but still fall back to spreadsheets, old habits, or manual workarounds, you may be dealing with the Invisible Intelligence Gap. In many cases, the issue is not that the intelligence is wrong. It is that the product does not align well enough with how work actually gets done. I break down that broader problem in The Invisible Intelligence Gap. This article focuses specifically on the workflow alignment portion.

Highlights / Skip to:

• Steps to implementing Flow-of-Work Alignment (FOWA):

1. 1. Tailor your demo or POC to map to the prospects' world and their workflow (1:53)
   2. Treat product improvements as bets that have to be tested so that observable outcomes are what you’re holding your product team accountable for (3:57)
   3. Reducing perceived behavior change (6:39)
   4. Realize that your product’s visual design are likely impacting your product’s clarity and its desirability (12:29)
   5. Aligning your sales and product teams around customer outcomes and not feature gaps (18:03)

• Why you might think FOWA won’t work for your product—and how to reframe those objections (24:22)

Transcript:

Brian: Welcome back to Experiencing Data. This is Brian T. O’Neill. Today we’re looking at part two. Obviously, that means, if you didn’t—if this is the first time you’re listening to this show, I recommend you go back one episode, to the episode titled “Can’t Close the Sale? The Invisible Reasons Prospects Aren’t Buying Your Technically Superior Analytics or AI Product.”

In that episode, I talked a bit about why I think there are challenges in the sales process that might actually be product problems and not necessarily sales problems, and I introduced a concept called Flow Of Work Alignment, or FOWA, F-O-W-A. So, I kind of wanted to continue where we left off and actually give you something actionable that you can go do in your product development to hopefully accelerate some of those deals that might be feeling stalled or possibly rescue some deals that unfortunately went into the closed/lost folder in the past. So, let’s jump in. Again, check out the prior episode first, and then maybe jump back here. Let’s get into FOWA, Flow Of Work Alignment. So, here are five actionable changes that you can make to get Flow Of Work Alignment in the product.

So, the first one is tailoring your demo or POC to map to the prospects' world and their workflow. This means not relying on canned walkthroughs where everyone, for example, is seeing the same data, it’s a hard-coded prototype, or, you know, hard-coded PowerPoint presentation with the same data every time. At a high level, this means that you’ve done the work to also design a user experience that maps to the steps that they’re already doing in their natural work without your product. On a low level, this means things like, again, pre-loading their data into your demos or to the prototype solution you’re going to show them, or however you do your demos and POCs. You don’t want, you know, ‘Alpha Corp’ to be in the demo; you want to basically remove as many possible pieces of noise from the experience or the customer having to translate.

You know, let’s say you’re showing analytics about revenue or something like this, and they’re a $2 million company, and all of your numbers are in the billions of dollars, that customer is doing mental translation to try to see themselves in your solution. So, we want to remove as much of that translation as we can so that they’re really focused on seeing themselves in an improved situation with your product. So, we’re really—with this one when we talk about tailoring the demo or this early experience that they’re going to have learning about your product, removing cognitive burden—as we call it in the UX world, which is, again, all that mental translation that they’re doing—and removing objections overall. Because effectively, you are doing that when you remove some of this translation risk that’s in there and they can better see themselves or their business reflected with your solution in play. So, that’s number one, tailoring the demo to map to the prospect’s world and to their workflow.

The second one is to treat product improvements as bets that have to be tested so that outcomes—which means changes in the world that can be observed—are what you’re holding your product team accountable to. So, this means you can answer, if we ship this thing, this feature, by what date should we expect to see X metric improve? Again, I’m going to say that again. If we were to ship this thing, this bet, into the market, which is probably a feature or something like this, by what date should we expect to see some metric improve? That metric doesn’t necessarily mean more sales occurred and you can isolate that variable as being causal.

The feedback might simply be that you are getting no more comments about some confusing aspect of the product on the sales call. Like, that whole comment stream just went away. So, metrics here doesn’t necessarily mean analytics in the product. It doesn’t mean everything has to be directly causal or perfectly attributed. We’re not doing science here; what we’re looking for are signals that are our product improvement bets are actually paying off.

So, this means you’re effectively moving from a sprint and output-focused product development approach to a benefits and outcomes-driven one, and I’m sure this will largely rhyme. If you’ve listened to this show in the past, you know that I’m a big fan of having the outcomes over outputs as the driving force behind the product work that we do. This also helps you move faster because if your product team now has accountability for outcomes, they’re likely to place smaller bets and test them sooner and respond to that feedback.

So, this is also a method of empowering the team to be responsible for the value and to be able to justify why are we adding this feature? Why is—were this new view of the dashboard that we never had before? Or the model will now know how to—it’ll, you know, provide a unique UI rendering based on any queries that have to do with healthcare protocols, treatment protocols, or whatever it may be. There should be ways to go out and validate that this work is moving key things forward for your business as well as your customers. So, wrapping that one up. Number two, treating product improvements as bets that have to be tested so that outcomes—which means changes in the world that we can see—are what you hold your product team accountable to.

Number three, reducing perceived behavior change. This is a big one that I think is really misunderstood, particularly with AI tools, where really smart entrepreneurs and founders can see how leveraging AI, and particularly the language model capabilities that are out there now, we can make really rapid changes, we can make rapid improvements, we can automate work at a scale that we haven’t been able to do before. The issue with this is the risk that comes with that and the amount of behavior change that we are asking customers to make. And the question for them is, is the required behavior change investment going to be worth it for me? And that gets into, well, how easily can they see the value of your solution?

So, by showing integrations with existing tooling, using familiar design patterns and conventions, and overall reducing the amount of change you’re asking the user or buyer to make, this is collectively, this effort is going to reduce some of the risk of customers moving forward with a purchase of your solution. All of this requires that you know a lot about your customer, which also means investing in routine customer research or customer exposure time, with an emphasis on observation over conversation. So, this is a broad topic, like, how to do customer research that’s actually to give you signals that are useful, but some of the core ideas here are, your product team is learning by watching how your prospects are currently solving the problem without your solution and without judgment of how they are currently doing it.

Another one is allowing your prospect, not your AI and analytics capabilities and your solution, but allowing the prospect to own the problem and decide what pains or problems matter to them. Owning the problem means—or I should say, the customer, owning the problem means that you have to empathetically put aside what’s technically possible and instead focus on providing a benefit or an outcome or, in this case, a relief to the pain of the problem that they believe that they have. So, to put this another way, if they feel like they’re having a big pain with something that you might feel is trivial or maybe it’s not the underlying cause of their problem, we don’t discount that. Instead, we look at it, like, from their perspective, this thing hurts. I am having a problem with this thing. That is a real thing.

We’re not here to judge whether that’s ultimately—it’s kind of like I want to lose weight, but I don’t want to change my diet. And this person is looking for a rapid solution to that problem, even if it’s a short-term problem. You can keep telling them that they need to change their diet and exercise, which maybe some people will do, but that’s a long-term investment. Sometimes the buyer is looking for a shorter-term solution with faster time-to-value because they can’t take the risk of that long-term thing not working out. So, I’m not saying that we should always deliver a short-sighted solution that’s going to leave them hanging later.

The spirit of this is that their ownership of the problem is real, and we go along with them owning that problem and how severe it feels to them, we accept that as ground truth, and we position our solution against that so that we are addressing something they perceive to be true and not something that you think that they should care about. And that’s the key difference with this one. Another idea here with the research part here to again, we’re talking about reducing perceived behavior change requirements by using your product, once the problem space has been well defined, with intention, you design the user experience of the product to map to their flow of work, such that you can move them on that scale from frustration to at least satisfaction at a minimum, and ideally over to the delight category. And to pass guest Jared Spool for this model of explaining what user experience outcomes—and again, I’m going to say it again, ultimately, what we’re doing and the way to measure if the user experience is getting better is to figure out what is their experience now, and how is that experience on a scale from frustration to satisfaction to delight. And if it’s in the frustration category, we want to move it minimally to satisfaction and ultimately to delight.

And as a general rule, for teams that don’t have strong product design skills, I’m usually focused on getting them simply to the satisfaction level because getting to the delight level typically requires a larger investment in user research to really understand the customer at a deep level so that you can anticipate what their needs may be. This is different than addressing the surface needs that are quite obvious, but as a starting point, really focus on getting to that first tier of satisfaction, but understand that delight is ultimately what creates sticky products that people refer and that people talk about. And I’m sure all of you love that when you get that natural, referral-based marketing and people talking about the product in a positive light. And when all that’s done, you have a demo or a POC that feels intuitive and empathetic because you’ve reduced the perceived behavior change required on behalf of the user.

The fourth one here, realize that your product’s visual design. It’s interaction paradigms, like, you click here and this thing opens and then it returns this data, and all we call interaction design and its overall usability, which is its perceived simplicity and utility, these are likely impacting your product’s clarity and its desirability. I’m going to say that again. Your visual design, the interaction paradigms that are involved and the usability overall of the product is likely impacting your product’s clarity, desirability, and on the whole, it’s potentially impacting the sale. It could be doing it in a positive way for doing a great job.

If you’re not doing a great job, it might be actually working against you, even though you might see some of that as fairly cosmetic or minor front-end changes or whatever. And so, you might not have a designer, but all products are always broadcasting a design and a user experience. There are no null choices here. So, what you want to move to, if you don’t have skilled product design resources, is to understand first that there is a design and there is a user experience, whether you’ve put intention behind it or not, and move to designing that experience with intention so that it is not a byproduct of engineering or data science choices, as is the case sometimes with AI-based solutions.

So, that’s kind of the big idea here. Whether you leverage a true data product designer or have that team and resources in-house or not, the creator of the product or this feature or this area of the product—your product—should be able to explain why is the UX the way it is, why was it designed that way, and it should be backed up with some research at least some of the time, instead of just guessing all the time. This should be backed up by that customer research and exposure time that creator had. So, we don’t want UX just emerging always as a byproduct of technical work. This method usually results in whatever the default was, or it results in the developers’ testing or evaluation tool that actually starts to become a real UI that gets exposed to the customer, or it’s whatever was really fast to build, regardless of efficacy, or it’s they typed in a prompt and asked for a front-end to be delivered, and what you got was the average front-end of all the other people who have been asking that because you all know how the training data works.

And sometimes average might be enough to get started. The question is, with this UI that you asked for, do you know what the resulting user experience is? And I would say, if you’re not trained in this space, you cannot look at the UI and know what the experience is going to be. The user interface is not the experience. All of this leads to—if not done well—leads to adoption risk, and adoption risk is a form of ROI risk.

And low adoption frequently stems from poor usability, low perceived trust. This is a big area where visual design starts to matter. Obviously with AI-based solutions, trust, accuracy, data privacy, these are all factors that go into perceived trust. Too much effort to turn analytical evidence into actionable insights, this also can create adoption risk and awkward interactions in your product, so where you’re pushing a lot of tool time on users. So, an example, this would be, if you’ve ever copy and pasted code samples from ChatGPT or Claude’s web-based interface into your IDE and then you recompile or rerun the script and it fails, and you’re going back and forth, back and forth between these two windows, that would be a form of awkward interactions and tool time that you’re pushing on users.

So, even if you have an API product, remember your product does have a user experience, and it has a brand, even if it’s for technical buyers, and it has a feel. You just have to design all this with intention, instead of as a byproduct of technical work. The reward here is that customers can better see themselves in your product, the product starts to sell itself, the product feels indispensable, and everyone wins, both you and the customer and their business, since most of the time we’re talking about B2B here. So, that’s—collectively I know that was a lot, but I really want you to remember that all products have a user experience, whether they’re technical products or non-technical visual design, interaction paradigms, and usability all can negatively or positively impact your product’s clarity, its desirability, and its buyability. So, the question is, do you know how it is currently impacting those desired metrics that you care about? Waiting just for customers to talk about it is not the only way to figure this out, and customers are not necessarily voicing everything that’s causing them to perceive risk.

Cool. The last one, number five here is aligning—this is another internally oriented one for your team, but this is about aligning your sales and product teams around customer outcomes and not feature gaps. I could probably do a whole episode just on this one thing, but I want to give you some kind of tactical-level advice about bringing these teams together, you know, if you’re large enough that you actually have separate teams for this. But involving salespeople in your customer research process. This builds empathy for the users and the buyers with no expectation of a transaction because if the salesperson is the one talking and doing the approach, that is going to change the dynamic of the conversation.

So, having them involved as a silent note taker or something like this, that’s probably a better way to do that, and for them to really hear the customer open up in ways that may not be happening under the pressure of a sales call—and I’m hoping your sales team is not putting pressure on there, but we’ve all been there before, and we know the dynamics are different in terms of what we’re willing to share when we know someone has something to sell to us. The second one here about aligning sales and product teams is, involve your product people—this is to the contrary—involve your product people in the sales process. I’ll just tell you, personally, as a product design consultant, and even when I was a staff designer internally or in-house with large enterprise companies, way back earlier in my career, I used to see salespeople as the enemy. They’re just selfish folks that want another feature done so they can close a deal and get a commission. These days, I see really good salespeople as trying to facilitate a transformation for the customer, and they also can be a wealth of information about customer pains, buying triggers, workflows at times, and competitor solutions. So, get your product folks shadowing those sales calls and make sure that they’re not just throwing feature requests over the wall and then they’re going to re-approach—reawaken sales conversations when the features are done.

Another way to align these teams is the role of sales engineers. Sales engineers can be extremely helpful in helping close the gap between these feature requirements that sales will sometimes ask the product team to build in order to land a deal and the benefits of those features that customers actually want. When we don’t have clarity around the problem space and the benefits—which is a product management skill that a lot of salespeople won’t have—your engineering team or whoever’s running the delivery side of your business, they will just see, “Add feature: allow CSV export on this thing.” Or, “The model should produce better results in the healthcare domain.” You’ll get these very tactical requirements that sound very engineering actionable, and it sounds like if we just deliver this, we will win.

But when teams blindly work on features without understanding the benefits in the context of use, you’re basically just in that project, instead of product management-focused culture where delivery of the feature on time is all that matters, not the quality and the outcomes that the feature should be producing. Sales engineers may know why sales is asking product to build that new capability and they can be a great addition to the typical product triad, acting as, like, an SME, or Subject Matter Expert. So, this is basically you get your tech lead, product lead, your UX design lead, but bring these SMEs like sales engineers into the conversations early. And what we’re doing is preventing delivering the wrong solution by making sure we have really good context. And the sales engineers often have much more of the important details about what the product needs than the sales person, who may be dealing only with the fiscal buyer or really focused on the fiscal buyer alone, but not necessarily the end-users. Talking about ROI, which is the overall value that your products target customers, their businesses, might receive, that’s very different than what the end-users on the ground may need or want from the product in order to consider adopting it and changing their status quo.

So, let’s review those five tactics one more time: tailoring the demo to map to the prospect’s world and their workflow, so no canned walkthroughs; treat product improvements as bets that have to be tested so that outcomes, which are changes in the world we can see, are what you’re holding the product team accountable to; the third one is reducing the amount of behavior change you’re asking customers to make in order to get value from your product quickly; the fourth one, realize that your product’s visual design, interaction paradigms, and usability are likely impacting your product’s clarity, desirability, and perceived utility. So, you might not have a designer, but your product is always broadcasting a design and a user experience. There are no null choices in this case. So, you need to move from byproduct design, as I call it, to designing this user experience with intention. The fifth one is aligning your sales and product teams around customer outcomes and not feature gaps. So, we talked about ways to get those teams working together, and the value of sales engineers in particular as potentially providing a lot of assistance to product teams who are trying to interpret requests from salespeople that things that they’re hearing on calls that they’re doing all the time.

So, that’s a lot, and I’m guessing that maybe some of you might be thinking that this sounds like a lot of work, and you may have some objections to some of this, so I wanted to talk about some of the common objections and just give my responses to those that I’ve heard from, you know, analytics and AI product leaders through my work and just exposure to the market. The first one—and I’ll kind of do these as quotes—“Our buyers are technical. They just want features, and that’s a clear buying decision. Yes or no: do you have feature x?” Well, my response to that is that, while sometimes yes you’re going to encounter someone that will just give you a blanket yes or no based on some feature capability, this really assumes that features and not benefits are why people buy.

So, whether you’re technical or not, you’re only buying because there is perceived value. Even technical buyers need clarity and adoption confidence. So, for example, let’s say that you have some coding copilot tool or product, and sure your user is an engineer. Do you think that they want to allow the entire codebase to be touched and reformatted from tabs to spaces, just because the bot decided it should update all of that, while adding, say, a little minor method or capability to some function on one particular screen or view? Should the tool prompt the engineer to accept the white spacing recommendation, just do it, or should it never even suggest that at all?

Well, what about if the tool solicits access to private API keys or asks for excessive privileges beyond what seems necessary? Oh, now it’s telling me I have to stop using Python? If I want to do this, I need to adopt a different language? I think you get my point here. Technical users are people, too, and developer experience is just another form of user experience. So, whether they’re technical or not, they have an experience. Your product is delivering experience, whether you designed it with intention or not. I think remembering that features aren’t really the reason technical buyers are buying. They are still buying benefits, whether they say it that way or not. They are looking for value.

The second one—objection—is, you know, “We’re disruptive. Customers may need to change if they want to get this big promise of value from our product.” And this is really true on the B2B AI product side right now, where I think a lot of very sharp founders and technical people are building some potentially really cool stuff, and they see that work as being disruptive. So, my response to this is that no customer I have ever talked to said, “You know, Brian, I just wish this product team could come in and disrupt us. Like, literally no one has ever said that to me.”

Now, sure, they might be open to innovative new solutions, but this is not the same thing as asking for disruption. And furthermore, when I hear all this talk about disruption touted as a claim, I find this to be more self-centered than customer-centered. And worse, it might be coming across as an inferiority complex, that you or the product have something to prove that can only be done in a very loud way: with disruption. To me, projecting quiet confidence positions your product as a solution that inherently proves its value. It doesn’t have to blow up what’s already working and it doesn’t set expectations that a big disruption at the customer’s company is required to get value out of your solution.

Now, I will say this, it is true that big change may be required to get big ROI and benefits, but what if you focused first on delivering smaller value sooner, so that you build trust along the way that the big change that you may eventually ask the customer to make in order to get the big ROI is actually worth it and safe? Number three, “Customization of our POCs and demos? Well, this just doesn’t scale.” I totally understand that, you know, ingesting customer data, building a test server just for their instance or an account, these days, this shouldn’t be that difficult, but you know, there are always edge cases, and you might need proprietary data to show the value of your solution, which requires legal agreements and all this kind of stuff, so just thinking about what are some ways we can nudge towards FOWA, that Flow Of Work Alignment, how can we get closer to it, even if we can’t get perfect, customized, fully customized demos for each person? Well, one way is to think in terms of templates, either by, like, a job role or an industry.

So, for example, think about what does the head of finance at a healthcare company care about that’s unique to them? That might not be the same of what the head of finance at a supply chain company cares about. So, you would have this understanding in the product team before you demo to either of those two buyers, if your solution is intended to solve pains for both of them. You could use realistic data for each of these different templates. So, what I mean here is, let’s say you have a market insights dashboard or your tool can show industry average or averages across all of your customers so people can benchmark against others like them. Well, you wouldn’t want to show them data for one industry that might be completely unbelievable numbers in another one.

So, let’s say you’re talking about new sales growth, and it says you had 1700 new customers last month, and this business typically does 10 to 15 new customers per month. You don’t want them getting hung up on this completely unrealistic sales forecast, or, you know, metric that you’re showing them from the past. This requires all that translation, and it really takes them out of their headspace, which is trying to imagine your product in their flow of work, so use realistic data for each template so that you’re not distracting people with unrealistic numbers. This is particularly true for, you know, historical analytics products or even predictive ones that are going to be showing quantitative data. And also along this line of thinking in terms of templates, at least, or categories of customers, and having canned a different demo experience or POC experience for each category or template is having a specific honeymoon UX for each of these, where in the product, you will understand and probably nudge what their user experience should be during that process.

So, a specific example here would be that—let’s use the supply chain company and the healthcare company example from earlier—let’s say in one of those you know that the product’s value is in really seeing the historical data across all the competitive landscape or whatever, so getting in there and seeing it and letting them compare those averages to the numbers in their head is good enough. Like, the dashboard right out of the box, pre-loaded with the proper industry data, that might be good enough, and so the default experience there is to drop them into the dashboard and let them explore some of these KPIs that they’ve never gotten to see before. Whereas in another industry, in the second industry, you might know that this customer isn’t going to believe anything until they have piped in their proprietary data, or we need to do some model training, or there’s some data engineering, or data sources that need to be connected in the product alone because it’s like, this is an enterprise-scale thing, they need to go through that process in order to get their initial value. It’s pointless to drop them on the canned dashboard because it’s just not going to be good enough. So, in that case, you might steer the POC experience to understand that’s likely what they’re going to want to do, so you might need to have a really good experience around allowing all those data connections to happen prior to them actually using the main part of the product there.

And this is all part of the perceived utility and usability of the solution, even if attaching data connectors and building pipelines or putting data into the system so it can be trained and deploying the training process and all this kind of stuff, we call this tool time. This is another Jared Spool comment which I really like. This is all tool time and not goal time. While we don’t really want them focused on that, if we can make that tool time feel effectively invisible such that they’re making good progress in the overall experience, they’re not really going to remember that anyways. They’re just going to see it as a necessary path to get to the value that they want. So, let’s design that with intention as well.

What you don’t want to do is, the opposite of this would be for in this second scenario, would be requiring them to fumble through the process of establishing these data connectors, doing data imports, having a clunky experience, possibly multiple times, and then saying to themselves, “You know what? This is just way too much work. We’re not even sure the product’s going to be able to tell us anything interesting and so far, it’s just, I don’t have time for this. It’s going to require these approvals. It’s not clear what’s happening in the background,” and on and on and on, and you’ve basically lost them, lost the sale already.

Even if the value would have been great, they couldn’t get past the technical hurdles required to even get value during the POC. So, customizing by template, even if you can’t get down to the specific customer level, that’s one way to customize your solution, the demo experience, or the POC experience to a degree that doesn’t require every single prospect to get their own build of your application or whatever if that’s difficult.

The next objection number four, sometimes we hear is, you know, “We don’t really have the budget to overhaul user experience or the UI, or we just had someone redo the UI, and now we’re finding out that it’s not good, again. Like, we just can’t invest in this again.” A lot of times you don’t need a giant redesign. That’s the first thing. In fact, we generally don’t want to go down that path unless—I mean, there’s always exceptions to this, but frankly, if you’re not a design professional, you are probably not going to know how to diagnose when that is warranted and when it’s not.

The counter to this is to look where the highest frequency and highest value workflows or jobs to be done reside in the product’s experience right now. Like, what are you supposed to be facilitating for customers right now that gets done frequently, or that’s really high value, but possibly not as frequent. Using the bets model that we talked about earlier, when you do product work, you want to tie user experience outcomes to business outcomes so that any of your sprinting work or whatever, which includes redesigning the front-end or components or experiences within the front-end, we want to tie those back to bets that can be tested, even with rough data or usability studies or just getting redesigned prototypes in front of users. The point here is that each design increment and investment you make, you should have clarity about what kind of results, from a business standpoint, might I see if I do this. You should not be hearing that we’re doing it because the product doesn’t look good and it needs to just look better, and we should just accept that if it looks better, then nice things are probably going to happen down the road.

You cannot quantify every design improvement that’s made. It would take too long, and we can’t actually do that level of attribution for everything, but the contrary is also not true. You don’t need to hear that entire redesign is needed and that you need to boil the ocean to get any value at all. We can map investments and user experience back to product benefits or business benefits that you should be able to observe in the real world, in your sales process. Fixing this will unlock this blocker in the sales process. So, where to start there, then focus on the high-friction demo moments. First, try to get some small wins, so you’re building some confidence in the team that you’re starting to knock down some of these objections and work on this in iterations. That’s my general advice, not seeing your particular product, of course.

And then number five, the last one here, is like, well, how would I even know if this whole Flow Of Work Alignment thing is working? Like, how would I measure as the, you know, founder and CEO or head of product at my company, how would I know that I have Flow Of Work Alignment? How would I measure that? I know data people and data product leaders, like, you like to be able to measure things, and that’s a really fair thing to ask, so I think some of the possible metrics you’d be looking at here would be things like your demo-to-deal conversion rates, but again, that is ultimately what you want, but that may be hard to attribute to single, isolated changes, you know, especially if your salespeople are changing their scripts, you’re deploying multiple different work streams and product iterations at the same time, it’s sometimes hard to isolate that this one change created this downstream value.

But ultimately, we do want to be moving towards improved deal conversion rates. So, what are some of those progress metrics that might tell us we’re getting towards those success metrics? Well, from a progress perspective, sales-cycle length could go down, including the whole POC-to-production timeline. You may have a metric, which is that customers voluntarily say they can see themselves using the solution on the calls, you may hear a lack of commentary in the sales calls about your product’s design, it’s user interface, it’s experience. In other words, salespeople are not having to spend time discussing or defending your UI or explaining it, but rather, they’re focused on the value conversation with the customer and the design and the UI is essentially invisible. It’s just not even brought up, which is probably a good sign, or even better, you might even get some praise that it looks really easy compared to competitors.

And the last one here about the measurement thing on progress here is, usability testing your product iterations, your sprints. And as you start making these bets, we want to test these things. In order to test the improvement, though, you need to understand the baseline you’re starting from. So, this gets back to what we were talking about earlier, with understanding how frustrating is the product experience for, say, onboarding the customer, connecting the data pipelines, or whatever it may be, how frustrating is that now? Then you define a target future state. Well, we want it to be this easy going forward. We want to move them from frustration to that satisfaction.

So, you get agreement on how you’re going to measure frustration and satisfaction before you ship. Then you do your product work, and then you go back and measure whether or not through use it—oftentimes, we can use usability studies for this, but we get the product in front of the customer and we observe them. We see, did their frustration level go down? Did the satisfaction level go up? I am not a fan of surveys and just asking people this customer, this is something you need to decide on how you would observe this. We want to look at what people are doing more than what they’re saying in this case.

And this could be blown out into a whole episode, but the main thing here is: know your current state, know how you’re measuring that it’s bad right now, define your desired future state, decide how you’re going to measure the improvement, and then fit your product work into that and test whether or not you improved or not. And again, this can be done at a workflow-specific level or a feature-specific level. I always like it tied back to workflows, though, that have defined starts and endings. But the point is, there are ways to measure that you have Flow Of Work Alignment.

So, just to wrap this up, let’s boil it down one more time. The key to converting demos and just solid contracts and sales for your B2B data product is to make your prospects' future usage of the product feel real and immediate and achievable, that you want them to see themselves in a better place. Technically superior products will win deals only when customers can clearly see themselves and/or their team using your product successfully, so if they can’t envision that, they’re not going to buy it, no matter how great the features are. In practical terms, I think B2B product leaders need to shift from selling product capabilities to selling outcomes that are inside the customer’s workflow. So, when your demo and discussion shows the prospect a picture of them using the tool to solve a problem that they struggle with, when they think, you know, “Oh, that could be us next quarter, finally fixing X,” you have effectively closed the imagination gap that can stall deals.

I have emphasized that designing with FOWA in mind, Flow Of Work Alignment, we’ve talked about this because that’s the vehicle to drive this vision home. So, align your solution to how people work rather than expecting large amounts of behavior change to occur in order to even test out whether or not your product is going to make their life better. And so, adopting this approach, you really get out of the pitch kind of conversation and instead, you’re really giving a preview of what their future better state is going to look like. And hopefully that means you lead to a closed deal and contracts become a formality, and the prospect isn’t just convinced, they’re actually eager to make that vision real. So, we don’t want to be selling the product. We want to sell the story of the customer’s success with the product.

But it’s a lot less about a story being told. We want to make it concrete in the product, so that they can inherently see this in themselves, especially when they’re actually trying to use it. It doesn’t take convincing with words; the product does this work for you automatically. And really, it doesn’t do it automatically. It comes from good product management and design leadership that is steering it in that direction because it understands what is the current state and what is our desired future state, how do we want to improve this customer’s experience, and then carefully measuring that we are actually improving things as we release features and new product increments into the world.

We’re actually checking our progress. We’re calling in those bets. Did the bet win or not? You should be checking that because shipping is not the end of the story. It’s really the beginning of the story. When you go to production, that’s really day one, even though it feels like you’ve just finished a bunch of work.

So, I think, in essence, like, closing the demo to contract gap, it really comes down to deep empathy. And I see a lot of similarities, really, between the sales process, if done empathetically, and doing good product design work. It means deeply understanding the customer’s world and showing how your product neatly fits into it, flowing with the way they want to do things now, but making their work better. It’s about their workflow, their pain, their outcomes. They own all that, and get to decide how much it hurts and how important it is, not you, even if you could see how you could make their life better in some other thing they’re not talking about. It doesn’t matter because they get to own that problem space, but their improvement will be powered by your B2B analytics or AI product.

So, I hope if you keep some of these ideas front and center in the conversations here, you are going to end with more deals in the closed one column, and you will be getting some of that nice revenue coming in, so you can fight the good battle tomorrow and keep making the customer’s world a little bit better for the next week, month, and hopefully years to come. Good luck.