Episode Description

Sometimes DIY UI/UX design only gets you so far—and you know it’s time for outside help. One thing prospects from SAAS analytics and data-related product companies often ask me is how things are like in the other guy/gal’s backyard. They want to compare their situation to others like them. So, today, I want to share some of the common “themes” I see that usually are the root causes of what leads to a phone call with me.

By the time I am on the phone with most prospects who already have a product in market, they’re usually either having significant problems with 1 or more of the following: sales friction (product value is opaque); low adoption/renewal worries (user apathy), customer complaints about UI/UX being hard to use; velocity (team is doing tons of work, but leader isn’t seeing progress)—and the like.

I’m hoping today’s episode will explain some of the root causes that may lead to these issues — so you can avoid them in your data product building work!

Highlights/ Skip to:

• (10:47) Design != "front-end development" or analyst work
• (12:34)  Liking doing UI/UX/viz design work vs. knowing
• (15:04)  When a leader sees lots of work being done, but the UX/design isn’t progressing
• (17:31) Your product’s UX needs to convey some magic IP/special sauce…but it isn’t
• (20:25) Understanding the tradeoffs of using libraries, templates, and other solution’s design as a foundation for your own
• (25:28) The sunk cost bias associated with POCs and “we’ll iterate on it”
• (28:31) Relying on UI/UX "customization" to please all customers
• (31:26) The hidden costs of abstraction of system objects, UI components, etc.  to make life easier for engineering and technical teams
• (32:32) Believing you’ll know the design is good “when you see it” (and what you don’t know you don’t know)
• (36:43) Believing that because the data science/AI/ML modeling under your solution was, accurate, difficult, and/or expensive makes it automatically worth paying for

Quotes from Today’s Episode

• The challenge is often not knowing what you don’t know about a project. We often end up focusing on building the tech [and rushing it out] so we can get some feedback on it… but product is not about getting it out there so we can get feedback. The goal of doing product well is to produce value, benefits, or outcomes. Learning is important, but that’s not what the objective is. The objective is benefits creation. (5:47)
• When we start doing design on a project that’s not design actionable, we build debt and sometimes can hurt the process of design. If you start designing your product with an entire green space, no direction, and no constraints, the chance of you shipping a good v1 is small. Your product strategy needs to be design-actionable for the team to properly execute against it. (19:19)
• While you don’t need to always start at zero with your UI/UX design, what are the parts of your product or application that do make sense to borrow , “steal” and cheat from? And when does it not?  It takes skill to know when you should be breaking the rules or conventions. Shortcuts often don’t produce outsized results—unless you know what a good shortcut looks like.  (22:28)
• A proof of concept is not a minimum valuable product. There’s a difference between proving the tech can work and making it into a product that’s so valuable, someone would exchange money for it because it’s so useful to them. Whatever that value is, these are two different things. (26:40)
• Trying to do a little bit for everybody [through excessive customization] can often result in nobody understanding the value or utility of your solution. Customization can hide the fact the team has decided not to make difficult choices. If you’re coming into a crowded space… it’s like’y not going to be a compelling reason to [convince customers to switch to your solution]. Customization can be a tax, not a benefit. (29:26)
• Watch for the sunk cost bias [in product development]. [Buyers] don’t care how the sausage was made. Many don’t understand how the AI stuff works, they probably don’t need to understand how it works. They want the benefits downstream from technology wrapped up in something so invaluable they can’t live without it.  Watch out for technically right, effectively wrong. (39:27)

Transcript

Note: this episode is also available as a shorter article here.

Brian: Welcome back to Experiencing Data. This is Brian T. O’Neill. Today I’m rolling another solo episode for you, specifically those of you who are working in tech companies, if you’re a founder of a B2B, a SaaS analytics company, if you’re selling insights for business workers and that type of thing, or if you’re at an AI startup, anything in the intelligence space, decision support that type of thing. When people like this, often they’re founders, sometimes they’re heads of product, occasionally, if it’s an engineering-driven company, they’re sort of the de facto head of product, even if they have a technology title, doesn’t really matter, but it’s the person who’s trying to make sure that the product is useful, usable, and valuable, and occasionally you figure out that DIY product and user experience design is not working.

So, this can be in the form of understanding that dashboards or user interface components are more complicated than they need to be, or customers are complaining about it, or you might have a slightly higher elevation, which is kind of the UX lens, so you can tell that workflows are not intuitive and people don’t know how to fit the product into their existing work environment, for example. You’re seeing a little bit more of a higher level, holistic look at how this product is fitting into a user’s life, and you could see that something is wrong with that. And a lot of times, teams try to tackle this themselves. They have someone on the technology side. It could be an analyst building dashboards, or a developer who’s doing all of the UI design, as well as the front-end work, or it can be the founder themselves who’s the de facto head of product, and also doing all the interface components, and maybe they’ve hired someone to do some visual design to support their sketching and wireframing and that kind of thing.

At some point, though, when someone gets on the phone with me, and they’re realizing the DIY thing is not working, there are often some signals I get, some repeated patterns that I hear, some things that these founders and product leaders, frankly, are getting wrong about product and user experience design. And so, I wanted to talk about some of these so that you can become more self-aware, the stuff that you don’t know that you don’t know, that if you did know it, it might actually help you get ahead with your product, whether that’s getting outside help from a trusted person, or hiring internally, or just doing better work yourself because you’re more knowledgeable. So, let’s jump into this.

So, what happens? When I get in a call, well, it’s a new prospect, right, and they know they need some type of, again, we talked about dashboarding, or user interface design, or just a user experience thing, and this DIY phase has not really worked out. They’re not getting the results that they’ve been looking for. And it might be that they’re not seeing the results quickly after feeling like they’ve been doing a ton of work on this. There also could be internal debates about what’s best for the user, and we have all these different ideas.

And particularly in the enterprise space, we might have a rather complex product that needs to service a lot of different—I’m going to use the term personas here, but different types of users who have different types of workflows or demands on the product. That’s often a challenge in analytics, particularly, like, if you have someone who’s strategic that’s only going to receive the insights from this product, but may never actually log into the service, whereas you might have a more day-to-day type user who’s in there all the time, this can pose challenges, right? Another challenge might be that there’s a loud opinion or voice on the team about design that may need to be checked, and they feel like we don’t have an internal person to kind of help them break that deadlock because there’s this loud voice. And maybe that loud voice is you, and maybe you feel like you need to get some outside perspective on this because you’re not a designer, and that’s not what you—you’re feeling the pain of having to carry that weight on top of everything else that you’re doing. And there’s also this person sometimes that is coming in because they’ve already gone through all this stuff in the past at a previous company or at a previous project, and this time, they’ve learned it’s faster and cheaper to do the design work at the beginning of the journey instead of waiting until the end.

So, these are all, like, the initial kinds of, like, signals or situations that can be going on. And I want to say that all of these things are okay because it shows growth when somebody raises their hand and says, “I know we need to get some outside help here. All this internal stuff is slowing us down. We’re trying a lot of stuff. We’re generating a lot of outputs and artifacts and design stuff, and we’re building it, and the vision isn’t coming out. The value is not becoming self-evident. We’re doing stuff, and it’s not working.”

And so, that you’re at that point where you’re realizing it’s time to get some outside help. That’s good. It shows growth. And I think we all know when we’ve hit that before, whether it’s with a digital project of some kind or something in real life, we probably know when it’s time to get that outside help. And I imagine most of you have done DIY projects at home, like yourself. And you know, we have YouTube and all these great resources to give us so much information, but the challenge is often not knowing what you don’t know about a project you’re doing or an initiative or something like that.

And the not knowing manifests itself in the form of taking a lot longer to get results, and often you can then spend up more money, both in terms of your labor, whether you’re paying someone to do or your own time, which is probably worth a whole lot to you if you’re a busy person, like most of the people that I talk to are, that costs us a lot. And then there’s, of course, materials and all that kind of stuff, right, and sunk cost, et cetera. But why does this take us longer? Why aren’t we getting better at this, doing it ourselves? Well, one reason is that we often end up focusing on building the tech and following this often agile-related mantra, which is, get it out there so we can get some feedback on it.

The thing is, getting feedback quickly isn’t really what the goal of doing product well is. And I see design as one of the stools—one of the legs of the stools of product. It’s one of those support [tillers 00:06:53]. You have product management, you have technology—engineering, usually—and design. And sometimes we have this fourth leg called data science. When we’re talking about AI in particular, but also in advanced analytics, we may have a separate that engineering technology leg into two.

So, we all support this game of product. But product is not about get it out there so we can get feedback. The goal of doing product well is to produce value, or benefits, or outcomes. That’s the real game. Yes, learning is important, and I love the idea of getting things out there and learning if they’re working or not, but that’s not really what the objective is. The objective is benefits creation.

I think Marty Kagan, who’s been on this show, he has this framing of time to value as one of the, kind of, the games of product management, and I really like that. And if you accept this framing, then you realize that shipping the technology artifact to the customer is the beginning and not the end of the game, right? It’s the beginning. So, you don’t really get any points for simply shipping the tech. The points in the game come when the price the user is paying in their own dollars or their time is lower than the value that they’re getting out of the product. That’s when your solution is going to be seen as being valuable, right?

So, for your business, this can be all sorts of increased KPI metrics, and for actual end-users, it means, did we make this person’s life, this user’s life, better by doing fill-in-the-blank? And the latter can be measured, but most founders and product leaders can only define the business metrics, the additional sales revenue they want to capture, the increased product adoption or reach, or maybe they want more seat licenses sold, or they want to see an attrition number go down. However, the user’s life being improved is inherently tied up in all of this. And this is one of the key messages that I try to, when I’m talking to prospects and they’re wondering, do I really need to invest in this hand-wavy UX/UI design stuff, what do I get for that? Well, again, the user’s life being improved is inherently tied up in all of these business KPI metrics that I just mentioned.

If they’re not buying, they’re not renewing, or they’re not using, then the humans in the loop, whether it’s the buyers or the end-users, are simply not getting the value. And even if the buyer upstairs, maybe you sell into the C-suite, you know, they buy into all the theoretical gains that your marketing and your sales team, when they finally got that lead and got into the sales conversation there, this is still true, and if they bought into all of that because then you have the problem of renewals, right? And if no one’s using it, then best case, you’re hoping that nobody notices someone’s using it, but that’s not really a business strategy. That’s just a ticking time bomb, and that’s not a way to get ahead, right?

So, where might things have gone wrong for you when you try doing your own product or UI and UX design, and you had someone that wasn’t necessarily trained in doing that, and you created a whole bunch of stuff, and you shipped some things out, but you’re not getting that traction. What is going on here? What do I hear on calls? What are the common things? Well, let’s go through them. I picked out ten of these things. I don’t know why ten. I just—I didn’t want to stop at nine. I got to nine, I was like, there’s got to be anoth—ohp, yeah, there’s another one. So, here are ten things I often see or hear when I get on these calls with you, dear product leader or founder [laugh]. Let’s jump in.

The first one is that you might see this whole design thing—whether you call it UI or UX or DataViz, blah, blah, blah, it doesn’t really matter—you see this as something that is part of the role of front-end development or something an analyst can do. And often if the word is ‘dashboard,’ then a lot of times it goes with analyst, unless you’re in a tech company, and then it’s ‘front-end development.’ And there’s these pairs that happen. After all, you grabbed a—you or they—grabbed a UI, like, a design library that’s built with all these free, decent-looking JavaScript CSS components. And hell, what are you paying this person for, if not for that, this front-end dev or this analyst that’s supposed to be cranking dashboards right?

Well, what you didn’t see is that you’ve been asking the team to go, go, go, to go faster—and I hear this all the time, we got to move fast—and fast usually means shortcuts are taken, and it means developers don’t want to customize stuff, and they don’t want to deal with one-off components that sit outside of the framework they chose. And they chose that, why? Well, you said that speed was really important, so we don’t have time to roll our own stuff, right? They’ve been tasked to build the front-end. Build the front-end.

So, when your home has a remodeling project and the builder shows up, what might their reaction be when you ask them to come up with some blueprints first? And you expect these blueprints to both be good, in service of your business goals, and of course, you, as the person paying for this or taking ultimate responsibility for the product value also wants to like the design. You want to feel confident in it. So, that’s number one. You see this design job as something that’s part of the role of front-end development.

The second one, you have a developer, or an engineer, or maybe a junior designer who really likes doing this type of design work, but they lack the skill to do it well. The problem is nobody on the team actually knows there’s a skill gap because this person that likes doing it happens to be the best one on the team. They have the best skills. So, it’s really hard to understand what the skill gap is because they’re the best one you have. So, while the interest might be better than having indifference, speed is still the driving metric the team is often operating on. Speed to deliver sprints and outputs and releases and features on a schedule.

But the thing is, you really don’t know if they’re doing it well or not, beyond your own personal opinion about whether the design is, quote, “Good,” so it’s mostly going to lead to opinion wars. And maybe you’re too busy to think about all the countless small design choices that ultimately add up into the UX that’s perceived by your users and customers, and often boiled down to one or two sentences when a colleague over a beer says, “So, what do you think about that product X that we just got?” And they respond with a couple sentences. Well, the sum of all these design sentences is often what will go into those couple sentences that a customer uses to describe your solution and whether it’s helpful. So, where are the results of the work here?

Because even though this person on your team likes doing the work—and that’s a great start because they are invested in this, and hopefully they’re getting better at it—but there’s the input and the effort, and then there’s the results downstream. So, the question is, as a product leader, you’re supposed to be delivering value and benefits, not outputs. So, is this person who likes doing this work, are they actually helping you get benefits and outcomes, or are they just helping you get outputs quickly? This is one of the place where skills matter and what separates a professional from a non-professional here. Because a professional should be taking on the responsibility of owning the value creation with you, or taking on more of that responsibility. Not labor and effort, but actually helping you produce the benefits that you’re promising to your customers.

Number three, despite doing your design in-house and creating a lot of artifacts, you’re not seeing progress on your business goals. Now, this one’s a little bit similar to the previous one, but it’s less about this person that likes doing it. So, in this situation, it’s clear on your team, your design resources that you have, whether they have that title or not, it’s clear they’re doing work, but you’re not getting the value that your business and customers need to see. Or worse—and this is the kicker here—you don’t actually know if the design is better or not. You don’t know if it’s better beyond how it looks to you or feels to you, and that kind of gut reaction that you have to it, so you have no way to know if it’s on the right track.

And this is often because you don’t know what the right success metrics or signals are to tell you if progress is being made. So, this is something that I often like to, when I’m on a call with somebody one of the first things we often do before we work together is to figure out what progress looks like. How would we know if we’re making progress? What might need to be true? And your feelings about it can be one of those signals, especially if you’re not feeling confident in the past. You have a right to feel some confidence about that, but what is the work we need to do to get you to feel that way?

And sometimes your feelings, you may be like, that’s totally irrelevant how I feel about it, and that’s okay, too. The point is, if you’re doing a lot of work in-house and creating a lot of stuff, that doesn’t necessarily mean progress. You have a right, and you should be feeling some sense of progress against your goals. Hopefully, results, but sometimes results with design are fairly far downstream because we have to build the designs, and then we have to test them, and then we have to release them, and then we wait to see what happens. What do we do in the interim?

Well, again, this is sometimes where in-house teams don’t have time to get into all that because go, go, go, speed, speed, speed. Moving quickly trumps everything else. And when we’re making stuff, it looks like we’re having progress. Progress often looks like are we burning down tickets in Jira. Can I see more screens in the Figma? What does stuff generation look like? This is often what we resort to measuring.

Number four, the quote, “Magic,” or vision, or your IP, or your special sauce, the language can vary here a little bit that I hear, but that vision, the thing that was supposed to make your B2B AI product, or SaaS analytics platform, whatever it is, the thing that’s supposed to make your product a powerful alternative to the status quo. Why are you different? How do you uniquely bring value to the market? Why isn’t that manifesting itself in a clear way that customers can obviously see, and they can obviously love. So, this is something I’ve definitely seen before, a frustrated leader who’s like, we’re doing lots of stuff, and I know we have something really special here, but it’s not emerging, and the customers aren’t seeing it, either literally they’re not seeing it, or the product is not creating the feelings that you know they need to have in order to switch from whatever they’re using now, whatever that status quo looks like.

Now, this situation often can happen when your designers or your UX resources do not understand how you’re currently or going to create impact in the market through your unique combination of technology, data, and user experience. They don’t know why buyers buy, or why users stick around. Or sometimes the reason here is that they want to know that, but the strategy you gave them is simply too in the clouds. Plural. I don’t mean it’s in the cloud because you probably are in the cloud already, but the strategy is it’s too in the clouds to be called what I refer to as design actionable.

And worse, the team might have just jumped in anyways with design because, after all, a designer’s going to design, right? We don’t have time for that, to wait around. Let’s just get going. When we start doing design on a project that’s not design actionable, we build debt, and we actually sometimes can hurt the process of design because it starts looking like it’s taking a long time to get anywhere. And it’s true because if you start with an entire green space, no direction, there’s no brief, there’s nothing, then the chance of hitting any type of bullseye, let alone progress, is much harder because the dartboard is huge, right?

And over time, this can make it feel like progress is just going to be really slow, but the reality is somehow the strategy, the vision, the special sauce, that thing has not been made design actionable and clear enough to the team who could help you envision that and put that into a real product. They could do that if they knew what that looked like better, but they don’t know what it looks like because that has not been either figured out or it hasn’t been communicated in a way that they can understand, that they can execute against. So, we need to get that clear, right?

Number five, to get started you or the subordinate under you, or whoever’s doing the work, they went out and found a dashboard template, or a competitor’s UI, or they went out and got the favorite tool that they’ve been using for some completely unrelated purpose, or whatever, some UI that they saw from some other context that they think might fit as a starting point. Or maybe it’s a design library, whatever. The point is, they went out and found someone else’s work, and then they customized it to try to make it yours, your unique, special product. And why are we doing this? Well, it’s because you’re masking the fact that your team—or maybe you—are not really comfortable doing or asking the team to do the really hard zero-to-one design yourself. I sometimes call this the nothing to something phase.

This is an area I really like to help founders out with. It’s kind of going from the PowerPoint deck, the vision, this idea phase, or this rough prototype or POC, to the first thing: zero to one, the nothing to something. This is particularly hard if you’re not a designer for a variety of reasons, but the zero-to-one phase can be really difficult for some people because it’s the cold-start problem, and so it’s a lot easier to take someone else’s thing and then try to work it into your thing. I think that’s fairly natural, whether it’s for design or something else. It’s kind of like, imagine—many of you know that I also have a career as a professional musician, so let’s take an example of like, hey, we want to, you know, get hired by a performing arts center to do a concert, and I need to give a contract to the presenter to protect my rights and so that their rights are protected, and it’s clear what the services are, blah, blah, blah. Let’s go and find an existing contract and modify it to fit my ensemble, right?

Well, there is some truth to that. We don’t need to be starting at zero with everything. Some things, we should be starting at zero. So, what are the things that make sense to borrow and steal and cheat from—in the tradition of great jazz artists, for example—when does it make sense to do that, and when does it not? Well, it takes skill to know when you should be breaking the rules, or, quote, “Cheating,” what stuff is safe to borrow, and steal, and cheat from? And I mean those in positive ways. I’m never advocating for theft, but I think you understand what I’m talking about here.

Deep inside, you probably know that shortcuts often don’t produce outsized results. And if you were redoing your bathroom at home for the first time, you probably wouldn’t take shortcuts unless you knew what you were doing because you had designed and built a hundred bathrooms before that. And, you know, hey, oh, I got to reroute this wire around this joist. Really, we should go through the joist, but they’re probably really not supposed to do that. It’s not technically against code, so—and I’m just totally riffing here; I’m not advocating for any illegal electrical work in your house—but the point is, would you take that kind of risk there?

The challenge here is also, when it’s something that seems like anybody can do it, the risk might seem lower to you because you don’t really know what the downstream impact of any one choice is going to be because you haven’t done this kind of work a lot. So, then you have to decide—and I’m not trying to scare you. I’m not trying to say that, like, every decision needs to be analyzed to death and be afraid to make any type of decision whatsoever because you have no idea what the impacts are. I’m not advocating for that. This gets back to having a healthy knowledge about, what do I know that I know, and what do I know that I don’t know, and then being open to the fact there’s stuff you don’t even know that you don’t know. It’s kind of tied back to that thing.

But when it comes to your special sauce and your strategy, this zero-to-one problem, you got to be really smart about whether you’re going to bias your product by borrowing someone else’s interface and design and trying to fit your vision into that because you have immediately biased it right there. And it’s possible you biased it in a good way because maybe you’re borrowing some familiar patterns and your product is not going against standard norms or low-level heuristics best practices, things like that, but you’re probably not going to know whether it is or not unless you’ve done this a hundred times before. That’s what the issue is: what you don’t know that you don’t know about that. But I do think you’re smart enough to know strategic shortcuts probably aren’t going to give you outsized results, and you probably do know when you’re taking the wrong shortcuts. You probably know when you’re doing that much.

Number six, you built out an MVP or a POC—a Proof of Concept—to prove out your tech. And the longer you used this, the more intuitive it got for you and everyone you’ve showed it to, et cetera. So, instead of tossing it out as a proof of concept, instead of a product, you keep building on top of the POC, until you realize that your sales prospects and your users who got their hands in the demo, that no one else is understanding it. So, I don’t know if I need to say more on that one because this is that simple example of going native, plain and simple. You know how it works because it’s your baby, and you have been exposed to it a ton, and the more you’re exposed to it, the more obvious it probably will start to seem to you, unless you’re being really objective, you have deep empathy skills to be able to wear this hat of a newbie, a new buyer, a new user, to have that perspective in a business context.

That is hard to keep if you’re living and breathing this product 60 hours a week. A POC is not an MVP, and the V here is ‘valuable.’ A Minimum Valuable Product. And some people hate this term. It doesn’t even really matter what the term is. The point is, there’s a difference between proving out the tech can work and making it into a product, which means something that’s so valuable someone would exchange money for it because it’s so useful to them, or it gives them the status they need, or it helps them feel better, or it helps them reduce their work, whatever that value is. These are two different things.

And I think this is really important to say in the AI context, where we have very impressive models coming out, models that can surprise us, models that can tell us how the world works in ways that might challenge the status quo. Does that mean someone wants to pay for it? Does it make someone’s life better, or does it threaten them? It could be really fascinating from a science or an insights perspective, or what an economist might say about that’s amazing feedback. We never really knew these two things were so highly correlated, but it can be technically right and effectively wrong.

So, POCs are not the same thing as MVPs, and your bias will grow the more you remain attached to this baby of yours, the thing that proves out your tech, particularly if that tech is built on artificial intelligence, and on the front-end, maybe it’s rather simple. Think about something like ChatGPT, a text box and some dialog that gets spit out as a response. A rather thin, very thin, small GUI on top of a massive set of intelligence, data, algorithms, two different things.

Number seven, you’re afraid to make the UI or UX too opinionated in this B2B context, and so you resort to offering customization early on as a way to ensure all possible users can do—insert job workflow or something—their way. You don’t want to make it too opinionated because there are so many different use cases because your product can do so many things for so many different types of users. So, you offer customization. After all, you wouldn’t want to lose a customer or a seat license, so the best way to do that is to support all of them, right?

Unfortunately, though, this creates a huge product challenge. It’s hard for design, it’s hard for marketing, it’s harder for engineering, the tax on the team and the product actually goes up to try to support all of this, especially if you’re a startup and you’re trying to show traction, right? The thing is, trying to do a little bit for everybody can often result in nobody really understanding the value, or the mental model, or the utility of your solution because a lot of the work has been pushed onto them in the form of having to do customization to get it to provide the value that they hoped was going to be there in the first place. You are effectively putting some of the design work on their shoulders, and then we try to position it as a benefit, which we call customization.

Customization can hide the fact the team has decided not to make some difficult choices, that we are going to kick butt at this, and we’re not going to follow on that because that’s too many different things, and we will not survive as a company unless, especially if we’re coming into a crowded space, we are not going to get people to switch their behavior. If we’re just a little bit better for all these different user types, that’s not probably going to be a compelling reason to switch. Customization can be a tax, not a benefit. I’m not saying all customization is wrong, but it can be a tax. And a lot of times, particularly with your traditional analytics products, SaaS analytics products, where you’re selling insights, this idea of often there’s a blank slate or a desire to push people into building their own because we don’t want to start with any one thing that might not be exactly what this user needs. So, we immediately, we actually push effort onto the customer to start designing the value into the solution that they already paid for. As a general rule, you’re probably not delivering your biggest impact if that’s how the experience feels, particularly early on in a customer’s experience. That can cost you in the form of attrition demos that don’t translate into sales, et cetera, et cetera.

Number eight, you abstracted aspects of the product to make things easier for engineering, or so you could build your product on top of your own API. I’ve seen this one before as well. But your data model, your object model, your technical model doesn’t match user’s mental model. And this is the way they see the world, the way they think about your product and your service in their head, regardless of how it’s actually modeled technically in your product. So, in effect, what’s happening here is you’ve prioritized making engineering’s life easier or faster above customer value, although we’re selling this as well, we’re able to move more quickly because we’re making it easier for engineering, so therefore our velocity is up. That’s the counterargument. The thing is, enabling your data or engineering teams to be able to move more quickly doesn’t mean that they’re moving in the right direction, more velocity? Well, maybe, but if you’re not going in the right direction, does it actually matter that you’re going faster?

Number nine, you believe you know good design when you see it. Okay, this is a favorite [laugh]. I mean, after all, you have eyes, and you know what easy to use feels like. And generally at some point, this is where I get a comment about somebody’s favorite Apple product or their iPhone, and of course, they want—they or you—want your product to emulate that Apple feel and to be as easy to use as the apps that you use on your phone. And maybe you’ve even hired a designer to take your UI or make the visualizations and interface look good for your demos or whatever, but despite passing your esthetic test, you’re not seeing those KPIs move.

So, you think you know what that Apple design feel is—again, you know good design when you see it; that’s what you’re saying—and you want that Apple feel—or name some other popular design company, usually it’s Apple—and you assume when that feeling arrives, you’ll see the outcomes that you seek for your product. But so far, they’re not appearing. And while maybe right now, you’re not embarrassed anymore to show your demo, your product, your UI, you realize that customers don’t really care how you feel about it, and they don’t really care if it’s Apple-like either.

And they might say something. They might give an offhand comment about, why is this so complicated? And on my phone, I can just do X, Y, and Z. You might hear those comparisons, but the kicker here is that if I work with you as a client, I care a ton about how you personally feel about the work that you’re getting and the help you’re getting. That is really important. There’s also the direct business value of the work that you’re getting, but your feelings matter. However, your customer doesn’t give a flying you-know-what about how you feel about it, about whether you think it’s good or not. It’s completely irrelevant. So, be careful with believing I know good design when I see it, and when I get there, then I’ll know we’re done. This is a trap.

And you might know what good design is, whatever the hell that means. Is that, like, if you think that this is a nice design, and then eight out of ten professional designers also agree, then therefore you have good taste. I don’t know, and I don’t even care. It’s kind of irrelevant. I often don’t even like to talk about what good design is when I look at a brand-new thing because, especially like an enterprise application, when someone asks me, “Is this good?” My usual response is, I can give you an answer about what I think, my opinion about it, which will largely be based on heuristics, best practices for rather low-level stuff, like, are you breaking conventions? Are you using common patterns? Is language feel generally obvious? Those kinds of rather low-level GUI things.

But is it good? Well, in order to answer if it’s good, I need to know what it’s like to be the person paying for it, the person using it. How do they feel? What makes them feel like a champion when they use this product? What do their workflows look like? What’s their behavior like? What should it be like after they use the solution? You can’t actually answer this question without knowing that information. Now, sometimes I can go a lot deeper because I’ve been exposed to that industry before, or I know something about the actual end-users are familiar to me, so you can go to the next level with an eyeball analysis, but relying on your sense that, like, “I’ll know it when I see it and I know good design when I see it,” this may not be a very good way for you to determine whether or not your product is on the right track. And my guess is those two things probably aren’t highly correlated. I could be wrong, but I think it’s healthy to retain some objectivity here and to remember that your feelings about it, they matter to me if you’re working with me as a client, but they don’t matter to your customer at all, so is that something you should be trusting here or not?

And finally, number ten. Because your data science, the AI work, the machine learning, modeling, all that stuff was successful, and it was difficult, and it was expensive, you didn’t give much thought to the UI/UX piece around it because the outsized value of your AI should be obvious. Except it kind of wasn’t to end-users. In fact, maybe it was threatening in its accuracy or its power. It was almost too good, and that made users nervous.

Maybe a technically right machine learning model does not necessarily equate to a desirable, usable, usable interface and customer experience that’s so good it’s worth paying for. The amount of effort you put in doesn’t necessarily equate to value. The accuracy of the model does not necessarily equate to value that’s worth paying for. How we wrap up this AI, this solution, your special sauce, how we package this thing up, and I mean literally, from the marketing of it, the feelings it creates in the marketplace before someone buys it, and then the experience that they have using it, and the behaviors that it encourages or doesn’t encourage, and the status, the way it makes people feel, this stuff can matter with business software as well. It’s not just for consumer software because we’re still talking about humans being humans, right?

I’m assuming your app isn’t for dogs. I cannot tell you anything about dogs because I’m a cat person, and my cat—well, I don’t have a cat, but if I did have a cat, it wouldn’t care. All you cat listeners out there probably know exactly what I’m talking about right here, but I’m totally getting off track here. Let’s get back to the fact that maybe the heart and soul of the company is the early modeling you did, this IP you have around the machine learning work that you’ve done of this AI, whether it’s GenAI or not—generative AI—it doesn’t matter. And I understand, there’s impressive, expensive, difficult work that can go into producing an accurate model, and especially one of these models that can do things that almost feel like magic, they’re so groundbreaking in their nature.

But making sure that that value translates into a product and not just a freak show at the zoo, a circus, step right up, pay your two dollars, come look at the freak behind the curtain. “Wow, that’s interesting. I wonder how I might use that.” And then, “Oh, look, there’s a shiny thing over there. Let’s keep walking. I’m going to get an ice cream cone here, and I want to—” do you punch the giant dummy, or what are you supposed to do at this circus? Isn’t there, like, the something giant guy or something? Anyhow. These don’t equate.

Watch for the sunk cost bias here. Humans be humans, buyers be buyers. A lot of them probably don’t care, don’t know how the sausage was made. They don’t understand how the AI stuff works, they probably don’t need to understand how all that stuff works. They want the benefits downstream. The benefits downstream from the technology need to be wrapped up into an experience that’s useful, that’s usable, that’s hopefully delightful, something that becomes invaluable so they can’t live without it. Watch out for technically right, effectively wrong, particularly if you come from a technology background, and your technology world around you would be really impressed by the work that you did from a purely academic, or theoretical standpoint, or from a technology standpoint.

That’s great if you want to be doing tech labor and seen as an amazing technology thought-leader, that can be great, but it doesn’t necessarily mean sales, and retention, and a network that talks about it, that spreads the idea because the idea is so good that it creates impact. So, those are the ten things. Learning Figma or whatever tool, this is the least of your challenges, just like understanding Python isn’t going to make someone a great data scientist. So DIY, do-it-yourself product and UI/UX design, it’s fine. If you have the time, and the budget, and the patience for things to take longer than you might like, particularly if you’re in a niche data type product, and you don’t have that type of expertise, that’s okay.

If you have the money and the time, and you can deal with the ambiguity inherent in doing product design work, the not knowing part, the not knowing how to measure it part, and if you’re comfortable starting over when you’ve sunk too much cost into a direction that’s not serving your customers and your business. It’s okay. If you have those resources, this stuff is okay. Keep doing it yourself. I love that you’re doing it at all, and I hope you’re learning something about how to do it better, and your skills are growing.

But if you’re doing it right, then customers and users should recognize the value of your solution. They should find it, if not just usable and usable, delightful. Something they can’t live without, something that’s worth paying for. And maybe they won’t even comment on it because you’ve wrapped this solution up into a benefit that’s almost invisible. They don’t even see it. They don’t even think about your user experience or your interface or anything because it’s practically invisible. You’ve made their life so much easier in some context that they really value.

And if you can get all that stuff right, the buyers will be buying because the value is obvious, and the customers will be staying around because they can’t live without it, because you made it indispensable. Ultimately, that’s what I hope you will get to, whether you do it yourself, or you get some outside help, or you hire a team, I’m hoping having some of this [laugh] podcast today and some of these insights about what I sometimes hear on calls with folks like you, having this knowledge will help you shift the way you’re working, the way you’re thinking about it, to make better decisions. Should we keep going? Should we get outside help? When is it time? How will I measure it?

Especially if you’re a founder, and you’re a small company, you wear so many hats, you can only put so much effort into each thing, you don’t have time to get great at everything. So, when is it time to get better help? That’s the goal of today’s episode, is to realize some shortcomings you may have about design and to be self-aware of those things so that you can make better decisions about how to move forward. So, I hope this helped. If it did help, if you shared this episode, then that’s a good example that the word spreads that I provided some assistance to you.

I’d love to know what you think about this. If you head over to designingforanalytics.com/podcast, you can record a comment for me, or a question if you have one. I try to go through those, and sometimes I do episodes on this show to go, like, mailbag and go through those. At any rate, best of luck for the rest of 2024. Maybe it’s 2027 right now, and you’re going back through this. My guess is a fair amount of this will be true in three years from now, but regardless, best to you. Good luck. Keep doing your design work, keep making data products that are so good, someone wants to pay you for them, and they can’t live without them because the experience is so good. I wish you well.