Transcript:

Brian: Welcome back to Experiencing Data. This is Brian T. O’Neill. Today, the unique challenges and solutions to selling API-based analytics and intelligence products. I’m thinking specifically of tools such as MCPs, data feeds, APIs, things that are typically going to be consumed by a software engineer, a developer, a data scientist, analysts, technical tools, things of this nature.

So, why are we talking about this? Why is some guy, a company named Designing for Analytics, talking about developer tooling? Well, I think you can design your way to a better financial future for your product if you actually think about the design of the experience around these tools, and I want to talk about how this can help smooth out your sales process and increase those closed, won deals.

So, what’s the premise for today? What’s prompting all this? APIs, MCPs, data feed products that fall into these general technical tool categories, they offer lots of flexibility, and they are intentionally designed to allow custom application development to happen downstream. The challenge with flexibility is that we also may be forcing our buyers to have to get creative and imagine a better future with your product in the loop. And when we couple all that flexibility with the effort it requires to integrate your solution into their custom application, or whatever it is they’re trying to do, this can add up to sales friction before any value can actually be perceived, particularly in that POC or demo phase, if that’s what you’re going through. And I know most of you are selling B2B, which probably means there is some type of proof of concept or demo phase or something like this.

So, when we add friction to the sale, we either slow down the close or we might even prevent the sale from occurring at all, and I’d like to suggest that design can help close this imagination gap and it can help connect your product’s capabilities to value that your customer cares about right now. So, why right now? Why are we talking about this right now? I’ve seen a few clients offering MCPs, APIs, feeds, other more developer-oriented solutions, often thinking about the enterprise buyer, and coming to this realization that despite not thinking they need to have, like, a SaaS style user interface, there’s actually some value in doing this. So, I want to talk about the challenges that you might face and what some of the main ideas about why you might want to consider putting a design on top of your technical solution, and how this is going to help possibly close some new business and help your customers close that imagination gap.

So, the challenge: non-technical buyers may not immediately see the full value of a technical product, particularly if it’s trying to sell itself, or you’re trying to sell it as doing a lot more than what the buyer’s immediate need is, the thing that they can get budget for right now, and that they’re willing to pay money for to make that problem go away or to capture that value that you’re offering. AI-based solutions in general, AI products, I think these even more so are promising wider flexibility, more general-purpose application things of this nature, but building trust that your product is going to perform adequately in all scenarios is harder to test for them because the boundaries of what your product can and cannot do well can’t really be seen; it’s almost like you’re limiting it to just your imagination. So this, to me, while you get that flexibility, the cost that’s associated with that flexibility is actually not being able to see the edges very well, which makes it harder to evaluate, and it slows down the evaluation process. So, when we force the buyer to imagine too much trying to cross what I call this invisible intelligence gap, we are creating friction in the sales process.

And so, if you haven’t listened to show before, I’ve talked a lot about the invisible intelligence gap. This is when the value and capabilities in your product are there, they’re in the code, they’re in the models, but your users and buyers cannot see them yet or they are not able to realize that value yet. So, in other words, they can’t see this analytics, the analytical intelligence, the quality of the data, the quality of the insights, all this kind of stuff. It’s kind of invisible to them right now, so we want to close up that gap.

This idea that, like, oh, it can do all sorts of things, you know, this can work in all industries, this stuff sounds really good to technical buyers and engineers because they want flexibility and they’re not always sure, maybe how they’re going to use it in every possible way, and it feels like it might cover all these use cases that the customer has not even expressed yet, but I think this flexibility is sort of a liability that you need to manage in a sales conversation. I think it’s probably best to assume that your buyer is likely fixated on whether their immediate need is either their immediate need or their desire for value, whatever that specific thing is, they want to know if that’s going to be solved properly or not. And if your product is promising to solve 100 different problems, then you’re not really signaling to your customer or your user that you’ve made the hard choice to really think through their most critical needs and to deliver some type of indispensable data product against that need. When we’re trying to do a hundred things, it doesn’t look like you’ve really doubled down and nailed it; it looks like you’re kind of fishing for the right thing to solve, and it’s so general purpose that you’re not building that confidence that the thing they’re writing a check for, that value is going to crystallize fairly soon, or on some time horizon that they really care about, and it’s going to be obvious.

So, I have seen—what do we do about all this? Well, I’ve seen a couple clients find value in adding a UI layer, a user interface to their developer tooling or their API, whatever this technical thing is. And this can serve a variety of purposes, but I want to go through about four or five of those. The first is, this literally can just be a sales aid, so less explanation being required and more showing. You’re showing what an arbitrary implementation might look like with your, you know, API or whatever your tool is under the covers in action, inside an application here, and so the connection between the customer problem and the solution can be more quickly communicated.

And this could be, these days with AI, you might even be able to spin up an industry-specific prototype of something that leverages your product in order to convey this rapidly, so if you are trying to sell into multiple industries, which generally my suggestion is, like, find a narrow problem, narrow buyer, get it right on a narrow vertical before you start trying to go wide with it, but if you are, this is a place, just like if you’re customizing your resume, you’re trying to get a job, these days, you can create an infinite number of resume versions pretty fast and customize it, and the same would go here.

The second reason you may want to consider putting a user interface design layer on top of your technical developer product is adding a UI may open up new markets and buyers. So, the way I see this is you might have thought that this is something that’s only going to be valued by an enterprise buyer, but as you start to actually put something together, you might find out that you’ve kind of accidentally fallen into a product that might be suitable for a smaller B2B business or a slightly different kind of buyer or someone that doesn’t mind using the nuts and bolts of your application. It’s good enough for what they need. Maybe it’s not, you know, integrated directly into their Salesforce instance, or whatever it may be, but they’re willing, for the price trade off and not needing to do customization, they’re willing to take some of that pain. So, the act of going through this, I think, of actually designing this, you may discover this as a byproduct of doing the first thing, which is creating this sales aid to use in your sales calls.

The third one here is that I think a prospect who’s seeing a user interface on top of your application, I think it also makes it easier for them to imagine derivative applications and usage contexts that they might not have thought before. So effectively, this UI you create, and maybe it’s only for demo purposes, maybe it doesn’t have account management, it’s a single user, you know, it’s not meant—it doesn’t need to be a standalone product, but that UI can act as an accelerant for imagining other types of applications, and so this can help the buyer possibly see ways they might use it.

Fourth one here—and I kind of just hinted at this—but you might be thinking, “Oh, it’s going to be really expensive to go out and build a full product UI on top of our technology here, and we’re really a technical play, that it’s really about the data science and the model quality and all this kind of stuff.” As I just said, you don’t necessarily need to build out the full SaaS version of your product or one instance of how your product could be used. You’re not necessarily creating an entire business SaaS application here. It’s just enough to help close these imagination and visible intelligence gaps we’ve been talking about and to start communicating the ideas more quickly. So, not only do you not need a lot, the hardest work here is actually figuring out, well, what is this product strategy or this demo application strategy going to be, and what is the basic user experience that it needs to have in order to communicate the value quickly?

The UI execution actually becomes fairly straightforward if you have the product strategy down right and the user experience has been thought out sufficiently, the UI will take care of itself. And I think this is a place where it’s fairly easy to rebrand stuff these days with these Copilot tools. You can have custom versions for your different verticals, as we talked about. Again, it doesn’t need to be a full-blown production-grade user interface for an application. It just needs to be enough to express the possibility of what your technology can do.

So, you really need to focus less on, oh, it’s going to cost a lot of money, and we don’t have the skills, and all this. The thinking part, the strategy, and the planning part on the UX and product side, that’s the most important thing to get right. If you get that right, the UI design tends to be more of a delivery and execution thing. And again, this is a place where machines may get you a fair way, or maybe you get a good deal of the way, and you hire someone to come in and do the last mile for you, but if you do that upfront work first, you won’t have to spend as much time kind of figuring out what the UI design should be. I don’t want to rat hole way into design stuff, but most non-design product leaders and founders I talk to they tend to start with the user interface and then work backwards and start thinking about the strategy and the user experience, and by that time you’ve already got sunk cost and all this kind of stuff, so I recommend trying to work the other direction or get some help if that’s not where your best skills lie.

And the last idea here is another way to think about a user interface on top of your product here is providing visual evidence of how much value the product is actually producing for the customer. So, the way to think about this is something like a management tool, for example, or a management console that might sit there and report the financial value or the operational value of the tool as it’s used. So, think about it as, like, almost like analytics on your analytics tool, and the main job of this user interface might be simply to communicate what is the tool doing, how much is it being used, things of this nature, and ideally, what’s the value that it’s creating. This is something that can be really useful during a demo or POC, particularly when you’re not there to look up this data for them or try to explain to them what the value is. They can look at a screen inside the application to understand that.

So, what kind of results? Let’s jump to results or impact here. What kinds of sales impacts or results might you see if you were to invest in having a UI on top of a technical product that’s mostly for application development and things like this? One of my startup clients is a couple years ago with a product that was a machine-learning product in financial services targeted at capital markets and institutional financial services companies, they mentioned that after having a UI to showcase what their machine-learning capabilities were under the cover, what they were doing with this—it was in the NLP space, every sales conversation they had after that was positive. They, at the time that I checked in with them, I was asking them how things were going, and they said every single conversation was now positive. There were no longer any nos. It was now just a question of how do we move this forward and going through the crazy procurement process that is part of working with any large enterprise, but particularly banks and financial services.

So, they felt very confident that having this SaaS style interface was doing a great job at communicating the value of the product and moving that buyer to the next stage in the sales cycle. The second one here—and this also came out of, you know, having this little retrospective with this client, with the CEO—was that it helped clarify the sales messaging and, like, the go-to-market strategy. So, this visual helps really communicate more the value with less talking and less explaining because it starts to become visually evident. So, you want to take advantage of the fact that human beings are visual creatures, we process visual information much faster than words and listening, so use that to your advantage.

If you are trying to get the value across, this is part of the reason why design matters. It’s not just about making something look good aesthetically or just in making it easy to use, but we’re also trying to visually communicate the value and utility as fast as possible, through visuals, but also through experience. The third one here is again, we sort of talked about this, but if you have this ability to monitor your own application’s usage and tie that back to value, I’ve seen this be really helpful when you have very technical products that might sit, like, in the I/O stream, for example. Let’s say you’re selling into a technical company, like infrastructure work or something like this, and you have a gadget that sits on the electrical wire and it’s processing the electrical current going through and it’s measuring the quality of the current, and then it’s telling you whether or not how much electricity is being wasted, and it’s not being transmitted properly—totally making this up right now—but the point is, if your solution is sort of invisible, or it requires some integrations, or maybe there’s a little application that’s going to, you know, manage the power supply automatically for the transmission station, having this analytics or reporting GUI on top of the product can start to show, well, here’s what electricity was costing, here’s how much money was saved by rerouting the electricity at the right times, here’s the number of reroutes that the application handled for you.

This interface becomes the way that the customer understands the business value of what the product is promising to do. So, the intelligence might be in the IoT and the hardware, the data capture, and all that kind of stuff, the telemetry, the way you’re cross-referencing the telemetry with other stuff. That’s all the intelligence layer, but until they have that ability to translate that to value that they care about, it’s kind of invisible, it’s hard to see it, it’s hard to quantify it, and so this designing this interface on top of it helps us communicate that value much more quickly, particularly when they are by themselves and they’re not on a sales call. So, those are some of the sales impacts here.

So, I want to leave you with a couple last ideas, some practical takeaways here. When might you consider adding a user interface, designing and adding user interface to an API, MCP, data feed, technical product for, like, a developer, data scientist, technical audience? When do you do this? I would be looking at things like, frankly, you’re not getting traction in the sales calls, but you’re, kind of, getting this sense that people think, well, yeah, I kind of see the value there, but there’s really not a second phone call. You’re not getting a flat no, but you’re not really moving things along, that may be a signal it’s time to do this.

The second one is, your solution creates what I’m going to call blue ocean value here, meaning the customer did not—and I’ve talked about this. The blue ocean thing is not my idea—but this idea that the customer did not have the need or desire for your product until they saw it and realized what it could do for them. This is particularly relevant right now if you’re building an AI-powered solution that is intended to go in and disrupt or eliminate volumes of manual human work, and this ends up quickly bringing a downstream problem to the forefront. So, what do I mean by this? Well, I actually just heard an example of this on a podcast called Exponential View with Azeem Azhar, which I really like listening to his analyzes of how AI is transforming businesses.

You know, imagine your AI product is in financial services and it aggregates news feeds, analyst reports, internal data and other sources in order to provide, like, buy-sell recommendations for stocks and securities for traders to use, right? So, in the past, going through all that information, coming up with the insights, figuring out, should we buy it, should we hold it, should we sell it, what do we think about it, that was the bottleneck. There was only so much speed at which you could go through all this information, maybe you had multiple different people doing different parts of the analysis, et cetera, et cetera. The bottleneck with AI, with something like this, can change. So again, the analyses used to be the hard thing, and then the decision to place the trade was fairly easy because we didn’t encounter the trade decision as frequently because the slow part was the analysis, and then you get to the trade decision.

Now, with AI, if you’re in this blue ocean space, you might have actually pushed the trading decisions up—you haven’t pushed it; you have brought this into the forefront of their work. So, whereas in the past they were doing a lot of time doing the analysis work; now the overall business’s problem is placing all these trades. Well, what’s blocking us from doing that? Well, someone has to sign off on this trade. Is there enough margin or capital to place the trade in the first part? Is risk and compliance okay with placing the trade?

Now, this is a much more frequent problem that we’re having because the analysis on what to do has been provided. The recommendations are now sitting there, and they’re waiting for the business to react to the recommendations. So, this is kind of that blue ocean thing, which was like they’re not thinking that they have this problem yet with getting the trades placed because that’s never been a problem before, but as soon as you solved the first problem, which was the analysis part, you just pushed that downstream problem right to the forefront. And this also happens with analytics products I talk about—I just had this lunch salon at Boston Tech Week, and one of the people that was there was asking me about solving that first problem versus the second problem. The first problem being just get the data—in this case, it’s a traditional analytics and insights product—just get the data. Just let them see what are the facts, what’s going on.

And she was asking, do we try to solve that problem or do you try to solve the downstream problem? And my feeling is the problem with only trying to sell into the first thing, which is just get the data put together is that, as soon as you get just the facts, the downstream question immediately becomes the new problem, the new status quo. What do we do with this information? What decisions should we make? And my feeling is you always should be focused on that downstream second problem.

As long as you’re solving the first one, it’s okay, but you should be very mindful in your product strategy about how far into that second problem should we go? Because I think analy—AI, in particular, is going to accelerate the need to be thinking about this. Because in a short period, a lot of people are going to start optimizing on the labor reduction side of things, and reducing workloads, and finding optimizations, and this pattern of using AI to shorten work cycles to reduce human work, all this kind of stuff is going to create new problems, or it’s going to increase the volume of those downstream problems. Those will become the new status quo problems, so your product will be better positioned if it’s starting to think about that stuff. So, I know I went on a little bit of a rat hole there, but I think it’s important to be thinking about this, and again, this is where having a visual to help communicate this stuff might be really helpful.

The third one here is you designed your AI solution—and again we’re talking about practical takeaways here, right? When would you consider adding a user interface layer to your technical product—another time you might do that is that you designed your AI solution as an MCP to be easily accessible via another agent, or what I would call, like, a machine user. But the machine isn’t your buyer, and the buyer needs some proof that the solution is generating the promised value. So, depending on what the MCP does, the MCP itself is not the value; the MCP is a translation layer there, but you need to be thinking about, well, what’s on the other side of that MCP? Again, if we get too abstracted here, if we’re only thinking about the machine compatibility and all that side of it, the value may not be super obvious yet. So again, this is where thinking visually about solutions, I think, can help you make the value of these things much more concrete.

The last one here is you want to test whether a less technical segment of your market might trade the flexibility of say an API or MCP or a technical feed that requires a developer or analyst or some kind of technology person to integrate it before there can be any value realized from it, a reason you might add a design layer here is to go out and test whether or not there’s a different buyer type who does not want to go through all that and they are willing to use your, you know, URLs, your web-based—it’s probably a web-based interface, or whatever—they’re willing to go to a second product to get that value out of it. It’s not fully integrated into their own, but they’re willing to switch over to a different pane of glass to get that value because for them, it’s good enough. So, a design would allow you to go out and test this without building out a lot of new capability in the underlying intelligence part or the analytics part. This is just a different front-end or surface layer for the humans-in-a-loop to actually interact with the product. So, this would be a way you could go out and test whether there’s a different, less technical buyer who doesn’t need an enterprise-grade solution.

So, just to kind of tie all this up, if you’re sitting on, you know, an API or some kind of analytical intelligence product that’s for technical buyers and you’re wondering why the sales process feels harder than it should, the answer, it just, it may not be in your sales deck or your pitch. It might be caused by what you’re not showing visually to your customers. What is missing? What can they not see? This may be the thing that’s blocking the sale, is they cannot understand the full value of what the solution is there, and you haven’t tried simply communicating that in a visual way, putting it into something that’s concrete that quickly signals what the value is, or at least it gets the gears oiled and turning, so they can start, “Oh, that’s what it can do. Now, I kind of see how one could do that. We’re not in the restaurant space, we’re in the medical space, but I can see how they use that for operational”—blah, blah, blah. They can start putting those things together when they get to see what it could look like. So, show, don’t tell. Let the design tell your product story in as few words as possible.

Thanks for listening. We’ll see you next time.