The Vibe Coding Phenomenon: What Happens When Everyone Becomes a Developer?

Speaker A: Welcome to Between Product and Partnerships, a podcast focused on bringing together product partnership and engineering leaders to discuss how to build support and scale SaaS ecosystems. This podcast is presented by Pandium, an integration platform for building native integrations. Hi everyone. Thanks for listening to our podcast Between Product and Partnerships where we talk about the challenges and what it takes to build integrations, tech partnerships and SaaS platforms. And today I am so excited to have Rod Moshfegh, former VP of Product at Knack, join us on the podcast. Thank you so much for spending some time with us. Um, and can you share a little bit about yourself and your background with our audience?

Speaker B: Perfect, thank you Christina. Uh, great to be on the podcast here. Um, Rod, former VP of Product at Knack. Been in the API partnership data game for a number of years now. Taking me From IBM to layer 7, which was kind of one of the OGs in the API management API gateway space, to CA Technologies, to Hootsuite, which is I would say one of the OGs in the third party developer space. Uh, especially working on the social media platforms all the way to my recent last four years at NAC, working on again APIs and integration, specifically with various components of the MarTech stack. That leads me to today here with, on this podcast.

Speaker A: Amazing. You've had such a great and varied background and uh, as a, As a former OG API consumer, you've been working with APIs and integrations since around 2011. So I'm curious, curious from your perspective and you worked at a middleware company, um, how the middleware world has changed to adapt to today's API economy where Everybody is using APIs for everything.

Speaker B: I think one of the biggest things that's happened is simplicity has definitely come in. The idea of keeping things simple, making things easy to onboard, really focus on that versus previously it was focused on really data consistency and almost like the engineering practice. So the best example is. I say the word wisdom though and I get blank stares now because that was such a relic of a previous era where it was really all about really, really thorough, uh, uh, really well done technology, really well done specs and the move to open APIs, rest and simplicity and the ability to get up and running and now the move to MCP and the agentic world is just turning that on its head basically. You know we used to say the term citizen developer. Now that's truly the case. It's capital C, lowercase D where everybody can develop and vibe code through all the LL and the frontier models. So it's really seen that progression and more and more folks are familiar with the concept of APIs and that infrastructure that sits behind it versus in the past. Again it was just something that they weren't familiar with. Or again I get blank stares when I brought up soap or whistle or things of that nature.

Speaker A: Even I use the um, the term like CRUD functionality not that long ago to somebody and they totally had no idea what I was talking about. And I was like, you know, I, maybe that's like an old school term. But I will say I still interact with a lot of APIs that do have full CRUD functionality. And I'm like, we need, let's go back, let's go back to basics. Um, and with that in mind, like my team and people that I know in my personal life have heard me talk a lot about the rebranding of technology over time, where it's like, wait, there's these kind of common concepts, but obviously with AI we have all this new stuff too and new nomenclature and kind of language around that. To you like what about right now feels genuinely new and what is like a rebrand or sort of, uh, and it's all an extension of fundamentals. But what do you, what do you think is actually new and novel versus just a new name for an old concept?

Speaker B: Yeah, I mean I find MCP and MCP servers are kind of a rebrand of an older concept. You know, like we, especially at nac, we had some customers before, you know, months ago because this is also like new. But uh, you know, like late last year they were already integrating their uh, uh, agents. So agentic workflows with our product using our public API. So this is before our Plug Alert, our new MCP server that was released about ah, uh, a month and a half ago now. Um, but they were already integrated so they were just using our open API going from there. So I do find the concept of MCP server at times is a bit of a rebrand of original open aps because you can kind of replicate similar things. Um, what I do find new is just more folks are involved, more folks are able to work with different products and more folks expect the ability to be able to work with them. They expect to be able to sit in Claude, in Cloud code, in Codex, in ChatGPT and be able to interact with these different uh, SaaS products using integrations versus before it was a concept, it just wasn't top of mind for them or it was something that intimidated them to be honest. And when I say more folks, I mean um, more folks working in the enterprise in traditionally non super technical roles. So non developers, um, starting to see the shift though. Like I've seen the shift from developers to non developers, but still tech. And this is where especially Martech we see a lot of technologists that don't necessarily have that traditional computer science development background. And now we're starting to see it getting more and more into folks that are even further away from. So folks that weren't used to setting up infrastructure, folks that weren't setting up like databases more on the brand creative side are again starting to expect these integrations. They're by coding a little bit themselves and they're just expecting these um, kind of API integration points that are really hiding behind the MCP servers to be there.

Speaker A: I'm curious, and maybe this is like a spicy question, but in your role as leading like product orgs, how do you or uh, do you see any friction being introduced with folks that are slightly less technical having an expectation of things working in a specific kind of way? And I think the reason that I ask that is, you know, vibe coding is a great example, right? Like you can get from like zero to like 90% really fast, but that additional 10% is maybe where you're going to really hit a wall. And I could imag in a product org, especially if you're in Martech. And I think marketing and marketing ops people are crazy tinkerers, like more than a lot of B2B sort of users. I think like I could imagine there's a lot of pressure to like it needs to. This must be easy, like do it fast, do it now, do it perfect. And then that sort of the uh, flip side of that is like you as the product manager being like maybe we need to temper our expectations a little bit about what is possible. Um, I'm curious if you've run into that. I feel like with the, to your point, with this influx of data, new less traditionally technical users, I see more of this friction coming up. But I'm wondering if you've experienced the same thing.

Speaker B: It's kind of been the world I've been living in for 10 years to be honest. Because, because, and, and it's, and you're right, it is, it is exponentially growing and it's an ongoing saga I would say. So the reason I say 10 years is I spent um, between 2016 and 2022 I spent six years at Hootsuite. RICP was, was folks in marketing, but social media marketers and it was, it was challenging at times to kind of have conversations with our customers where we'd say, I know you see this functionality in Meta or in a user interface in LinkedIn, but it's not on their API. And we get these kind of looks of like. Well, what do you mean? Like, it's just to say you should be able to be in your user interface. And we'd have to kind of break down that kind of really explain the technology difference there and then, you know, the concept of API first or not and all that. Um, so that. But that was, that was kind of in that world. Once I moved over into more dealing with mops folks, like marketing operations folks, and my tenure at knack between, uh, 2022 and up until recent, um, it was a little bit. It was a little bit of an easier conversation because I think folks understood, oh, there's this API thing, it's different, it's a different interface. But now as we get more and more folks Vibe coding and starting to kind of see the world of technology being easier again, they're like, well, this all should just be easy. And it should be that. What do you mean it's not in your API? Or what do you mean it's not already done? And so it's been. It's an ongoing thing to really, to really iterate or really to reiterate that, um, that last 10% is not 10% of time necessarily. It's 10% of functionality that actually makes this thing tick. And, uh, uh, it's been an ongoing thing to be able to explain to folks and be like, that's what separates you using this Vibe coding product and 10,000 people being active on it at the same time is that 10% and the ability to scale it and have underlying proper infrastructure and all that. And so it is an ongoing thing. I don't have a silver bullet right now. I just know it's a constant conversation that we're having and it's just happening more and more and more now. Um, I think what I'm hopeful though, because I've seen in these situations as folks are going through it and as they go from 0 to 90 really quickly and as they try to go from 90 to 100 and it takes way longer, they do appreciate how difficult it is. And so, like, I think in six months, a year's time frame, we're gonna get, uh, kind of a different perspective from folks who are like, oh, yeah, this is actually hard. This is hard.

Speaker A: Oh, for sure. I think it's gonna normalize a hundred percent. It's just, it's been. I was reflecting on this, like a couple days ago, where for many years, and by many years, I mean M. 15 years, 20 years, there was this idea that, like, software engineers are this like, mythical kind of beast. It's like super. It's super difficult. This is a highly specialized skill. These people are geniuses and like, no, you know, super expensive, really hard to hire. Da, da, da, uh, da. And now over the last, like two to three years, especially with the vibe coding stuff, it's like that's been flipped to the polar opposite where it's like, we don't need engineers. Everyone can do it. And like, it was just. It was this piece of technology, I think, that really caused that hard pivot. And it's. It's interesting to think about. Like, I think both of those are not correct. Right? Like, there's nuance there and the truth is somewhere in between. But, like, this impulse to be like, um, you know, we've got to pay engineers a bajillion dollars. We can't give things to the engineers. Like, their time is so sacred. And now it's just like, who needs them? I'm like, that is like some serious whiplash. Um, in a world where like, you know, AI and generative coding is obviously super helpful, but, like, the underlying technology that runs all of this stuff has not shifted in a meaningful way. Right. So, like, the. The issues that make a great engineer a great engineer and make it a specialized skill are still. Still remain. Those challenges are still there. Right. Um, but I do love the sort of leveling out of the playing field a little bit more. Like any. I've said it on this podcast a ton of times, like, anytime access to technology can be democratized in some way and we can allow more people to like, have a positive experience and be empowered with tech, I'm all for it. Um, but it is like an interesting. I'm sure as a pm, it can be challenging to now be. Treat. Now be servicing essentially an entirely different set of users.

Speaker B: Yes. Yeah. An entirely new set of expectations. Yeah, I think you're bang on. And I actually have to catch myself sometimes too. So story time. Uh, recently, um, so when we announced McP server at DAC, one of the big things was we announced it, uh, at a talk that OpenAI gave with us, and they were talking about how they use portion of our MCP server to automate a certain workflow that they had going through Slack and integrated with linear and a bunch of other things there. Um, one of the big things for me, as I was sitting in the audience. This was at Adobe Summit. As I was sitting in the audience and I was seeing everyone and their eyes lit up because they understood, hey, I could build that. And so it was really cool. So I got, personally, I got inspired. I'm like, I'm going to go and put this together. Like, how hard can it be? I could vibe quote something in Codex. I can like uh, you know, or just vibe quoted, just in plain chatgpt, run it as an agent, hook it into Slack, all that. One of the things. So I got from zero to 90 really quickly. I got things hooked up in Slack. What did that last 10% though? And, and the part where I'm like, this is easy and it's still this easy to get to that point. But that last 10 where I was like, oh yeah, this is hard. And the expectations that I have of our engineering team, sometimes when they're like kind of slow at something, I should temper that because I started running into race conditions ones that. And you need. And like, you know, I haven't. I used to be a, uh, you know, I run DevOps teams. Like I, you know, I used to write like DevOps toolchain. I used to be J2E developer, build data warehouse. I'm like, I'm technical enough. Like I can write Java. I can, you know, code in various scripting languages and all that. So I understand, I've designed architectures before, but it was one of those where I'm like, oh, okay. It's not just me telling, you know, an LLM, hey, put these things together. I have to really, be very, very prescriptive about, you know, the sequence. And I have to actually build a sequence diagram and be very careful about the information that gets passed and where things get, uh, persisted and then the interface for that persistence. And I'm like, you know what? Sure, software engineering. And the software part was traditionally was coding. Maybe that is democratized. But engineering is about to get amplified because I kept, I kept creating issues where I was creating race conditions and I couldn't figure out how to debug them. And I'm like, you know, like, you need to kind of step back and like write this out and create diagrams and all that and to like really figure out what to do. Eventually I figured it out, but it wasn't as trivial. And that was that kind of like last 10% where I could then give it to my team not only to be like, look at this fun shiny thing, but this is actually a process we could use for like ingesting, uh, uh, Certain requests coming into our work via Slack. In this case it was for email generation but it could have. We're going to start using it for um, product requests coming in as well too. Tinkering with that.

Speaker A: I find like a lot of that 10% that we're, that we're referencing I in my mind frame that as like resiliency and I think of like the race condition stuff, concurrency, like the ability to pick up where you left off, like cash cursor, all this stuff like kind of falls in that 10% that like if you're only trying to get one record from here to here. And uh, we do integration stuff all day. So like this is all I've been thinking about for 20 plus years. But like you know, if you just have one record going from you know, Reddit to Slack, like you're good but if you're trying to do 20 or 200 or 200,000 maybe you're not so good. And if it's really important that, that they all make it over a period of time in order as you were mentioning, like Slack messages are time sensitive in a lot of ways. They have to be process in order. Um, that's where you start to get into to your point like these comp. Sci kind of fundamentals and it's. I totally agree with you. I think that like software design in terms of not just the UX but the you know, the actual design of resilient like scalable software is going to become even more important as like the hands on keyboard typing, um, is less important. But uh, as you were telling that story and saying that it was like a talk on stage, I got like a sense of anxiety because I was like oh God, tell me he didn't go up there and try to do this live. Because like that going on, I'm like no, no, not the live demo.

Speaker B: No, I mean, I mean you know, for hopefully listen, shout out to Jeff Canada. He could have, he could have pulled it off. Like he's, he's good at that. But it was. If he didn't do no, that would have been a thing. I mean I was sick. I'm like I could do this live. And then once I got into, I'm like oh, okay. Yeah. Because it was one of the interesting things is again, again you need to start doing system design. A little bit of like, okay, what's the context my built an agent here to be able to do a bit of a uh, uh, of a handshake between the two protocols. Surprise, surprise. It's kind of something that you probably deal with on a day to day basis. But it was. And it was which context is it in? And then it would lose the message or it persisted in the wrong place because they had to do something in, you know, an open API in the, you know, ChatGPT infrastructure. It had to do something with regards to NAC and its MCP server and they had to do something in Slack and sometimes it just get lost. But that's the thing about. I think a lot of citizen developer types are going to find out really quick that they need to go learn that stuff pretty quick because you're right, the underlying infrastructure hasn't changed. It is, it is still the same, you know, at times, ball of twine that sits underneath it. So yes.

Speaker A: And we are, it's like all zeros and ones and despite the models being cool, like we're all still bound, we're all still bound by like physics and like the speed at which things can happen. And um. But it's cool. I mean it's, it's definitely snazzy. I'd love to see what you guys have used. We could take it offline. But like what, how that ended up working out. Um, and you, you referenced, I think a little bit ago talking about um, LinkedIn like it's in the UI and why can't I access that? There's no APIs in LinkedIn. Don't at me. But is like notorious for that as a company. But I'm curious because you've worked with a lot of companies that I think especially hootsuite, that is very dependent on that third party. And a lot of our listeners, I think almost every ecosystem has that big fish, fish, little fish sort of thing. There's like the Shopifys, there's the Salesforces, there's the Twitters. Um, I'm curious what lessons you learned about like platform dependencies in working with those big kind of players. It.

Speaker B: Yeah, it's. I mean, I know you recently had another podcast. Yes. Talking about partnerships and like the big fish, little fish and like the, the um, conversations there. It's. Yeah, it's. I, it's tricky. It's all. It's arguably when you set out down this path, especially when you're going down the partnership path, you have to be very thoughtful about this. I think the big thing is go into it with the research of where do we complement each other and where do we compete? Because odds are there's likely some level of competition occurring during the hootsuite era and I'm sure. I know you had one of my, uh, ex co. Actually 2. 2 times ex coworker Billy Anna that you had on the podcast. And I know she was talking about some of the kind of the fun stories of hootsuite era. Um, but part of it is, uh, a lot of times they, um, you know, because they're a partner, they're open up these APIs. But the reason they're useful to you is they probably have some flavor of your functionality within their product. So you have to really, really be careful and do some analysis there of, um, where do we compliment, where do we compete? And also what's our moat against them? Because you need to be prepared, even though you have a business relationship in your partners, that there could be a situation where a customer isn't or a potential, let's just say prospect, even an existing customer isn't, is looking at y' all as, you know, two complements together. You're their joint customer. But at some point it could be looking at y' all as competitors of like, what if I want to do platform consolidation, can I take one of them away? And this was, you know, with. With. hootsuite, especially with the social media networks, we. It was, um, it was challenging at times, especially when one moat, which was. It was a little bit like I should. The. The old school mode of. Of hootsuite was omnibox, where it's like you create once and be able to share across multiple networks. Um, where that kind of didn't. Or at times it. It changed because the social media networks change. And it was just basically different audiences on different networks. So you weren't necessarily sharing something on Twitter as is on. On Facebook or Instagram. So you have to be very careful of what is our moat there. Especially now we're competing kind of like directly with those. Um, I know. Um, it's interesting because at nac, like, again, similar things do come come up with the, uh, marketing automation platforms when we work with them, where sometimes the. The feature sets overlap so much that almost they seem like competitors.

Speaker A: But.

Speaker B: And uh, that's where you got to really, really lean in and be like, this is actually what's unique with our product. Like, we have a really robust way for you to define a design system, or we have a really robust way for you to do collaboration that you wouldn't necessarily do in these other products that we still think are great for like managing leads or managing data or sending things out.

Speaker A: So you just.

Speaker B: I think more and more you do have to kind of step back a little bit beyond the tech and look at the business side and honestly the customer's jobs to be done. So I was wondering how long it would take me before I reference the GTBD framework. But really like what is that and where does this uh, overlap? So that's, that's kind of, it's an interesting, it's tricky but you do have to pay a lot of attention to it.

Speaker A: And how do you think about that type of differentiation and also identifying like the problem set that you want to build against in a environment where hypothetically there are people trying to build their own stuff. So like they know their problem really well. Yeah, you hope. And they are building their own thing. Um, and I have a lot of opinions about this which you people can find on my LinkedIn if they want. But I'm curious from, from your vantage point, what you, what you think about that.

Speaker B: It's you know, and pre. So this was really interesting at ACT because pre, um, even pre, like you know, everyone says November 2025, you know, when some of the kind of the more exciting uh, models from Anthropic came out and everyone became a vibe coder. Um, even pre, that uh, a lot of NAC's customers would try to build their own in house versions of NAC and what they would slowly find and this is what kind of becomes the moat. And I think what a lot of folks have to really be careful is the maintenance that last 10% that kind of more and more becomes your moat because you can always get from 0 to 90. Previously you just have an engineering team. They spent you know like 12 weeks or uh, to like a year building something and then, but that's, it doesn't end there. And a lot of it like our, a lot of folks would be like okay, we're done. But then they would find out later that you have to maintain this. And especially as things change both in terms of third party APIs but even downstream for the APIs and the email world, it's like the um, the email clients and all those downstream as they change, you have to change. So that's kind of the thing is really our, our thing was what is our, what is our unique value differentiator and also what do you get when we say maintenance and an ongoing SaaS business. At the end of the day we have folks whose whole job is to make sure your, the product doesn't break but also stays up to date with the entire ecosystem. And that is a huge cost. Arguably that is more of A cost and almost a disincentive for building your own, maintaining it over time. Uh, that's, I think the big reckoning that's going to happen in six to 12 months from now is everyone's going to realize software is really um, expensive to maintain. And it almost for those that went from the hosted to the cloud world, it's a bit of, you know, it's, it's kind of a, uh.

Speaker A: We've seen this movie.

Speaker B: Chuckle.

Speaker A: We've seen.

Speaker B: Yeah, exactly, exactly. And it's like we've seen this play out. You're going to find out, you know, like it's like it's these things that are hard to maintain. Things change and that's why, you know, some people get big bucks to just keep an eye on them and roll with them.

Speaker A: So yeah, it is uh, I agree with everything you're saying and like it's also interesting, I do feel like back in the, you know, the on prem or like the kind of legacy software world where everyone was building their own stuff and then we moved to the cloud and SaaS and all that, people also stayed at companies longer. Like yeah, you could have somebody that built your in house, uh, pricing engine for whatever and that person is with you for 40 years. So like he or she almost always, he is like responsible for owning that thing and like you know when he's going to retire, like somebody could kind of take it over or by that point you move to the cloud. Now it's like we have so much mobility within the industry. Like it's shocking to even find people that have been entry, not entry level, like mid level folks that have been in a company for three years, you know. So when I hear about all of this, like oh, our ops people are building this thing and this thing and this thing and this thing, I'm like, like that person's probably not even going to be at your company in 18 to 24 months. And like who, who was responsible for the maintenance of that thing at that point? Like let's pretend you do want to keep up with it. Like yeah, it's when every person is building their own software, there's like every, every human has tech debt. You know, it's like how I think about it.

Speaker B: But yeah, yeah, yeah, that's such a good observation in that uh, mobility and the kind of the, the lowering of the average 10 year has meant that tribal knowledge isn't a crutch anymore. Like you just can't be like, oh, you know, you know I'll, you know, Bob Or Betty just knows and just go talk to them. You can't rely on that. They're going to turn over and you need to be resilient to that. Um, it's. Yeah, it's going to be even more amplified. You're right. Like everyone comes in and yet they create a bunch of value in terms of what they built, but they also leave a bunch of tech debt too. Um, yeah, it was, it was funny because, uh, a bit. But hootsuite, we, we had like kind of a. We felt this earlier on in the sense that it was a young exciting company in Vancouver. We used to hire a lot of really talented folks early in their career. So we got used to new folks coming in, moving quickly up the ranks and then moving on. And so we got good to kind of being resilient and just kind of expect that like you're going to go into a code base and it's going to be like four or five people have been in here over the last like five years. They've all left their little marks and it's going to. You can't rely on just talking to someone again. Amped up. So everybody got good at like kind of, of reading and just being prepared that that's what's going to happen. There's also almost like a, uh, being comfortable that things aren't going to be perfect. Like, you know, almost like when eventual consistency became a thing because people just kind of like just got, you know, like comfortable with the fact that you can't get it. You can't like nail something on the first go and eventually things are going to get consistent. Um, that's kind of the, the comfort level. It's like and, and really focusing on um, and build something that just provides value and then, you know, you may leave some tech debt and be okay with that again. It's easy for me as a product manager to say this because I'm not the one that gets the, you know, the outage in the middle of the night from someone else's tech debt. It is an interesting thing. That's a really, really interesting observation. And yeah, way the, the sprawl of Vibe coded internal apps again, exponentially growing, that's going to be more and more that's going to happen. So you do wonder if eventually, like maybe this scenario that AI helps with more and more where then you can like point a model at something and be like, tell me everything I need to know. That's for me to be able to jump in and kind of, you know, like, ninja Fix this or maybe seal this.

Speaker A: I also wonder, and this is again kind of a spin off of the AI stuff but like I do think there's probably a lot of uh, there's like this resurgence of like shadow it, right? So if you don't have like really tight controls globally in your company, like people are building all this random stuff, right? And that's always been the case, but it's even more common now because everyone can. And I wonder if there will be like, I feel like there's an opportunity for like a unification layer there. Like Claude cowork is kind of like that for Claude stuff. But it's like, hey, if you're gonna build a thing, it needs to like conform to and live within this infrastructure or framework so that you don't have like somebody deploying things on Vercel and this other person has a replit thing and then there's a lovable thing over here and someone has it running on their laptop and like just like all uh, all of that stuff and like for us I think about it a lot because at ah, you know, at Pandium we do integration work and integrations have historically been those things, right? Like people weren't using lovable because it didn't exist. But the idea that someone has an integration that customers are using running on like a free AWS instance that they spun up with their personal email address is like totally a thing that still happens. So like that sprawl of like the technology project that the engineering team didn't really want to work on but had to get done just appearing somewhere like is a, is a uh, again a problem movie we've seen before and I think like what, you know, at what point? And maybe, maybe the vibe coded internal apps don't get to that point, but I'm just picturing like a large company and somebody walking in there being like 600 little apps running at that company. And like how do you get your arms around that? Like yeah, how do even you as a, as a product person, like within uh, your own teams internally, like you're using what for what? Like that kind of thing is just an interesting set of problems that this democratization of technology can create. Um, I think it's cool. You know, there's obviously we could talk forever about security and stuff but um, there's all kinds of other downstream, downstream impacts that those things can have. But I don't know if you have thoughts.

Speaker B: Oh yeah, yeah. I mean one of NAC's big things is governance and the ability to provide governance and you're right. When uh, I think we have to start getting really tight just in general as an industry that this is going to happen. There's going to be 600 apps. They're going to be running on multiple different platforms. Platforms, uh, using multiple different types of identity. Some it's going to be personal, some it's going to be some like tied into the SSO provider of your corporation or of the, of your org. Some are not. And so who's going to be providing this level of governance? There's also going to be duplication. I think there's going to be four people that have written the exact same like little basic script to move data from one part to another part. And how do you know the thing that you ended up or what if there's a change that's needed? How do you proliferate it to all four of um, them? At some point you're going to have to settle on one. Um, you know, for nac, it was interesting because we provided governance for email landing, page creation. At the end of the day we provided a bit of, we provided a design system, the branding and all that. And so it was, it was a thing that we'd been thinking about for a while. But um, it is a thing that's gonna now it's gonna amplify, it's gonna show up in areas that you never thought of before. Like, you know, I've seen people that are like vibe coding like GTM little apps and it's like okay, well what if, you know, just there's, you know, what if you need a new messaging to be proliferated out? What if new branding comes out? And like these apps weren't necessarily set up to be able to pull down branding from a branding source of truth or so it's, I think it's going to be um, there's going to be some interesting things down the hill, down the line. Like hopefully there aren't like you know, security issues or uh, incidents that come up. Yeah, but, but you know there's, it's going to be interesting. I think right now we're in that, that initial phase where everyone's being encouraged to um, use as much products as many different products, experiment as much as possible. But I do see eventually like a process consolidation happening. I also see there's just folks, especially in our own ICP where um, that were just process oriented people and I know this stuff makes them uncomfortable. Like at some point they're going to be like, I am supporting people that are building stuff on like they're doing little things on you know like on replit Vercel, they're doing little things on cursor, on cloud code. And at some point um, I just can't deal with all their nuances. So we're going to have to like consolidate on one thing. Like pick something, let's consolidate it.

Speaker A: Yeah, I agree. I think it'll be, I think people will end up getting like overwhelmed with the amount of stuff at some point and um, and get a little bit of like heartburn from it too. That's, you know, that's when we'll then go back I think to there'll be like another wave of like hyper focused SaaS products, like micro SaaS products where it's like, like oh yeah, we like talked to 200 companies and they all had built some version of this little replit app or whatever it is. So like we're gonna make that into a product and then we're gonna be like full circle back to SaaS again. It's like we're gonna just keep going at these cycles forever. Um, because like look at the end of the day, like I could bake all my own bread too, but I don't want to. I buy at the grocery store. Like I prefer not to do that. And there is something to be said for like just not having the cognitive load and it's like, it's the uh, I think it's the balance of that like dopamine hit that folks get when they build something.

Speaker B: Yes.

Speaker A: Balancing that against the cognitive load of the long term requirements of using that thing and like when there will be a flip at one point when like the coolness of being able to build a thing is no longer cool enough to make up for the nightmare or the pain in the neck of supporting it forever. Right. And that's when it's like why don't we just go buy accounting software?

Speaker B: Yeah, yeah, yeah. Once, once you have your first like outage at uh, like the 11th hour or like, you know, you know something that the first time and then that'll imprint on your head and then you'll always remember be like put it on your br. Always remember that. And you'd be like, maybe this isn't just because I can doesn't mean I should. I think you're, I think you're bang on. Like it is funny. I even just at a macro level the way folks are flip flopping back and forth between codecs and Claude code is super interesting right now. Like I'm seeing it and it's like, which model has the latest thing? And people are going back and forth. So even that I'm sure is giving uh, you know, like the IT world a bit of heartburn there to like which one do we pick? And it's hard right now to mandate one because it does change so frequently and it can have such a, a big impact on your ability to do business because the new model will just be so much better at doing X and you want to jump on it and you want to use it, but then two months later, you know, like something new comes out from Gemini or something comes out from another model, you want to jump over to that. So yeah, it'll be interesting. It'll be interesting.

Speaker A: And also like the cost is gonna, is starting to sort of trickle in the way people, the pricing models and the way these tokens are sliced and diced and like all of that, that makes that switching even more attractive because it's like you just keep bouncing around to like the freest one and that will eventually stop. Like yes, eventually. Right now I feel like there's no. Because we haven't ever really seen anything like this before with like the AI token consumption sort of thing. Like there's no floor or ceiling for the pricing model. It's kind of like what are the other ones doing? And everyone can kind of just fluctuate. But at some point there will become like I think a common sentiment around like how much is this worth? So then that, that ability to just charge whatever you want or not will eventually go away and then folks will have to assess these things to your point on like how good the model is for the specific thing they're trying to do or other feature related things. But yeah, uh, it's definitely an interesting, oh, interesting world. And I cannot believe that we're like at time, which is crazy. Uh, I could talk to you forever. We could do this like 10 more times. But in closing, um, if you have one piece of advice for product folks that are working with APIs, integrations, trying to do great things in this brave new world that we just described, uh, what would that piece of advice be?

Speaker B: I think be thoughtful and approach it in a very much a classic product management way. Try to run things like jobs to be done framework and uh, really focus in on areas where it's known on what the user and sometimes your user's user is trying to do and really map that out and just be very, very thoughtful of that in certain situations where you think there's innovation that you haven't thought of, it's okay to take a leap of faith and just put something out like an API that you don't know how it's going to get used, but try to be very, very thoughtful about it. I think, uh, it's sometimes easy to just pull out cool tech or put out cool tech, but it's even better to solve a workflow really well or help a partner solve a workflow for their customer or a customer solve a workflow for their own internal. So I think being thoughtful is really, really important, especially in this new world where everyone's building everything and like there's, you know, there's a sprawl of APIs and MCPs everywhere. So that's, that's the big thing that I'm starting to really think about of uh, like that. Can I add a second one? The second one. A second spicy thing. Distribution is going to be the new bottleneck. So be really, really thoughtful and set a bunch of time aside for distribution, for enablement. Because in this world where everyone not only is just building a lot of things internally, but a lot of companies are just building and releasing, the humans are starting to get overwhelmed with how much things are getting bombarded with. So you need to be very thoughtful about how to message information to them, the value prop and then enabling them to be able to adopt this. So just be very thoughtful about that. I think it was really. That's, that's. Those are my two spicy takes.

Speaker A: No, I love that. I think the focus is really like really important. And then what you said about jobs to be done is the way that I think about it and talk about it. It, uh, here and out in the world is like, start with the problem and then work to the, to find the right technical solution. Don't like, start with the tech and try to find a problem that you can shoehorn it into. And like when you have new and exciting technology that's accelerating really quickly, it's very easy to be like, this is really cool, let's build something with it. And that's fine for experimentation, but like really your customers, unless they are early adopter engineers or early adopter tech folks, like, they often are not going to care about the under like the technology that got them there, right? Like they have to your point, there's a problem to be solved. What's the best way to do that? With the least amount of clicks and the least amount of like, overhead. Mentally, if that's AI, that's great, but it's doesn't need to be, um, in the same way that, like, your customers don't care if you're running on AWS or gcp, like, or if it's Python or if it's Ruby. Nobody cares.

Speaker B: Like, no, they have a job to be done and they need you to help them do it, and that's the end of it.

Speaker A: Right? Right. Nobody cares about the people listening to this podcast, the people that we have on it. Well, this has been so fun. Thank you so much for spending some time with us. For our listeners, um, if you want more information about integrations, APIs, uh, frameworks, partnerships, all that great stuff, you can check out pandy.com. um, Rod, we'll throw your LinkedIn in the description of this with the video so folks can find you. And yeah, I really appreciate you taking the time. This is so fun.

Speaker B: Thank you, Christina. It's been great. And I, uh, thank you for having me on.

Speaker A: Excellent. We will see you out there. Thanks for listening. If you enjoyed our content, subscribe to our channel and give us a thumbs up. For more content on tech partnerships, integrations and APIs, check out our articles, ebooks and other resources in the description or visit Pandium's website.