S13 Bonus: The Intention Layer: Why Coding Agents Need Product Judgment with Drew Dillon, Founder & CEO of Brief
Drew Dillon is a tech founder and product leader, centered in the Bay Area. He is a person who likes to do a bit of everything, having an engineering background, but spending time in design, sales, and product management. He's been a part of many startups - Yammer being one of them, and several others from Y Combinator - along with being a consultant and fractional CPO. Outside of tech, he has 2 kids that take up most of his time. When he isn't on the sidelines of a soccer game, he enjoys woodworking and reading a good sci-fi book.
At a prior startup, Drew built a system using AI, which spit out something reasonably shaped. He took a look at the process he went through to create it, and realized that there are a ton of disparate parts, all separate from the shared organizational context - IE the "why" behind what is being built. He set out to change that, and built institutional memory and product judgement within AI agents.
This is the creation story of Brief.
Sponsors
Links
https://www.linkedin.com/in/drewdil/
Checkout our episode stacks on Stacklist! https://stacks.codestory.co/ Hosted by Noah Labhart | Technical Founder & Startup Mentor.
Advertising Inquiries: https://redcircle.com/brands
Privacy & Opt-Out: https://redcircle.com/privacy
[SPEAKER_02]: A lot of people didn't see where we were going when we built flood decisions agents. [SPEAKER_02]: Does it mean this library that we picked? [SPEAKER_02]: Does it mean we actually use forever? [SPEAKER_02]: Does it mean that we don't use m-dashes in our product copy? [SPEAKER_02]: Stuff like that? [SPEAKER_02]: So we started very intentionally with just this tiny thing from the feedback that we're hearing of people who were starting out at the very beginning of the process where we were, where we've got a document of copying and pasting the same props 10 times.
[SPEAKER_02]: And I just have the agent go figure that out. [SPEAKER_02]: even then, the models of the time prior to even Opus 4, they're real following, wasn't that great. [SPEAKER_02]: So, we've spent a lot of time just getting them to understand what decisions meant at finding out the right integration points between an agent and so decision log. [SPEAKER_02]: My name is Drew Dillon, I'm the CEO and co-founder of Breathe.
[SPEAKER_03]: This is Code Story. [SPEAKER_03]: a podcast bringing you interviews with tech visionaries. [SPEAKER_03]: Six, six months moonlighting goes. [SPEAKER_03]: It's the last and all of the backgrounds who share what it takes to change an industry. [SPEAKER_00]: I don't exactly know what to do. [SPEAKER_03]: It doesn't go as to get right. [SPEAKER_01]: who built the teams that have their bad company is its team's help each other, which is proud of our team. [SPEAKER_03]: Keeping scalability top of mind, all that infrastructure was up there.
[SPEAKER_03]: Yes, we've been fighting it as we grew up. [SPEAKER_03]: Total waste of time. [SPEAKER_03]: The stories you don't read in the headlines. [SPEAKER_03]: It's not an easy thing to achieve. [SPEAKER_03]: To get yourself a deficit of off, try to begin to ride the ups and downs of the start-up line. [SPEAKER_01]: Need to really want it. [SPEAKER_04]: Not just about technology. [SPEAKER_04]: All this and more on code story. [SPEAKER_04]: I'm your host Noah Leopard, and today, no true Dylan, is helping you align your team and your AI agents from Vision to Impact at AI Speed.
[SPEAKER_04]: Drew Dillon is a tech founder and product leader, centered in the Bay Area. [SPEAKER_04]: He is a person who likes to do a bit of everything, having an engineering background with spending time and design, sales, and product management. [SPEAKER_04]: He's been a part of many startups, Yammer being one of them, and several others from the Y Combinator, along with being a consultant and a fractional CPO. [SPEAKER_04]: Outside of Tech, he has two kids that take up most of his time. [SPEAKER_04]: When he isn't on the sidelines of a soccer game, he enjoys woodworking and reading a good sci-fi book.
[SPEAKER_04]: At a prior startup, Drew built a system using AI, which spit out something reasonably shaped. [SPEAKER_04]: He took a look at the process he went through to create it and realized that there are a ton of disparate parts all separate from the shared organizational context. [SPEAKER_04]: IE the Y behind what is being built. [SPEAKER_04]: He set out to change that and created institutional memory and product judgment within AI agents.
[SPEAKER_04]: This is the creation story of brief.
[SPEAKER_02]: Brief is basically your AI product brain, so it's really an extension of your product team's understanding and capability. [SPEAKER_02]: They're knowledge as well as an operator that helps you extend the capabilities of that team. [SPEAKER_02]: This is all based in my own background, of course, in product management. [SPEAKER_02]: What I found, especially in the past six years, in between starting my own start-ups, I was a fractional chief product officer, and always at any company, the process of building software changes all the time.
[SPEAKER_02]: It changes between projects, it changes between teams, especially more so between companies. [SPEAKER_02]: But what I found was the why of why you build products is actually extremely similar. [SPEAKER_02]: It's the same process at every company. [SPEAKER_02]: You start with where you see the company going over the next 36 months, then to the road map of what helped you get there, then down to the individual features and capabilities, then down to the build, and then each of these, of course, are iterative back and forth, so you learn as you go along the way.
[SPEAKER_02]: but that structure actually was repeatable. [SPEAKER_02]: And that's when my consultancy basically did I helped companies operationalize that process and in doing so, basically found that we would more than double their engineering velocity, just through helping everybody through that entire process understand everything that comes into building software. [SPEAKER_02]: And that's basically the inspiration behind brief. [SPEAKER_02]: That's what brief does for companies. [SPEAKER_02]: It helps them operate that why, along with the how of actually
[SPEAKER_04]: So tell me about the MVP for brief the first version. [SPEAKER_04]: You built you created how long did it take to build and what sort of tools were you using to bring it to life?
[SPEAKER_02]: So briefly, it started actually at a different company that company previously was called Moxie, and it was around AI powered sales demos. [SPEAKER_02]: And prior to starting Moxie, I hadn't really coded an anger in about 15 years, where I'd been managing engineering teams, but not actually a coding engineer working on anything. [SPEAKER_02]: When I was working on Moxie, I picked up Percer for the first time. [SPEAKER_02]: And for the first time, it was able to describe the software that I wanted to have it come out in a reasonable shape.
[SPEAKER_02]: And when I went around and showed a bunch of people what I was working on, they all basically said I was weird the way my operating process was for using cursor. [SPEAKER_02]: And it's because I was using my product management tools. [SPEAKER_02]: I've been explaining that engineers why we need to build stuff for 20 years. [SPEAKER_02]: But I was doing the same thing at the cutting agent. [SPEAKER_02]: I wasn't like move this button center that did. [SPEAKER_02]: I was like, here's the user.
[SPEAKER_02]: Here's what the user wants. [SPEAKER_02]: Here is why we're doing this thing. [SPEAKER_02]: And so, brief out of grew out of that process that I developed through initially copying a pasting prompt out of a document, then into Markdown documents, then connecting a bunch of MCPs, actually building kind of a second frame that could actually coordinate with the agent itself at that velocity. [SPEAKER_02]: and then just got smarter and smarter, add more intelligence, add more things to it so they could make better decisions and continue to extend my speed and understanding to the coding agent.
[SPEAKER_02]: And so the funny enough, the MVP was very dumb. [SPEAKER_02]: It was, we built it in about three days and it was a log of all the decisions that we had made around the product, who are users or what they were doing, etc.
[SPEAKER_04]: So with that MVP, let's stay on it for a minute. [SPEAKER_04]: I'm curious about a decision or trade off you had to make and how you approach building that original version, right? [SPEAKER_04]: And maybe it was leaving it dumb, right? [SPEAKER_04]: Or maybe it was some sort of acceptance of debt or limitation or something. [SPEAKER_04]: But tell me about one of those and how you cope with it. [SPEAKER_02]: A lot of people didn't see where we were going. [SPEAKER_02]: When we built flood decisions agents, because it was a decision to mean a lot of things.
[SPEAKER_02]: Does it mean this library that we fixed? [SPEAKER_02]: Does it mean we actually use it forever? [SPEAKER_02]: Because it means that we don't use M-dashes in our product copy, stuff like that. [SPEAKER_02]: So we started very intentionally with just this tiny thing from the feedback that we're hearing of people who were starting out at the very beginning of the process where we were. [SPEAKER_02]: Where we've got a document of copying and pasting the same props 10 times. [SPEAKER_02]: and I just have the aging, it'll figure that out.
[SPEAKER_02]: And even then, the models at the time, I think this is prior to even Opus 4, Opus 3, it probably sounded, I don't even remember what the number was at the time. [SPEAKER_02]: Be out, be much older models, they're real following, wasn't that great. [SPEAKER_02]: So we've spent a lot of time just getting them to understand what decisions meant at finding out the right integration points between an agent and so decision log. [SPEAKER_04]: So then from that point, you've got something it's getting you some of the validation or traction you want.
[SPEAKER_04]: How did you progress a mature from that point? [SPEAKER_04]: I think Treffen a box a little bit on looking for is how do you go about building your roadmap? [SPEAKER_04]: How do you go about deciding that this is the next most important thing to build or to address with brief? [SPEAKER_02]: I heard this once that there are two forms of product design. [SPEAKER_02]: One is expert design, which is we go research really hard. [SPEAKER_02]: We try to understand the user base as much as possible.
[SPEAKER_02]: In expert design, you're saying I'm not the user, but I'm going to go learn everything I can about the user, which is fundamentally where I end up, where I think every product eventually ends up, you can't always be your own user. [SPEAKER_02]: And then the other is self-design where you build the product that you understand and you need but the moment that you need it And I think that's a magic of a really early stage product is if you are building for yourself You don't really need to go and put too much thought it out just like, okay, I'm working on this thing and now I wanted to do this [SPEAKER_02]: And that's been where Buryf has been, probably for the first six months or so of the life cycle.
[SPEAKER_02]: It's just, I know what like consulting practice does, and what does Buryf need to be able to do to deliver the same kind of results that I delivered to my consulting practice, that needed integrations, that needed agents, and needed skill files, and ways of looking at data in different ways to be creative about what we needed to work on next. [SPEAKER_02]: Each of those kind of grew organically as I hit those moments of building Buryf itself,
[SPEAKER_04]: So I'm curious about team, right? [SPEAKER_04]: To do something like this, you gotta have the right people at the helm. [SPEAKER_04]: How did you go about building that team? [SPEAKER_04]: And what do you look for in those people to indicate that they're the winning horses to join you? [SPEAKER_02]: Especially in the age of AI power and everything, we really need people who are able to articulate broadly challenges, be more thoughtful about the flow of work rather than the specifics of what they're doing.
[SPEAKER_02]: Fundamentally, also, we see this combining and overlapping of roles across multiple different departments and not just engineering product design, but even between sales, marketing and product support, et cetera. [SPEAKER_02]: So it's flexibility in understanding of your role. [SPEAKER_02]: There can't really be ownership or people who get too pedantic about what they're working on. [SPEAKER_02]: They need to be thoughtful about their work and their operations. [SPEAKER_02]: And also it will start to articulate it in a very specific way.
[SPEAKER_02]: And that doesn't mean you don't get specialists. [SPEAKER_02]: So we do have specialized AI engineering function. [SPEAKER_02]: So when we build agents, we're not building the based off of winging yet in Google searches. [SPEAKER_02]: But we hired, for example, my buddy Ryan, [SPEAKER_02]: I work with as an enterprise salesrab 13 years ago at this point, and because Ryan has been a founder himself, he's taught himself to code, he's actually shipped multiple products. [SPEAKER_02]: But the expectation wasn't Ryan was going to come in and just immediately take over enterprise sales, like if you're going to come in, you're going to help build, you're going to help execute, and that was the first thing he came in week one had Hermes up and running,
[SPEAKER_04]: I'm curious about scale Drew. [SPEAKER_04]: How did you approach scale from the early days? [SPEAKER_04]: How did you think about it and how you're building the product? [SPEAKER_04]: And this obviously is baked into what you've created. [SPEAKER_04]: But I'm curious that there have been interesting areas we've had to fight it as you've grown. [SPEAKER_02]: Everybody asks me what's so hard about building an AI product and I tell them that it's API authentication. [SPEAKER_02]: It's the least standard part of any API and it drops all the time and they don't document why it drops all that kind of stuff.
[SPEAKER_02]: The interesting, I think, the magic of being not fresh out of college and working in this area. [SPEAKER_02]: I don't worry that much about Vibecoded software because I know I had to describe the problems that engineering teams that I've worked with and managed myself. [SPEAKER_02]: I've encountered over time. [SPEAKER_02]: So anything from like technology choices which databases are we going to use. [SPEAKER_02]: API rate limits, security, things like that. [SPEAKER_02]: All of those get baked into the system from the earliest time periods.
[SPEAKER_02]: So even those get registered as decisions in brief. [SPEAKER_02]: We're going to use this until we hit this scale. [SPEAKER_02]: We're going to have, we're going to operate this way until we hit this moment. [SPEAKER_02]: All of that actually is baked into the product plan. [SPEAKER_02]: And so agents will even come back to me to code a gauge. [SPEAKER_02]: And I say, hey, I've have this conversation with our brief agent. [SPEAKER_02]: And it told me that when we hit this moment, we need to do this.
[SPEAKER_02]: And we actually, we need to go do this now. [SPEAKER_02]: And so making investments and commitmentally, as we can see around the corners of what those scale challenges are going to be.
[SPEAKER_04]: Okay, Drew, as you step out on the balcony and you look across all that you've built this far at brief, what do you most proud of?
[SPEAKER_02]: Every new feature has a moment where we dark launch it, and we are the only users of it. [SPEAKER_02]: And it's funny building an agent that gives advice because how do you build e-vowels against advice? [SPEAKER_02]: That's not, we're not scanning medical records. [SPEAKER_02]: There's no numerical practice that we're working towards. [SPEAKER_02]: Was this good advice? [SPEAKER_02]: Or my bar for me is like, does it sound like me? [SPEAKER_02]: that sound like a decision I would have made in that moment, does it express that opinion the way I would express that opinion?
[SPEAKER_02]: And I think as each part of the product hits that inflection point, I'm, hey, this is actually a really good advice. [SPEAKER_02]: I can actually, this is something I wouldn't even know because I don't go scan all of our competitors' websites every day at a way, for if it does. [SPEAKER_02]: That's just stuff I get really excited about. [SPEAKER_02]: So we send that a weekly email. [SPEAKER_02]: That's probably the crown jewels of the product. [SPEAKER_02]: Here's what we learned last week.
[SPEAKER_02]: And based on what we learned last week, here's what we think we should be focused on next week. [SPEAKER_02]: And it's at this point, it's really good. [SPEAKER_02]: That actually really sounds like me. [SPEAKER_02]: It sounds like a advice. [SPEAKER_02]: I learned stuff whenever that email comes out. [SPEAKER_02]: So those, the fact that it took a lot of work. [SPEAKER_02]: It took all of the underlying infrastructure, all the agents. [SPEAKER_02]: all the APIs and everything to get to a point where it could have that sort of 360 view of the organization, but I'm really happy about how that came up.
[SPEAKER_04]: Okay, Drew, let's flip the script a little bit. [SPEAKER_04]: Tell me about a mistake you made, and how you and your team responded to it. [SPEAKER_02]: In the day brief, of course, was a pivot from a previous idea. [SPEAKER_02]: So I think understanding the signals of what you're learning that the previous idea hit kind of a moment where we were ready to go asking people for money and the money just wasn't there. [SPEAKER_02]: People were coming back next quarter who's basically the best response we got, which for an early stage start up means you don't have it.
[SPEAKER_02]: Probably one with brief. [SPEAKER_02]: We did start with a lot of earlier stage companies. [SPEAKER_02]: We were asking a lot of folks to look at us in best way early on and more recently our attractions actually come from much larger organizations, which I would not have predicted for a number of reasons. [SPEAKER_02]: And so understanding also your ICP and just keeping your eyes and ears open as you're learning your ICP but also not making sure you
[SPEAKER_02]: Ask for the money up front. [SPEAKER_02]: You're not just doing stuff for free forever, and then you are not not using happy ears when you hear customer feedback Let's move forward then drew this will be exciting. [SPEAKER_04]: What is the future look like for brief for what you've built for where the industry is going? [SPEAKER_04]: It changes so fast. [SPEAKER_04]: What does the future look like? [SPEAKER_02]: The buzzword of two weeks ago was loops, and again, everybody's now come back to factories and graphs and all of these sorts of things.
[SPEAKER_02]: That's always where we've oriented is that there will be specialists as well as generalists and the generalists will need to orchestrate parts of fleets of agents. [SPEAKER_02]: Those agents will be doing traditional product design engineering work, and the people operating those agents might come from a product design or engineering background. [SPEAKER_02]: and we see brief as the product management stool at the strategic arm of the communication arm and the mediation of ideas arm of that whole process that empower sort of these these individuals as they're operating these factory sort of environments.
[SPEAKER_02]: I also say a lot of people try and make that job really early. [SPEAKER_02]: They go right from very traditional development to a full [SPEAKER_02]: factory autonomous development environment, that's probably where I see most of the mistakes today. [SPEAKER_02]: Most people have to, you have to step into it, you have to build your harness and think about these things all incrementally. [SPEAKER_02]: So that's where brief is today, but where I see briefs going is you're going to have product management agents operating product strategy within organizations.
[SPEAKER_04]: Let's wish to you who influences the way that you work. [SPEAKER_04]: They're my person or many persons or something you look up to and why. [SPEAKER_04]: That's a good question. [SPEAKER_02]: I think there are a lot of product thinkers in the world in terms of strategists and people who are just very thoughtful and opinion about these things. [SPEAKER_02]: One guy I know the primarily through what Twitter is this guy Andrew Ziggler. [SPEAKER_02]: There's been his podcast, this is called Dev Interrupted, the Andrew Ziggler's podcast, Dev Interrupted.
[SPEAKER_02]: He's been on the sort of the bleeding edge of all of this stuff. [SPEAKER_02]: He was talking about loops and things like this back in December. [SPEAKER_02]: The huge info there, Keaton Shaw, of course, is a big influencer in the overall product community, but just watching him migrate his product thinking towards a
[SPEAKER_04]: Last question, so you're getting on a plane and you're sitting next to a young entrepreneur who's built the next big thing. [SPEAKER_04]: They're jazzed about it that can't we show it off the world and can we show it off to you right there on the plane? [SPEAKER_04]: What advice do you give that person having gone down this road a bit? [SPEAKER_02]: I would always tell them that I give terrible feedback. [SPEAKER_02]: I have many times we will show me stuff and I'm like, that's stupid and I don't end up being great.
[SPEAKER_02]: I always can't. [SPEAKER_02]: If it's not specifically for me, don't, I'm not going to give you that about it. [SPEAKER_02]: I'll help you think throughout think about it, but I won't, I won't be the person you have great feedback. [SPEAKER_02]: then after that it's like yes lessons about if you are selling something for money then you need to charge money that's a critical moment so when you are talking to people about the product also you shouldn't talk to people about the product [SPEAKER_02]: just a general product management sort of philosophy.
[SPEAKER_02]: You ask them questions about their challenges and fear if they save the things that you expect to hear. [SPEAKER_02]: And if not, again, don't use happy ears. [SPEAKER_02]: Follow that pain point rather than your own sort of a prescription, and fall in love with the problem. [SPEAKER_02]: And not the solution, if you will. [SPEAKER_02]: Once something is starting to work, it's starting to pick up, you're starting to take off a bit, then what you need to think about is the long term of people that you have around you and your role of the organization.
[SPEAKER_02]: Eventually the CEO's job is... [SPEAKER_02]: operations and inspection, but that a lot of people don't love that work, operations meaning process, you actually have to be a thoughtful and careful and really care about process until a lot of people that's a dirty word, but also just think about where you see your own personal interest going over the next 10 years, if there's something you really don't want to pursue. [SPEAKER_04]: Couldn't agree more that's fantastic advice. [SPEAKER_04]: Drew, thanks for being on the show today and thank you for telling the creation story of brief.
[SPEAKER_02]: Yeah, thank you so much.
[SPEAKER_04]: and this concludes another chapter of Code Story.
[SPEAKER_04]: Code Story is hosted and produced by Noah Labhart. [SPEAKER_04]: Be sure to subscribe on Apple Podcasts, Spotify, or the podcasting app at your choice. [SPEAKER_04]: And when you get a chance, leave us a review. [SPEAKER_04]: Both things help us out tremendously.
[SPEAKER_04]: And thanks again for listening.
Podbean