Jeff Breunsbach: All right, welcome back to another episode of Chief Customer Officer.io. This will be coming out to you on Thursday, June twenty fifth. Jay, how's it going?

Jay Nathan: It's going great. I'm in Seattle. Beautiful here. No rain. I guess it doesn't rain this time of year here, which is cool. going to my first my first pro football match, World Cup game. So that should be that should be interesting. I've I've been watching a lot of it on TV. Have you been watching the World Cup? Yeah? You're a soccer guy.

Jeff Breunsbach: That's nice. Yeah, it's coincided nicely with paternity leave, you know. It's been nice to but it's honestly one of those things I would say like we try to not let our kids watch a lot of T V, you know. I mean they're one our oldest is four, so like we're not you know, he's not binge watching T V or anything, but it's just something nice to have on in the background to be honest. Like you can kind of you know, like I I'll watch the USA games in intently, but like yeah, like I forget it's like Scotland, Brazil today, which is like mildly interesting to me. So I'll have it on the background, so

Jay Nathan: Yeah. Yeah. yeah. Yeah. Yeah.

Jeff Breunsbach: We've been watching a lot of it, yeah. So so much so my wife has has already made comments like, All right, how how much longer is this thing? You know, like how many how many more days is this?

Jay Nathan: I have no clue. I don't understand any of it. I I understand the games. I just don't understand anything about like the structure of the tournament itself. So I'm just I'm just along for the ride. But anyway, well good. Yep.

Jeff Breunsbach: Yeah. that's cool. Yeah, we're we're surviving over here, you know. nothing too I don't know, dramatic. Everybody's happy and healthy. We've got a third third child now, so I would say we're just trying to find our we're trying to find our rhythm and routines. And it's so far so good. Yeah, so far so good. so far it's it's been good, but I'll definitely say we're starting to see some of the cracks of attention being attention being shared. You know, everyone loves the baby, but at the same time

Jay Nathan: Good luck with that.

Jeff Breunsbach: You know, we've gotten some some children I don't know, going backwards in some areas. our our twenty our twenty month old right now, Elliot, is his favorite word right now is no. And I can't stop laughing at it because it's very cute when he does it. And my wife is like, You gotta stop laughing. But you I'll give you one example and then we can move on. But he you know, you'll be it'll be like si six thirty or whatever, trying to go to the bath. Elliot, you wanna go take your bath? No. And then he just starts running it from you, you know, immediately, just like as soon as you start

Jay Nathan: Yeah. A voice. Yeah, that cute.

Jeff Breunsbach: Elliot, do you wanna you know Elliot and then like now my favorite is like his no yes. So like I the other day I set up a little water slide out in the back and I like, Elliot, you wanna go on the water slide? He's like, No, yes. Like but his first like immediate thing is just no. It's so funny to me. so I'm currently laughing at that quite a bit.

Jay Nathan: boy. boy. It's a lot. All right.

Jeff Breunsbach: well let's jump in. Well I know we were just before this, we were talking about something that we just thought was interesting. And so I I would say like the thing, you know, the last week or so, I've been trying to binge watch I would say like more content than I have been able to, you know, over the last year or so. And now that I've got some some more spare time. So I've been watching Claire Vaux, who runs a podcast called How I AI. It's part of Lenny's newsletter and and kind of his network. And she's a former, I believe, chief technology officer or maybe chief product officer. I think she worked at like Launch Darkly and some others. Like she's she's kind of become you know prominent in the space. and it's to me it's been awesome content because she brings in some really prominent leaders around across product and engineering and honestly like a lot of them are showing their screen and kind of doing the stuff that we enjoy, you know, kind of actually like showing their work.

Jay Nathan: Yeah.

Jeff Breunsbach: and one of the the things that caught my eye, which I have found myself doing, is one of her guests, and I'll have to find his name by the time we got get off here, but he created a public GitHub repo for two tasks or two skills sorry that he believes are are like pretty foundational to what people should be doing. And one is around creating a PRD, which is a product requirements document. and the second is what he calls generating tasks. And so I guess his whole his whole message in ethos was basically like, yeah, it's cool. Everyone's got the ability now to go vibe code and you you've kind of got this stuff at your fingertips. And people are just running with that. And that's great, right? You kind of get innovation from that, you get a lot of early movers, like there's a lot of just, you know, you could basically you're throwing a lot of spaghetti at the wall, seeing what's sticking. There's there's some good in that. But I think he's kind of alluding to this fact now that like, okay, we need to start shifting this evolution and trying to help people with this newfound power understand that like actually your AI and the skills and the the kind of tool set that you have now will actually do better if you start to kind of I call it building bumpers on a bowling lane. But you know a PRD document I would say is is something that's been established between product and engineering teams where, you know, we're you're trying to lay out functional requirements for what's being built, why it's being built, what's the goal. is there anything you don't want it to be almost like the anti goals? you're you're trying to build kind of a a list of of these things. And so anyways it got me thinking about how I I've felt like myself doing this where you just start building something and all of a sudden you're just kinda like, I don't know, ten steps in you're like, man, like I I kind of even know don't know what I built. And now I've got a I don't know, I've got a menu on the left of like twenty things in a menu and you're like, well man, like I

Jay Nathan: Yeah.

Jeff Breunsbach: What is this like, you thing that I'm building? And so I don't know, it just got me thinking about how like this idea of product management I guess has been interesting to me, right? Like the idea of trying to solve a problem and what's the problem I'm actually trying to solve and am I actually building the right solution? I guess is like where I'm coming to over the last week, which is interesting. and so I don't know. I don't know if you've got any like immediate thoughts on it, but I think like this. whole kind of creating PRDs and and I can talk about the generating tasks in a minute, but this is just what's I don't know, I found it interesting of the last week.

Jay Nathan: Yeah, and I think so the maybe I'd boil that down to say like there's a big difference between building like engineering a product or engineering a production system and vibe coding it. Right. And I think what we're seeing right now is a lot of a lot of folks are vibe coding stuff, which is cool. It's a great way to learn. And we keep, you know, the the learning and the experimentation continue continues to happen. But when you're building Something that has to run in production, it has to be reliable, right? Then you've got to you've got to start breaking it down into its pieces and understand how what you're adding to it or removing from it will impact that. And you know, to your point about like having a menu of like tons of items, like the thing that I keep running into, that there's this skill in product development, which to me is one of the most important things that a product person can do is you you set it, start with a goal in mind and continually strip things away from it, what you're building. Like it's not about building more, because we can build more all day long now. It's about building and then pulling everything away and continuing to iterative iteratively simplify the thing that you're building. But I what you're what you're also describing is a transformation that product that IT teams are going through as well because operations and operations teams, IT teams, they are having to become product teams now, right? To build the the data layer, the agent layer, and the workflow layer, whether that's builder buy, to put all those pieces together for the business that they're working in and with, right? For the people that they're working with and trying to deliver for. So

Jeff Breunsbach: Yeah, and I think like the I guess like the other thing that's been interesting for me on this too is that like as you're starting to think to me, I guess this is like helping people or at least for me, the research that I've been doing over last week has helped me, I guess, better start to understand about how you move from single player AI to multiplayer. I keep talking about this, but I just I still continue to think that that is like the largest gap that enterprises have right now, right? Is like this idea of And so to me, I think that's that's the evolution and shift too of like, okay, like you said, if I'm gonna cool, I vibe coded my own like I vibe coded my own little project management tool at junction and it it pulled in my Gmail and my linear tasks and all this stuff, and I would have like a triage in the morning and stuff, but that's like single player AI, and it's like cool. I'm I'm just now seeing my only tasks.

Jay Nathan: If you're if your account goes away, like if you were to leave junction, that whole thing goes away, right? Because it was built under your Gmail account, tied to your Cloud account. Like that's the quintessential definition of of single player AI. It's cool. It's cool and it's useful for you. But yeah, it's not it's not something that the organization is getting benefit out of other than through you as the the person who's running that stuff and is

Jeff Breunsbach: Yes. Yes.

Jay Nathan: Yeah.

Jeff Breunsbach: Yeah. And that's like a that that's a very great depiction of it because that that's the way I started feeling was I started thinking about this from a PRD lens of like, okay, you know, how would I what are the what are the requirements in order for me to roll this out to the entire team? Okay, well I would need to figure out like how can this skill get loaded across Claude for my other teammates? How are they pulling in the same systems, integrations, tools, data layer? Like how are we all leveraging that same stuff?

Jay Nathan: Yep.

Jeff Breunsbach: And then, you know, how does this get loaded into an interface that they can interact with? Right. Like right now I'm just doing it in cloud code, but it like if this is going to be probably used by my team, it would need to be. So I don't know. You just start, I know. I guess you start thinking about it in, like you said, in terms of like an enterprise ready solution of like, my team's gonna have to log into something to use. And therefore, like that that requires a different level of authentication and how are you gonna bring in the right tokens and API keys and all the stuff that you know you you just kind of don't think about when it's just individual.

Jay Nathan: it Yeah. It's it's a s it's a sweater that quickly unravels when you start pulling one thread, right? And just the tokens alone. We talk about token usage a lot here, but I mean think about it, just because you you have a skill that you share across the team, you might not want everybody to go run that skill across the same account, call transcripts, everything else. You've already done that once. So then where's the repository? Where's the landing the landing spot for

Jeff Breunsbach: Yeah.

Jay Nathan: the thing that you just generated, there still needs to be a system of record for that, right? Where where that gets captured and tracked longitudinally over time to see what the what the changes are. And so you know, I think all this points back to there there's three enterprise layers. There's the data layer, there's the agent layer, and then there are the workflow tools, which again are like the landing spots, the systems of record for the data itself. Some of those you might buy, like a CRM.

Jeff Breunsbach: Yeah.

Jay Nathan: I would not recommend building your CRM, at least yet today. But some of them you're going to build, like the CS platform. I think there's a clear case for starting to build something like that. And you know, the more the more time that passes, I think that's a good use of time is to build your own CS platform. Maybe there'll be accelerators and tools out there to help do that faster in the future. Maybe we have some ideas on that that we're not going to talk about here. But but yeah, so But th those are the three layers, but they've got to be enterprise layers, not single player layers, so to speak. They and in MCPs, that's one thing, right? MCP servers are are one thing, but having a curated data set that you can work from to do you know durable business processes, that's a that's a different thing altogether in my mind.

Jeff Breunsbach: Yeah. And I think that Yeah, well you talk through the different like how do you see the differences in that? Because I I think I under or let me play it back for you where I think like the MCP essentially I guess grants you access to go kind of pull from the systems what you need, right? Hey, I I've kind of got access now to the system in a language in a way that I can interact with, like in a cloud cowork something that like allows me to do that. But I think what you're alluding to is like, yeah, but that that still leaves a lot of room for error because now you're just allowing anybody to access anything in their own way in their own context, but you're almost saying we should actually get back into like how do you start to structure some data sets from that MCP or from that main data, structure some data sets so that we're again we're all prompting the same data. It's not it's almost like similar to like we're all looking at the same dashboard, we're all looking at the same report, right? Because pretty quickly you could see, I've got access to the MCP and all of sudden, I don't know, 13 steps down the line, it's like, well, why is Jeff why is Jeff's segmentation A look different than Jay's segmentation A?

Jay Nathan: Yeah. Yes.

Jeff Breunsbach: And why does, you know, why does ARR look different for Jeff's accounts, you know, one, two, three versus Jay's accounts, one, two, three? Like why are these things separate? And it's like, because we're all maybe using the MCP, you know, we think in the same way or we're trying to use the same thing, but ultimately like it it's better if you actually structure a data set that we're all then pointing to and saying, Okay, this is the accurate of data set that we should all be relying on.

Jay Nathan: Yeah. I mean you could even technically solve that by coupling a skill with MCP, like hey, when you pull revenue out of the system, here's the way to interpret revenue and report on it always. Right? And then the the LLM may or may not follow the instructions. That's a different issue. But that you know, there are there are ways around that. I've been trying to explain this a little bit and so check me on this, help me explain it better. but I think, you know, from from my point of view, MCP is like, okay, if I were

Jeff Breunsbach: Yeah.

Jay Nathan: the person with access to all the systems doing this manually, here here's what I would go do. And it's it's very it it I would go look up the record in Salesforce. I would, you know, I would pull a report in Salesforce, I would throw that in the spreadsheet, and then I'd go look up you know records out of my invoicing system or my my general ledger and figure out what the revenue is associated with that. And I'd try to connect them together. I might do a V lookup to link both things together. you know that

Jeff Breunsbach: Yeah.

Jay Nathan: So MCP is basically giving us the ability to go pull data out of systems in real time and connect it together and do something interesting with it. It's it's still pretty token heavy. It it it's doing a lot of work for you that you would normally do otherwise. So you know, there's a cost to that. It's not your time anymore. It's tokens. Okay. So think of it as like automating the manual stuff that that you would do today. The difference in like curating a data set, what if you had a Master customer database in Snowflake, right? Set of tables that's like, hey, when you go read from this table, this is the for sure, these are our customers. This is for sure how much they pay us in ARR. This is for sure their billing history. This is for sure. Like and to be able to ha not have to interpret that every single time I do a task through Claude or any other agent.

Jeff Breunsbach: Yeah.

Jay Nathan: That's efficiency. That's that's where you get the token efficiency from. I don't have to go calculate everything. I don't have to go reconnect all the data every single time. I've already done that once in the in like the master files. I was talking to a colleague of mine yesterday and he was, you know, talking about vendor master files. Like who are all the people that you have to pay for the services that they provide to your company? That, you know, you should have a master vendor file that is already curated.

Jeff Breunsbach: That's right.

Jay Nathan: Clean and you know what that is. And you don't have to build a big data warehouse. You can start with one data set at a time. I think in the world that we spend a lot of time talking about, the obvious place is just a customer master file. I've been working with a friend of mine who you know we're just chatting about how to sort of accelerate their AI efforts in his company. They have three CRMs, three three instances of Salesforce. You think they're ever like, how does MCP work in that environment? Well, you're gonna have to have three MCP servers connected to three different instances of Salesforce if you want to get any view across. Gonna be very expensive from a token usage standpoint to go do that. So let's go create a a master data file. Like it's gonna take you three years to merge those Salesforces into one because of all the business processes and workflows built on those. So start by creating a common, you know. customer master file that sits on top of that and brings everything together in one view. I think that to me is a logical starting point. And then you could put a lot of things on top of that. Agent workflows or agents and then workflows on top of that that go back out into Salesforce in that case. Does that make does that resonate at all?

Jeff Breunsbach: yeah, no, it does. which is I I think I think somewhat funny. It's like a circuitous thing, right? Like I I think maybe 10 years ago when you and I have have been in customer success, important thing 10 years ago is data. Like you know, ha accuracy of the data, how do we start using it better, how do we start pulling it from systems, and like we're still in the same it's still the same thing, right? Like we no matter the tool set that we have, it still is reliant on the context, and context is reliant on data. And so like therefore, like you still have like this. need to make sure we've got, like you said, repositories and clean places. And I think like maybe the thing that I would just explicitly say, and I I think I'm interpreting what you're saying, but like when you when you say like a master customer file, I do not think that you mean like, hey, we have a Google Sheet of like master you you actually mean like we have we have a database table, we have a database table that essentially like is scrubbed or cleaned in the right way, that is like up to date, that has processes that surround it so that we know, okay, this database table is

Jay Nathan: Yeah. No. Yeah. Yeah.

Jeff Breunsbach: Kind of if I always access active customer database table, then active customers, you know, I can for sure know the business processes that you guys have cleaned it up on any church. you know, it's in interpreted any upgrades or increases. Like anyways, there's there's things that surround it, but y that's what you mean is that like ultimately these things end up living living in databases, not a Google Sheet. I just heard that Yeah.

Jay Nathan: Yeah, yeah. Hundred percent, yeah. Yeah, yeah. I I'm using like old school direct marketing terminology by saying the word file, I know, but like that's conceptual, right? Like the the conceptual thing, but yes, it's the the like the clean canonical set of data about your customers. So yeah.

Jeff Breunsbach: Yeah. Got it. Yeah. Okay. cool. I'll just share this w real quick because I th I just want to talk to you about the other part. So this is this is this this PRD skill that I created. So the thing I think is interesting is like I specifically ask it to to ask me questions. And so each time that I'm building something, it's going to come back and start to focus on like, okay, what problem does this solve? What's the core functionality? What scope is this? What's success criteria? Who is this actually for in terms of users?

Jay Nathan: Yeah.

Jeff Breunsbach: And so it's got a clear set of like every single time I suggest, hey, I should go build this or I want this to be in part, you know, a PRD, it's coming back and asking and making sure that it's clarifying itself. And that's context it can use to go better build something. But it's also, I think, helping me like build something better because it's actually challenging and asking me, okay, like, is this the right thing to be building? Are you sure you understand what the actual goal is? Like, you know, it's it's and then it just goes to generate this whole, you know, PRD based on

Jay Nathan: Yeah.

Jeff Breunsbach: Nine different criteria. Again, I think this might be overkill. I could probably, you know, chop this down a little bit, but at least I guess like at the end of the day, what I'm learning from this is like this actually ends up all being context for AI. So that when I want to go build something and I say, hey, let's go build uncommon circles, then it doesn't just like take a three sentence description that I say of like, this is what I think I want. It takes this whole nine part architecture and says, okay, like I've got a much better understanding of like what you're trying to do. And I think specifically where I've noticed a lot of things get better, are these like three areas. The non goals. So like what's out of scope? Like what do I not really want to build? what are the design considerations? So like how do I want this to look and feel? I would say like you know, like that to me has become a big part. And then like technical considerations too. Like what where where does this need to map to in terms of other systems or integration points? Like what needs to be pulled in. So like those are three things that I just felt like I probably wasn't thinking about enough that this is like introduced. and so then like the on the back of this PRD process, there's another skill that I built, which is generating tasks. And basically what it does is it goes through this PRD and it breaks it down into more chunked out work. I don't know the right word. More I guess tasks and subtles. And so the other part, or I guess like the to your point earlier, like There's final rules that I put in here. So like do not start implementing the PRD. Always ask clarifying questions. Always save it to linear file. So I have a local markdown file. Like confirm like which linear space you're doing stuff in. and then when I go to do something, I'm actually building out tasks and subtasks so that I can go see, okay, like where are we like where is this work actually getting done? Are we taking some of the right steps? and you can basically go start to have it execute certain parts of the step versus going all the way down the path before you get too far. So like

Jay Nathan: Yeah.

Jeff Breunsbach: I don't know. This is just an interesting thing I've I've been working on over the last week and try and like I used this guy's like public re public GitHub repo for some of this stuff and then I've tried to adapt it for a little bit of of what I wanna try and do. But it's been fun to do this.

Jay Nathan: You know, t to to the other like part of what I'm sitting here thinking is I've done s similar things, but I don't have a PRD skill per se. I just the way that I'm working with these tools is we're building and the big thing we're building is this agent command center thing. And it's got so many tentacles, it's very easy to get down a rabbit hole if you're just, you know, going, you know, vibing it so to speak, vibe coding it and then like I said we talked about before we started here. There's a difference between just vibe coding something and like, okay, let's just add this and add that. Before you end before you know it, you end up with a Frankenstein tool, right? But there's a difference between that and sort of designing something for production use. So but I I tend to do it a little bit more organically than having these big structured documents and just sort of chat with it about, hey, look, this is the subsystem I want to work on right now. like the part of this thing that I'm I'm focused on. And these other things may come come up and as they do, I'm like, okay, let's make a to-do item for that. And that ends up going into linear for us, right? As almost like a backlog item that we need to come back to and design. And even if I had thoughts on it, like, hey, here's how I'm thinking about this thing. How are you thinking about it? Okay, good. Let's log that away and do something with it. But I think like that's a you're right. That is a skill. It's a it's a s it's a focus thing because it's very easy to follow intuition. on this stuff. And, you know, the the AIs are whether you're chatting with it about a problem you're trying to solve or you're coding something with it, they're very they're gonna take you down the path that that that they think you're trying to go down. So I keep I keep forgetting the word for this, but they're they're sort of they they follow your lead, right? And and they don't really push back a lot. And so, you know, it's really your output's gonna be as good as your thought process.

Jeff Breunsbach: Yeah.

Jay Nathan: Your thought process.

Jeff Breunsbach: Yeah. That's like a great y like the the word I keep coming back to is like they're very agreeable, right? Like they'll just kind of keep going like, yeah, like let's just keep going down this. I can do that for you, sure. Yeah, let's let's keep doing that. Okay, let's keep going to the next step. And so like that's where I think this has also helped me, like you said, like having some structure where something is pushing back and saying, like, okay, what is the goal of this thing? And I think like the other day I wrote out a goal and it was like that's not a really clear goal. And it's like, okay, like that's

Jay Nathan: Yeah. Yeah, yeah, yeah.

Jeff Breunsbach: you know, this is not really a a clear outcome for like this this user that you're you're thinking is going to use this feature. So so yeah I think it's been a good th like thought partner and in trying to help you. it just reminds me maybe like a little bit of like how for years customer success leaders you know have have you know looked at product leaders and been like why are you building these features? You know, why are you building this functionality? It's not even helpful. It's not even whatever and you you know cool. Now people actually are just doing that ad nauseum. with your own vibe coding tools because you think it's the some it's the thing you think it's the thing that you should do, you think it's the thing that's going to solve something, but then like where does it fit in the grander scheme of like using a system, using a tool, using software. and like to to kind of go back to your point, like I I just think a lot about how like I think a lot of people are doing stuff on kind of intuition, gut feel, just like, you know, kind of like Hey, this is like a chat interface. This is like so easy for me to do. And I think like I think that you're gonna start to see over the next three to six to nine months, like more and more people start to adopt this idea of skills and trying to get like bumpers in a bowling lane. Like how do we start to okay, like we need we need some of these things. Yeah, we need some of these things to start basically honing in on like what we're actually doing. So it's been a fun little little exercise last week to just go down this path and look at some of these things that people are building.

Jay Nathan: Product development. Yeah, it's a good segue to another topic I wanted to talk to you about, which is like how are teams structuring, how are companies structuring these functions? So I was talking to somebody else yesterday who their their organization, this is a major, like large Fortune five hundred company, but they have structured their AI organization in a centralized org. and but they're not really It's like IT at this point, right? They're not really close enough to the business to to make an impact on it. and I think, you know, the other thing that I heard in a different call last week, I talked to a lot of people, you know, you that. I'm just like a busybody. But it was really interesting because one of the people that I was talking to, he actually listens to this podcast. He's gonna know who he is when I when I walk through this, but he he meant he's he's entrusted by his IT shop. with with a couple of things. One is building useful tools and two is token spend. They know he knows what he's doing, right? The rest of the organization doesn't they don't have the same a level of trust in in those there there there isn't a a guy that looks like him or a girl that looks like him in these other departments within the org. So they don't get the same privileges that he does. They are constrained by the amount of capacity that the IT team has to work with those lines of business and get stuff done. So and they're not gonna just turn the line of business loose other than giving them a claw license, maybe with limits, right? They're not gonna turn them loose to go create agents that can go run wild and and burn, you know, the the budget on all this stuff. I mean so I I guess, you know

Jeff Breunsbach: Yeah.

Jay Nathan: That's one of the things I'm really interested in learning is like how are teams really struggle or structuring these AI initiatives? Are they putting, you know, a four-deployed engineer into the ops organization for each of these teams? Cause over the past few years, as or over the past couple of decades, as systems have gotten more robust, like every team has ops, right? You have finance ops, you have product ops, you have customer ops, you have all these ops. folks sometimes are centralized into a a BizOps team, sometimes they're distributed, but there's sort of this direct line into the IT organization when it comes to the spend, because now the spend is getting centralized. So I'm just really interested in in how folks are are organizing around that. And I do have like a very specific motive for wanting to understand that because we're trying we're selling data and AI services now, right? Agnostic of any any platform. So

Jeff Breunsbach: Yeah. Yeah.

Jay Nathan: I'm trying to figure out it well like where's the spend? How do we get how do we help and become an extension of that team that's constrained, that can't get around all the other business units to handle the A P and invoicing, you know, use cases that need to be addressed. So I don't know what you've seen.

Jeff Breunsbach: Yeah. Yeah, there's well, I've got a couple of thoughts that I can share. I've talked to I would say like it's similar, yeah. I'm I'm less of a busybody than you, but I I've talked to a couple of people recently about how they're how they're structuring some of this stuff. So I think there's a couple of early thoughts that I have just on the like I guess the the core idea you're talking about, which is I actually think this PRD stuff could be helpful to you. And no matter no matter where this stuff rolls up into, whether it's a centralized team or it's not, right? If you can showcase that you have

Jay Nathan: Ha ha ha.

Jeff Breunsbach: ideas in a structured manner and that you want to go build something and having actual requirements around it. Like I actually think like your AI team would love that, right? Like they'd be like, okay. Like you actually have a structured use case. You've got you've thought about this. You know the systems you need to integrate where so I actually think like this whole idea of like you said, product product management, like taking a lens of that and trying to bring that to your rather than just going to your AI department and saying, Hey, I need a I I I need to go build a a tool that helps me listen to our phone calls or like that you know transcribes our phone calls or right. It's like, no, I need to be able to listen for I'm listening for these three things and here's what I want. Anyways, so I think that's like one. Two, is I I do think that this idea of like like you said, I think there's an interesting thing that people might be glossing over, which is and I want to emphasize what you what you said, which is like, yeah, there can be as much

Jay Nathan: Yeah, yeah.

Jeff Breunsbach: I don't know, AI and and forward deployed engineers as as you want, but like people who are in those departments that have been doing those functions for years have context and knowledge and like they've got an intimacy towards that function that like is actually valuable to producing the right tools, to producing the right outcomes. And so like, you know, I think there again, like I think there's always this fear-mongering of like, okay, you're gonna lose your job and like AI is gonna take over. But like I guess look at that intersection and try and and take advantage of that. Like, okay. I've been doing customer success for, you know, quote unquote, like 15 years. Like there's knowledge that I have and have gained of like the things, the processes, the systems, the reports, the things that we should be doing. Right. And I'm not saying it's gonna save me for the next 15 years, but like I think in this window right now, there's a valuable way that I could contribute to say, okay, how am I gonna help my team level up? How am I gonna take it help AI team level up so the business gets advantages? And like that's an intersection that like you should play at as a leader. So those are two thoughts, just like. Right off the bat. and then I've talked to two people, I would say like one similar kind of Fortune five hundred company and another that's like a v or not VC, PE backed business. The Fortune five hundred company is going a centrally deployed AI team. and then like you said, they've essentially got tentacles though into the ops departments. And so like I I I don't know the way it works right now. I guess like the way that I've hur that like it was kind of envisioned to me is basically like somebody from the ops department is essentially going to that AI team and is like the liaison on like AI specific projects. And then like they're they're getting from that centralized AI team what they're getting back into their ops and like what they're supposed to be bringing back is basically like, okay, you know, here's the tools that we're contracting with, here's like how we're trying to centralize data and try and get it clean like I guess the larger Like company-wide projects, like they're supposed to be like bringing that back to those teams. so that's like one thing that I've heard. And then the second, the private equity-backed business that I've heard about has one AI person. They've like hired a head of AI, but then like that person is essentially just going into each of those departments to effectively help them go deploy their own things. Like they're just basically saying, Okay, like I'm here to basically help you understand I guess what's possible or like what's here and then they're going to each of those teams saying, Okay, what do you need in this department? How can I help you basically like, you know, yourself go build this stuff? so I guess like two different approaches that from what I've heard in terms of like I guess ways to do it so far.

Jay Nathan: Yeah. Well, that that's interesting because so I I actually heard Garov from ClickUp was on the top line podcast last week and I've been listening to him and they created something they call a foundry internally. And the foundry is the team that's building the the core agentic machinery inside of of ClickUp for their operations, basically. Not their product. Although they build it on their product, I believe, because they have an Agentic product now. But but they are they have something called the foundry. And what you just described of having one person that's head of AI, quote unquote, that seems like a small company kind of approach, right? Because you you only have one. But that person essentially becomes a forward-deployed engineer who goes. I I think the best way to do what you described is to embed that person into Wit next to you know, shoulder to shoulder with those subject matter experts that you just described and the ops people that are trying to deliver solutions for them. And go build in their environment that that includes buy versus build decisions, like what tools did that does this part of the organization use? It's like the AI architecture inventory, like what tools do we have? What can we use today out of the box? And then taking the best of that and bringing it back to the foundry. Right. And so It's not a f like take the product piece out of it for a minute, but they are essentially productizing portions of what they're learning back into the mothership as the central AI capability for that company. So whatever learnings they bring back, whatever tools that apply enterprise wide, they should be bringing that back into the core so that other organizations can benefit from it as well. But I think the key to this is what you said. It's like it you've got to embed in the Business unit. It's not just hey, let me come in and advise you on how to do it. It's no, I'm gonna actually do it with you. We're gonna send somebody in to do it with you because we're gonna put together the the AI skill set alongside the domain expertise in that particular area to make something happen. I was actually also looking at job descriptions today for different roles. Like there's a company called tomorrow.ai that I think.

Jeff Breunsbach: Yeah.

Jay Nathan: Think just got acquired by that open AI big you know consulting conglomeration that they're building. And I was looking at open open roles. I mean, they even have AI adoption specialist roles on their website. And what is that? That's somebody that just teaches you how to use the tools that you already have, right? Teaches you how to how to think about what an LLM is giving you, how to provide context. Like it could be Clawed, right? I mean, they're just they're basically AI whiz kids.

Jeff Breunsbach: Yeah.

Jay Nathan: making sure you know what these tools are capable of. not necessarily helping you architect new systems per se, but just making helping the workforce get ready for it.

Jeff Breunsbach: Yeah. It feels like the like what you described a around this whole I I guess like I guess like the foundry I guess would you consider that like a center of excellence? Like that's really the model I guess that they're going for. Is that do you think that this something different?

Jay Nathan: I I mean center of excellence is is is like a big corporate term for like centralizing knowledge of how to do something internally. I think this goes a little bit further than that in that you are actually centralizing tools and capabilities you're you're proliferating the best, right? So like how do we do how do we deploy agents on Azure? How do we, you know, we ha we're using Glean

Jeff Breunsbach: Yeah.

Jay Nathan: in this department, is that a tool that we could bring back and use across other so I would say, yeah, it's it center of excellence might be like the more traditional enterprisey kind of terminology for it. But there's a product, there's a product and capability aspect of it too. I guess center of excellence is probably fine the more I'm rambling about it.

Jeff Breunsbach: Yeah. It's No, it's I mean, I was just cu curious if that's but I guess like what's interesting to me about like this the idea of like having the center of excellence, right, is like I think what you actually have now at a lot of companies, at least like individual contributors or like even like managers and and people that I've talked to at the lower levels, is I think you have a lot of hesitation and a lot of like you kind of have this whole concept of like every company says, we should be adopting AI. We should be using it, you should be making your job better. And I think everyone's going to do that. But then to your point, like I think these businesses sometimes are missing that like if we don't centralize, if we don't start building some of the core infrastructure, if we don't have the foundry built, then like all I'm ever going to get is just a bunch of people using a bunch of tokens individually. And like that's only going to get that's only going to opt that's only going to optimize to a certain like that's only going to get you, I don't even know the right percentage, but like I don't know. That's only going to make somebody 15 more percent more efficient than they currently are.

Jay Nathan: Yep. For the same things.

Jeff Breunsbach: Whereas like I think like what you're describing is like cool, if you do the foundry, if I have the data layers, if I have the agent layers, if I have like the the core tools that we're using, like all of a sudden now, like you start to think about, I guess, like the true version of enterprise AI that people talk about, where it's like, cool, we could get like fifty percent better at this, like a a step function, but we could get like so much more better at this because like now essentially I've like I I've like granted everyone power. that is like along the same track and is actually using the same context. like so I don't know, it's just interesting to me that I think like it's this whole idea that you basically have to slow down to speed up, right? Like it's it's easy right now to get caught up in the we should be using AI, pushing the the foundation, but or pushing like the frontier. But like at the end of the day, what's really core is like, if we actually had the foundry, if we spent time now doing the data architecture, building the tables, getting these like systems really I guess hooked in right and then like enabling our teams on that, then right, like I could be going to build a a cursor application for my team based on a data, based on like you said, a verified data set that is is on a domain that I can authenticate with my team and make sure that they can log into and that it's got the right security, it's got the right data, it's got the right but then I can bring like the workflows whatever. So like I don't know, you just start seeing how like the it's actually I don't know, like in in most of these situations. It feels like everyone is is almost like telling you or fearmongering you into like you're not going fast enough, you're not adopting AI, you're not doing the right things, when in essence it's like, actually you should probably go back and focus on the core first. And then like that's actually going to unlock more than just creating a bunch of random skills.

Jay Nathan: There's an ROI problem though. Th there's an ROI problem with all of this right now, and that's why it's hard to go and say, hey, I'm gonna create a bunch of infrastructure in the middle without delivering any outcomes. So like there's just study after study that says there that this money is being wasted inside of a bunch of, you know, companies right now. And I I think you and I have both seen it.

Jeff Breunsbach: Yeah. Yeah.

Jay Nathan: I think it's really interesting going back to that same podcast with Garov on ClickUp. I mean they just laid off twenty two percent of their team. And they didn't do it because they were trying to get more efficient from a cost perspective. They were trying to do it because or they were do it they're doing it ostensibly, and I really sort of like their positioning on this because they they want like Zeb, the CEO, his vision is like we're not trying to do things 10 times better. We're not trying to do things five times better. Like we're trying to get a hundred times better, do things completely differently, ship new products, ship new capabilities. We're not just trying to automate the crap that we've already done. Right. And I think that's the the fallacy in all this. Yes, you're gonna get some efficiency there, but that's task by task, right? If you wanna if you want to change the the structure and the complexion of the company, you then you have to reimagine the whole way that.

Jeff Breunsbach: Yeah.

Jay Nathan: that work is getting done. one of the things that I've been thinking a lot about is as we build agents, what work are we gonna go, what outcomes are we gonna go sell to our customers that we just own and deliver for them in perpetuity? Okay. And when I say outcome, I don't mean like increased revenue retention. That's just too it's a it's an outcome, of course, right? But it's too far down the line. I think about it the way that you know you've got fin in intercom. And for those who don't know, Salesforce just bought Finn. Fin is a it's a resolution platform, right? Like problems arise, fin goes and and autonomously resolves those problems for a customer on your behalf as a company. aka support, right? But they sell resolutions. That's the outcome. So maybe I go sell claim processing, right? And I'm just doing claim processing for you now. At a certain percent of accuracy, you're gonna pay me on a per claim basis. So again, like that's an insurance example. But like the the point being like what what are we selling in the future? For I mean us being a services team, this is the AI native services mindset, right? Like we're selling an actual completion of some task at the end of the day. And the more complex, the better. The more judgment that we can, you know, standardize and take off people's plates, the better. I don't know if I got us off track there or not.

Jeff Breunsbach: Yeah. No, no. Well I think like I think what you're alluding to though, right, is like this idea like I think we've talked about outcomes before, but I think like now you could trul truly own like, okay, like can this agent go deliver this outcome, right? Or can this process and workflow go deliver this outcome? And like at what accuracy and how effective can it be? And then like over time, you know, can I go improve that, right? So if I think that if I if I think that like a certain campaign or a certain adoption of a feature is going to drive

Jay Nathan: Yeah.

Jeff Breunsbach: higher retention in the future, can I actually go build a campaign that's specific to adoption of that feature? And actually then like the agent, that's all it's thinking about, all it's doing, right? Is like, okay, how do I continuously get better at like getting Jay, getting these people to adopt this feature? and like, you know, over time does that lead to a higher retention? But I think like that level of specificity is like what you're trying to go for. And that's probably a a crude example, but like that's I think that's what I think of.

Jay Nathan: Yeah. But that's right. Task level outcome versus business level outcome. And you have to there's still some mapping you have to do between the task and the and the and the business outcome that you're looking to drive. So

Jeff Breunsbach: Yeah. Yeah. Cool. All right. Well, this has been fun. I kinda like these where we I don't know, we just started going and I think there's been some interesting pieces in here.

Jay Nathan: Yeah, we we didn't hit our our our agenda at all, but that's okay. We'll we'll try that again next week.

Jeff Breunsbach: No. but yeah, no, I appreciate it. And I think, you know, by the time we have next week's we've got another uncommon AI session on Thursday, this coming up. So hopefully we'll have some some more to share about what people are building. I think that was pretty fun last time and we're gonna start to get some beta users into our uncommon community this week. towards the end of this week. So we should have some more to talk about next week, which I think will be be fun.

Jay Nathan: Yeah. Yeah. Love it, man. yeah, and by by the way, like the the demo day for Uncommon is today if you're listening to this on the release day of the podcast, which is Thursday. So this afternoon. So you can still sign up. Come come join us. I'll probably have to cut out halfway through that, but I'll I'll I'll be there for the first half for sure. All right. Good to see you, brother. Thanks. See ya bye.

Jeff Breunsbach: true. Yes. Yeah. Okay. All right, cool. All right. Enjoy enjoy the soccer game. See ya.