#16 Why 85% of AI Projects Fail - And Why Most Teams Are Still Getting AI Wrong | Greg Nudelman

Speaker A: This is the UX Institute podcast and I'm Mark Swain, founder of uxi. In this podcast, I interview UX and product leaders from around the globe.

Speaker B: AI projects fail because of lack of good UX practices. It is squarely on our shoulders to get this back on track. Stop letting developers run away with it. You need to become an AI MacGyver. We need to learn how to bring that. Show me the money. Energy. Let's make this happen this afternoon. Energy.

Speaker A: So why are we hearing that most AI initiatives are failing within companies? Despite billions being invested and AI dominating every boardroom conversation, the majority of AI initiatives are not delivering meaningful results. Joining me today is Greg Noodleman, four time author, renowned speaker, AI strategist, and author of the new book UX for AI. Greg has spent more than 16 years building AI powered products, holds multiple patents in the field, and has helped organizations navigate some of the toughest challenges in product development and emerging tech. In this conversation, we unpack why so many AI projects are failing, how traditional UX and product management practices are being challenged, and what teams need to do differently to build AI products that customers actually want. We also discuss why use cases, data and understanding customer problems matter more than ever and even more than the latest AI models and tooling. How, uh, designers and product managers can remain relevant in an AI first world, and why six months may be an eternity when building AI products today. Here's my conversation with Greg.

Speaker B: Mark, thanks for having me here. My latest book is UX4AI. It's right here. The reason why I wanted to write it is I've spent 16 years doing AI related projects. I've shipped 34 different products in the space and I got a bunch of patents. Uh, what I noticed is it's a fundamentally different thing. It's not something that we can apply the same kind of thinking to. And so that forced me to write the book about it and invite 12 co authors because I always love to invite other perspectives. So please check it out. We are running a UX for AI certification now that is based on the book. Ah. Uh, and our first cohort completely sold out our workshop at south by Southwest and the book's actually sold out in the south by Southwest workshop. I don't know what that tells you.

Speaker A: That's great, man. People are hungry for it.

Speaker B: Thank you so much. It is, as you said, timely. And one of the things the book tries to address, and I think does so effectively, is why so many projects fail today. In fact, According to Gartner, 85% of the projects fail. The book literally starts with how to fuck up your AI projects in five steps.

Speaker A: Right? Yeah, yeah, yeah.

Speaker B: It's a very honest book because a lot of things do fail and they fail not for technology reasons, but for reasons of technology alignment to customer needs and to business needs, uh, called the Four Horsemen of the Apocalypse. We address those. Uh, hopefully that improves your betting average. My goal now in my practice is to really flip the equation is that only 15% fail and 85% succeed. I think it's just a tremendous waste, not just a waste of resources, but it's just a giant waste of time because as you said yourself, Mark, it's moving so quickly that losing six months, uh, is almost inexcusable because that's the time you're not going to get back. It's not the $2 million that you wasted going down the wrong path, uh, because it's just the ultimate accelerator and ultimate leveler of the playing field. And the danger is real and it's happening. You can see all the layoffs and tremendous disruption in the marketpl. This is not a trend. This is a fundamental disruption of the magnitude we have never seen in this industry since the beginning.

Speaker A: Thanks for saying that. And, um, being so honest about that point, because this is the exact point that I'm not sure still, that is landing deeply enough with most people. We've gone through our cycles in the past. Chatbots in 2016, then some of it settled down and went away, some of it stuck. Right. But SaaS has been at the core for 25, 30 years, whatever it's been. But this is very different and it's shifting daily. What do you think is actually going on right now? How are people feeling? Product managers, UX lead, UX researchers, UI designers. Antropic, um, is just launched. Cloud design. Figma's trying to keep up all the time with MCP and whatever else. And how do you think people should be feeling right now to stay hung on to the coattails of this and try and get out the other side and still be relevant? And what happens to people who don't?

Speaker B: It's a complete disruption right now. And the biggest thing is that you have this pressure from the board. At least that's what I'm seeing from the companies that I consult with the board. Pressure is real. They say we got to build with AI. Give me some of that AI. And it's funny because I call it the, uh, Hadoop syndrome. When Hadoop first came out, I don't know if you're all that old Hadoop.

Speaker A: Yeah, yeah, yeah, no, I know what you're talking about.

Speaker B: Yeah, Hadoop first came out, nobody knew what the heck that was, right? It was a big data play and all these boards were constantly going like, give me some of that Hadoop. And I remember talking to CEO and what do you want to use it for? They're like, we don't care, just give me some Hadoop. And that's exactly what is happening here. It's like they don't care, they don't understand it, they just know they need it. And in this case it is definitely real. This is not just a branding thing, it's absolutely a real deal. And boy is it, ah, is it changing things. So the boards are pushing them to adopt AI and to use it, but they're not shelling out the money to train them. And this is new because I've been in training for over 20 years. This cycle is bizarre because nobody's spending money on internal training or when they are spending, it's extremely low cost. So I've actually had to adopt and create a low cost training program just for enterprises because they're not willing to spend, but the training is needed. I think the biggest thing right now is that designers, for want of a better word, is they made themselves disposable. Let me tell you what I mean by this. We have invested so much into our tools, into Figma, to this tool. And so it became equated in people's minds and in minds of PMs and developers and most of all leadership that, oh, you, uh, need to purify something we call a designer, you need to design something we're going to call a PM or talk to developers. It's a very unfortunate thing that we kind of backed ourselves into this corner. We're not blameless exactly. But it is something that I feel a lot of empathy for because the company itself shoehorned different folks into different silos and that became our silo. And we went to it willingly because it, it was a simple enough work and um, we followed the patterns, we made the designs and we got the very nice paycheck. And who doesn't want to get paid for drawing pictures all day long, right? Like, sure, that's pretty awesome. But you know, at the end of the day the value just wasn't there. And we ended up doing lot of that robot monkey work as a colon in the book. And it's this repetitive stuff that taking simple products and doing the same exact design for a different product of the same kind and then Just putting a different skin on it.

Speaker A: Oh God, I've been through it so much in SaaS over the years. I've designed so many SaaS, platforms, login, onboarding, dashboards, snooze and uh, yeah, it's just done to death completely.

Speaker B: And because it became so popular, we made, you know, myself included, I was a GA instructor, General assembly and similar kind of shindigs. And pretty soon the marketplace is very saturated with designers that can just do this very simple work. You take some design patterns, canonical pages, a design system, and then you come up with a new page when it's time when somebody gives you specifications. So I travel around the world and I do this UX for AI training, which is just completely different. It's from the ground up, completely different. It's completely strategic. It's all about building your prototype with uh, vibe coding and using RAG for data and all that stuff we're going to get into. But this wasn't it. So when I do this kind of teaching, people just come up to me and go, that's not what I do. I don't do this. I don't move the mouse until I get complete specification from ipm.

Speaker A: Yeah.

Speaker B: So people still tell me that that is such bullshit. That's not going to guarantee your employment anymore. It's guarantee your unemployment because now Claude can do that. So this whole concept of forward looking PM is basically a PM who talks to customers. I mean imagine that. Wow, what a concept, right? You're basically creating products and you're going to talk to customers. Mind blown, right? Like wow, they've discovered the ability to talk to customers. So a lot of that is happening while all this disruption is going on. So what I want to really challenge folks because the skills that you have are extremely valuable. They're very well grounded in customer satisfaction, customer delight and understanding customer motives, jobs to be done. So you already have the skills, they just kind of atrophied a little bit. You haven't been used right. So it's like a muscle that hasn't really been used in a while. Don't consider it game over. Take a program that will teach you how to use those fundamental skills to apply them to AI projects. Because like a program that we teach UX4AI professional certification ux4ai.com they're easy to remember, just like the book title ux4ai.com. So you just go there. But you know, I'm not saying take my program, it's good. But you know, there's plenty of other ones as well, take a program that will give you that confidence back, that mojo back, that ability to then refocus the skills you already have and know to this new medium, which is AI. It's so, so important you do this because AI projects fail because of lack of good UX practices. That is very clear. It is a conclusion of uh, pretty much every single report that I've read. This is not about tech, it's not about business. It is squarely on our shoulders to get this back on track. The 85% failure is UX driven failure. So we got to get involved because data science alone is not going to do it. AI is just too important to be left to data scientists. We need to get involved en masse and really take an active role to get this back on track.

Speaker A: It's so great that you're framing it this way because very few are. Your LinkedIn feed is half poisonous of Claude prompts that you should be using to overthrow your UX team, your designers, your go to market. It's overwhelming. Let's pull it back into like give some examples of an enterprise project that fails. So my immediate thought is that a typical SaaS or enterprise company tries to adopt some AI modeling to create some efficiencies in some departments and some workflows to either slim down the pain in some key areas that they've identified that they could start with, or even trying to create a backbone of AI in the org or some model to get off the ground to get workers learning and moving in a different direction because half the employees are trying out GPT and whatever else and pissing around with it and not really doing a whole lot or not even understanding how to prompt correctly. Right? So there's that big shit show is happening everywhere at the moment. I hear it too. And then we have startups who are building so many agent based platforms that are being invested in at the moment where they can come in, insert, they've got multiple model wrappers around the platform and we can inject, point to a repository of data and get you off the ground quickly with a couple of agents on two or three key use cases. I'm hearing and seeing a lot of that too. Where's this failing? What's falling down here to get a project running the right way?

Speaker B: So number one is the wrong use case, the one that torpedoes, I would say majority of the of the projects you really, really want to understand what is it you're solving for? What is job to be done? What pain are you addressing? How is this getting done today? What is AI going to bring to the table? That is not being done. And that is the kind of thing again, UX should be doing with the rest of the team. It shouldn't be just a solo exercise. In fact, if you're doing solo exercises, you're probably doing it wrong. You should be able to create a storyboard, which is what I recommend as the first step. Take more than 15, 20 minutes with your team about what is it that you're trying to solve? And that should say, where's the happening? What is the interaction between the AI and the customer? And then what is the outcome? Those are the things to nail. And we walk through this in the book, there's a special chapter just on that. Exactly on how to do this. So framing the problem is extremely important. So that's number one. Number two is data. And if you don't have the right data to answer the right question, and by which means it's gotta be training data. Ideally it's bespoke. This is the prompt, this is the output. And a lot of people get this very, very wrong, especially at the C level. They think they have the data, but so often the data is isn't there or isn't there to tie the input to the outcome. And that is going to be doom for your project. Let me give you an example of this from cybersecurity. So I was consulting for a company that wanted to build a detection agent that would determine something wasn't doing well with the tools. So these are detection rules that are, for example, would detect that somebody's logging in from Moscow and an hour later they're logging in from Dublin, Ireland. You can't get from here to there in an. So that is called impossible travel. So that's the kind of rule that fires occasionally. There's a bunch of different rules that are in security systems. And so the agent would determine that rule suddenly starts to misbehave and then it would suggest a fix. And then the customer would say, yes, human in the loop and all that. And then the fix would be it. And I said, well, this is a great idea, awesome. But do you have the data to show what does it mean for a rule to misbehave? And then what the fix was and that the customer said, thumbs up, yes, that's a good fix. And they thought about it for a second and they said, nope, we don't have that data. I said, well then you are about to build a bullshit generator because it will always give you an answer because it's trying to Please you, no matter what, it's going to come up with something. You know, especially in an academic setting, you can say, prove to me that a dictatorship is the best form of government. And it will do that. But that doesn't mean it's true.

Speaker A: It's just really good. You hit on this exact. I've been playing back to other people in different orgs and in my own network is that be careful what you absorb in terms of output. Possibly a third of what is spat back at you is actually useful and you can work with. But if you sit down and contextualize, you'll realize that the large percentage is not usable, applicable contextually, and um, is garbage. Unfortunately, a lot of people are getting paralyzed and taking what AI spits out to be true fully and running with it.

Speaker B: Exactly. It will always try to make you happy. And the way that I got around that, did I tell them like, no, you can't do that project. I said, well, you are about to build a bullshit generator because you don't have the data to train the model. Uh, that this means misbehaving rule, and this means a fix to that misbehaving rule. And that is a fix that, that the customer actually approved. So, but I said, look, you know, all is not lost. What we can do maybe is have the customer actually have the human in the loop to give the prompt to say, this is what is happening. This is what I did. And now this is what I'm seeing in this rule. Can you help me fix it? Uh, to take the impossible travel rule, we've installed the new VPN system which has multiple IPs, so depending on the time of day, or just like lottery, it either has a center in Moscow or it has a center in Dublin, depending on when you log in. It just automatically sort of switches, switches, um, the IP address. And it looks to the rules set that something is misbehaving and it looks like impossible travel. That is why that rule keeps firing. So we just got a new VPN system and this rule just keeps firing like crazy. And you know, can you help me fix it? Now that is a much better prompt because that is a perfect agent prompt. In fact, it correlates the impossible travel with a new vpn and it can find the answer very, very easily because there are plenty of canonical examples. And the fix is very simple. If IP equals X, ignore that is it one line fixes that rule. And so that essentially is a tiny pivot that I did as a UX person, understood the fact that you need a Use case, the right use case and the right data together to then solve the problem. And if you understand that, that's the kind of power that you have, and that's what we teach you in our UX4AI certification. And, uh, that's what the book teaches you how to do. It teaches you to ask better questions so that you get this thing back on track. And guess what? In an afternoon, I had that working. In the morning we had that conversation. By the afternoon, I had a prototype working with an agent that went out and did exactly that. And I, uh, showed them the fix and I said, now you can have this system go and harden it for production and we can have it out in a couple of weeks. And once you start collecting data now, you can correlate. This was the prompt that the customer said. This was the actual behavior of the rule that they were complaining about. And this was the fix that they said thumbs up to. And now you have a year's worth of that data. A year later you can actually implement exactly what you wanted because now you actually have the data that you've collected that shows this is the misbehavior, this is the fix, and this is the thumbs up that the customer gave. And that was the reason why. But you couldn't do it a priori. You couldn't do it from the start because you didn't have the data. So the data is the other horseman, and then the third horseman is the value versus risk. There is a exercise that is worth the price of admission in the book, and that is the value matrix. I didn't come up with it. It's authored by Orjit Singupta, who runs Abel. Uh, he's the one who created Salesforce Einstein. I had the chance to work with him and that was one of the key components to the six patents that I help them file for that company. All it's really looking at is it's looking at a real world impact of the outcome. Typical AI decision. You have true positive, false positive, true negative, false negative. All this value matrix does is it assigns the cost or the benefit to each outcome and then it multiplies that times the number of times that outcome actually occurs. So if you have something that's very, very accurate, maybe that's good, maybe that's bad. If you have a very accurate AI that leaves a lot of money on the table. For example, let me give you a simple example that Origin came up with is if you have a very, very accurate AI that TSA is using to screen People that come on the plane and it figures out who to pull aside. In all this time that we had, we basically had like one incident of, of an attack. So if this model can be 99.9999% accurate, so that is just ridiculous accuracy and be completely useless because if it always returns false, this, in other words, this person is not a terrorist, this person's not a bad guy, don't scan him. It will be 99.999% accurate. Uh, completely useless. Why is that? Because it is leaving a lot of money on the table. It's trying not to be wrong. That's what accurate means. It's a model that tries not to be wrong. Now that is good for some and it's terrible for other use cases. So as a UXer, you need to understand the cost and the benefit of each outcome so that you can help your teammates construct the AI that's actually going to be appropriately aggressive or appropriately conservative and accurate to match the real world scenario. And these things are quite different. And we're just going through with the Cohort, we have 44 people, uh, in the cohort, and every single use case is different because every single use case is going to have a different balance of true positive, false positive, true negative, false negative outcomes. And that is what nobody does. If and when AI hallucinates, what is the cost of that? Right, Right, right, right. When your Tesla smashes into, into a picture of, of a forest on the side of the big rig. Right. What is the cost of that? So figure that out. The last but not least is what Mark already mentioned is the process. And most people still apply the old three in a box process to developing AI that just no longer works. We need to have a different process. And I have invented that based on 16 years in AI and 34 shipped products. What I called it is Snowball Sprint.

Speaker A: Uh, yeah, I've looked at this. It's excellent.

Speaker B: That is literally the extension of the old design Sprint concept. And we start with the framing of the problem before we even write a single line of code. We frame the problem using the use case, the data and the value. Right. We try to really understand it and all three exercises work together to really help understand. Is this the right problem to address? Do we have the data for it? Is this the right use case? So first you frame it and then you work on the rag file, quick design in, uh, paper and pencil. And then you do a very quick rag file, which stands for all your data, a little templating work. We put it together and then we vibe code a solution that we then take into a rapid iterative testing and evaluation phase. But in this case, instead of write being done with pictures, it is done with actual prototypes that we vibe code. So you always have the AI's actual response that you're putting in front of customers. And again it doesn't take a long time. Just like the original um, design Sprint, you maybe need a week or two to get all of this done. And you have an actual running prototype that is customer validated that you know you also have the data and you have the right risk reward profile for your AI to make it worthwhile to pursue that exact product. And then you roll it like a snowball, then harden it and that becomes your shipped product. You don't create something in the silo that's different and then you have to recode the whole thing from scratch. It becomes your product. So it accelerates your development. And it's a completely different way of thinking about it because you're no longer drawing pictures and handing them off. It just kills the handoff. No more handoff. Everyone works together, everyone rolls the snowball together. You wrangle the whole thing as a team with the customer in the middle. And that is what I feel is the destiny for the new UX PM forward. PM Persona in the enterprise is driving these projects and driving tremendous ROI uh for the company by bringing people together to solve real world problems for your customers in the way that only you know how with your bespoke data that only you have. That is how you going to be able to become relevant again. It is not by learning more figma or more tools. Focus on shipping the real thing which literally means it's got to be AI

Speaker A: enabled prototype natively from the ground up.

Speaker B: Exactly correctly framed problem that is then turned into an AI uh enabled AH prototype as quickly as possible.

Speaker A: Visit uxinstitute.com to sign up to our new newsletter. UXI will be sharing best in class UX research practices as well as in depth interview content so you can excel at your career in ux. The process is great. It aligns to what we've grown up with in uh terms of UX processes. It's a follow on from that. It's keeping us all aligned. However, I don't know if you find this your perception of what's happening with AI at the moment, but people aren't following processes. They are jumping straight in and building out slop and pushing it out and they are not stopping to conduct this piece of work that you've just described, which firmly aligns the org use cases to get off the ground in the right way. So as whatever agent swarm we're going to put in place is actually going to conduct the work the right way, people are just jumping in, slopping about and trying to get something off the ground. It's as much spaghetti at the wall as possible. They're half educated, half baked. But the communication about UX in this process that we're seeing every day in our feeds is based around a, uh, doomsday scenario for UX people and ui people and PMs, even, you know, latest pods and people I listen to are saying in the next few years, 50% of PMs are going to go away. But you're really framing the UX piece right here because this is still so badly needed to make projects successful in enterprises.

Speaker B: Yeah, I love that you mentioned PM's, uh, going away as well. So one of my favorite articles that I've written is you should replace your PM with AI as soon as possible. Because what I've been seeing, it's the same situation we got caught in as, uh, UXers. PMs got caught in the same thing. They became the machine to translate a boss's vision into a bunch of jira, uh, tickets and then follow up on these juror tickets to make sure that, that the job gets done. Now, AI is actually going to be better at that. Like I can tell you right now that this is, there's nothing magical about it. Most, most PMs absolutely are terrible. They're not moving the needle. All they do is just, it's just a glorified juror ticket writing machine.

Speaker A: Plus, it's not enjoyable. A lot of PMs are not having fun, right?

Speaker B: They're not having fun. And a lot of them don't know how to use AI. They don't understand it. But what I hear right, just let them. Let them. Right? No, no, uh, you should absolutely not let them. And this is where again, you should call bullshit as soon as possible and bring people back. Every single time I've seen it happen. My biggest regret was not pulling the plug soon enough. Because it's not just the money, it's the time you can get back. And then the customers are starting to feel very, very restless. They keep hearing all these features from the competitors and if you didn't deliver parity, they're going to start leaving. Smart folks have figured out that what you have to do is make the switching costs easier, make it cheaper, and, uh, make it better. And so you specifically hit all those three and magically the customers are going to just start, uh, leaving company A and going to company B. And that six months that you let them muck around is going to be disaster. Six months is a long time in the age of AI.

Speaker A: Absolutely. And I guess then the PM's role along with the UXer, even though they are being filtered down as we read and hear every day, but their discovery process or their workday rituals that they go through as an AI first team, that's changing drastically, right?

Speaker B: Absolutely.

Speaker A: Can you describe a little bit about that in terms of an AI first team where there's still a PM maybe at the helm?

Speaker B: Yeah, Mark, you're absolutely right. I mean, as a practice, product management is more important than ever. It's the fact that over time the company culture, the SaaS building culture, has siloed them in a very specific box. And that is what PM job has become. Toe the line, don't disrupt, don't rock the boat. That's your whole job. And it's the same thing with ux, right? It's what we've been trained to do. But that whole culture is blowing up now. We need to reinvent ourselves as sort of a UXPM hybrid, which is probably the best of both worlds. Don't think of it as you're losing something. Think of it as you're up leveling. You're up leveling your UX or PM skills. For example, if you're a UXer, you're up leveling and you're adding things like ROI. Discussion. How does the business make money? What does the customer want? What is the product market fit? What is their jobs to be done? What is the pain that we're addressing? What is the competitive pricing, um, which is one of the hardest things to solve, that people just aren't given enough credit. Somebody who's run a business like myself, you know, pricing is one of the hardest things you can solve. It's really, really hard. It's a hard problem.

Speaker A: Absolutely. In SaaS world.

Speaker B: So hard you're up leveling your UX chops and your strategy and your, in your customer focus to uh, understand these other parts of the business which are really, really critical to making money as a pm, you're up leveling your product market fit your pricing, your go to market, your connection with the marketing, your understanding of the business, you're up leveling that to actually talk to customers, to connect your use case with your solution and then have some design opinions. Perhaps. But the main thing is just talking to customers and really understanding. Because most PMs, in my experience, they really struggle. Their idea of talking to customer is just selling. And I'm like, uh, you know, this is why you should buy a solution. Then let me just walk you through this presentation. I'm like, oh, my God. This is not user testing. This is just the sales. Sales session, one on one. And that was the good pm. That was the PM that was actually talking to customers. Most of them refused to do that flatly. Both disciplines need to just get off their collective assets and come together and start building things that matter. Stop letting developers run away with it. Stop handing off and say, oh, my job is done. The hole is not on my side of the boat here. I handed off all my Figma designs. What the hell? They build garbage. It's not my fault. It's like Han Solo, uh, in Star wars, right? It's not my fault. It's not my fault. No, it is your freaking fault. Right? Come on. It is absolutely your fault. Get off your butt. You need to start experimenting, get closer to the customer. You need to become an AI MacGyver. We need to learn how to bring that. Show me the money. Energy. Let's make this happen this afternoon. Energy.

Speaker A: Because it can be done.

Speaker B: It can be done. Exactly. With AI. It's a huge accelerator. Use it. Solve the problem with the pieces you have, rather than, oh, my God, this color. Oh, it's driving me crazy. It's one pixel off. And let me just work on this login form for six months. Because that's actually happened. That's happened to me. For a SaaS company, a team of 10 people worked on a login form for six months. How insane is that?

Speaker A: It's so good to hear you frame it like this. Because that's where we're at. You know, we can spit out a login form and some dashboards in an hour, out of replit, out of cloud code, whatever we're doing. And, um, it's really, really good.

Speaker B: Customers honestly don't care.

Speaker A: Don't care. No.

Speaker B: And so much is in AI output. That's why I said Figma is a Titanic. I wasn't just picking on figma. I was basically saying, look, the whole idea of building products has changed into placing a lot more emphasis on the content that AI is producing and how to massage that content. Is it the right amount? Is it wall of text? Is it too many, too much, too little? Are, uh, the rubrics correct? Is it actually answering the question that you care about at the beginning, from the start. Is it using the data the right way? Does it have the right risk reward ratio for what it's producing? All of that stuff needs to be addressed. And the only way to really do that genuinely is not by building wireframes, but by building an AI, uh, driven prototype that actually uses a thin slice of your data so that you're not trying to drink the ocean, but you're trying to just do a very small subset of your data and then it's real and then the customers can really interact with it. You see the kind of questions they ask and you can tell them, look, that's it. You can ask any question you want as long as it's about X. I did this for CloudTrail. There's a thousand rules. I said, look, you know, in the first prototype we built, it was just CloudTrail. So it turned out it's just 15 rules about CloudTrail. So you can ask anything you want as long as it's about CloudTrail. And there were tons of questions that they had. So we were able to test the entire behavior of the system with just thin slice. If I were to say, oh, I got to have everything, then I would be like, oh, I need a vector db, I need this, I need that. Oh, it's a latency. And all of these questions, you don't need to address that. I mean, not yet. It's very, very important. Very important. But it's further down the line right now you can take a thin slice, identify that, just take this piece, build it just to address that, and then put it in front of customers immediately. There's zero reason why you should be waiting for anyone's permission or for anybody to code anything or any of that nonsense. You should be doing that right away, both as a UX and as bm. Both of you there, great work together on this. Figure out who's got the data, who understands the use case. Let's line up the customers, everyone pitches in, everyone rolls a snowball together, and then you make rapid progress, rapidly iterating. We always said, kill your darlings, right?

Speaker A: Yeah, yeah, yeah.

Speaker B: The best way to kill your darlings is not to have any Darlings to begin with. It brings the cost and the time you spend on each iteration almost down to zero. If you don't have a working demo of your prototype every week, you're on the wrong track.

Speaker A: Those are such tangible examples that you're giving of how it should actually be strung together to get something of value so quickly. I think a lot of teams are messing about in AI, uh, trying to figure out how to build better, more efficiently, faster, use it to drive, build prompt libraries, whatever they're trying to do. But actually getting a customer use case data wise, readied and answered is amazing. Amazing.

Speaker B: Yeah, I mean I've built stuff like Q and A or um, for example, one of the very common use cases you can get started if you're looking to get started on something is knowledge management. The reason why a lot of that knowledge stuff is going to be open to be on the firewall, right? So all the, for example APIs for your product, all the uh, support docs for your product. So start with that and see if you can build a very quick solution. It should not be, hint, it should not be taking a year to build this, it should not be taking six months, it should be six weeks. So in six weeks you should have a nice knowledge management system that is going to be able, you're going to be able to converse with it, it's going to be able to answer specific questions about your system. Now you should be able to put that together in the weekend. If you need help, just ping me ux4ai.com just ping me. I will help you out. Uh, but that's great. But literally I was amazed how quickly you can build that. Company I work for, we had, I grabbed 2,500 documents that were public.

Speaker A: Ah.

Speaker B: And then I grabbed some of the uh, internal tech support stuff, um, that a friend of mine sent me and I obfuscated everything. I removed all the customer names and made sure, you know, spot tested all this, threw it all together into a very simple Vector DB system and I had it up and running literally in an afternoon. It was like that simple, fantastic. And then yes, you probably want to harden that to production. But as a simple proof of concept, there's Nothing like taking 3,000 documents and making something work that actually answers real questions and gives you a reference of the. I'm looking at this document. I mean it is like a tangible, valuable thing that most SaaS companies don't have today. Like if you look at even HP or IBM, they don't have that system. I just went looking for an old driver for my printer. It was horrible. The experience was horrible.

Speaker A: It would take you half an hour to source it.

Speaker B: Oh my God. Yeah, I had to go to Claude, I had to go to ChatGPT. I had to go and like, why is this, why is this no driver? This is like what the hell, right?

Speaker A: But it's so True. Like even to your point, just to source a repository like that, most SaaS tools can't do that or have not offered that level of feature that specifically.

Speaker B: Go build that for your company.

Speaker A: Yeah, that's it exactly. Next project. These examples are absolutely brilliant for our listeners. Uh, you know, PMs, UXers, this is exactly what they want to hear. They're sitting behind an array of AI tools daily. They're being bombarded by updates daily. Their heads are probably spinning minus two to some degree.

Speaker B: Mine is two.

Speaker A: Yeah. And so I'm just hanging on to the coattails myself, trying to learning as fast and hard as I can. I'm building lots of stuff out. Uh, but it's going to be interesting when the dust does settle after this cycle where we all land in say two to three years. Um, what AI native teams actually look like, what roles look like, how it's flipped around. A final question. If you could talk to product teams around the world who are in Fight or Flight at the moment. Both, you know, from a career perspective and a home perspective in terms of paying their mortgage in a year before they start on their AI journey, what can they take from your book? What key area should they focus on to really level themselves up, to really stay relevant?

Speaker B: Yeah, I'd say just addressing those four Horsemen of the Apocalypse is a really good place to start. And the book is a fantastic tool that we've written specifically to improve your batting average. So it will help right away. There's a very specific intro. It tells you which chapters to read and in what order. If you're in the Fight or Flight, one of my favorite inspiration was actually Luke Wroblewski's book on forms.

Speaker A: Oh yes.

Speaker B: And uh, it's something literally you can pick up a book and read it on the flight from San Francisco to Dublin. You can get off knowing everything you need to know about implementing really good forms. It's the same thing. So every time I write a book. So Luke Kabruski was my mentor, uh, before I wrote even my first book. Uh, and now I'm m on book six, so I simply can't shut up. But it's always been my inspiration to make it very practical and immediately implementable. So that is what the book is on. And so read the intro. It will give you exact chapters. You'll be on your way. But literally it's all about getting the right use case, the right jobs to be done, addressing the pain for the customer, understanding where your data is and what is the data telling you and if you need to do a quick pivot that we talked about with security rules, understanding how to do that, and um, having enough voice to really say, hey, by the way, have you considered this? Wouldn't it be better if we did X or at least sequence our AI strategy? Don't try to drink the ocean. And then just really thin slice that first use case to prove that you got something working and don't overreach. Right. Like thin slice of rag with your LLM. That should be enough to test your idea with the customers. And then understanding that risk reward value matrix that I talked about, you start with these three things you are going to solve, I would say 80% of the problems. And then naturally you're going to start doing a different process that involves framing the problem first and then doing rapid iterations with the customers. Because you now have these tools that um, will allow you to very quickly get to the point where something is working. And so you will create AI products that customers actually want to buy as opposed to spending six months coding and then discovering you don't have product market fit. You're addressing the wrong problem, you got the wrong risk reward ratio, or you don't have the data to do what you're trying to do. So just spending a couple of days just really thinking about it and um, you're going to solve for so much pain. I know it's really hard when you're kind of in the vertex, uh, to do that. Which is why we made these techniques very, very lightweight and they're plug and play. So no matter where you are in the project, you should be able to help the outcome by plugging in one of these techniques like the digital twin or the storyboard or the value matrix and getting an immediate better betting average for your project. So check out ux4aiuh.com as well. There's tons of articles there. All my best stuff. I put it out there.

Speaker A: I'll be sure to share that with everyone on the show. Notes.

Speaker B: Thank you so much. Yeah. And Mark, thank you so much for your questions. It's such an honor and a privilege to be here and to speak about the stuff that we're all experiencing now. We're all in this together. And, and don't forget, it is really, really important that folks get involved because AI is just too important to be left to mega corporations and to the data scientists. We need to get involved with that human perspective just as soon as possible.

Speaker A: Yeah, amazing. That's a great sentiment to leave this with. We absolutely need to stay relevant because otherwise you are going to end up in a world of slope. Thanks again Greg for your time. It was absolutely super. The honor is all mine to have you here. Six books in and you're still, you know, pumping out some really great stuff. I'll be sure to share links to the book courses, your articles, everything on the show notes, and we'll get it out to all our listening base. Thank you again.

Speaker B: Thank you.

Speaker A: If you've learned anything from this episode, I ask one small favor. Please leave a five star review on our Apple podcasts or share this episode across your networks. Both really help the growth of the podcast and will allow me to continue to secure amazing guests that will partner insight with you. Thanks for listening to the official UX Institute podcast and talk to you next time.