How (not) to Launch Your Startup

0:00You think you have a great startup idea, so you spend six months building towards your big launch. Keep the idea under wraps while you polish every feature, convincing yourself that once it goes live, customers will buy. Then launch day arrives. You get 92 visitors, two signups, and zero paying customers. By the next morning, that spike is over. So, what went wrong? Usually, the problem isn't launch day itself. It's [music] everything that happened or didn't happen leading up to it. I'm Rob Walling. I've built six companies, invested in more than 240 startups, and I've written six books on entrepreneurship. I've watched thousands of founders try to get their companies

0:37off the ground. And I've seen the same launch mistakes come up over and over again. In this video, I'm going to look at six of those mistakes and what I would do instead. [music] The first is believing that one big day will change everything. Too often, I see founders putting all their hopes on one big launch day. It's like they've watched one too many episodes of Silicon Valley or seen too many biopics about the advent of Apple Computer or Facebook. And so founders get it into their head that they're going to kickstart all of their marketing and get all of their early customers from a Product Hunt launch or a thread on

1:12Hacker News, maybe a podcast appearance, a single launch email, or some other burst of traffic that's going to show up just because they're launching on that day. Most launches see very little traffic and even successful launch day spikes are temporary. A surge of visitors doesn't matter if the product, your positioning, and your follow-up aren't ready. Most successful startups

1:35build traction through repeated actions. These are customer conversations, small experiments, iterations on positioning, marketing, sales, doing these things over time and doing launch after launch, launch of new features, launch of new marketing approaches, and putting in the work over time. A launch should amplify demand that already exists. You're not trying to create demand from nothing. So, what would I do instead? I would think of launch day as the culmination of a bunch of marketing effort that I have put in in advance. So I would have been marketing since the day I started coding. Right? That's the title of my second book. Start marketing the day you

2:13start coding. And think of your launch day as a series of events that starts 6 7 8 months prior to that. When you get a landing page up, you start having conversations and you get folks on either an email list or some other way that you can contact them such that when you do launch, there's a bunch of people waiting for it. It's not trying to

2:34generate cold traffic out of nothing. People posting on ex Twitter and thinking that's going to be a launch are delusional. But if you've been posting to Twitter and you've been doing SEO and having customer conversations and maybe running ads or you any other of the 20 B2B SAS marketing approaches that exist and you've been doing those for months and months to build your launch list, you're in such a better place than showing up and thinking that the internet's going to pay attention to you for that day. Another thing that I would do is build your network, not your audience. Now, some folks really like

3:06building audiences and are good at it. If you're that, go ahead and do it. But for most folks, building a network in your space, and I don't mean other indie hackers. I don't mean other software entrepreneurs, unless those are your customers, in which case you probably have bigger problems. Build your network in the space that you are trying to launch into. So, if you are catering to graphic designers or web designers, well, hang out where they hang out. hang out in those private Slacks, in those

3:29subreddits, in those Facebook groups. They're probably not in Facebook groups, but if your customer base are realtors, they probably are on Facebook and Instagram. And so, you're going to want to hang out and hear what they say, and you're going to want to contribute and build that network. Another thing to keep in mind is if you do build a big launch list, which almost no one does, but if you do, you want to launch to a small group, a small portion of that launch list. You want to learn, improve,

3:54and launch again to the next group. Because over time, you will be able to measure success by the improvements you make. And whether you get a spike on launch day or whether you're launching to your launch list, you want to carefully observe activation. Are customers getting in and actually doing anything? Are they converting? Are they

4:11paying you? Are they sticking around? Right? That's retention. And these are the milestones or the steps that you want to be observing as folks are signing up for your app. Again, people think that launch is post product hunt, post hacker news and dot dot dot profit. But unless you're relatively scientific about it, at least a little bit, and you are measuring activation, conversion, retention, and building a list over time instead of trying to do it in a single day, you're going to struggle to get traction. You're going to be disappointed on your launch day. But even if you get hundreds or thousands of people to visit your website, it won't

4:43matter if none of them can tell whether the product is meant for them. Founders often resist choosing a narrow market because they fear limiting their growth. So, [snorts] their homepage ends up using vague language like the all-in-one platform for businesses of every size, and it's everything you need to work smarter. This type of broad positioning makes it really hard for potential customers to recognize themselves. A specific target customer, an ideal customer profile, you heard this term, ICP or ECP, if it's an early customer profile, and you're just taking a guess at it. This gives you clearer positioning, better marketing channels, or at least more specific ones. You can

5:19narrow where are your customers? That's how you narrow those 20 B2B SAS marketing approaches. You say, well, where are my customers and where is it maybe not oversaturated, where is it possible to reach them? Having this specific ICP or ECP allows you to build more relevant features for them, has stronger word of mouth, means your sales conversations and your customer development conversations are much more productive. Starting narrow doesn't mean staying narrow forever. You can always land and expand. I've seen a number of companies do that because you can come in and be proposal software for designers and if you establish traction with that segment and people are using

5:52it, let's say sales folks are using it. It's pretty easy to add that as another kind of role. It's not really really a vertical I don't think, but um to add it as another role or to then just go horizontal and just be like proposal software for everyone. But that's once you have traction and if you get to the point where you're making 10K a month and quit the day job, you can take these bigger risks. So what I would do instead is try to define a specific early customer. In an ideal world, it would be one ideal customer profile. Can you have

6:19two? Could you have three? Maybe. Especially if you're a little more experienced and you know more about this, but learn the rules so you know when to break them. And if I were going after this, I would try really hard to have a single ICP. And then you want to ask yourself the question, who are they? What painful problem are they trying to solve? What are they using now to solve this problem? Why is this problem urgent? Where do they look for solutions? And what language or phrases do they use to describe it? But you can't figure out what those customers

6:46need by sitting in a room and guessing. At some point, you do have to talk to them. Founders often mistake building for progress. So, as a result, they'll go into their basement or their home office and build and build for weeks or months without talking to anyone. And maybe they have one conversation and they're kind of building it for themsel anyway. And you know, customer conversations, they're messy. They take time. They are confusing cuz you can have 10 conversations and get seven

7:14different opinions in different ways. It's it's a lot of time and it's a lot of thinking and it's a lot of gray area. So, it's easy, especially as a builder or an engineer, to want to just go with your opinion and be really convinced that your opinion of what you're building is what your customers need. And as a result, many founders avoid sharing their assumptions until the product is finished. Customer conversations can help you understand whether the product is real, how painful and how frequent it is, how people currently solve it, whether they have a budget, who makes the buying decision, and which words they use to describe the

7:50problem. So, if you're in a customer conversation, you don't want to ask, "Would you use this?" You want to ask about actual behavior with questions like, "When did you last encounter this problem? How are you solving it today? What happens if you don't solve it? Have you paid for another solution? Who else is involved in this decision?" The challenge is people you talk to will give you compliments. They will give you hypothetical interest, and those are not

8:13validation. You have to read the room. And if someone says, "Yeah, yeah, that's cool. I'd totally consider trying that out." You need to read it. Don't just take a a nodding and a kind of a yes as a signal. Strong signals include someone getting really overly excited and saying, "Oh, I would try that today." Absolutely. That's an amazing thing. Or if they offer to give you money for a paid pilot or to pre-order it, prepay for it, a letter of intent is a stronger signal. An introduction to a decision maker if this person isn't, or frankly, a verbal commitment to try the product,

8:44which is the weakest of all of these. But depending on if someone's in your network and you trust them and you know that they will actually give the product a try, this can have some weight to it. So instead of not talking to customers, you're going to want to speak with prospective customers before you build too much. And as you're going along and as you build that launch list and the launch list, even let's say you have a thousand people on your launch list, you might have like 10 or 20 folks who are really active and you're talking to and you know by name. And those are the

9:12folks you can do a little customer development with, assuming they do fit within your ICP. You can show them screenshots. Of course, you can be sending screenshots to the list as well. But you're speaking with these prospective customers all along the way as you build. And you're looking for patterns across conversations rather than reacting to a single person's opinion. And you're going to learn to refine who your ICP is, what your problem is, the problem you're solving, your positioning, cuz you're learning

9:38language and verbiage that they use. Learn to define what should be in your MVP and even potentially your launch plan as you get to know these potential customers more and more. So, knowing who to talk to, what to ask, and what to build afterward is one of the hardest parts of starting a company. And I go deeper on this in my new book, Idea to Traction. This book walks you through the messy process of finding and validating an idea, building your MVP, reaching your first customers, and working towards product market fit. Idea to traction comes out this fall. Join the wait list at ideatottractionbook.com and I'm going to send you a free copy of

10:12my 9-to-f5 audit. It's a practical guide to finding promising SAS ideas in the problems you encounter at your day job. So, we surveyed hundreds of successful SAS founders and 72% found the seed of their startup through their own work experience. And if you sign up for the list, you'll also be invited to a live Q&A where you can ask me about your idea, your launch plans, or anything else you're wrestling with. If you're interested, go join the wait list at

10:35idea to tractionbook.com. All right, so the next mistake is building too many features. So founders have always been tempted to overbuild because it's just an easier thing to do than marketing and selling. Less scaries, less risk. Now that there's AI and that dopamine rush of telling an AI to build something and and that feature being built in 20 minutes, 30 minutes, whatever it takes, there's so much overbuilding going on. It's really a problem. So not every problem should be solved by building a feature. The more features you build, the more complex your software gets. The more potential bugs you have, the more support, the messier and harder to use it gets. The

11:16user interface will become and can easily become kind of a mess. Technical debt is a thing. Like every line of code you write, even if it has test coverage, even if it's virtually bug free, every line of code that you write adds some complexity to your product. So only build features that are going to drive your product towards stronger and stronger product market fit and are going to retain the customers that are using your product. A thing to keep in mind is that feature requests need interpretation. Don't just build

11:44everything customers tell you to. Customers are usually better at describing their problems than designing the solution cuz they are not builders. They are not product people. So if they ask you for a checkbox here, what you really want to say is, well, what problem are you trying to solve with that checkbox? work backwards and put your product hat on and figure out is there a better way to implement this. In addition, one customer asking for a feature doesn't necessarily mean the broader market wants it. You have to get a pretty sophisticated view of your space. You have to develop your own opinion of where your product should

12:13head and how your customers think and what their needs are. The better you understand your customers, the more you can say yes and no when a feature request comes up. Building features, especially with AI, can be a form of procrastination. if the features are not something that are moving to get you new customers, to get you closer to product market fit or get stronger product market fit or to retain customers. But building certainly feels safer than asking someone to pay or selling. So before you build a feature, ask yourself, does this help our target customer achieve the core outcome? How many customers have demonstrated this need? Is it preventing someone from

12:50buying or is it just a nice to have? Man, there's so many of those. Can you solve the problem manually first? Is there a simpler way to deliver the same outcome? And what will we choose not to build if we build this? Because it's all about priorities. Your MVP doesn't need to do everything right. It needs to solve one painful problem well enough that someone will pay for it. Another mistake I see is overpromising what your product can do. I get it. You're a founder. You're super excited about where you're headed and about the vision you have for your product. And the current iteration of your product might

13:20feel underwhelming compared to how you actually want it to function or what you ultimately want it to do. So founders can have a tendency to overpromise to promise that it can actually do all of this stuff as good as a human. It can do replace 100% of this role in a company or a soup to nuts. It can handle this production process when in fact maybe that's 6 months out or a year out. The challenge of course is this attracts customers with expectations that the current product doesn't meet. So this can result in people being super disappointed during onboarding, low activation, poor retention, high churn, lot of support requests, bad word of

13:56mouth, people talking about you in forums and such. A bold vision, your bold vision is useful, but it needs to be clearly separated from the current capabilities. So what to do instead is demonstrate your current product. Be specific about the outcome it delivers now and label your future plans as future plans. Avoid promising timelines you don't control. But of course, you can give vague ideas and say, "Hey, I can't commit to anything, but yeah, we think we'll have this out in the next month, or this is the direction we're headed. We're going to be building these features you're asking for. This is going to attract customers whose

14:26immediate needs match the product that you have." All right, so this last mistake is one that I see way too often. It's building in secrecy. I'm not exactly sure where Stealth launches got popular. I mean, it was in Silicon Valley. It was just companies that raise huge buckets of money and they say we're in stealth mode. We raised 50 million from XYZ venture capital and we are in stealth mode. And so somehow bootstrappers got the news that maybe stealth mode is a good thing. In fact, it's an excuse not to be talking about your product, right? It's an excuse not

14:54to be out there selling and marketing. So if you do a stealth launch where you're not talking to anyone, you launch with no audience, no network, no email launch list, and very likely no customers. So, you launch with no early access users. No one's beta tested it. You've got no feedback on features or your positioning. I'm not saying you have to reveal your road map or every detail of your product to people, but start talking about the problem you're solving and the people you're solving it for. This is where I talk about get a landing page up, collect email addresses, recruit some early access or beta users, share what you're learning,

15:29have conversations, and then use that weight list to build genuine interest. I think a lot of people want to build in secret because they're worried someone will steal their idea. And I made a whole video about why I think that fear is misplaced. You can check it out over here. Thanks for watching. If you got something from this video, subscribe to the channel and give it a like. I'll see

15:48you next time.