#121: Why your side project should start with distribution | Colin Matthews (Head of Education @ Lenny’s Newsletter)

Before we dive deep into this episode, I just wanted to do a quick note that this is a unique episode. This is a recording that I did with my friend Colin Matthews, who is the head of education for Lenny's Newsletter. He's also been a founder himself, a PM, and this took place at the Toronto Product Conference. And the thesis of the conversation is basically that one of the best ways to prepare for the AI era is to build a side project, but not just like a weekend prototype. Build a real product, find users, and most importantly, try to get someone to pay for it. And the whole idea is that, you know, as building gets easier, distribution matters more. Basically learning to turn attention into usage and revenue. And that's, I think, it's going to be one of the most valuable things that a PM can practice. So if you're a PM or a product leader thinking about what skills matter most next, this episode is for you. If you want a step-by-step launch playbook, we don't really go that deep in this episode. And then finally, I just wanted to say a huge thanks to Andrew Balaji and the Toronto Product Management Association for having us. It was a blast. And yeah, with that out of the way, let's get into it. Thank you. Cool. Super exciting, first live podcast that I'm doing, and huge thanks to Colin for joining us. Also shout out to my co-host, Ben Eris. He couldn't be here because he tore his ACL and had to get surgery, so we'll be thinking of him today. Yeah, it's very clear that the role of product is changing. And, you know, if you follow the LinkedIn discourse and many newsletters, you'll see, hey, is the PM role dead? Should PMs be coding? Should that code make it into production? Are the lines between engineering, product, design blurring? And while I have a lot of hot takes on all those questions, I think the interesting question to me is, like, what are the most important skills and judgment that PMs and product leaders need to develop in this future, right, and also this present? And I think that, from my point of view, the PMs that are going to do best in this kind of present and future are people that are very high agency and that can basically make the most and basically allow everyone in their team to operate at a very high point of leverage, right? Like, engineering is working on things that they can only do, designers only thing they can do, and so on. But also, one of the best ways to do that, I think, is getting very close to what they're doing, right? So getting close to building, so understanding enough, hey, like, how do you take an idea and make it into, like, a usable prototype so you can make tradeoffs quicker, you can make decisions quicker, and getting close to kind of production, right, and understanding basically, like, you know, what needs to change when you have a demo and taking that into production, right? Like understanding auth, infra, et cetera. And also distribution is super important, right? Like, if you're not able to get attention for whatever you're building, it doesn't really matter, right? And then if you cannot turn that attention into usage and that usage into revenue, then you don't really have a business. And my thesis is that one of the best ways to do that is to build a side project. And the reason for that—and by the way, I'm not saying that everyone should kind of become like a founder, but I'm saying that you should try to play the different roles that you work with, right? So engineering, design, sales, marketing. And if you do that, basically you're going to build what I call, like, the three judgments. One of them is what I call the boundary judgment, right, which is really understanding, like, very clearly, like, what is the highest leverage use for engineers, for designers, and for PMs. The second one is around production leverage, right? Like, what really matters when you have users that are using your product at scale, and what's still very hard from an engineering point of view. And then finally is, like, the distribution, right? Like, how do you get people to actually use and buy your products? So that's kind of, like, where I wanted to start. And Colin, I'm curious. First of all, thank you for listening to my TED Talk. But second, I'm curious, like, yeah, is that thesis sitting with you? Where would you push back? Yeah, just to recap. So, like, we said we have kind of boundary judgment, you know, what should PMs do, distribution judgment, and then production judgment. I would agree. As mentioned previously, just for some context on me, I've been building side projects for a long time. So I did an undergrad in CS and then been building little software projects for a while. Some of them have had users and revenue. Most of them have not, to be really clear. I built side projects this year that have no users and no revenue. So my hit rate is probably like 10% on anything working. But yeah, just through, like, the practice of building software and taking on the role of, like, the engineer for a little bit or taking on the role of the marketer for a little bit, I think you build some level of, like, empathy, first of all, for, like, the types of problems that need to be solved. And then also, you obviously get better at working with those functions as well. So, like, you know, when I was working in product, my primary role was usually on technical products. I worked on a lot of, like, data exchange products or platform products because I worked really well with my engineering team, because we could communicate more easily because I understood what they were doing. So definitely, like, a lot of leverage, I think, to be gained in terms of, you know, leveling up your skills, and side projects are a great way to do that. Yeah, and I think an important distinction too is, like, how you define a side project. And, like, I think today it's very easy to build an app in 30 minutes with cloud code, and that maybe, you know, a few friends or family members are using, but I wouldn't really consider that, like, a real side project. I think a side project has to have real users, and maybe even better if you're making money. And so I'm curious, maybe, like, what is the first kind of, like, side project that really started to teach you something about those boundaries, and whether it was, like, a successful one or a one that maybe didn't work out? Sure. Yeah, it's a good question. I mean, like I said, I've been building for a while, so probably the very first one, I was in, like, a university startup accelerator. If anyone's familiar with, like, the DMZ, for example, that's nearby, very similar to that. Not the DMZ, but similar. And I went through that whole thing, and I was trying to build a product that allowed you to reserve a spot at a walk-in clinic. This is still a problem that bothers me, that you have to sit and wait in a room. And I was like, let me just reserve in, like, a digital line, and then I can go and I don't have to literally sit in the room instead. And so I learned a lot about, like, I would say all of it. The engineering side, like, it was terribly engineered. It was the first thing I ever really tried to build. So there was lots of problems and all that stuff, but I learned a lot from that experience, obviously. I would say actually what I learned more and, like, the lesson that stuck with me is on the distribution side. At no point in time did I consider, like, how am I going to sell this? How much are people going to pay for it? You know, where is the funding going to come from? Especially, you know, in Canada, where, like, healthcare services are free, are patients going to pay for this convenience of, you know, saving a spot? And so I did not consider any of those things at that point in time. Obviously the project didn't work out. But yeah, like I kind of have on the slide here, I think distribution was the main thing that I did not consider. And still to this day, sometimes I don't consider, depending on what I'm trying to accomplish, yeah. Yeah. And I feel like that's also going to be one of the bottlenecks in this future of, like, you, as building gets easier and easier, and, like, just telling people, hey, here's what you have to pay attention to, or this is a product worth trying, is going to be harder and harder. And I know you've almost, like, built a framework around how to build, when you think about building a side project, that I think it kind of touches to that distribution part. So maybe, like, can you start talking a little bit about that framework a little bit? Yeah, sure. It's not, like, anything super formal, but basically the idea is, generally speaking, I think in, like, product discourse, we're kind of taught to solve, like, customer problems first, right? So try to figure out a customer problem and then solve that problem. And the framework just basically starts with distribution before caring about a customer problem. So a good example of this is I've been teaching online for a while as well, and I taught on a website called Udemy, which I'm sure most of you are familiar with. And so the distribution there is, like, okay, but wasn't great for me, and I was really focused on the customer problems that I was trying to solve, and whether or not I made a good product or not was kind of irrelevant because I just wasn't getting the distribution that I needed. And then I later moved on to a platform called Maven, and the distribution was way better. And so the thesis here is basically, like, if you start with a distribution channel first. Especially as a solo builder, and then you look at what types of customers are active in this channel and what types of problems can I then solve for those customers, you can got a lot more leverage than the other way around, which is like starting with a customer problem, like I want to solve a problem for product managers and then trying to figure out how to reach those product managers, right? It's almost, it's much more difficult to do it that way than it is to start with the distribution and then kind of work backwards from there. Yeah, it's almost like starting first thinking what distribution channels I have available to me, and then based on that, kind of start to think what problem spaces should I go after, basically. Exactly. And like the distribution channels that you think you can play well in will limit the set of customers that you want to focus on, right? So, for example, I do not really like creating content that much. I don't like posting on LinkedIn. I don't, you know, I don't mind writing long form stuff that I find useful, but I'm not great at like regular social content. And so for me, you know, if I started by trying to create some solution to some problem, right, and then later on I just tack on the distribution channel of like, I'm going to post on LinkedIn, the probability of that working out for me personally is very low. And also there's no relationship necessarily between the customer that I'm trying to solve for and my idea that they're going to be active or convert from LinkedIn, right? I've just assumed that to some degree. Versus going the other way, right, as we said, like starting with a distribution channel that both fits you well, as well as, you know, you know that there's some group of customers you want to solve a problem for that are already there, and then kind of work your way down from there. Makes sense. Let's say I'm a product leader or a PM that be like, hey, actually the way I've been doing work is I've always started with like the PRD, or, and then after that I start working with marketing to figure out like how to get distribution either for a zero to one bet or maybe like a new feature in your core product. How would you maybe incorporate that type of thinking into like this new product process? Is it just like involving like sales and marketing earlier? Is it something else? Yeah, that's a great question. I think it depends on the context. So we'll answer the question two ways, like one as an individual, if you're trying to build something, and then one, you know, kind of at work as a PM. As an individual, it's a weird kind of like muscle to try to learn because at work you have a marketing department and a sales department and all these other people who kind of take care of distribution to some degree for you. And so for many PMs, I think it is an afterthought or not even something you consider when you're shipping something, like how will this get distributed and is it going to increase the kind of size of, you know, the product in that more users will use the product or see the product because of this individual thing I'm shipping? So, so yeah, anyway, back to solo, I think, you know, really it's about playing to your strengths. Another thing that I've done in the past, for example, is integrations with existing marketplaces where people can search for my stuff, but it's not hyper-competitive. So you might think about like a Shopify marketplace or like a Wix marketplace, and you ship something in that domain. People can search for it, find it, and you don't have to do any type of active marketing. For the work side of things, I think this is kind of like the blurring the lines question to some degree. Like, I think you would be a more effective PM generally if you consider distribution when you're doing your work, especially if you consider it early. And some people do this, like, you know, it might, you might decide, is anyone going to use this feature or care about this feature after I ship it, rather than just does it solve a customer problem? Because oftentimes, I'm sure you know, like apps can get bloated, people can't even find the thing that you just shipped, like you spent six months on something and it's in some submenu somewhere, right? And so like trying to lean in and understand the impact of what you're going to ship ahead of time is certainly useful. In terms of ways to accomplish that, I think it's like, honestly, yeah, partnering with marketing, partnering with sales, probably partnering with whoever owns like, or has responsibility for the product surface area to figure out like how you're going to get your stuff out there in the world. Yeah, and I think that's where actually like a lot of the learnings that you have from building a side project can be really useful, right? Like, because when you are, you know, building a side project, you don't have a team, so you have to get very scrappy. It's not like you can build a full-fledged, you know, marketing plan or sales plan. So a lot of times you just do like hacky things like, hey, like let's build a website that, you know, you can get interest on, and if we get enough clicks, then that's a sign that we should build. Or maybe it's just like, hey, like, you know, fill out this form if you're interested. So I think like it almost opens the aperture of what's possible and kind of gets your creativity flowing in ways that are very interesting that maybe before you didn't feel like the ownership to do that. Yeah, one other thing that's interesting is it can introduce a little risk, I think, personally, because if you try to consider distribution first, there's a chance that the thing you're trying to make will not succeed. And, you know, the nice part about that is you'll know that early, so you don't build it. The downside of it is, like, most of us, our job is to build things, right? So, like, if you spend six months at work trying to figure out if the bet you want to take or a series of bets you want to take are going to work, and they all don't work, it's going to look like you're not doing anything, right? So you'd have to be a little bit careful, I think. But if you could imagine the counterexample where, like, you do, you know, some of this validation activity that you have a strong distribution for the thing you want to ship ahead of time, and then you ship it, the amount of impact that will create is much greater than, like, shipping a feature and ignoring distribution, right? You get to say you did it, but, like, technically you kind of, like, checked the box, but that's kind of really it. It doesn't move the needle for either yourself or for your company. Amazing. Yeah. So we've talked a little bit about, like, kind of the blurring lines between, like, distribution and product, and I think there's a lot of potential there, and I think a side project can be an amazing way to do that. The other kind of that I'm interested in is kind of like, you know, I think you've half a lot of experience working with engineers, also with designers. So I'm curious, like, kind of what are some things you're seeing in terms of, like, blurring the lines in those two functions, and, like, maybe, yeah, like, what would be, like, the things that you would start paying attention to and start doing if you're a PM at a company? Yeah, this is probably, like, the hottest of topics nowadays, right? So we can just kind of name it quickly. Basically, PMs are shipping to production—I don't know what percentage of them, but maybe it's like 15 to 20% at a maximum—PMs who, you know, they get into GitHub, they create a pull request, engineer reviews it and merges it. So that's certainly a thing that is happening. I would say that's kind of like the end level or the top at the moment. But, you know, six months ago or a year ago, that wouldn't have been considered at all. So AI obviously is enabling that there. Outside of that, like, prototyping is a really big use case, where working with design or engineering, to be honest. And then, yeah, there's a lot you can do in terms of using AI coding just in general to, like, produce artifacts that are useful in those contexts. And I think this is why AI has been such a big deal in product, because PMs can, you know, lean in a little bit, take some small tasks off the engineering team's plate or just ship things themselves, or at least try to build some intuition on, like, if I built this thing, would it actually work, which is more of the prototyping side of things. Yeah. And that makes a lot of sense. And yeah, I think the shipping code to production is interesting. I have a lot of people in the Supra community asking me, hey, like, I have everyone in Cloud Code or Codex. We're making great progress, but I'm like, I'm not sure what to do here, if I should give them full power, like, to ship things to production. I mean, I think the thing that has stayed consistent across a lot of works that I'm seeing is, no matter who's shipping to production, the quality assurance of, and like, who reviews the PR stays the same. Like, there's the same level of diligence, and almost even more if someone who's submitting a PR who's not an engineer. And I think kind of where I'm seeing things land a little bit for a lot of the companies that are a little bit ahead of the curve is that they are allowing people to ship, like, almost like surface-level changes into production. So, like, quick copy changes or quick UI changes, but for more complicated features that have some backend architecture, that's where, like, be like, cool, you've prototyped this, but now let the real engineers figure out the changes. And I actually think that's where kind of like side projects can be really helpful to build that intuition. And like Ben and I, we run another company called Insider Loops, and we just had a big problem with Auth that it broke, and I'm like, oh shit, like, I would have loved to have an engineer for this, and we probably should not be building that. So yeah, I think building that side project can be really helpful to figure out, hey, here are the pieces that having someone who's really good at what they do actually really matters, because the stakes of getting that wrong are super high. I'm curious, like, your reaction there. Yeah, so I've been actually talking about this a lot lately. So maybe we can add it as a fourth line, which is just technical judgment, maybe similar to your production one there. And the idea here is like, what artifacts should you ship as a PM? So should you be shipping to production, a.k.a. creating a PR, and that's what you're handing off to engineering? Should you be shipping a prototype, which is theoretically, like, if we just think about velocity, less useful because someone has to pick up the prototype and actually move it into production? Or should you just be going with the classic methods of, like, you're writing a PRD or a spec or something like this? And the answer is kind of based on what you said, is based on technical judgment. So, like, what is the level of competency for the individual in making these changes? Like, what is their level of technical skill? How well do they understand the systems that are currently in place? And then kind of like organizationally, what's useful or accepted? So in most organizations, like changing copy is something that probably anyone could do with like a Claude code or whatever, because there is no technical, like, judgment necessary. You're changing text somewhere. Now, we'll make a small exception to that. What if your product has many translations and, like, internationalization, and there's some internationalization system that is complex? So, like, you could take almost any example that seems simple and, depending on the context of the company, could not be simple. And one of my favorite ones for this is, like, adding a profile picture, because it seems like a simple feature. It's like, if you prompt Claude code, like, Hey, I want to add a profile picture, it'll figure it out for you. But almost always it makes the same mistake, and this is gonna be slightly technical for a second. It's gonna store the picture in the database as text in a format called base64, which is basically storing, like, this very large text string in the database, where what you should be doing is creating an object storage, something like Amazon S3, put the file in there, and then have a reference in your database to the ID in object storage. And that's, like, a very, very simple thing. It's like there's no—any engineer would do that, but a Claude code is going to make the mistake every time of, like, if you don't have that set up already and you're introducing something, it's going to make recommendations that don't make any sense. So, I mean, I don't want to ask myself a follow-up question, but maybe a follow-up question is, How do you avoid that? Yeah, that was going to be exactly my—like, how do I know that I'm not, you know, like, hitting one of those icebergs that, like, looks very simple on small from the surface level, but, you know, in the bottom of the ocean, just it's, you know, gnarly? Yeah, yeah. Great question. So I think, generally speaking, like, side project is a fantastic way because you have complete control over the architecture. So you can spin up object storage or put a database or use whatever type of database you want, spin up any service, any product analytics. Can I ask a question there? Because I think, given where the models are going, especially, like, Opus 4.7, 5.5, like, and, like, Codex, like, goal feature, you can just be like, Hey, build this, and it will build it for you, and it will make all these decisions. And there's a world in which you don't really need to understand the decisions because it's just so good that it's just, like, almost like one-shot that. So, like, how do you recommend people, as they're going through that process, to really understand what's happening? Like, what should they be paying attention to? Yeah, this is where, like, using AI for the purpose of comprehension rather than, like, velocity is really useful. And if you're on a side project, like, it's tempting to want velocity because, like, it's cool to ship stuff, but really it should be about comprehension most of the time, I think. So, like, one small recommendation is I would say don't use Supabase, not because I hate the company or I don't like the product, but because, like, it's one of those things that's a convenience where they package together all of the things for you, and for whatever reason, our AI models really love to recommend Supabase and they know how to use it. And so everything can be, like, fully automated end to end. You don't have to worry about hosting or object storage or databases or anything, right? But I guess my pushback to that is, like, if that's where the future is going, why wouldn't you just, like, adopt, like, the tool that's clearly going to become the norm? Yeah, and you're saying that if your goal of a side project is to learn, then that's what you should do it. But, yeah, like, how do you navigate the two, right? Yeah, I think, like, Supabase is a great product for velocity, but the problem is that, like, your company doesn't use Supabase. There's a zero percent chance that any company of any size uses Supabase, maybe, like, you know, YC startups and individuals and whatever, but, like, you know, Amazon isn't using Supabase, obviously. And then the second thing is that you don't, I think, learn the pieces individually. You get this kind of package where everything is kind of, like, the word is automagically works. Like, it kind of just all fits together nicely, and you don't have to solve the problems of getting things to fit. And so I think that's how you learn is you, like, you try to spin up a server somewhere and you, like, I don't even really know what that means. Like, what does it mean to spin up a server? You're like, oh, okay, I need to host the backend for my application. That's going to be an API. And then separately, I need to host a database. Whereas, like, with Supabase, it's just like all comes together, right? And so you see a little bit, I think, more of the internals when you do it intentionally, like one piece at a time, if that's what you're focused on is you want to learn the technical side. And that's how I learned most of my stuff. I mean, like I said, I have an undergrad in CS, but you have to learn most of this stuff outside of school. And obviously it's been a few years at this point. So yeah, most of my experience with it is just, like, continuing to try to build something that I wasn't able to do before and, like, adding on a new layer kind of one step at a time. I want to take a moment before we get back to the episode to tell you about Insider Loops. This is a company that Mark and I started because we just believe this should exist. Companies should be offering candidates the best possible preparation for their loops, yet what they give them is vague and often not very actionable. So we took the matter into our own hands. We've put together well-researched and continuously updated guides for PMs interviewing at companies like Anthropic, OpenAI, Google, Stripe, DoorDash, and more. If you're getting ready for PM interviews at those companies, go over to insiderloops.com and learn more. Now back to the episode. Makes sense. Let's say someone is listening to this, like, cool, I'm sold. Like, side project is such a great way to build better empathy, like move faster, help my engineering team make better decisions. Is there, like, a stack that you usually recommend starting with that will capture, like, maybe, like, the 80/20? Yeah, so I would say pick a stack that's going to feel comfortable for the AI. In that, like, you don't want to pick some, I don't know, like eclectic language that doesn't get used at all, because you have to remember that, like, you know, all these AI—yeah, they're all trained on, like, you know, data that exists in the world. So most of the time it's going to be, like, either a Python or a JavaScript stack, right? So for Python, you can use, like, the normal stuff. Like, you can use—or sorry, for JavaScript, you can use, like, React on the front end, Node on the back end, and usually PostgreSQL or some type of SQL database on the database side. And any AI is going to be fine with that. And then if you want to do the Python side, like, there's lots of similar options like Django or Flask or whatever. I don't know if you're asking that or another question. Yeah, but basically, like, what are—want to give you a flavor of, like, what your engineers are going through and kind of, like, the key pieces or the key building blocks. Yeah, and then, like, you're going to build a client side, right? So the UI, it's going to have some stuff. You're going to build a back end, which is your API. Your client's going to talk to your API. You're going to build a database for storing data. You might have to add object storage, as we talked about before, or third-party integration or OAuth with OAuth if you want to do Google OAuth. Like, all these things you start to, like, learn to layer on—that the very basic primitives, like, you can get up and running pretty easily, but then you might get stuck on, like, an auth problem. But then you learn, right, and you won't get stuck on that auth problem a second time. I'm kind of going back to something that you said, right, that there's, like, almost, like, this spectrum of, like, you know, teams that are still writing the PRD, teams that are then kind of, like, moving into, like, maybe prototypes, and then, like, the full, like, kind of, like, cycle, right? Like, not only just you're shipping code to production. And is there a case for not—for just writing a PRD and not writing the prototype? Because, like, I feel like you just get so much more, I don't know, like, information and data from the prototype and allows to advance the conversation way more. So, like, is there a case for just not doing that? Yeah, I think so. I think, I do think like, okay, well, I taught a course on AI prototyping for a long time, so I might be a bit biased. But I actually do still think there's, like, a lot of value in a spec or a PRD. Like, really good things like distribution go-to-market aren't going to be captured in a prototype. Like, it's just not possible, right? And so, like, you know, or, like, legal risk, or, you know, I worked in healthcare for a long time, like any type of privacy risk, right? Like, there's so many things that need to be resolved from a product perspective that have nothing to do with what is being shipped to the user in terms of the interactions. So I think prototyping is fantastic to, like, I would recommend doing prototyping first before writing a spec, because it's like, should we ship this thing, AKA does it have any user value, right? And then second to that, like, okay, if we were to ship this thing, what are the implications? And that's where, like, some type of document might come in. So I, yeah, I'm a pretty big advocate for prototyping almost everything. And prototyping doesn't have to mean UI. It can also mean, like, if you work on a backend product, you can prototype an API. You can prototype the output of a machine learning recommendation. Like, you're going to, you know, build some machine learning system, and you're going to say, this is what it would output, right? So, like, prototyping can really mean anything, and it just really is about, like, showing someone what the final state would be to try to build some level of, like, confidence and conviction that that's the right final state. Makes sense. And now maybe let's talk a little bit about, like, design and product. And, you know, I think when you're doing a side project, you're basically being the designer, right? You're building everything, and I think— It's possible that at a company you might move to, like a similar world. I think to me, like the way that I'm imagining is, like, the best designers are probably going to be working on their kind of, like, design system, and then it's going to allow, like, PMs and engineers to just build based on, like, that beautiful design system that talks perfectly with Claude, with Codex. And is that kind of, like, what you think the puck is going? And also, like, is there anything that you can, and I think given that you're going to be making more decisions but within constraints, like, what are some of the things you can start to, like, kind of build more of that design intuition as a product leader PM? Yeah, I think it works very similar to, like, code, right? So we think about code as, like, we have an existing code base that is our documentation of what exists today. And then when you want to prototype something or ship something, ideally you're using that code base as a reference so that whatever you prototype makes sense in context of what exists today. You're not, like—actually, I'm really not a fan of, like, some of the web-based prototyping tools at this point, like, you know, v0 or Lovable. It doesn't really matter which. I don't have anything against those companies, just the idea, because they're built, like, in complete isolation to your product, right? And you can put in a screenshot or something like that, but it's really not the same thing. For example, it wouldn't capture the data model of, like, your product, right? And so what's possible is not really captured, and they'll let you kind of build anything. Anyway, so for design, I think it's a very similar set of things, like what you're describing, which is what is the baseline set of, like, information or context that we want the model to have? And so, yeah, that's going to be the design system. Funnily enough, the design system can be expressed in more than one way. One way is obviously, like, Figma. That's going to be the one that most people are familiar with. And you can use, like, the Figma MCP with Claude Code to interact with that, and it does an okay job. The other way that the design system is expressed, which is more legible, is code, because you have, hopefully, like, a component system inside your product. You have the way things look and feel today. And so once again, you can kind of go back to the code base as a form of leverage for design work as well, right? You don't have to necessarily interact with Figma in order to accomplish that. But yeah, I do agree with the kind of premise, which is— Trying to create leverage in the team. And I think this also goes the other way. Like design and engineering should get leverage from product, where they don't need to depend on product to, like, make product decisions. And in the same way that there should be, like, context and artifacts that product can provide to help engineers, you know, make decisions independently of you. But ultimately, yeah, I think it makes sense that, like, there should be some form of leverage that's produced by the design team. They are the experts at design. They share that leverage with others, and maybe they do, like, some type of, like, consultation-type thing where they come in and help with, you know, more gnarly problems. And do you think it's an overkill for when you're building on side projects to build a design system to, like, as a way to, like, to learn how to interact with that? I don't think so. And how would you start with that? Would you just go into Figma? So funnily enough, I did this recently because I have this, like, mock product. It's like a Strava clone. Actually, if you come to my talk later today, you'll see it. It's called Stride, and it's purely for the purpose of, like, building a full ecosystem around a mock product to demo some stuff. But one of the things I did is I built a full design system in Figma, and I did it through the Figma MCP because I'm not a designer. So I just, like, basically I had my code base. I told it to translate the designs in my code base over to Figma, and it used, you know, the proper, like, component systems and styling and all that kind of stuff to create that into an actual design system, like, you know, proper design system, not just content in Figma. And then, yeah, if I want to, I can pull that back out now with any type of reference and use it. So for myself, I'm not an expert at Figma. I just use Figma MCP for it, but you can do it whatever you want to do it. Makes sense. I feel like we've talked about a lot of things. We've talked design, we've talked engineering, we've talked distribution. Let's say someone listening to this is, like, excited, be like, okay, I'm fully sold that I need to start a side project to build that intuition and be a more effective leader in my team. How would you start? Like, what would be the first step, right? Because, like, if you hear all of this, it's daunting, right? Like, I have to pick up, like, a database. I maybe start thinking about the design system, maybe the channels. Like, what would be, like, the first thing that, you know, if you had, like, seven hours in a weekend, where would you start? I think the first thing to start with, and this still trips me up sometimes, is, like, what is the intention of the side project? So I still build side projects with the intent to understand or solve a technical problem. And then sometimes I trip myself up because I will try to convert that to a business, like it's a real product. And very often what I find is that if I'm trying to start with a technical problem, I do not do my due diligence on whether or not I should actually build this thing. I'm just building it because I think it would be cool. So anyway, I would start with trying to understand, like, are you really trying to build a side project for the purpose of, like, capturing users and building a side business, or are you trying to do it for the purpose of learning? And if it's for the purpose of learning, you have a lot more leeway in terms of, like, your decision-making because you can make bad choices and it doesn't really matter. If you're trying to do it for the purpose of building a business, there's a lot of work usually you have to do prior to actually shipping anything to check whether or not anyone cares about what you're building. And again, this is the mistake that I've made many, many times. Can you talk maybe about the trade-offs, right? Like, because I think if you want to get the full experience that we just talked about, like, I think you probably want to build, like, something that has real users that maybe you get conversions, at least if you want to touch on the distribution part. But I think that's very hard and it kind of delays the part of, like, building. So, like, maybe, like, how would you help people choose, like, when is the right to start, like, to choose something for the learning and, like, the design system, the engineering kind of knowledge and technical foundations versus, like, maybe, like, kind of the end-to-end spectrum? Yeah, I would personally start with just shipping for the purpose of learning. So, like, I wouldn't even try to ship something for the purpose of distribution. You can certainly still put it in the world and, like, maybe you'll get surprised. But, you know, I think it's better to set the right expectations so you don't disappoint yourself in the future. And so, you know, just get something up and running, basically get something working, integrate with Stripe, integrate with Google Auth, like, figure out how to get the whole thing, the whole stack working. Because you will come up across many problems that may feel overwhelming if you're also trying to be like, man, this is taking longer, and I really want to make money or have revenue, and you're, like, stuck behind all these technical issues, right? So I would take the first project just as, like, a learning experience. Still do the whole thing. Still put it out there. See if you can get a sale. Like, there's no reason not to. But I wouldn't, like, focus on the distribution side if you've never shipped anything before. And then maybe on the second or third iteration, like a new project, you can kind of restart and think more through the distribution side first and figure out what you want to ship and for whom. Cool. So, yeah, I think that makes a lot of sense. Like, start with just building a couple of products just for the sake of building. And it sounds also like maybe as you're planning through it, like, you might want to be proactively models, be like, hey, like, my goal here is learning. I want to simulate a real environment. I want to use whatever my company is using, like maybe AWS, real databases, not Supabase. And it might also be helpful to have connected to Stripe or something. And even if you don't get any real customers, just, like, maybe, like, doing, like, a fake, like, transaction, right, and, like, just refunding yourself, like, just going through that process and be like, hey, does it work when someone buys something? Are they able to use Auth and Sign Up and kind of connecting, like hooking all those things up can be super useful. And I think that makes a lot of sense. So, okay, so I think, cool. Like, I think it's clear for people who just want to build for learning. And I think you mentioned all the key pieces that you need. And then maybe, like, for someone who is like, I'm ready to graduate to the next level, like, what would that, like, maybe distribution sprint look like? Like, what are you, like, when Colin is starting a new project, like, what are you doing in the first, like, maybe, like, couple of days that really helps? Yeah, I'll just start by telling you, if I knew how to solve this problem consistently, my life would look very different if I knew how to get distribution on all the things that I built. I think, generally speaking, for me, it is still a bet. Like, in that you're never going to have certainty that whatever you're doing or you're thinking about doing is going to work. And so I really like this idea of, like, a meaningful rep, which is just the idea that, like— You, ahead of the time before you try something, you define what does it mean to try to attempt this thing? Like, you know, instead of having your first failure kind of daunt you and put you down, it's like, I'm going to try to do this for six months. Then maybe that's my meaningful rep, and I'm just going to commit to that at the beginning. And then in terms of, like, distribution best practices, so I think as an individual, there's really two common patterns that I've seen work successfully. One is to build some type of personal brand. There's lots of people who do that, right? So you're creating content, you're going on podcasts, you're, like, trying to get your name out there in the world and trying to offer something of value. Typically, if you just want to know, like, the way that this works is you try to, at least I try to give away as much value as I can, and then people who like what I'm providing will very frequently go and see if I have anything else to offer and then end up purchasing a product. So it's not like trying to gatekeep any type of value or content, but it's giving away a lot of content. And usually the way I structure this is that, like, I would give away all of the information, and then I would sell the implementation, right? Or, like, I basically solve the problem for you when you buy the product, but you can solve it yourself if you'd prefer to do that. And that usually builds goodwill with people and all that kind of good stuff. So that's one way to do it. The other way to do it is to tap into existing distribution channels. So you're not trying to build an audience at all. You're going to somewhere where people are trying to find the thing, and you're showing up in that space. So, like, the classic example of this would be, like, you know, SEO, but SEO is a competitive space. Yeah, or like the App Store, for example. Yeah, exactly. So you might think of, like, you know, something that's a smaller marketplace, but still a marketplace that people are searching for. So I give the example of, like, Shopify before. A smaller example is, like, Wix. So I actually built a Wix—actually, this was before ChatGPT with GPT-3. I had to get special permission to use it. OpenAI had to— You're a early adopter. You're allowed to use this model. I built a product description generator. So literally what people would do is they'd go in and, like, bulk generate descriptions for their products with a Wix integration. And, yeah, that got to, like, I don't know, a couple hundred dollars a monthly revenue and I think a couple thousand users because I had a free tier. And I didn't do any marketing of any kind. Like, I was sitting somewhere where people were looking for the solution or had a problem, looking for a solution, and then they just, you know, picked it up. So those are really the only two ways that I know how to do it and that I've had any success with is, like— Building it up yourself, which takes much longer, but is generally more sustainable. Or, you know, trying to tap into existing distribution and then finding something that fits for that channel with the types of customers that are in that channel. Yeah, I think an important piece of nuance too is that I think you're really good at finding distribution channels that are on the newer side. And when it's newer, right, it's like much easier to get noticed, right? So, like, for example, I think you did a landing post about, like, building, you know, ChatGPT apps in the App Store, and you're one of the first people to talk about it. So I think just also thinking about, like, where the puck is going and being one of the first people to build on that platform is going to give you an advantage over someone in a massive app store, like the iPhone App Store, right? Like the App Store. Actually, that's a really fun example. So, yeah, I wrote a post with Lenny on building ChatGPT apps, which are also known as MCP apps. And I had also built a coding agent for that where you could basically go to this website called Chippy and build your MCP application. And this is a really good example of me focusing more on a technical problem than a distribution problem and not really doing the product thinking properly, because I wanted to build a coding agent. I thought it'd be cool if I could build one from scratch, and I wanted to know how they worked. So I built a coding agent for this use case because there was an up-and-coming use case. And I got it to, like, 1,800 bucks in revenue in the first month or two, which is not bad per month. But ultimately what happened is that everyone who's shipping these tools, like MCP apps or ChatGPT apps, is using Claude Code or Codex. Like, they don't need my thing. And that's kind of obvious in retrospect. But, you know, ahead of time, I was like, oh, it'd be cool for me to ship a coding agent, and here's a use case where I think I can add value. And so, you know, again, sometimes it's like, could I have scaled that business? Maybe, right? Maybe there's, like, a prototyping lens to that or, like, a testing lens where, like, there's probably different adjacent problems. But I didn't. That one is one that's just in the graveyard. Amazing. I know we're almost out of time. Anything else that we should have covered or that you want to share with the room relevant to this topic? Yeah, I think, well, we'll see about time, but one is just, like, be curious. I think that's maybe, like, an obvious thing, but it can feel intimidating to start. I think learning is the important part, especially as models get better. I think learning actually becomes harder because it's so easy to get velocity, right? So taking the time to pause and try to actually understand what you're doing versus just, like, allowing an AI to produce something that you, like, looks reasonable and continue moving forward. And then the other one is just that, like, I don't think that you can really make a mistake learning the wrong thing. I've had many people talk to me about this, that's why I'm bringing it up, where they're like, What should I start with? or What should I do first? or something like this. When you, like, learn something, you have no context and you learn something, you are now in a position of, like, Oh, I learned the wrong thing. I'm going to go learn the right thing. You know what I mean? So, like, technically you can spend more time than, like, the perfect path if you could somehow predict what that was, but I think it's kind of a silly notion to think that you could. And so, yeah, I would say, like, again, it's not, you know, it's pretty generic advice, but, like, starting is better than trying to figure out how to start. So, yeah, just make something. Time in the market is better than time in the market. Exactly. Yeah, yeah. And the last thing I'll say is, like, if you're a leader, like, I also encourage to bring your side projects into your teams and encourage them to do the same thing. I think, like, if you don't see leadership doing it, I think they're going to be intimidated because they're like, Hey, maybe they think we're distracted or not. But I think actually, like, even though maybe this is not working towards the core product that your company is building, I think it's really valuable as an experience and getting that kind of end-to-end, full-stack kind of developer-builder experience. Amazing. Colin, thank you so much for joining the first live podcast.