A challenge I frequently hear about from subscribers to my insights mailing list is how to design B2B data products for multiple user types with differing needs. From dashboards to custom apps and commercial analytics / AI products, data product teams often struggle to create a single solution that meets the diverse needs of technical and business users in B2B settings. If you're encountering this issue, you're not alone!

In this episode, I share my advice for tackling this challenge including the gift of saying "no.” What are the patterns you should be looking out for in your customer research? How can you choose what to focus on with limited resources? What are the design choices you should avoid when trying to build these products? I’m hoping by the end of this episode, you’ll have some strategies to help reduce the size of this challenge—particularly if you lack a dedicated UX team to help you sort through your various user/stakeholder demands.

Highlights/ Skip to

• The importance of proper user research and clustering “jobs to be done” around business importance vs. task frequency—ignoring the rest until your solution can show measurable value (4:29)
• What “level” of skill to design for, and why “as simple as possible” isn’t what I generally recommend (13:44)
• When it may be advantageous to use role or feature-based permissions to hide/show/change certain aspects, UI elements, or features (19:50)
• Leveraging AI and LLMs in-product to allow learning about the user and progressive disclosure and customization of UIs (26:44)
• Leveraging the “old” solution of rapid prototyping—which is now faster than ever with AI, and can accelerate learning (capturing user feedback) (31:14)
• 5 things I do not recommend doing when trying to satisfy multiple user types in your b2b AI or analytics product (34:14)

Quotes from Today’s Episode

• If you're not talking to your users and stakeholders sufficiently, you're going to have a really tough time building a successful data product for one user – let alone for multiple personas. Listen for repeating patterns in what your users are trying to achieve (tasks they are doing). Focus on the jobs and tasks they do most frequently or the ones that bring the most value to their business. Forget about the rest until you've proven that your solution delivers real value for those core needs. It's more about understanding the problems and needs, not just the solutions. The solutions tend to be easier to design when the problem space is well understood. Users often suggest solutions, but it's our job to focus on the core problem we're trying to solve; simply entering in any inbound requests verbatim into JIRA and then “eating away” at the list is not usually a reliable strategy. (5:52)
• I generally recommend not going for “easy as possible” at the cost of shallow value. Instead, you’re going to want to design for some “mid-level” ability, understanding that this may make early user experiences with the product more difficult. Why? Oversimplification can mislead because data is complex, problems are multivariate, and data isn't always ideal. There are also “n” number of “not-first” impressions users will have with your product. This also means there is only one “first impression” they have. As such, the idea conceptually is to design an amazing experience for the “n” experiences, but not to the point that users never realize value and give up on the product. While I'd prefer no friction, technical products sometimes will have to have a little friction up front however, don't use this as an excuse for poor design. This is hard to get right, even when you have design resources, and it’s why UX design matters as thinking this through ends up determining, in part, whether users obtain the promise of value you made to them. (14:21)
• As an alternative to rigid role and feature-based permissions in B2B data products, you might consider leveraging AI and / or LLMs in your UI as a means of simplifying and customizing the UI to particular users. This approach allows users to potentially interrogate the product about the UI, customize the UI, and even learn over time about the user’s questions (jobs to be done) such that becomes organically customized over time to their needs. This is in contrast to the rigid buckets that role and permission-based customization present. However, as discussed in my previous episode, designing effective AI features and capabilities can also make things worse due to the probabilistic nature of the responses GenAI produces. As such, this approach may benefit from a UX designer or researcher familiar with designing data products. Understanding what “quality” means to the user, and how to measure it, is especially critical if you’re going to leverage AI and LLMs to make the product UX better. (20:13)
• The old solution of rapid prototyping is even more valuable now—because it’s possible to prototype even faster. However, prototyping is not just about learning if your solution is on track. Whether you use AI or pencil and paper, prototyping early in the product development process should be framed as a “prop to get users talking.” In other words, it is a prop to facilitate problem and need clarity—not solution clarity. Its purpose is to spark conversation and determine if you're solving the right problem. As you iterate, your need to continually validate the problem should shrink, which will present itself in the form of consistent feedback you hear from end users. This is the point where you know you can focus on the design of the solution. Innovation happens when we learn; so the goal is to increase your learning velocity. (31:35)
• Have you ever been caught in the trap of prioritizing feature requests based on volume? I get it. It's tempting to give the people what they think they want. For example, imagine ten users clamoring for control over specific parameters in your machine learning forecasting model. You could give them that control, thinking you're solving the problem because, hey, that's what they asked for! But did you stop to ask why they want that control? The reasons behind those requests could be wildly different. By simply handing over the keys to all the model parameters, you might be creating a whole new set of problems. Users now face a "usability tax," trying to figure out which parameters to lock and which to let float. The key takeaway? Focus on addressing the frequency that the same problems are occurring across your users, not just the frequency a given tactic or “solution” method (i.e. “model” or “dashboard” or “feature”) appears in a stakeholder or user request. Remember, problems are often disguised as solutions. We've got to dig deeper and uncover the real needs, not just address the symptoms. (36:19)

Transcript

Brian: Welcome back to Experiencing Data. This is Brian T. O’Neill. If you’re new to Experiencing Data, I help B2B, AI, and analytics product leaders remove sales and usability friction with user experience design. If you’re new to this space, and are perhaps new to realizing that usability, utility, and experience might have something to do with why customers or users either aren’t buying or they’re not using your solution very much or as you would hope they would, then I’m hoping these episodes that I record on the show now for probably seven… I don’t know, seven years, something like that, I’m hoping these episodes will help you, both the solo ones that I put out, as well as my interviews with various product and data leaders who have dealt with these challenges, both internally in internal data teams, as well as founders and heads of product and software companies that are leveraging data to try to produce value for their target audience.

So, without further ado, what’s today’s topic? Well, today I want to talk about how to design successful B2B data products for multiple user types with differing needs. This is—when people join my insights mailing list—you can hop on that at designingforanalytics.com/list—they get a welcome email from me where I ask a few questions in there just about who they are and why they joined the list and that kind of thing, and one of the typical responses I’ll get from that we’ll often cite something around the idea that I’m building dashboards or an analytics product or an AI product, and we have multiple different user types, and they all have slightly different needs, and we have some technical users, and we have business users, and they find that this challenge of trying to come up with solutions that are going to be useful, oftentimes a single product that would be useful to all of these different personas, as we sometimes use the word—I may use that word in this episode, which has sometimes a loaded connotation in some spaces, but just if I use that—the word types or personas, let’s just pretend that this is all means the same thing, but classes of users—it’s difficult. This is a hard challenge that a lot of teams face, not only teams that don’t have user experience design and research as a core discipline on them, whether you have those resources or not, this is often a challenge, particularly later on, when you know growth becomes a goal, and you might be trying to—you know, if you’re on the commercial software side—trying to move into another industry, or you’re seeing how, hey, this data product we built for healthcare could be used in financial services as well, and you’re starting to try to leverage all of your technology work to go into a new space, but you’re really dealing with a different user, despite the fact that you may see them as all kind of needing the same solution. So, let’s jump into this.

As I mentioned, this problem exists both in the commercial software world as well as in large enterprise organizations where we have data leaders that are trying to build internal data products and may have to be satisfying analysts, data scientists, business users, even downstream executives. So, I’m going to kind of address this, both on the commercial software side, as well as the internal enterprise side. Some of the points may be more or less relevant to each of those, depending on who you are, but I think you might be able to learn something from the other camp’s advice, so to speak. So, jumping in here, I’ve got about five, six, I don’t know seven, I forget how many big points I want to make here, and then just some closing thoughts.

So, jumping in here, the first one in your user research—which, of course, you’re doing some type of user research and getting in front of your customers one on one—you want to be looking for repeating patterns in terms of tasks or jobs to be done, as it sometimes called, and focus on satisfying either the high-volume tasks, things that are jobs, work, that these customers are doing a lot of, or on very high business value tasks, and ignore the rest until your solution demonstrates measurable value on these core needs. And again, just to reiterate here, we probably have some folks from the user experience design disciplines listening to this show; this episode is really meant to be for product managers and founders who may be owning all the design themselves. You don’t have internal resources, or they might be junior, but really you’re tasked with effectively being the designer as well as the product owner, product manager, or founder of your solution. So, I really want to focus this on things that you can do on your own if you don’t have those resources currently to assist you with this. So, just keep that in mind with the advice.

So again, the first one here: in your user research—which I hope you’re doing because it’s really hard to get this stuff right if you’re not actually talking to customers—look for repeating patterns in terms of the tasks or jobs to be done that they’re doing, and focus on satisfying the high volume ones or the high business value tasks, and ignore the rest until your solution demonstrates measurable value on those core needs, where measurable needs to be in the eyes of the buyer or the customer or the end-user, the person that’s going to actually use this solution. That value has to be in their eyes, not in what you think might be valuable for them, but rather they have told you or shown you with their credit card or their check somehow, that this product is meeting their needs. So, let’s go in a little deeper on this one. You just can’t do this work effectively if you have limited access to users, or even data from these users if you can’t talk to them directly. So, think about things like mining the logs of your customer service team, if you’re, like, an internal data product leader.

You know, if you can’t get access to the actual customer service reps, hopefully you can get access to their logs and their discussions with customer calls that when the customer calls in and they have a problem, you can mine this data for information. That’s kind of first party data, in a way. It’s just not coming from the minds of the actual user. But if you can’t get either of these, this is just going to be really, really difficult to get right, so you need to have some kind of plan to start getting in touch with and getting at this what we call customer exposure time on a regular basis. Again, when talking to users about their needs, you want to look for the repeating patterns of need and problem.

And this is different than hearing multiple requests for solutions and artifacts, such as I need a dashboard or a report or a machine learning model, et cetera, et cetera. Those are all possible solutions that may or may not be right, but you have your end-users self-diagnosing what they need. And so, the goal is not to go look in your Jira backlog or something, and then find every mention of feature x or dashboard y, and because there’s ten of those, then go and build that thing and then hope that it works. You need to be looking for patterns on the problem and need side. And most of the time, unfortunately, the need and problem side is not the way users and buyers tend to talk about their problems; we have to actually extract this through conversation usually and questioning. It’s not usually right on the surface, so just really learn to focus on the problem space here, not on the solution space.

I would say, as a general rule, just super generalizing here, but if I see a client with a large base of users, say they’ve got hundreds or thousands of current and/or anticipated users with this data product they’re making, I’m generally going to recommend that they optimize for user experience outcomes here, meaning giving a win to the tasks that the majority of these users need. So, contrary to this is that it might mean that the management or executive users are not going to have a great user experience, at least initially, with this application or tool or solution, but the large volume of users who do share a common problem, jobs to be done, or tasks will have a great user experience because, in aggregate, the business value of all these people’s lives being improved with your solution ends up adding up to some significant value. So, this may mean that your solution may be a little bit more task-oriented, or doing things like making these users’ jobs easier to do, and things like this. On the opposite—the flip side of this is that if your product’s intended audience is smaller, such as if I was advising a startup trying to find product-market fit where your buyer might be someone fairly senior in an organization, they’re only going to use the solution on a periodic basis, and they are the actual user as well, then I might generally recommend that you’re going to optimize the design for use cases that are going to demonstrate the business value of the solution as quickly as possible. So, for example, this might mean, like, in a dashboard or analytics product, there’s an excellent 10,000-foot view, but from an individual contributor’s perspective, the application may not provide as much actionable advice for those people.

So, if it’s, like, sales, then imagine the sales manager is super delighted here, but the actual salespeople that are out there hitting the phones and doing all of that LinkedIn outreach, or however they sell, they may not find a lot of value in this application, at least initially, or this data product. So, we have to optimize for something here, especially when we’re lean on resources. So, that’s really the key. The key idea here is we need to narrow the problem space down and try to produce an outsized value for the highest value and volume needs, versus trying to throw a little design dust in everyone’s direction and hoping that we’ll put a part-time, you know, data viz developer on each product, and they’re just, kind of like, you know, smooth out the edges and this kind of thing across everything that goes out of the engineering and data science team’s portfolio. That’s not the direction I would recommend that you go.

The good thing is, is that chances are, a handful of use cases may comprise the majority of your need, and your job is to satisfy these needs well before going wide and trying to satisfy more use cases or personas. This also goes for data platforms. I understand the purpose of platform products and this kind of thing, and oftentimes they’re being built to support a large number of possible use cases; I still think that the same thing remains. The platform is useless if it does a little bit of everything for everybody, but it’s really difficult if the goal of the platform is to stand up a product on top of it, for example, if it’s really hard for the most urgent product developers who are going to use this platform to actually stand up their product because it does a little bit for every possible scenario, the platform really doesn’t have a lot of value. I’d still rather you overinvest a little bit in the bias of what a few people need that have a common problem space, and then later on, start to widen the scope of that solution and potentially make it more complex in order to satisfy more users.

The one big point, kind of, closing thought on this one, is that when you test your design or prototype or the product iteration, you still need to test with real people and validate your designs with real users. Even if you can demonstrate how logical your solution is for these benchmark use cases or jobs to be done that you identified in your research, humans are fickle [laugh], and also they’re the only ones with wallets to spend money on your product, and free will they decide what they will and won’t use or pay for. So, even if we did the analytical work here of being really disciplined about the problem space we’re going to attack, you still want to bring in the messy humans to actually validate this, and not assume that because we narrowed the problem space, we have therefore created a product worth using and paying for.

Number two here: when trying to balance simplicity with depth of evidence and data, you want to design for what I would just say is mid-level domain and technical knowledge, but only after you’ve identified and delivered clear, obvious value to the user that it’s worth sticking around for. So, the general idea here on this one is that if customers can observe and feel the value of your solution early on, they’ll be more invested in whatever struggle or investment may be required to get even deeper value from the solution. So again, when you’re balancing making it easy to use, but you also want to—and this is particularly true with the analytics products where there’s all this evidence and drill-down data and detail that you theoretically could go in for—you want to focus on this mid-level domain and technical knowledge here, but you first need to make sure that you’ve done number one, and identified a problem that you’re delivering outsized value on in the current solution.

While your product honeymoon experience is—what I call the honeymoon experience, the thing that happens right after people get their hands on it or they’ve made a purchase, I call this the honeymoon experience, and it usually lasts a few weeks—while it’s really important to get this right, for many dashboard applications and B2B, like, analytical data products there may be a lot of depth and detail that the solution could go into here. And if you’re finding it hard to even just get into, like, what’s the first step that I need to take, step by step—I do have a framework for this called CED. There’s been an episode on this show about it. I forget the number, but if you go to designingforanalytics.com/ced you can read it there, as well as get a link to the podcast episode where I go into that, but this will help you with the foundational ideas of designing for C, which stands for Conclusions, followed by E, which stands for Evidence, and then D, which stands for the underlying Data and how we progressively disclose or do not disclose this type of information to users in order to deliver the value that they seek.

A little bit more on the mid-level domain technical knowledge suggestion here, what do I mean exactly by that and why is it mid-level? The general thinking here is that with more complex B2B applications, particularly in the data space here, the idea here is that a lot of these things are not going to be walk in, do a task, leave and you’re done. These are not transactional applications. They tend to require thinking, decision making, slow and fast thinking. The human experience is a little bit mushier than it is with highly transactional types of applications, and trying to overly simplify these things can actually just be misleading because, as you all know, data and all the things that we can capture with data and then present back to users, it’s a complicated space.

Life and business is really complicated. Problems are often multivariate. On top of that, we don’t always have all the data that we need, or the data could be in bad—you know, poorly formatted or not in all the dimensions that we need it to be. These are just complex spaces, and so the level of intervention a user may need to do to get deeper value is generally higher than it is with more transactional types of applications. So, I’d rather see a little bit of initial friction, like, even if the very first touches with the product feel like they have a little resistance.

Like, if you were to run a usability test, you might say, well, the users, they did manage to accomplish the task, but they said they vocalized how difficult it was to get through it. I would probably call that a win if your product has some real depth and the potential for value is really high, so long as they actually were willing to push through that friction in order to get the value. Now, I would love it if they didn’t have that friction at all, but for more technical products, sometimes there is a friction because the reward takes some investment up front. What you can’t do is use that as an excuse for not doing any design work at all because, ultimately, the design of the solution is really your problem. It’s your fault, [laugh] unfortunately, if it’s bad and not working.

It’s not the customer’s fault. It’s our fault as product people to get this stuff right. So, a little friction is okay. I do want to make sure that people can actually accomplish the task that they’re doing if I was to run a study with them and ask them to perform tasks that the product is supposed to solve for, but I’m okay if there’s friction there, as long as they’re ultimately receiving value, a reward, they’re feeling a sense of ROI after that investment. And this allows us to try not to artificially overly dumb down something that effectively, really can’t be overly simplified in the first place.

There is such a thing as trying to oversimplify things, and what we do is—I’m sure some of you have seen this—adding data sometimes adds clarity, and often you hear like, oh, there’s too much noise, and we don’t want all this noise, so let’s remove some of the information to make it really simple to use. But sometimes adding information is what makes something more clear from a user experience perspective. So, as I said, this stuff is difficult to do, especially if this is not your full time job, but I’m hoping that you can take the general premise here and run with that and still deliver some value.

Moving on to number three, if you have regular contact with users in the form of one-on-one research and you’ve clearly identified that there are a handful of distinct user types that each have distinct needs, then and only then, you can consider implementing role-based permissions here as a way to simplify the UI in the UX. Just remember that users often don’t fit into rigid buckets, and so in some ways, your UI design overhead may actually increase because now, when you think about designing your workflows, and your UIs, and your dashboards, and all this stuff, you’ve got multiple different modes or personas, or again, literally, what we often call role-based permissions, to deal with in there. So, you are simplifying for the user, but you’re also making something more complex for a team that may not have, again, those UI and UX design resources on it to actually spend the time to think through all of this. So, that becomes on your shoulders, unfortunately. So, just let me get a little more concrete idea here so this is not too abstract.

A general idea might be that you have, again, say this sales manager has a view of the application that’s different than what the sales team members, the individual contributors, might need, or you might have a data scientist who needs deeper access to raw data than an analyst or a business user, even though they’re looking at the same kinds of information here. So, we might create role-based permissions, kind of based on their job title there. But you don’t have to do it on job title either. You could do this by functionality. So, for example, you might have a permission setting which you set whenever you onboard a new user into the product that has something to do with, like, how deep can they drill down into analysis, for example, or into the deep E screens, the evidence screens, as I call it in my CED framework.

Why would you do this? Well, think about something like the debug mode in your web browser. You might only allow access to that menu option when someone has that switch toggled on in their profile. And maybe they’re able to toggle it on themselves, and you set the default when they onboard there that it’s off for a business user, but if they want to turn it on, they can. And so, the reason we want to do this on a, like, a feature basis here is because of that problem that our users often don’t fit into these rigid buckets, and so you might have, like, a salesperson who happens to, you know, maybe you’re selling a technical product and they used to be a software engineer or a data analyst, so they’re able to actually make sense of some of the deeper functionalities that your product has, even though the average—I kind of hate using this word, the average—but your typical individual contributor sales person, does not have that capability or they don’t have that skill set in order to know what to make of all the information.

So, you might also want to control access to when we talk about this, like, Evidence data, this could be things like different types of filtering controls, or different depths of being able to drill down. And why would you want to hide that? Well, it may be such that because you don’t have the resources either on the technical side or the UX side, that as soon as you go into the deeper domains of your product, you’re really into, like, the engineering views. Which I’ve often seen this before with our very early stage products, where the UI actually kind of emerged as a debugging tool or a tool to visualize what was going on within the system, and it was being used by the engineers or developers, and slowly that started to morph into what the team thought might be an interface for actual end-users. And so, if you know that it’s highly biased to your own team, and it’s really not—it’s something the users could shoot themselves in the foot with, or they’re not going to understand the jargon, or things like database field names don’t map to logical business objects, and so they’re not going to know what field WX_317 is actually ‘Customer ID’ in their lingo, but that’s not how it was stored in the database because the field name was auto-generated by a piece of software, and so unless you’re highly technical about the data domain, you would never know what that means.

And as a product leader, you may realize I know that’s a weakness in my product, so I’m going to disable this stuff unless I know that the user is not going to shoot themselves in the foot here if I give them access to this. Other examples of restricting features can be around things like, which model can you use when you’re running a forecast, for example. I’m sure you’ve all seen the foundation model providers of LLMs like Claude and ChatGPT, and they have this little drop down under the prompt box where you can choose which model you want. And they might give you one or two words, like, ‘generally the fastest’ or ‘overall best at reasoning, but slower.’ They’re trying to make it clear what the differences are between these models, but unless you’ve really done a lot of homework, it’s really hard to know which one to pick, and it’s a lot of overhead to go redo all of your prompts using all the different models they have, and then try to make sense of which answer is correct.

Now, there are people that may understand that within your business context, and so giving them access to that may make sense, but if you don’t want to have a flood of inbound customer service requests or people complaining they don’t understand how to use it, you might shut that off until you can give that part of the product more attention. And so again, this is more of a feature-based set of roles and permissions that you would smartly, you know, enable or disable based on the profile of the person coming in, instead of saying, “This is data scientist mode,” “This is salesperson mode.” Those sound really nice, but again because of the nature of people, and not fitting into rigid buckets, you’re probably going to find these exceptions where people sit in the cracks, and it’s kind of hard to know what to do there. But the main point here is we can filter the product down to make sure we’re not doing any damage with it, but we are letting people who—advanced users to get access to things that they may find valuable, even though they’re in the minority there. So, it’s a way of designing for these multiple users without overly complicating the product for everybody.

Number four here, in lieu of this route with the roles or feature-based permission, there’s another option here, which is to leverage AI and/or large language models in product. And what do I mean by this? Well, to allow learning to happen by the user in the product, and to progressively hide and show functionality, or even change functionality and UI based on need, at the time of use, or because the UI is adapting to a customer over time and the types of usage that they’re demonstrating within the product, as captured by your products analytics. So, if you have good data and metadata, probably enhanced with things like knowledge graphs, you may be able to leverage an LLM to, say for example, provide really good explanations of different visualizations, for example, or insights or concepts in your product that might not be immediately understood. And in addition to simply explaining these or allowing people to interrogate visualizations there, you might even allow the user to change the designs of some of these and say, you know what? Like, limit the scope to United States only because I’m only doing sales in the United States; I don’t need the global view here.

And so, these customizations can kind of be happening, in context, in the product at the right time, as opposed to making these, like, profile settings that either the customer has to go through in a, like, kind of a survey format, or you have to know all this information up front and set it before they get access to the tool here. This one is really on the—I almost didn’t want to include this one because my feeling is probably you’re going to need a designer or a researcher to help you. You may need someone to really help with this, and the reason why is, as soon as you start sticking, you know, AI—which broadly I’m referring to GenAI here, and particularly the large language models as it relates to business applications—you’re also potentially creating what I call hidden user experience taxes that someone has to pay. And these taxes are not always going to be really obvious to you on the surface. So, you’re getting value—you’re—theoretically, in the short term, you’re getting some value by having some of this capability built in right into the product experience, but then there are these taxes that you also have to pay, and the taxes aren’t always obvious here.

So again, these things all lie in a spectrum, and it really depends on how much you’re investing in that, versus kind of dabbling in it, but it’s just something to be aware of. I think episode 164, the prior one to this episode you’re listening to right now, is the one that I go really in-depth on what I think these UX taxes are that LLMs can impose on your customers here. Another problem just to be aware of with this route here is that you need to start being aware of what we call state management, for example. And this is where understanding—you don’t want to get into this very widget-based dashboard design mentality where the user is basically seeing every widget as a discrete object, and so they’re kind of bouncing back from looking through a straw and seeing this one widget versus looking at their entire scope of their problem, which might mean looking at the entire screen, or looking at various workflows, or drilling down, drilling back up, et cetera. The challenge here is that when you start adding AI in here to interact with the product, it’s not always clear what is the scope of the AI’s knowledge about the user experience.

Like, when I said I only wanted to talk—I only wanted US data, well, did that request stick in my session or with my profile? Does that mean every screen and experience that I touch in the product is now going to automatically filter for US-only data? Or did that only exist within the scope of this one widget? Like, this starts to get really complicated. Again, these are one of those taxes I was telling you about. It’s not always clear what the AI knows when we start putting an interactive widget there that seems to be listening to what we’re asking for and remembering this stuff; it’s not always clear what is actually being remembered.

Number five, invest in new rapid prototyping solutions, which include AI but also your paper and pencil, for example, such that you can actually validate whether or not a single interface or UX solution for your data product may actually sufficiently satisfy the span of users that you have. It’s easier than ever to shorten the design to development gap right now. Like, spinning up prototypes quickly has never been easier than it is right now, and this means that you can spend less time doing design to development work, and more time actually rapidly validating design choices and prototypes as you go through the product development process. Even though there are AI tools that can help write code and build prototypes, don’t forget about the power of whiteboards, you know, whether the digital or literal, sketching by hand. Working in very low fidelity in order to get feedback quickly, you really want to be eliciting feedback as fast as you can here because ultimately, prototypes, especially early ones, I want you to think about your design prototypes early on as actually a prop to clarify the problem space further, and not necessarily as, hey, here’s my design. Is it on the right track? I’m going to go do some research with my customer to see if my solution is on track.

So, in other words, I want you to have a bias towards remaining in the problem validation space mentally before being too deep into the solution space. And if you’re technical, if you come from a data background or an engineering background, we tend to jump into the solution space and want to be—you want to live more in that building and solving the problem kind of space, so you need to counter that bias and be suspicious of your own work. Keep that concept in your head that my prototype here is throwaway. My prototype here is to get people talking. My prototype here is to figure out, am I actually solving the problem that they need to have solved? Even if the design is wrong, am I getting feedback about it? Am I hearing whether or not they’re connecting their problem to this potential solution that I’ve shown them? You need to stay biased towards this problem space.

And fast prototyping means faster learning cycles, and so product leaders and founders should really always be on this race to increase their speed of customer learning. This is how innovation happens. It’s like, how many experiments can you run? How fast can you run them? Where an experiment can be, hey, where I’m going to sketch out or prototype out this new feature functionality, and I want to see how fast I can get feedback on that. So, design artifacts are just one way to help doing this; it’s just you do need to know how to interpret the feedback you’re getting when you’re using UI designs or sketches as props for problem research.

Number six here—this is the last one, and then some, just some short conclusions—but number six: a list of five things that I don’t recommend doing when you’re designing data products for multiple personas or users. So, let’s talk about the things not to do from my—this is just my personal opinion, but the first one, giving customers a blank slate from which to customize your solution because you think, well, since we can’t possibly satisfy this for everybody, we don’t want to bias anybody here. Like, let’s just give them a blank slate to start with. There are exceptions to this; I’m not going to talk about those right now. I’m just going to generally advise you not to do this because what you’re doing is you’re effectively forcing the customer to become the designer of your solution.

And the irony here is that if you feel like doing the design work yourself is hard enough because design lives in this kind of gray area a lot of the time—it’s not highly analytical work, it’s gray area work—if you feel that’s hard enough, guess how hard it is for your customer and your user to do this work, particularly if they’re not in the product development space, that’s not what they do for work, like, if they’re an attorney or something like this, imagine how hard it is for them to do this work when it’s hard enough for us to get it right, right? So, that’s the first one. Second one, distributing your efforts widely and shallowly across many competing users’ needs. So, we talked about sprinkling your little bit of design resource across all your different features and products that you have in your portfolio in an effort to try to polish it up in the last minute, and hope that little polish is going to be the thing that creates buyers and makes users use more.

The third one: prioritizing competing needs by looking at the number of requests for solutions coming in, versus looking at problem frequency. So, we kind of talked about this a little bit earlier, but this is again, that idea that if ten people ask for the ability to control certain parameters of your machine-learning forecasting model, and you decide that you’re going to give them that control because they all asked for it, but what you didn’t do is you didn’t actually uncover, why do they want to control, like, lock certain parameters in the model there, and then have the other ones, you know, float dynamically when they run the forecast here. The reasons for those requests may be really different, and so simply giving them control over—let’s just give everyone control over all the different model parameters, and then that way, we’ll cover all the bases here. You may have just pushed a tax, a usability tax, back onto the users because they now have to decide, well, which model parameters should I be leaving fixed, and which one should I allow to float and play around with when I run my forecast there because you tried to make the solution generic enough for all these different user types here. Again, you need to understand the problem frequency, not just the solution frequency. And a lot of times, problems are vocalized or written down as solutions. Sometimes these are called presenting problems; we need to get past the presenting problem and get to the actual underlying need.

The next no-no here, letting loud and noisy customers—or proxy users—dictate your product’s direction, unless you’ve really invested in the skills to properly surface signals from these proxies. I do think proxies are better than nothing at all, if you literally cannot get access to end-users. That’s usually a bad sign, though, if you’re in the commercial software space. If you can’t get access to buyers, you probably don’t have a good product. It’s just, the market’s telling you something.

In large enterprise organizations, this can be more political reasons why you can’t get access or power status, perceptions about your team’s value, whether it’s right or wrong, people blocking you from getting access there. But an example here would be, like, the manager of the customer service team wants to be the interface to you for this data product you’re building for that person’s team, but they won’t let you actually talk to people who do answer customer calls all day because they used to do that job, and now they’re the manager of that department, and they feel like they can represent these end-users for you. So, you don’t need to be taking their time up, and how could you possibly only talk to three of them when they have a team of three hundred people answering credit card-related customer service calls? You know, I’m going to be a much—I’m just role playing here—I’m going to be a much better resource for you because I used to do this work for ten years, and I know what all three hundred people are doing, and I can speak much more broadly than you’re going to get in five or six interviews here. There are ways to navigate these conversations, and a good researcher can still get some signal from forced proxies; this is not a really reliable way to build products without a lot of debt. You’re more likely to over invest in the wrong solutions, and then you’re going to keep finding out that you’re not really nailing it when people just don’t use it, or there’s general apathy when the product goes out the door here.

I’m not picking on, you know, customer service teams, or, you know, sales teams, where there’s, kind of like, a blocker here. This person can still be a really good resource for your team, and in particular, I’m actually using both salespeople and customer service people when we’re building products. If your product is in that space, these can actually be fantastic allies, or what we call design partners in the design lingo. They can be fantastic partners for giving us customer insights that are additional to the horse’s mouth, so actually talking to the real end-users here. We just don’t want to let these noisy proxy users dictate everything and assume that that’s going to tell us what we need to do. It’s just generally not very reliable here.

And the last no-no today on the list is particularly for startups and founders. I’ve seen this a few times on some of my consulting calls, in particular with MIT Sandbox—actually not just with Sandbox, but with prospects and clients I’ve talked to as well—there’s sometimes a perception that, hey, we’ve stumbled on this thing that machine learning and AI or analytics can do, proprietary data set, or algorithm, or they’re using publicly available data in a way that no one else has done before, and they start to imagine all these potential market use cases for them that could range across all these different industries. So, let’s imagine something like you’re putting out a software product that’s in the data governance space or something along these lines, or data management space, and in your mind, you could see, having worked in many industries, probably, at some point in your career, that, hey, this could be really applicable to finance as well as healthcare, and education, and manufacturing, and on, and on, and on. And so, you abstract out parts of the design in your solution sufficiently so that you can try to address all these different user types using some kind of consistent language, and generally a user experience strategy that’s about being an umbrella product to all these different markets.

And the challenge with this is that even though, like, there probably are data governance standards, and there’s data management standards, and there’s best practices to follow on things like that across industries, it doesn’t necessarily mean that the urgency to solve the problem that your product promises to solve is necessarily the same across all those industries. So, for example, maybe there’s heavy regulation in one industry where you need to have audit trails, and you need to have whatever, like, you’ve got to be able to justify all the decisions you’ve made with your data in the past, and this kind of thing, whereas in this other industry, nobody really cares too much about what happened two years ago or a year ago. It doesn’t really matter, except in, you know, building out your models to do forecasting and things like this, but the urgency of that problem isn’t the same in industry number two. And so, when we approach this with the idea that I can imagine why someone would want to have this because it solves X, X isn’t necessarily high on the list, or urgent, or maybe even as expensive in one industry as it is in another.

So, we need to be conscious about who we’re designing this for, not abstracting out our product too soon. We want to make it domain specific, we want to make this data product amazing for our audience, for this discrete audience, before we start to widen the scope of how many users we want to address with it, or industries, if you want to look at it that way. The point is, you got to narrow first, and you got to do a bang-up job with the narrow, smaller audience first so you get some of these wins before you go back and try to satisfy additional user types. So, this is kind of a complex topic that also gets into product positioning and marketing, and it’s a little more for the software founders out there than our product management people, but I’ve seen this problem of abstraction quite a bit. It often comes with technical founders who don’t want to develop too narrow of a solution because they don’t want to rework the code later on, and so they start thinking in terms of all these abstractions early on so they can future-proof things. And the problem is, like, you can actually work against yourself because sometimes that manifests itself as friction in the actual interfaces and user experience.

So, that’s the list, the to-do’s, and the no-no’s—the not to-dos—on how to design successful B2B data products for multiple user types with differing needs, just kind of high-level conclusions here for you. You know, over time, you want to turn your demonstrable wins, these shows-of-value into justification for more investments of resources, which could be higher prices, money from stakeholders who are funding your initiative, or even just getting more time, or face time with customers and stakeholders because they’re starting to see the value of what you’re doing, and they’re starting to have an investment in what you’re doing. And when you start to have those wins, it’s easier to get those walls to come down a bit, and then you can start addressing some of the secondary users who haven’t gotten as much love in the first releases or rounds of your work and that type of thing. So, by focusing on user experience outcomes, which again, is how have you made a specific person’s life actually better at work—because we’re talking B2B here—but how have you made their life better a little bit with your solution? Well, by focusing on that, you start to have a compelling story to tell, and that story, it’s harder to ignore when you’re going up to your stakeholders or whatever, and you’re saying, “Look, here are the facts.” Like, “Hey, John and Jane in marketing, like, they’re singing the praises of this thing. This has completely changed how they fund their marketing campaigns and ad spend. They’ve never had access to this kind of data. Look, you know what they’re telling you because they’ve told me, they’ve told you about this, and so we need some more investment to go do X, Y, and Z, and help the sales team now that the marketing team is really excited.” So, you’re building this trust that your team can actually deliver on some outcomes here and not just push outputs out on a schedule.

And the final thing on this conclusion is that I know that there’s always politics, especially if you’re in a large organization and you’re doing the internal data product game, saying no is also a gift. Saying no that if you’re able to do that in your position, and say, we’re not going to try to address all these different users because we’re fairly certain we don’t have the resources to do that well, and what we’re going to incur is a bunch of sunk cost. We’re going to have all this technical debt to carry forward, and we’re pretty sure that you, dear stakeholder or customer, you’re probably not going to want to use this or fund more of this in three months when we come back to you and tell you, “Hey, this isn’t working like we thought.” So, we want to say no right now, so we can double down on our yeses and produce some real value for this specific audience over here.

And there’s true empathy in that because you’re saying, “I don’t want to take your money and waste it,” if you’re talking to, you know, a stakeholder who’s funding your initiative. You’re being candid by saying no and you’re being empathetic that you want them to have a positive outcome as well. So, saying no can also be a gift here. Sometimes you just have to stop trying to satisfy everybody just because they’re noisy.

Anyhow, that’s today’s episode. I hope this was useful. Again, if you’re interested in these kinds of insights, if you like to read instead of listen sometimes, I do write a weekly insights mailing list dispatch. Every Tuesday it comes out no matter what; I don’t go to bed until I release on Tuesday. Sometimes it’s Wednesday morning at two in the morning; I still count that as Tuesday night because I didn’t go to bed yet. But seven years—eight—actually nine, I don’t know, nine years now, I haven’t missed a week, so I guarantee that will be in your inbox every single Tuesday. Head over to designingforanalytics.com/podcast, and you can hop on the list there. Anyhow, that’s it for now. Stay tuned in a couple weeks for the next episode of Experiencing Data.