Knowing Your Problem Space Is the Moat With Adam Jacob  🔗 **Source:** [Knowing Your Problem Space Is the Moat With Adam Jacob](https://share.snipd.com/episode/f106f584-63f5-4d20-b7a7-da4ba3128929) ## Highlights - **When Repeated Praise Signals No Product Fit** - Adam Jacob shut down System Initiative after repeated “one more thing” feedback revealed weak product-market fit. - Large enterprise POCs succeeded technically, but the underlying product was not compelling enough without its AI demonstration. Transcript: Emily O'Meara How did you know that it was time to give up on system initiative? Adam Jacob Oh, that's a tough question. I would say it's two things. You know one is that the the market just tells you you know like at some point the the often when you're building products you take them out you show them to people you try to do that as frequently As you can you know the the more you can get someone to use the software to see it to touch it to to to give you feedback the faster you can improve. And we just had been stuck in this loop for a long time where the feedback we heard was, this is super cool. We're really into it. If it really just did one more thing, then that's what would tip us over the edge and make us want to use it. And at some point, you hear that often enough. And the answer, you start to hear the truth behind what they're saying, which is actually there's nothing here that's interesting enough for me to care or there, or the leap to, to get It is too far. Or, you know, like there's, there's all kinds of, of those sorts of reasons. And that's a really hard thing to do when, you know, you've committed your time and you've committed your investors money and you've committed the lives of the people who work for you. All of those things are sort of on the line. So it's hard to decide when the right moment is to do that. I think my own experience is that you very rarely hear somebody say that they did that too soon. And I think that's because it's just really difficult emotionally and intellectually to get to a spot where you sort of admit that you don't have anywhere else to go. And I feel like that's sort of where we wound up with System Initiative is we had seen some really great things. We'd done some large POCs with some really large enterprises that went super well, where we did things that really large teams had struggled to do. And we did them in a week. And that was amazing. But what was amazing about it was how we used AI to do it. And when you looked at how that system was connected to the engineering that we constructed over the years to solve those problems the way that we had, it was sort of clear that it wasn't Right. It just wasn't as compelling as it needed to be. And so that's how we knew. ([Time 0:02:44](https://share.snipd.com/snip/40d221d2-7dff-40f2-8ce9-232d29872c45)) - **Measure Optionality Before You Quit** - Founders must distinguish a normal growth plateau from a failing business by tracking whether options are expanding or disappearing. - System Initiative’s warning sign was that more doors kept closing than opening. Transcript: Adam Jacob It's just tough to know when to quit and it's tough to know, you know, I think one of the hardest things that you have to learn as an entrepreneur is that the same thing that drives you to Create and the same thing that inspires you to build new things, and that's also fuel to get through what are often just the common slings and arrows of building something new. You know, like when we show the graphs to people of like how your business works and it's always like a smooth line up and to the right, like that's mostly lies. You know, like usually it's a stair step for everyone and the flat parts are terrifying. And so, you know, part of why it's hard to know when to quit is that it's hard to tell the difference between like, am I just in a flat spot and, or am I, or, or, or is it, is it time to quit? And to me, a lot of that is like, what doors remain open to you, you know? And when, when, you know, when you looked at system initiative, like we were in a, we were in a moment where like just lots of doors were closing. Um, and there were more doors closing than the were opening. And that, you know, once that narrowing begins, it's, it's very difficult to re to, to reverse the trend, you know? Um, whereas, you know, sometimes when you had a flat spot in a growing business or you have more of those things working, like you can have setbacks, you can have product problems, you Can have those things. But when you look at how many doors are open to you, it's still actually a lot of doors. You know, there's still a lot of optionality that sort of exists there. ([Time 0:05:43](https://share.snipd.com/snip/305cef70-6fd7-439a-829e-126e7e096e43)) - **AI Makes Open Source More Necessary** - AI makes software easier to rebuild, lowering the defensibility of proprietary features and increasing the value of accessible source code. - Swamp uses AGPL source alongside a commercially licensed product, preserving openness while monetizing distribution. Transcript: Adam Jacob So Swamp itself, the source code is open source. It's under the AGPL. And then the product that we sell, Swamp, the product, not the source code, is we distribute that under a commercial license and sell that for money. So if you want Swamp for me, then you pay me for Swamp. If you don't want Swamp for me, while the software is there, you can fork that software. You can put your own branding on it. You can figure out sort of how you want to build that community in those times, and you can go do that thing, and we can collaborate in some ways. I think how exactly that collaboration works is interesting in this era. I think there's a lot of things that have changed with the way AI works, and the pace of velocity, and all of those things that sort of make collaboration a lot different than it used to Be. So I don't really know exactly how that collaboration would work if somebody was to fork the software and sort of build their own distribution. But fundamentally, Swamp is open source because I believe and I think the software also demands that sort of in the agent world, in the world where what we're doing is building software, We're using agents to do it, the idea that the software itself wants to be free is actually more important now than it has ever been in terms of being able to get to those outcomes. And we're starting to see this rise in people personalizing the software they're using and building things that are just for them or customizing the software in ways that otherwise Would have been very difficult to do. And so having that software be open and having the source code be available and being able to build a derivative, those become sort of critical unblockers in people's day in a way that Like before they were nice to have but now like if you don't have it it's it's actually an interesting critical business problem you know given that like a lot of software can just be rebuilt With time and effort and tokens and even if you're not covering off on like a hundred percent of the functionality of software you know you are perhaps covering off on the 25% you care About, you know, so where is that threshold? So all of that sort of leads you towards saying that the software should be open, um, and, and, and it should be, it should be, it should be available. And so, yeah, Swamp is open source software. ([Time 0:07:33](https://share.snipd.com/snip/3d80ad79-c52a-4cf7-9890-f7c632abaa9a)) - **The Code Is An Expression Not A Moat** - Code increasingly becomes a commodity because competitors can reproduce features over time. - Durable advantage comes from understanding the problem, architecture, security, teams, and customer context behind the code. Transcript: Adam Jacob To a degree. Yeah. I mean, you know, the code was, I've always been a little, the code is not your moat. Cause that's true. In a competitive enough market, over time, your competitors will have every feature you have. They'll cover off on all the space that you occupy. So yeah, in the fullness of time, the code is not your moat. I think there was a moment where I think you could have invented something novel. And in that novelty, sort of held for a while, the sort of whatever the technical prowess was that allowed you to do whatever magical trick you did. I think that's been getting less and less over the years anyway. You know? But, but yeah, I guess I kind of always have been a software is not your moat guy, but now like software is not your moat, you know, like it's really clear that software is not your moat. Emily O'Meara What do you think is your moat now? What's the, if, if what's the single most important moat that you can build and maybe one, ([Time 0:10:18](https://share.snipd.com/snip/745f69db-6124-4d74-9dda-e1c0bb62c30f)) - **Swamp Turns Community Into A Game** - Swamp builds community through Discord conversations, experience points, leaderboards, and shared achievements. - Members discuss work built with Swamp and other tools, creating value beyond simply using the product. Transcript: Adam Jacob Yeah, I think, think there's a few so i think one is um is community so the the truth of any given piece of software and the people who use it is that as they start to use the software and as It goes into the world like what is the value they get from using that software and what is the value they get from participating in the in the society in the community that forms around That software and so like with swamp um you know there's a ton of exciting stuff happening in swamp but one of the most exciting things is that if you join the swamp discord it's just filled With people building stuff all day and they're telling each other what they're doing and they're talking about what works and they're talking about what doesn't and sometimes they're Talking about stuff they're building with swamp sometimes they're not and in this era of like real uncertainty about like well how do i build with ai how do i think about bringing that Into my company how do i think about you know doing it in a way that actually works and isn't just like absolute hype and and lies like pretty great to have a community filled with people Who are doing that and then sharing with each other how they did it. And that happens because, yes, we're all using this software, but ultimately it's because that space has been created through the software to allow them to come together in that way. So a lot of the functionality in Swamp Club that moves beyond the core of what Swamp does is every time someone uses Swamp, we track what they did. We don't know exactly what they did, but we know that they did something. And we give them points, like experience points. And you level up. And it keeps track of those things. And it shows up in Discord. And when you level up, it announces to everybody you did. And there's like a season pass that has all the achievements that map to like learning all the different features and functionality of swamp. And when somebody like fulfills all of the pieces of that season pass, the whole community gets double experience points for an hour, you know, and it sounds ridiculous, but like, it's Incredibly fun and like people love it. And they go look at those leaderboards, and they're like paying attention. And when you see someone like spring up that leaderboard, people ask them, they're like, hey, what'd you do? Like, you went from, you know, last week, you were down at 25. And this week, you know, you were getting millions of points a day. Like, what did what changed? And that like sparks an interesting conversation about not just how they're using Swamp, but what are they doing in their environment and how has their job changed? And so that's one thing that I think is ultimately probably the single largest moat you're going to have, is how is the software you're producing? What is it like to produce it? The other is supply chain. So yes, anyone can produce software and yes, anyone could take what I do and they could reproduce that thing. And now they are responsible for it. And the ultimate question there is, well, are you going to be better at it than me? Are you going to have more focus than I am? Are you going to have more resources than we have? Are you going to be responsive in the way that we're responsive? Like our average time from someone filing a bug or a feature request in Swamp to shipping that bug or feature request is four hours. Four hours. You file a bug and we fix it four hours later. That's bananas. And what that does to the shape of the supply chain, what it does to the community, what it does to your ability to interact with customers, that's wild. And that's the other kind of moat that exists is like, okay, yes, anyone could write the software, but why me? What is it about, why would you trust me to write this software? And in this case, it's because I spent my whole life building automation. So if you don't trust me to build automation software for you in this era, I don't know who you trust, you know, which whatever, maybe you didn't like some of the software I built before. So you're like, I don't trust you, you know, but like that's those kinds of things. They have less to do with the source code on disk and more to do with like, how do we understand that problem? Do we understand software? Do we understand architecture? We understand teams? Do we understand security? Do we understand all of those things? And how does that come together in what you build? The actual source code itself, it's an expression of all of that, but it's not the most important part. ([Time 0:11:22](https://share.snipd.com/snip/876ae4fb-076f-472a-8959-f48c5a60ddb6)) - **Give The Community Its Own Value** - Define a distinct value proposition for participating in the community rather than assuming product usage is enough. - Users may avoid community, while former users or people unable to adopt the software can still find belonging there. Transcript: Emily O'Meara So first I want to just, for listeners, make sure to underline something that you said, which was about the community. Because I've actually done some talks about this before, which is about having a value proposition for your community that is not the same as the value proposition for using your software, Because they're not the same things. And you can use a piece of software and not join the community. I'm not sure that you would join the community and not use the software. That would be weird. But the point is- We had that with Chef. Interesting. There you go. Adam Jacob We had people who definitely liked hanging out with us, but they didn't like Chef. Anyway. Emily O'Meara I mean, you could also, know you could have people in the community who wish they could use your software in their in their job but they can't for some reason to use the software you know Used to use the software yes exactly and um so the value proposition for your community is not the same as a value proposition of your software of using your software um if you want to build A ([Time 0:15:42](https://share.snipd.com/snip/072cc801-31b6-4c19-8f8f-409e2c5fffd2)) - **AI Flattens Code Contribution Models** - AI-generated code changes collaboration because agents can produce tens of thousands of lines too quickly for humans to review safely. - Swamp therefore emphasizes extensibility, letting users build and publish integrations without modifying the trusted core. Transcript: Adam Jacob Yeah. So there's a couple of things that I think have caused this change to happen. And we're seeing it sort of, I think, across the open source community. Everyone's seeing it. And our reactions are different. And the biggest thing is that if someone using an agent can easily create 20,000, 40,000, 70,000 lines of code, you could refactor Swamp in hours in incredibly deep ways. No human being has the capacity to effectively understand the work that you would do at that level of scale. So I can't ask an employee. I can't ask me to be like, hey, I'm going to take a pull request from you, Emily, and review the 70,000 lines you did. Because I can't tell you if it was good or bad. I certainly can't hold it in my head contextually. And I certainly couldn't tell you if it was safe or unsafe. I couldn't tell you if it was good or bad. I might be able to trust you over time, right? Like we've met before. I could use that as a piece of trust that says, well, she's probably unlikely to be introducing bad things into the source code, and therefore, maybe I trust her. But when the source code itself can be written by an agent so easily and so quickly, and to do that well requires building a big software factory around it. So just for the people who are listening to me that think it's just like vibe and slop, it's not. It's actually like a, we spend as much or more time, we spend more time probably engineering the system that builds Swamp than Swamp itself, if that makes sense. And so it's like there's a lot of engineering that goes into making it safe to work at that rate of speed, no matter whether you're collaborating with other people or just doing it yourself. But once you have those things in place and you can work at that speed, then what tends to flip is saying, okay, what was the value that you got as a user of needing something done within The software? And so one avenue there is to say often the shape of those things is that you want to extend the software in some way in the shape of the functionality that already exists. So for example, Swamp supports multiple vaults where you can grab secrets data from other things. You can just write a new vault with your agent and you never have to talk to me. You can go publish it on Swamp Club. You can share it with other people. I don't need to be in the loop there at all. I can just unblock you by making the software extensible in that way. ([Time 0:17:24](https://share.snipd.com/snip/e232f881-b19b-41fc-8c07-274b136ea1fd)) - **The New Open Source Contribution Ladder** - Swamp’s core team filters ideas through a lab, builds selected features with agents, and credits the originating contributor. - Contribution shifts from submitting code to demonstrating good judgment about what should exist. Transcript: Adam Jacob But when it comes to the core of what Swamp is, when it's like, hey, how does Swamp work on its interior? What features are we adding? Which features aren't we? Those are things we very tightly control. And part of that's because we want to apply our own taste and our own judgment about what the product is and how it should work. And some of that is because we can't trust you or anyone to send us unfiltered input. And so what we do instead is we say, hey, we're going to take all of your features and all of your pull request and all of your bug reports and all of those things. We're going to stick them in what we call the lab. And then what we do is read them, triage them, and work them. And so if you come up with a good idea or you find a bug, then what we do is give you credit for your work when we write the code with our agents. And then that all flows back through into the community and into the ecosystem and back into that game that I was describing earlier. So when you file a bug in Swamp, we know that you filed it, we know who you were. We then track that back to your account. We know that you did it. We give you credit in the source code if that matters to you. But for sure, we're giving you credit on your profile and across the rest of those things. And so it's clear. Because at this point, it's not so much like, could you write the code? It's, do you know what to do? So if what you do is come up with a good idea that's like, oh, that's absolutely a feature we should build, what we do is build it. And we build it for you. And then we say, Hey, like Emily came up with this great idea. Then we shipped this feature and it was, you know, brought to you by Emily. Right. And that seems to be working just fine in terms of building a community of people who feel like they're collaborating because they are, you know, and, and that split between where do You enable people to collaborate in the open and where do you enable people to contribute code? Like, you know, the code that they contribute is code that they build themselves. They don't contribute that back to us. They never can. If somebody builds something in the open on top of Swamp that we think is great, then we talk to them and maybe we build it ourselves for our own version, but we never take anybody else's Code because we can't trust it. Emily O'Meara So what does this mean in terms of things like building a contributor ladder? Yeah. Adam Jacob Well, I think it means that the contributor ladder is flat now. Like instead of needing a contributor ladder that says, you know, like it was always hard for people to be like, value people who send docs PRS, you know? And like, that was always nice that we said that, but it wasn't true for most projects, right? For most projects where you were most valuable was if you could climb your way up to the core and be a person who was like responsible for deciding the direction of the software. I think it's probably possible to still build a community that works like that because what you're doing is still taking individual trust and deciding that I trust you to make good choices. I trust you to run an agent. But do I trust the masses to make those choices? I really don't. Right. Um, and you know, maybe I could foresee a world where if you've had enough of those conversations and enough of that collaboration that you open yourself up to allowing someone to work In that way. But I, I doubt it, you know, like if you have a corporate sponsor or you're building a product that's required to be vetted, uh, downstream, I don't, I don't, how those structures survive This moment. Certainly not once everybody can actually be productive. Like right now what's happening is that not everyone has actually become orders of magnitude more productive than they were before by using these tools, because the work to actually Use them effectively in the large is still really new. The number of people who've built effective software factories and can show you what that pace looks like, and they can walk you through how it all works, that's just a really small number Of people still. So yeah, I think the contributor ladder essentially disappears because your ability to contribute comes back to, well, do you have good ideas? And if you have good ideas, then you can contribute. And you can see them reflected in the product immediately, either because you asked your agent to do it, and it extended the product, or because it was to the core of the product, and you Filed a feature request, and we read it, and it was a good idea. ([Time 0:20:13](https://share.snipd.com/snip/b03a917a-8610-4b02-956f-1e3ad87b8af3)) - **Architecture Comes Before Implementation** - AI-assisted development moves learning from implementation upward toward architecture and system intent. - Engineers still need expertise because agents can generate code, but cannot reliably supply domain judgment for difficult systems. Transcript: Adam Jacob And I don't know, like even the question of how do I vet for your software engineering competency has shifted. You know, like one of the things we've seen in building software with factories in this way is that a lot of folks learned software architecture from the software up. It started from writing code, and then the architecture of the program emerged over time. And that's how they learned to understand how the program works was by reading the source code and understanding its structure. Here, you actually kind of learn it from the top down, right? It's like, well, what's the architecture of the software? And the implementation is a reflection of that high level architecture but but it's moving at such a rate of speed or it's evolving at such a rate of speed that you can't really learn it From the bottom up you can only really learn it from the top down i don't know what that means for interviewing software engineers i don't know what it means like i know today i think it Would be very difficult to, um, to, to understand how to work in this system without some expertise that already exists, just because I don't think we know yet how to teach someone to Do it. But like, do I believe that you can teach someone how to like write software in this way where they learn about architecture first instead of last, and use that to express what the software Should be and why it should work? I suspect the answer is yes. But in this liminal zone, where we're still exploring and everybody's still trying to figure out exactly how this stuff works, it's much, much harder the further out you get on the frontier To know exactly what you need or exactly how you need it because nobody really knows because it's the frontier you know you're only six months into doing it if you were the earliest you Know uh so so yeah i think how you think about hiring people what their jobs look like you know it's all going to be there there's going to be plenty of software engineering jobs you obviously Can't do it without expertise. Anybody who's watched people like, uh, vibe code something and then just keep going and it eventually falls apart under its own sloppy weight. Like there's, you still need some software development expertise here. You still need some, you still need, you still need to understand what's happening and how the system is working. I don't know if you always will need to do that, but for today, you definitely do. And my guess is that you always will to some degree. ([Time 0:27:04](https://share.snipd.com/snip/1ea1e056-7367-439e-9e5c-7f9bca812ad1)) - **AI Compresses The Cost Of Being Wrong** - Adam Jacob’s faster Swamp iteration would have exposed System Initiative’s mistaken assumptions far earlier. - Shorter build cycles turn months-long architectural bets into days or weeks, accelerating feedback on whether users value the product. Transcript: Adam Jacob All right. Emily O'Meara I have a last question that's going to sort of take us back to where we started this conversation. Because as I know you've said in a very popular talk, you are good at building products that people like, that people are willing to pay for. And yet you still failed at system initiative. So if now the the speed at which any sort of moderately competent programmer can build something if if that speed has been compressed dramatically or that that time has been compressed What does this mean about the importance of being able to understand what people actually want? And I'm going to say want because some people will pay for what they want. They would not necessarily pay for what they need. Correct. Adam Jacob Yeah. I mean, it's all that there ever was if the thing you were trying to do was start a company that sold things that tried to be a business. That's not the only reason to build software, right? There's a bunch of other reasons to build software, but if what you were trying to do was make a living doing it, and you were not trying to have a job, you were trying to like, you were going To start a company, you were going to do something on your own, you wanted to be in control of your destiny. You know, that's the only game you've ever been playing. The idea that there was any other game is foolish. Like the only game you've ever been playing is the game that says, well, can I, can I build something that I love? And if I love it, then that increases the odds that another person also loves it, you know, and like system initiative failed for sure, but I loved it. And part of the reason that the feedback was so foggy was that other people wanted to love it too. Like one of the most common things we heard when we shut it down, a bunch of people came out of the woodwork who were like, oh man, I really believed in system initiative. I thought that was going to take over. I really like, I was so excited. And I'm like, where the fuck were you? You know, like it's not, you weren't using it, you know, like, but they loved the idea, you know, and like, it's a harsh thing. And so, you know, I am good at building products and I am good at figuring out what people love. And it doesn't really matter if you're good at it. Like the numbers, the math tell you that the number of products you will make in your life, that's just the number of times that you decide to embark on that journey, and will be successful In that journey is small. You know, the average failure rate is super high, you know, like 80 plus percent, uh, uh, will just zero out. There'll be nothing like nothing. They'll just completely for one reason or another, absolutely fail. And then even if you make it through that funnel, the number of those companies that then stick around either to become independent public companies or to become companies that have Valuable exits is even smaller, right? It's a fraction of a fraction of a fraction. And so, you know, you just got to know the game you're playing like, and that's the game I play. And so, yeah, sometimes if that's the game you play, you lose. Like sometimes you try to build one and you love it and you think it's good and you just lose. And sometimes that's because you were wrong about what the product was. Sometimes it's because the market wasn't ready. Sometimes it's, you know, there's a million reasons why you can lose. That's why the percentage is so high, you know? Like, it's because it's hard. And if you decide to play that game, you most likely lose. Also, sometimes you win. And when you win, it's so fun, you know? Like, it's like the funnest game. And it's also fun to figure out how to try to win. And so like, yeah, I think, I think what it means that compression means that if what you have is an idea about how the world could be different, about how people's experience could be Different. And you also have expertise about what it means to do that. You know, like it's one, like one of the startups that I founded forever ago, we were trying to start streaming music, but we had no expertise in music record labels, none of that stuff. And we were, whatever, eight years too early. Good business idea, streaming music. Smart. Could we actually do it? No, you know, not at all. We were absolutely the wrong humans. The same would be true today, right? If you were like, oh, I have a great idea for something you don't know anything about, like it's gonna be a lot harder to figure out how to do that. But if you do have a great idea about something you know deeply, you do have a lot of expertise. You do understand how the whole thing should work. You do understand why it could be different on some fundamental level. Well, then just like a musician with a new song to play or a new song to sing, you can sing that song now and you can sing it so much faster and you can use that time to then get it out in the world And get that signal back that tells you, is this good? Is it working? If I could have iterated on system initiative at the rate of speed that I'm iterating on swamp, I don't know what would have happened, but I know I would have known a lot sooner that I was Wrong. Because the second bet where you're like, oh, here's what has to change, wouldn't have taken me six months. It wouldn't have taken a team of 10 a year to change the shape of the architecture because you got some feedback and you saw that it wouldn't work and that this was the fundamental technical Problem. It would have taken days, taken weeks. And that shortened cycle means that as a person who builds things that you're trying to get into the world and you're trying to make good, like all the signal you need to know if it's good, Can get so much faster. ([Time 0:42:41](https://share.snipd.com/snip/b5479031-74b7-4d52-bdac-70e9a591a9d6))