Recursos
Atrás

Únete al tour de IA y datos para recibir formación práctica, conocer historias reales de clientes y pasar tiempo con los expertos en productos de Domo cerca de ti.

Regístrate ahora
Acerca de
Atrás
Premios
Reconocido como líder durante
34 trimestres consecutivos
Primavera de 2025: líder en BI integrada, plataformas de análisis, inteligencia empresarial y herramientas ELT
Fijación

Why Your AI Prototype Falls Apart at Scale and How to Fix It

Try Domo for yourself.
Free Trial
Play video |
00:00
Watch the Webinar
Play video |
2:04:00
Watch the Webinar
Video transcript
Carrot arrow icon

Chris Willis: Welcome to Domo's podcast, Governed Data for Agentic AI. I'm Chris Willis, Chief Design Officer at Domo.

I wanted to start today with something that, for most of my career, has felt almost boring because it's been so much settled, and it's the way we build things with technology. Typically, you identify a problem, you plan around it, you prioritize, you prototype, you iterate, and then you deploy things.

When you deploy, you realize when you look back that the deployment wasn't typically a super linear process, but it was a familiar process. Anyone who ships software knows that you're going to loop back on things, you're going to argue about things, you're going to debate, and you're going to improve. That's just the way it works, but there was a discipline to it.

I feel like AI has started to short-circuit what that process is like, and that's not necessarily a complaint. I think it's opening up a lot of things. But it's not a process I think all of us are super comfortable with or very familiar with. Right now, AI is bringing us to the prototype before those other steps—the planning, the prioritization, and a lot of the conversations that happen around that.

So, I've noticed people have landed in two very different places about this. Some are thrilled that they can realize a vision very quickly for the first time, and they're building things themselves. That's really exciting. Others are worried in a different way—that the things we're building aren't things that we will actually be able to use out in the world. I think both groups are right, and that's what makes this interesting.

Today, I want to introduce you to somebody who has seen this happen in real time with real customers on real systems, and does it every single day. Dan Hendrickson, one of my favorite people at Domo, leads our Advanced Customer Enablement program. He's the person people come to when the prototype is built and the hard part is just beginning. So, Dan, welcome to the show.

Dan Hendrickson: Yeah, Chris, thanks so much for having me, man. I'm super thrilled to be here. I've been here at Domo for 11 years. I've loved every minute of it, but I'm having the most fun right now, and that is with the ACE program you mentioned.

ACE is an acronym for Advanced Customer Enablement. I get to work with the most amazing team of professionals who work with our customers on a day-to-day basis to enable them and get the most out of the Domo platform. What that looks like oftentimes today is how to appropriately leverage AI to get really cool, bespoke solutions created and deployed in their enablement to help their teams move the ball forward further and faster.

Chris Willis: One of the things that's great about you, and you've been such a great resource for so long, is you see exactly how people are struggling with technology both in the traditional sense, when we did have that much more linear development process, and now. How is AI changing that? What are some of the common questions or pitfalls that your customers run into?

Dan Hendrickson: What AI has done, that we see people experience all the time, is it has taken away some of the reliance upon a developer. Before, I was helping a customer a couple of weeks ago who built a production order system. Prior to AI, this was something that required a bunch of work and conversations with engineers. There was a lot of reliance upon those engineers to understand how to architect things, write the code, deploy the app, and go through all those things that you spoke about.

But in today's world, people are going into their favorite AI tool and saying, "Hey, I need a purchase order system," and some number of seconds or minutes later, they've got one, and it looks really great. It's really snappy, and it works really well on their local machine.

Where we see things start to fall down and where the trouble starts to occur is when they need to scale that. How do I deploy to my entire organization? How do I handle concurrent users? How do I ensure that it's secure and that all the right people can only see the right things? The ability to short-circuit the engineer in some of those regards has led to a lot of challenges there, where they think it's great, and then they share it with somebody, and it starts to fall over because the architecture wasn't well thought through.

Chris Willis: I was talking with a Fortune 50 company who talked about this concept of "plausibility theater," in that people are using the tools to create something that looks like it should work, but in fact, it's missing a lot of things. It's probably missing a lot of things because, to your point, those conversations are not happening. I don't feel like anyone's completely immune from this, but have you seen this sort of plausibility theater, and are there ways that organizations are either starting to recognize it or navigate around it, or are you essentially the answer to that problem?

Dan Hendrickson: Well, I'm certainly not the answer, but my experience can help people avoid some of that. The thing that people need to recognize is that your AI tool is most likely using mock data, and it's likely a very small amount of it. You're interacting with it yourself; it's local, and it looks really great.

Plausibility theater—I love that term. You see it all the time. I have a quick conversation with Claude, using the purchase order system example that we talked about earlier. Claude will mock something up; it's beautiful, and it looks great. They show it to their boss, and their boss is very excited. Everyone's pumped; they think they've got this solution that's ready to move down the field.

The reality is that it does work great for that user with that sample data that the AI tool generated, running in that local environment. What's been missed in that conversation or in that process is what happened yesterday when you had that conversation with the engineer. The engineer knew, "Hey, I've got 5,000 people that are going to use this thing every day, and we're going to run 200,000 transactions through it, and we're going to need to edit existing transactions, and we're going to have people try to edit the same one at the same time," and the engineer knew how to account for all of that.

But the excited business person who's having that conversation with Claude or their AI tool of choice isn't necessarily providing it with all that context. The good news is that the gap is easier to bridge than you might think, where we just need to make sure that we over-rotate on providing it all that context. People seem to be taking some big swings, to be honest with you. Writing a prompt for a very simple system versus a very complex system, like a purchase order system, is the same amount of effort. Yet, what is outputted and what is expected is very, very different.

Chris Willis: I'm curious, are there things that you've had to do to sort of have that conversation with people, like can you use the prototype as a starting point rather than an endpoint, and turn that into useful conversations? This then allows you to say, "Okay, we might take a few steps back, so let's bring in the engineers, let's bring in the business people, let's bring in the strategy folks and make sure this is the right kind of thing." I definitely see CEOs all the way down going, "Oh, I could rebuild Salesforce or Spotify or Shopify with a prompt," and yet, to the untrained eye, you probably could, but it's not anything that would actually work. What are some of those questions that maybe stop people in their tracks? You don't want to throw cold water on it, but bring a little reality to the situation.

Dan Hendrickson: Yeah, there are a lot of analogies that come to mind. One that easily resonates with a lot of folks is: let's pretend that you're moving from a condo to a home. You have an emergency come up and you're like, "Dan, I need your help. I need you to get this stuff from the condo to the house. I have to be out of the condo by Sunday." I reply, "Chris, no problem. I got you," and I go move all your stuff. I'm going to get it done, and you're going to walk into the condo, and it's going to be spotless, and everything is gone, and you're going to be really happy. But then you might walk into your house and realize that I put everything in the wrong place. Nothing is where you intended for it to be.

When we think about providing that additional context, there are lots of layers to this. You could say, "Dan, everything that's in the office needs to go in that second room on the right, and everything that's in my bedroom needs to go upstairs." I'll get a little bit closer, but I might miss details, like how I put your kitchen appliances away is probably really important. Maybe you're left-handed, and we want to make sure that the utensils or the accessories you're going to use while you're cooking are on the left side of the cooktop as opposed to the right. All of that additional context is going to allow me to get you much better equipped to be in your new home.

This is really no different than what we encounter with the AI tools. There is really no level of detail that goes too far in helping it understand the nuance. And they're really smart! So if I let it know all of these challenges—the fact that I'm going to have this high of user volume, this type of user, this type of activity—it's going to account for that. But if I don't, it's just going to guess, and it's probably going to get it wrong more than it gets it right.

Chris Willis: Yeah. I mean, you touched on a really big issue, which is if you skipped the planning phase because you were just playing around with the tools or you didn't even realize that planning was so critical to creating a better outcome. It seems like you could use the same tools to help guide people so that at least they are getting to a better spot. Are there any kind of clarifying questions or maybe even prompts you've written yourself to help sort of act as the product manager or the engineer—things that potentially allow people to understand the kind of judgment, intuition, or domain expertise that only they have, which the model does not have because, as you said, the model just guesses? And you want the model to actually be making fewer decisions.

I think what this means is, from a prompting perspective, you have to do more work up front. You're not doing as much work on the engineering part anymore, but you definitely have to bring a lot of the thought up front. And I'm not sure the tools, the way they're designed now, encourage that.

Dan Hendrickson: Yeah. I was just playing over the weekend with the Qwen model. Under the hood, each one of these models has a very different sort of context throughout the coding of the harnesses that they use. Depending on which model you're using, you can get wildly different results. So it seems like this is a discipline you want to build up, or some best practices that are emerging. How do you think about that and how do you advise people?

Chris Willis: Yeah, that's a good point.

Dan Hendrickson: One of the things that everyone needs to be aware of, if you don't realize this yet, is that AI is always wanting to be super helpful and is always very confident in its responses. But when you get back to the helpful bit, if I tell an AI model that I want to build this production order system, it's just going to start writing code.

But if I tell it, "Hey, I need to make a plan to build this production order system. I'm going to lay out everything that I know, and let's have a conversation. What am I not thinking of? What are the things that I should be considering that I haven't shared with you as we embark on this project?" It's going to ask you a lot of those questions, and it's going to know from all the learnings out there on the internet what things should be taken into consideration when you go into building such a tool.

What I've found is that having that conversation, and then at the end asking the model to help you generate a requirements document that you're then going to give back to it—either in that session or in another one to help you build the tool—is a really helpful way to get there.

Chris Willis: What we are discovering here in real time is that there is a new kind of framework for developing with AI. It's one, as you've alluded to, that requires an understanding of what the models do well and what they don't do well, but also understanding where your knowledge and ignorance lies in the organization, because you have to either fill in those gaps or find someone to fill in those gaps. You've kind of stumbled across a new framework for doing these things. Could you tell me just a little bit more about, as you're working with your ACE group, what you guys bring to that process?

Dan Hendrickson: The big thing is AI makes it so easy to get started, and what I always encourage folks to do is you need to have those business requirements conversations with your stakeholders. You need to recognize that you're going to iterate through this thing so quickly, and you're going to end up with a product so fast. Take the time that you saved to make sure that you've got a really robust understanding of exactly what the business needs and all the nuances.

Little things like: does this form need validation? If I'm entering a purchase order number in here, do our purchase order numbers always follow a certain pattern? Should it error out if I try to feed something else in there?

So, go on a little roadshow internally and spend your time savings there to say, "Hey, we're exploring building this tool. Here's what we understand the requirements to be. Let's mock it out in some sort of flowchart." The time that you spend there in getting all your stakeholders aligned will save you so much time and frustration later as you're trying to iterate and bake all these enhancements in.

Again, that AI, trying to be helpful, might try to continue to bolt things onto something that architecturally wouldn't have been built that way from the beginning had it known all those requirements. So spend the time with your business. Make sure you've got a really clear understanding upfront of exactly what you need. Make sure that you've got all that context you can give to the tool as you start down the journey because, man, it's so exciting.

I'm a car guy, and it's like I've got this Ferrari 488 Pista sitting in front of me idling, and it's ready to go. I need to run some errands, and I just want to jump in it, but I don't really yet know where I need to go or what order I should go there in. It's worth a minute. Let that thing idle there for a second, and go make sure I've got an understanding from everybody of where I need to go, what I need to do when I get there, and what order I should do it in, so I don't waste my time.

Chris Willis: Yeah, I love your analogies. We've talked a lot about this sort of new framework for process where you start with the prototype, but you start with the prototype in a more disciplined way. So the work and the discipline is shifting. How do you see people's roles? Are there certain people who are really good at this, or can anyone be good at this? Or is there a different sort of team dynamic that you look for, or that you encourage, or that you've seen out in the field?

Dan Hendrickson: Yeah, I think the things that are most helpful are two things: first, just being really curious. I love the concept of starting with "why." When you go on that roadshow with your stakeholders, you're going to find all sorts of suggestions of things that it should do. If you have the conversation around why—understanding, "Hey, why are we doing this?"—a lot of times, it's just the way things have always been done. And if we look back and recognize that we are truly reinventing a process and have a blank slate, what do you want to do? Just be really genuinely curious.

Coupling that curiosity with how this thing works, and using that to have conversations with those tools, you're going to get way better products. You want to be thorough, and we all know that leadership everywhere takes what's delivered and wants it even faster. The expectations are higher than ever regarding the speed at which we can move.

My advice is to take advantage of that speed to quickly get a prototype. Make sure people know that it's a prototype. If there's buy-in from the business, then you can invest the time in getting really curious about all the needs. Don't let that curiosity stop at the surface level; go really deep and understand, "Hey, why are we doing this? Who is this going to benefit?" Get all of the detail that you can—don't stop one or two layers deep. Go deep.

Have the patience to visit all the right people because when it comes to meeting that expectation of accelerated delivery that AI allows, I promise you that you will be much faster in delivering a usable, final solution. I say "final solution" in quotes because I don't know that anything is ever really complete in today's world—it's always a work in progress. But you'll deliver a usable solution much more quickly if you take time after that initial prototype to truly gather all the requirements and needs of the business. Understand the "why" behind it all, and get those together.

If you quickly build something and it fails 45 times in your subsequent iterations, you're going to lose trust with your stakeholders, and it will take you significantly more time trying to iterate on something that isn't correct from the beginning than it would have taken to gain that understanding of exactly what you need upfront. But that innate curiosity to understand why we're doing this, why it needs to do these things, and why the tools should be architected a certain way—those things are really helpful. A curious personality who takes the time and has the patience to really dig in and gain an understanding of what they're doing is going to have better success.

Chris Willis: Yeah, I don't know if you realize you're doing this, but you're definitely calling out some core tenets of design thinking, where you have to go out and, if you want to be very innovative, connect dots between things that people haven't made connections between. But at the start, you have to collect the dots. You can't do it without more dots, and so you do need a lot of curiosity. In design, that's a job requirement.

But I think also, there's a bit of a challenge there for people because curiosity without actually turning it into something testable is just entertainment, right? You just become a consumer of it. So I find that the really effective people turn that curiosity into things that start conversations. A lot of times they might not go anywhere, but they're building stuff, and I think these tools are letting us build things that otherwise would just remain as curiosity.

Dan Hendrickson: Yeah, it's really interesting.

Chris Willis: So, Dan, one of the things I've noticed is that working with you and going through this sort of new emerging framework for developing things has really changed how I use the models. Instead of just putting in a detailed prompt and then trying to get a design or an app, what I've noticed is I have to shift the work burden more onto myself with the model by saying, "Okay, let's do a lot of thinking and planning before you code anything." I literally have to tell it, "Do not code."

And what I've noticed is that, first, it can be kind of frustrating because the models do have certain kinds of patterns they've seen before and they spit them back out to you. When I see that, it gets a little frustrating, so sometimes I have to realize that I need to break this down into little bits and pieces, which takes me off in a different direction. I also have to be careful not to ask it for strategic advice. The models are really not good at strategic advice. If I say, "Hey, create me something super interesting that no one's ever seen before that's going to make me a billion dollars," it will give me some designs and a business plan, but it's not anything that's actually going to work.

So what I've noticed is I have to learn on the fly how to either start a new conversation, or take a prompt that it was writing for me and distill that down into something that is useful. How do you see the work and the skill set shifting from where it was?

Dan Hendrickson: Yeah. Let it know that we're in planning mode. Like you said, tell it: "Do not write code." Some of the tools out there have a "plan mode" where it literally is like, "Hey, we're not building anything yet. We're in this planning phase."

We've talked a lot about the fact that there's still a lot of work. The thing that I really enjoy about this is that, historically, all of the work went into understanding the contextual nuances of programming languages, like "I need a bang here, a period here, and a caret over there." That always drove me crazy because there was just such a high level of specificity. The thing that I love about this new AI-powered world is that I think it's a lot easier to bridge the gap to knowing how to be thorough and thoughtful and get a really great solution out of the AI than understanding what is the most programmatically efficient way for me to structure this loop, or nuances like that.

It's still work, but put it in plan mode, have conversations, and use them for what they're good at. They're great at riffing on stuff and bringing up points. Just be specific with it, take the time to learn and understand, and point it in the right direction. It's a ton of fun. I love where it's gone. I think about where we were a year ago, and I cannot wait to see what we're doing a year from now.

Chris Willis: Yeah, I think for a lot of people, the models actually don't have to get that much better to potentially really unlock a creative renaissance for many people who just haven't had access to it. Being proactive and saying, "Okay, like we talked about earlier, if you just skip to the prototype, you might be not just short-circuiting the kinds of capabilities that you could provide to your team or your company, but you might be short-circuiting your own creative journey." That creativity is going to become more important because the tools are getting more powerful.

So, the specialists who do focus on the code nuances—while very valuable—are going to be joined by people who have maybe much more interesting, bigger ideas but never had a way to turn those into actual products, experiences, or any kind of artifact. What I've learned from you is we have to add planning mode to our work in a way that we haven't, and that's going to force us to learn a little bit more about things we were a little weak on. I've noticed I've had to learn a lot more about aspects of data structures, security, and efficiency around code. Now, I may not be writing those things, but I have to make sure I understand them because if I'm thinking very hard about planning mode, I'm thinking not just about the thing I want to see, but about how it has to work. I think that is a discipline that used to be in different silos in an organization, but they're all kind of coming together.

Talking with a lot of leaders at other companies who are wrestling with AI, I think it is affecting the culture because they're realizing that they might need slightly different people, or they need people who will be working in ways that they haven't worked before. In a way, it's kind of a rise of people with range, or generalists. Many organizations are not set up to really leverage those kinds of people; organizations are set up as "stay in your lane" machines. AI doesn't care about your lanes, and it's also encouraging other people not to care about those lanes. Sometimes that can cause a bit of friction, but ultimately, it's going to be really beneficial not just for organizations, but probably for a group of people who have been overlooked for years because they weren't the specialists that fit very well within that organizational structure.

Dan Hendrickson: Yeah, you brought up a few things there that really struck a chord with me. One, I think it's important for people to remember that the "A" in AI stands for "artificial." We still need really smart and really innovative people creating the content that the AI consumes. I don't think we're in a world where there's a lack of need for human-generated things. So I think it's important for people to consider that.

To your point about generalists, I think it does open up the audience. We all know things about different personalities; typically, people who are really creative aren't very well organized. So people have kind of fallen into their lane or their role based on some of those strengths. I do think that this gives people the ability to drift around a little bit more and provides a place where some of those talents can be leveraged a little bit better to help generate some of these great outcomes.

Chris Willis: One of the things that you called out was using AI to address a bunch of problems that otherwise would go unresolved—the "long tail" of problems. The world is filled with these, but most of them in traditional product development never rise to the point of being actionable because it requires just too much work, too many resources, too much capital, or other things. But AI is changing that equation. Can you talk a little bit about what that future looks like when, all of a sudden, the world of solvable problems really opens up, and what that means for the kinds of people who want to solve them?

Dan Hendrickson: Yeah, it's amazing, you know, just a couple of short years ago. I think it might have been 18 months ago. I think it was Domo Palooza 2024. I spoke on some new automation tools that Domo had released, and I was talking to folks about how they put them to practice. I borrowed this matrix from Boston Consulting Group that had value and frequency on the two axes, and it divided it into four quadrants. I encouraged people, saying, "Hey, as you encounter all the needs of your business, and all the things that you want to automate, place them on this matrix and you need to consider how often they're occurring and how much value they bring to the business."

The upper right-hand corner was obviously the area where you had things with high frequency and high value, and those were the targets. The reality is that matrix is just constantly having new things pop up on it all the time; things are moving around.

One of the things I love about how quickly we're able to deliver solutions is some of those really obnoxious things. Like, if you've got one that's way high up on a frequency level and way low on a value level, you've got some poor audience of people out there—not "poor" in the literal sense, but "poor" in the sad sense of people that are out there performing these low-value, menial tasks. The speed at which we're able to deliver some of these solutions allows us to get way further down and to the left, which really brings huge quality-of-life improvements for people. Nobody loves doing high-frequency, low-value tasks, and I love how we're able to help solve some of those challenges that otherwise...

Chris Willis: Otherwise, yeah, I think we're energized.

Yeah, those are the kinds of projects that would never get prioritized, and I think we're starting to see that shift happen throughout enterprises. There's a lot of talk, obviously, about the SaaS apocalypse, but this is kind of different in that those long-tail of problems represent the kinds of things that, to your point, are of low value and kind of ended up as Excel spreadsheets, for the most part, or tiny little applications.

But on the flip side, there are many organizations that have actually spent a lot of time, effort, and resources buying big solutions, only to find themselves using a small portion of them, or maybe they weren't tailored directly to the way their organization worked or the way their people liked to work. So you run into this problem where they've had to live with that. I think AI does open up options, if some of these other things can be figured out—and I think there's other infrastructure, software, probably middleware, models have to get better, and harnesses, et cetera. But creating much more bespoke experiences and applications that do just what I need them to do, when I need them at this moment, is incredibly exciting.

That is a very, very different way of looking at things because the scale, economics, and intelligence have completely changed what can be coded and what that costs, and so that changes the conversation.

Dan Hendrickson: Yeah, it's interesting, right? When we look at these low-value challenges, it's funny, as I have conversations with people around it, a question I am innately curious about and always ask is, "Well, so what happens if that stops?" And the value quickly becomes apparent because people don't want it to stop. But it's not viable enough that you're going to go out and, like you said, license some big solution that's going to require a bunch of configuration, where you're really only going to use a subset of it.

So that's a great point that you bring up about the ability to quickly deliver really bespoke solutions that work to the very nuances of your business. That's one of the things that's so fun when I have conversations with somebody and they're excited about a piece of functionality in software that is a way larger solution than the problem they're experiencing. The ability for AI to help right-size that and let us really build that bespoke solution—it scratches that really annoying itch that exists for your organization in a way that doesn't exist for others.

Chris Willis: I love your question of very simple: "What happens if that stops?" That's a great way to help people understand: Is this something worthwhile doing? Is this something we need to think deeper about? Is this something we need to build more safeguards around? That's super important.

I would also add, just from my background in design, I definitely see with these bespoke apps a shift in how people are going to be interacting with applications. One of the things you don't want to do is start creating layers of complexity in the organization where you're just creating a sea of applications and creating just a lot more work for people to figure out like, "Well, I've got to go to this app to do this thing, and it's not integrated with that thing." We know what happens in organizations when complexity is added; workarounds pop up. People will do things that they wouldn't typically do or that don't represent anything on your process or your org chart. People are the ultimate X-factor. How do you see organizations either navigating that, or do you see something bigger at play?

Dan Hendrickson: When we go back to that curiosity thing that I hit on earlier, I can't tell you how many times—we've talked a lot about apps as well—I've started a conversation with a customer about an application they want to build. One of the things I love about my job is I get to ask "why" about a zillion times a day, and oftentimes we'll uncover something. Someone will say, "Hey, I need to build an app that makes it really easy for these guys to come and disposition these things."

   "Why?"

   "Well, because..."

   Okay, well, when someone looks at that—let's say that I'm the one dispositioning—what logic goes through my mind when I disposition that thing? They'll walk me through the process, and I say, "Okay, well, why?" Is that always deterministic?

Oftentimes, what we end up building are simple automations. I've helped folks in situations where they've taken an app that was totally over-architected because the reality was, nine times out of ten, there's a very deterministic process that it goes through, and we can really consolidate that app to only handle the exceptions and the outliers.

So, while we talk about AI and apps and building those, I want to make sure that people don't overlook the fact that a lot of these processes can exist either in an agent or a deterministic nature that can just do its thing behind the scenes and really only involve a human or an interface when that input and decision are needed. So, some of the best AI is maybe not AI. And the way to get to that is just by asking a simple question: "Why is that the thing?"

Chris Willis: Okay, that's great, great advice. I love that. "Don't forget the AI, AI would be time-efficient." That's like great, that's a great quote. I'm going to use that. I'm going to steal it; I feel it coming.

Dan Hendrickson: Do it.

Chris Willis: I probably stole it. One of the things that might be useful for everybody here is we begin to wrap up is that Domo has a state of the authentic AI guide with lots of ideas. As Dan mentioned, everybody is kind of living through a very interesting, disruptive, and innovative moment. And so, the folks that are starting to figure this out earlier rather than later are going to have a much greater lead in this race. So, we hope you get to check that out.

Of course, anybody out there who wants to learn a little bit more about Dan or the ACE program, or has found themselves in a plausibility theater situation where they're staring at a prototype and nothing more has moved—if they want to get engaged with ACE, how do they do it and what can they expect?

Dan Hendrickson: Yeah, so Chris, I launched the ACE program and started that because I recognized that we have so many really savvy and really smart people who don't want things done for them. They just want to be enabled. They want to know how to do it, but they need to move quickly. And as fast as AI is accelerating learning, you really cannot beat the ability to just phone a friend who has done it before.

And so, if you are building in Domo and you want that ability to phone a friend, that's what we're all about. Reach out to your account team. Let them know, "Hey, I've got some interest in the ACE program."

We have an amazing team of folks that includes—Chris gives me way too much credit; I ride these guys' coattails through the building every day—but this team includes machine learning engineers, classically trained data science people, and computer science. We've got the gentleman who managed Domo's internal environment for 15 years on that team.

So, the amount of knowledge and experience that's available through the program is really unprecedented, and it's amazing, and it's super fun to see. What it looks like for our customers is you get access to the group. You get a named individual that you work with on a day-to-day basis, but you've got access to everybody. You can hop on their calendar, you can grab time with them, whatever you want. I have all the confidence in the world that if an ACE customer wanted to have a conversation with one of us about a certain topic today, they could get time to talk with us today. That's what we're all about.

I would love to welcome anyone watching this into the ACE program and work with you. Just reach out to your account team, and they can let you know what that looks like and even set up an initial conversation with us before you make any commitments or anything.

Chris Willis: Well, again, everybody, we've had a super opportunity to meet with one of the smartest people in the building, Dan Hendrickson with the ACE program. Dan, thank you so much for sharing your insights and your time today. We love to have had you here.

Dan Hendrickson: Chris, thanks so much for having me, man. I could talk about this all day. Hopefully, I get invited back. I'll welcome the opportunity, and thanks again.

Speakers
Chris Willis
Chris Willis
Chief Design Officer
Chris Willis
Domo
Chief Design Officer

As Domo's chief design officer and futurist, Chris' hyper focus on combining data, technology and emerging trends in innovative ways helps to make Domo an indispensable platform for its customers. He has nearly three decades of design leadership experience in web, mobile and data visualization. And as one of Domo's earliest employees, he's involved in every aspect – from initial design, strategy and execution – of building and developing solutions that solve even the most complex problems faced by customers.

Prior to Domo, Chris co-founded HOUR Detroit magazine and Footnote.com (now Fold3.com), which was acquired by Ancestry.com for $27 million. Before moving into technology, he was an award-winning illustrator, journalist and author with multiple published works to his name.

Dan Hendriksen
Dan Hendriksen
Director, Advanced Customer Enablement
Dan Hendriksen
Domo
Director, Advanced Customer Enablement

Dan brings 25 years of experience driven by a deep curiosity for solving complex business challenges. As Director of Advanced Customer Enablement at Domo, he leads a team dedicated to empowering customers to unlock the full potential of the Domo platform through innovative solutions and strategic guidance. Dan thrives on understanding diverse business needs and crafting tailored approaches that help organizations maximize value from their data.

Before joining Domo, Dan held entrepreneurial and leadership roles across different personas and industries, consistently leveraging data to inform decisions and drive growth. His broad experience fuels his passion for continuous learning and creative problem-solving.

A lifelong musician, Dan enjoys expressing his creativity through piano, saxophone, and guitar. When not working, he loves spending time with his family, traveling, and exploring the world on two wheels.

AI can spin up a slick prototype in seconds, but a demo that looks ready and a system that actually ships and gets adopted are two very different things. In this episode of Domo’s podcast, Governed Data for Agentic AI, Chris Willis, Chief Design Officer at Domo, speaks with Dan Hendriksen, who leads Domo’s Advanced Customer Enablement (ACE) program and spends his days helping customers turn AI experiments into things they can actually run. He’s watched the same patterns play out across build after build, and he’s here to share what separates the projects that ship from the ones that stall.

This conversation is all about “plausibility theater”: the trap of building something that looks like it should work but quietly skips everything real systems need (user volume, concurrency, security, edge cases). Dan explains why the planning conversation matters more than ever now that AI has taken the developer out of the loop, why “do not code” and plan mode are becoming essential habits, and why the time you save on a prototype is best spent up front with stakeholders instead of iterating 45 times on the wrong thing.

Chris and Dan also get into the bigger shifts AI is setting off: the rise of curious generalists over stay-in-your-lane specialists, the long tail of low-value problems that’s finally worth solving, and the move toward bespoke apps that do exactly what a team needs. Along the way Dan makes the case that some of the best AI is maybe not AI at all, and that it all starts with a deceptively simple question: Why? Listen for a practical, field-tested take on getting past the demo and building AI that ships and works.  

After listening, you'll learn:

  • What “plausibility theater” is and how to avoid it
  • Why the planning conversation beats jumping straight to code
  • How roles are shifting toward curious generalists
  • When the right answer is a simple automation, not an app
No items found.
Explore all

Domo transforms the way these companies manage business.

An X in a circle
AI
No items found.
An X in a circle
Resource
Video
Adoption
1.0.0