Transcript:

Brian: Welcome back to Experiencing Data. This is Brian T. O’Neill. Today, “Surface Tension: The Five Essential Control Surfaces to Make Your Analytics Product Sell Itself.” Have you been building or have a sophisticated analytics product that’s been in market for a little while? Maybe it’s loaded with custom ontologies, and it has, of course, it has an MCP connector these days, and you’ve trained your own models, and it has agentic capabilities just like everyone else, and perhaps some other IP that nobody else has, and maybe you’re wondering why customers aren’t necessarily seeing the value, despite all of that technical investment. Why are sales not closing? Why are POCs taking longer than expected? Why is retention not always there?

Well, I want to talk about this, and I want to talk about these control services, what they are, the personas behind them, and where you may be placing too much attention in your product development. I generally don’t see all those technical things we just talked about as safe business modes, especially as of now; it’s summer 2026. If you want to learn more about what I do think about moats right now for analytics and BI products, intelligence products in general, go back to episode 197, where I discuss moats for analytical software products from ISVs like you. When you believe that the underlying technical IP, including your models and all this kind of stuff, should be enough to speak for themselves, but you’re seeing those stalled, you know, POCs, flat user adoption, quiet non-renewal, this kind of thing, it might be time to just accept that the underlying technology isn’t itself valuable; it’s the perceived value of this tech, all of this technical work that you’ve done, as experienced by the buyers and the users, the humans in the loop that are going to interface with you, starting from the point they have their first relationship with you at a sales call, all the way down the road to implementation where the product is in the hands of users.

So, how is your product being perceived? Well, instead of thinking about user interfaces and UIs, I’d like you to think about this in terms of control surfaces that enable different kinds of experiences here. And you’re probably thinking a lot about, like, chat-based user experiences right now. When we think about adding AI capabilities to products and things like this, this is the first thing that comes to mind, and maybe how your product will interact with other AI systems and the like. And a pattern that I’ve seen emerge with complex analytical data products is that you often have multiple stakeholder touchpoints with the product that are all needing slightly different things from a solution.

Frankly, I don’t think AI changes a whole lot on the need side. It doesn’t necessarily change what the customer needs are, but it may change how you implement your human and machine-user experiences within your product. I feel weird saying machine user experiences, but I’m going to roll with some of this language for now because I think most of our listeners, my listeners here, like you, are smart enough to know what I mean when I say things like this. So today, I want to dive into the five control surfaces that I think are essential to be thinking about if you’re trying to make your analytical intelligence product indispensable. So, let’s jump in on these, the five essential control surfaces here.

The first one to think about here is your POC and your demo value to stakeholders. Who’s actually going to use and then benefit from a POC? So that’s, you’re getting in your proof of concept, getting in the door, getting them their first exposure to what your product can do. At the most basic level, you’d ideally want the value to be obvious without a ton of explanation or usage of the product required. When your first gatekeeper can’t understand it, use it, or integrate it into their unique way of working, then your POC just has a larger chance of being likely to stall, and you may lose to a simpler product that obfuscates some of that complexity, even if that means potentially not having some of the technical sophistication there. You may lose out because they simply are showing time to value faster than you are.

Which personas need to be involved once and then go away? So think, like, IT, data analytics team, legal, et cetera. During this phase, it’s essential to deliver value on the ROI side because your enemy here is really them being able to justify the purchase of your solution. Why should we pay for this, and am I going… personally, me, I’m Mr. Stakeholder… how am I going to prove to the business that I made an intelligent purchase here?

I think it’s really critical to understand that this person is supposed to be doing the right thing for the business, but they have a personal stake, a reputational stake as well that you need to be dialed into. So, don’t underplay the importance of the individual human that you’re talking to here, and not just their department or the business that they work for, even if they’re fairly senior. So, your sense of value delivery here, though, is not just for this fiscal buyer, but we also have to think about the user, the organization, the different success levels here. For example, did the problem go away? Was the most urgent need met, which is the reason they took your call in the first place? What does the product need to do… or support… to help get it through compliance, through risk, or procurement, legal teams, all this kind of stuff?

So, let me give you an example here. Legal or compliance might need to see samples of your data, your model’s audit trail if it’s making recommendations or it’s actually implementing changes inside the business there, they might be very concerned about being able to justify letting a machine do this and basically CYA, and that’s primarily what they are incentivized to do inside the organization. Value be damned because for them they’re playing a defensive game, so that’s a perspective that you might need to think about before they’re going to sign off. So, once they can see how it works in their interest for what they need, then they can bless this and approve it and help your champion… I’m guessing most of the time, that department may not be your champion; you may even see them as a blocker to you getting your foot in the door there, but this can help return focus over to the champion who really can move things forward.

The key point here is that are you aware of the entire POC buyer lifecycle? Are you aware of all the people that are going to be involved in the purchase or renewal of your solution, and what their discrete needs are? And who might directly or indirectly be interfacing with your product along the way? If you get past the POC process and into production, congrats. You may have fewer mouths to feed inside the product, and this is relieving because when you have all these different stakeholders with different needs, it’s a lot of complexity, and as we add different surfaces for all these different user types, the challenge goes up to keep everything simple and valuable to customers.

So, while your mileage may vary here, many of you I think are going to see three, kind of, key archetypes that are going to become more of your evergreen control surfaces or personas that are going to have the most exposure to the product on a routine basis. So, it’s important not just to think about what are all the control surfaces I need and the different personas that are part of this buyer experience and then user experience, but to understand how much do I need to focus at any one time on these different personas within this life cycle here because the game is not… every mouth is equally hungry and should get equal attention. I don’t think that’s it. I think part of your product strategy is figuring out who deserves the most love inside the product. So, let’s talk about some of these more evergreen ones.

So, I’m going to move into the second of the five essential control surfaces for B2 analytics products, and this would be the one that most of us are probably thinking about a fair amount, which is the end-user experience or the operator user experience, as I might call it here. This could be a developer, an analyst, a business user, typically the… you know, even a data engineer. These are roles that we typically think about as using B2B analytics software. The point is, this is the person who is actively interacting with your solution as an operator of the product once you’re past this POC and into regular deployment. So, they’re probably there, of course, during the POC, but they’re the ones that are going to be there most of the time after.

And as a general rule, this person is likely more like an individual contributor, they’re self-interested in their own job performance, and so the question becomes, are you helping this person to be successful, are you making their lives better with your product, and does your product feel like an essential ally that they would hate to lose? So, landing the deal is one thing, but if you have low end-user adoption, you’re looking at churn come renewal time, or potentially less volume of use if you’re working on some sort of outcome-based pricing model and this type of thing. They may just depend less on your solution because they’re not getting the value out of it that they need. So, your goal should be to create an indispensable user experience for customers, and create an operator who’d hate to lose you, and they would complain to management, to their fiscal sponsors, the C-suite or whoever is buying your solution, they would go and complain if your product went away.

The second of these, kind of, three more evergreen ones to think about here are your managers, your management-type user personas. Often, this may be a champion of the product, someone that, maybe, doesn’t make the final fiscal decision on whether to buy or not buy, but they may ultimately have the loudest recommendation, the loudest voice, and they could be your champion, and they’re probably the ones that get you in the door for that big enterprise sales deal. Think about, like, a sales director, a customer service manager, or an analy… you know, VP of data, if it’s a head of analytics team, head of BI team, things like this. The trick with this one, though, especially with AI in the loop, and what I mean, AI capabilities inside of your product, is that satisfying this person’s needs may be at odds with satisfying number two, this end-user and this operator, more this IC person who’s actually in the product on a regular basis, the needs of these two can be at odds with each other. What is good for this manager, such as hey, look at my team’s efficiency, look at how much more revenue we’ve made, or how we’ve optimized this process, et cetera, this may actually be seen as a threat by that second persona.

They’re thinking, “I don’t want Big Brother watching me. I don’t want my job going away here. I don’t want to be left in the dust. I do want to be up to date on the latest tools and do enough to keep my job,” but some of that may be at odds with what the management person cares about. So, why should you care? Well, because this management persona here, the second control surface we need to think about, they might get you in the door, but if the end-users and operators aren’t using the solution at all, then they may really be the ones that determine whether or not your POC survives, or if it does survive, whether you get renewed when that time comes.

So, your challenge, partly, here is who owns the new problems that surface when your product goes into the organization? The manager? The end-user? The operator? Who owns those things? What happens when the manager seeks these efficiency gains to make their justification to the executive department or whoever the fiscal buyers are? But this is at odds with the end-users’ goals, which may simply be to survive the perceived automation that may be coming their way, or if it’s one of these kinds of things.

AI is welcome to so many, particularly people that are working in information and jobs that involve looking at computers on a regular basis, until they see how AI may negatively affect their own job role or necessity, so how can your product stand out if your product is making the lives of users better while also satisfying management? How could you use the product to satisfy both of these needs that can be seen as competing. I think there’s an opportunity to focus on this space to make both of these people win, to make both of their lives better, so that they, as a team, are creating obvious value that can be blessed for renewal or purchase by whoever your fiscal buyer is. If you don’t think about this, then don’t be surprised if your amazing agentic AI capabilities, et cetera, et cetera, may be possibly viewed as a negative. Initially, they’re really good, but when we start to see what the impact of all this automation is here, and if it’s not framed properly here, you could just be producing a value to one of these personas, management and the people responsible for value creation, but a threat to the end-users who are actually the ones that are going to use your product to create said value.

It might be beast mode here if you haven’t really intentionally thought about your product design and user experience here, but the fix is to basically, one, help the operator look good to management, two, improve the lives of both end-users and the management layer there, and three, give your product’s champion, whoever that is, the evidence they need to sell the fiscal sponsor on the value of your product so that you can get in the door, that POC gets passed, or that renewal that you seek comes through.

And this, kind of, naturally leads us to control surface four here, or persona number four, which is our executive stakeholders or fiscal buyers, the person that’s holding the purse strings here and makes a decision on whether to invest with your product. So, the budget holders, the ones I’m sure most of you founders and operators types out there listening to the ones that you are trying to talk to. After all, that’s your decision-maker. Those are the people that are ultimately going to give that go/no-go decision. The thing is, they actually may have the least touch points with your product, but they do care about things like ROI quite a bit, so the question is, how are they going to get access to that information?

This gets even more complicated to think about when your tool is somewhat ephemeral, or you can’t see it, or you provide an intelligence layer that sits almost like middleware somewhere inside the stack. How do you show the value of that information such that they can understand, hey, why are we paying for this thing? One of my past guests on the show recently, a founder and operator, referred to this as shipping the meter, meaning that his product was fairly invisible to customers. It primarily worked in the background, and so they needed to have some sort of meter running that would show the correlated business value… I think, for example, cost savings… that are attributable to the product being in production. So, right here, we have one of the very practical reasons why I don’t believe dashboards and product metrics and all this kind of stuff are dead. “Dashboards are dead in the age of AI.” Well, this is part of the reason I don’t believe that.

I think your deal is probably dead if you’re just waiting for a customer to ask Claude via your MCP for stats on the value of your product, et cetera, this kind of passive user experience that requires them to ask the right questions. Chances are, the experience for the executive stakeholder, even if this is not going to have a lot of specific UI that’s built directly for the stakeholders, they are going to hear something or see something or both about this product, and you can help shape that experience so they are properly attributing value where it should be attributed, and they’re not quote, “Blaming” your product for something that’s outside of your control. Don’t assume that customers always know what the right stats are to look at, nor whether, you know, a straight line to your product as being the driver of those stats and KPIs can actually be logically drawn or not.

So, I’m thinking very differently about the meter here and the UI and the user experience. I call it a user experience here because there is an experience being had by the executive team, whether it’s inside the product or not. There is an experience to be had about under… think about the, we have to cut 20% costs on our expenses here. Which products should we get rid of here? We have a lot of… we’ve got four different versions of tool X; we don’t need four different vendors for this. It’s time to let one go.

There is an experience they’re going to go through, so the question is, have you put anything deliberate behind thinking about that experience or not? Whether it’s dashboards or not, I think there probably is some type of reporting experience here, so this whole dashboards are dead, and these, kind of, sweeping generalizations about things, I generally don’t live in the world of sweeping generalizations as being true. The point here is that the meter, as my last guest called it, combined with the subjective feelings of the POC team including the manager persona, the data team, risk procurement, all those people that are have a shorter, may have more of an upfront experience in the buying process, well, your product’s value is going to be much more obvious when you deliberately make it obvious.

So, this is active, not passive product work. It may not be a lot of underlying feature work. It may not be super technical work that’s involved with making your models better and, you know, actually making the operator experience better, but I do think you need to be putting some time into this as well, otherwise, you are in what I call the invisible intelligence gap, which means the product has all this amazing technology here, but customers just aren’t seeing it here. So, call it a reporting layer, call it whatever you want, but there is an experience to be had here for this fiscal buyer, this executive sponsor of the product, and I think you deliberately need to be thinking about what that’s like when you are not present, since this is likely not going to be occurring on a call with you. Help them understand the value the product is creating, and if you can’t show that, you’re going to have a hard time.

The last of the personas and control surfaces here are the quote, “Machine users,” or we can think of this as AI agents who quote use your product. So, I’m not really sold on this as a persona, but I’m going to frame it sort of like this for now, for the purposes of this episode here. I tend to see machine users as really being attached to a human stakeholder, so they are not a first-class citizen. This is like a motorcycle, you know, like, in World War II, that has the little sidecar attached. This is always at least a duo. It’s always a human with a machine user attached to it.

And so, while we tend to think of, or the reigning mindset tends to think of agents as being fully autonomous, I think much of the time there is a human who is closely attached to these agents, who is steering the agents, they’re responsible for the outcomes that the agents are producing, and that person is really hoping that the machine user is serving them well. So, why does any of this matter to you? Well, if your end-users are human analysts, then they may not ever open your UI at all. If you have, like, a technical user and you have more of a business user, well, maybe your technical user doesn’t really want to open your UI. They might go in and ask Claude to interact with the product via MCP, for example, or some third… you know, a method outside of the deterministic harness application that you’ve written that runs in the browser or whatever.

However, if you, for example, through MCP or through Claude or through some, you know, a different interface that you didn’t explicitly design, if you just hand back, say, a metric, since we’re talking about analytics products here, you hand back some kind of metric or trend with no evidence or no providence, no ‘so what?’ Then an agent such as Claude or whatever one they’re using may relay a very confident but unexplained answer back to this technical user. So, why should you care? Well, ultimately, Claude in this case, is we… and I’m just picking on them arbitrarily, as that would be the machine user, partnered up with this human… ultimately, Claude here doesn’t care about their results. It is the human that’s downstream from there who’s writing the prompts or the application or runs the business process, et cetera, that person needs that provenance, the evidence, the structure, the proper guardrails, all that stuff.

You aren’t going to be able to design all of the UI surfaces, but instead you’re going to define the parameters for what successful responses look like to the machine with the end human in mind the entire time because we are not trying to satisfy what the bot needs, what the agent needs; we’re trying to always satisfy what the human that’s downstream from that agent needs. So, the product work, the output here may be more technical in nature, you know, think about code guardrails, rules, mandatory evidence that ships with responses, provenance, all this kind of stuff, but just because you may not ship a UI doesn’t mean that you still don’t have a dynamic duo of human and AI working together, and the human is still queen or king. You’re designing for the human through an AI intermediary. You are not designing for the machine user explicitly. I think this is really important to dial into that when we think about MCPs and allowing the AIs to talk to each other and all this kind of stuff, the problem I have with that is that we have disintermediated the human here, we have taken the human out of the loop.

And I think this framing of remembering that there is still a human stakeholder somewhere in the loop that cares about why the machines are able to talk to each other, if you are dialed into that, you’re going to win because that’s ultimately what matters here. The machines have no will, they have no personal goals and this kind of stuff, they just want to accomplish tasks on behalf of their masters. They’re a diligent worker, but they don’t care about anything.

The attached humans do. They care. They have feelings. They have needs. They want better status. They want to look good to their boss. That’s where the money is. That’s where the impact is. That’s where the meaning is, and why hopefully you’re in this business in the first place is to make things better by making better things. So, while that product work here might look like code and evals, guardrails, examples, not necessarily UI widgets and dashboards and application surfaces, don’t fall into the trap of designing for an AI agent in isolation here. Okay?

So, takeaways here: we’ve been talking about the five essential control surfaces to make your analytics product sell itself today. Just some, kind of, wrap-up thoughts here. The thing I worry probably most about if you were to take this episode and try to put it right into action… first of all, I love it when I hear that someone was actually able to take one of my solo episodes and put it into action; that’s great… I don’t want you to walk away with here is that there needs to be one screen, surface, or UI or dashboard for each of the five personas that Brian talked about and you need to think about a discrete sprint for each one of these things and boil it down to something that simple. Some of that might be right. There may be distinct screens for each of these areas at some point, or experiences, I don’t know, but most of the time it’s probably not going to be that simple, and it’s definitely not what our quote, “Agentic persona, our agent user needs,” end quotes.

The bulk of this work is really understanding that all of these needs exist in the first place, that they’re actually there, and that there may be control surfaces you haven’t thought of that need deliberate product design attention in order for your product to pass through that POC gate, the diligence gates, the data teams gates, the technical review, the business review, all that stuff. If you want them to get bought and remain essential, there are experiences all along the way here to think about. The product’s implementation tactics may include chat UIs and charts and graphs and table data and dashboards and push-pull and integrations with other apps and MCP connectors and all that stuff, but frankly, that’s, kind of, the easy part to figure out. These are all the outputs that you might design, but outputs in response to what? And the answer to that is where you start.

It’s about identifying all of these different humans in the loop, these different personas that matter, what a successful outcome looks like to each of them, and when on the timeline here when we think about that this stuff is happening in some sort of rough order here, and seeing their challenges, needs, and opportunities for delight. And when you know that, then the particular product features, these UIs, control surfaces, the way the MCP works, if you’re offering that, the provenance that you ship with the responses, et cetera, these user experiences, the product outputs, the stuff you’re going to code up with your engineering team, this gets a lot easier to both see and build, and you’re not guessing as much. It will reveal itself faster because when the needs are understood, and when we’ve gone out and we’ve observed how this process works and what these different personas need, it’s much easier to figure out what the solution side looks like without just guessing.

So, that’s where I want to leave you today. If you are feeling a little overwhelmed figuring all this out, or maybe you’re not convinced that your own AI Claude or whatever tool you’re using is giving you good advice, especially advice that’s rooted in routine exposure to analytics and intelligence products, well, there’s old-fashioned organic help out there, and I think I can help you with that. So, if you need some help, head over to designingforanalytics.com/go, and you can set up a free discovery call with me. My goal is to help founders and operators like you translate your technical complexity into commercial clarity. And again, that link to set up a free discovery call with me is designingforanalytics.com/go.

Until next time, thanks for listening to Experiencing Data. If you found this episode helpful, I hope you’ll share it, drop a review in Apple Podcast if you care. I really appreciate it. We recently had 200 episodes here. I can’t believe the show has gone on this long, and I appreciate all of the great comments on LinkedIn, the occasional emails or replies to my email list, things like that. That tells me that you’re getting value here. So, until next time, take care.