I love startups. I love anyone willing to go on that journey. So from the gate, I already want to do anything I can to help him out. When I eventually ran into him, we started chatting. He started pitching me his idea, and he spoke for 30, maybe 45, minutes. Finally he paused to take his first breath. I told him I thought his business idea was really cool, which it is. Then I asked him, “How many users do you have?” “Oh, we’re still working on the business plan,” he told me. “All right, how long have you been working on the business plan?” “About 18 months.” “Do you have any software developers?” “Yeah, my friend studied CS and we’re working on this together.” “What’s he doing?” “He’s working on the business plan with me.” I ended up talking to my fellow party guest for over 2 hours. I told him everything I’d learned working in software startups for the last 20+ years. My conversation with this startup founder made it clear to me that while startups are glorified throughout the business world, very little is understood about the day-to-day experience of being inside one, and especially what good technical leadership looks like from the driver’s seat. Startups are a wild ride, but they also put a lot of pressure on their leaders to make the right choices, find signals from noise, and move fast. It’s a stressful position to be in. Every decision feels crucial. But there are a few key strategies that will help you focus on what matters, and not waste runway on what doesn’t.
1. Be hungry for feedback, and be ready to change radically, quickly.
The most important thing I can tell you about how to succeed in a startup boils down to this: be hungry for feedback and be ready to change radically, quickly. How can you do that? Lower what it costs you to make a change. The lower the cost, the more able you will be to seize opportunities, and the less likely you’ll get tied down by your previous bad decisions. Cost of change is one of the most important ideas that you can grapple with as a technology leader. The drivers of that change will evolve with the growth of your business, but in the early days when you’re trying to figure out product-market fit, the scope of change is massive. A podcasting system called Odeo ultimately became Twitter, a giant social network. Tiny Speck, a gaming engine, becoming Slack, a wildly popular messaging platform. These represent sweeping fundamental changes to business models. Making small and large changes is what enables ultimately finding product-market fit.
2. Find your product-market fit
Getting feedback from customers is the most important thing you can be doing at the nascent stage of any business. Modern software tools make it possible to get your ideas in front of users on day 1 of your business, and that wasn’t always the case. I had my first job in software in 1998. Things were pretty different then. Our first server lived under my desk. When we raised a seed round, I flew to Herndon, Virginia to build out our data center myself. I flew in a plane with a suitcase full of disk drives. That was how you got software onto the internet in 1998. Today, you are lucky enough to be building a business in the age of AWS, Heroku, and serverless — which means you have an advantage that I didn’t have in 1998; in fact it didn’t exist for 99.99% of business history. Modern cloud deployment platforms give you the ability to get your ideas in the hands of users faster than ever before. With tools like this, you can focus entirely on building your product as users are interacting with it, so you can learn from those users as quickly as possible.
3. Don’t do “stealth mode”
Stealth mode is the period in which startups build their product in secret, and won’t talk about it or show it to anyone for fear someone else will steal their idea. Before I explain why this is a bad idea, let me first say that the fear around which stealth mode is constructed is generally unfounded. People are not sitting around, just waiting for a great idea they can steal and then build. If someone had the time and the energy to steal your idea, they probably already have their own idea, and they’re working on that. But more importantly, for anything that you’re currently working on, there are at least three other teams somewhere, right now, also working on that idea. The best thing you can do isn’t to work on it in secret, but to build it, and get it in front of customers as fast as possible.
4. Don’t write a business plan, build an MVP
Before you say “Rob Zuber told me not to have a plan,” I think it’s great and important to have a plan — just be able to articulate the plan in a single sentence. Don’t plan further ahead than you have to, which means: plan your next step, build it, and get feedback. Then amend the plan. Repeat. The absence of that large-scale, upfront, 3-ring-binder type planning is often interpreted as a lack of a plan. But really it means that I’m planning to be in an optimal position to seize an opportunity and that I will evolve the actual plan along the way as I do the work. The real reason to not write a business plan is that no matter how smart your business plan is, you’re wrong. You’re wrong about something in your business. Think back to those three other teams building your same idea. They’re wrong, too. But none of you understand what you’re wrong about yet. Your only strategy at this point is to be wrong as fast as humanly possible (ideally faster than those other teams) so that you can find out what right is and start building the right thing. This probably won’t surprise you, but this advice isn’t only for early-stage startups. At every stage, keep up this cycle of building, executing, and getting feedback. It’s only in this feedback cycle that you’ll learn where you’re wrong and start to get more right. Building the world’s most impressive business plan is not finding product-market fit. So put down your business plan. Find the simplest possible approximation of your idea that will give you any kind of signal. Build that in an afternoon and then go give it to someone and see if they care. Do whatever it takes to find that out — it shouldn’t take 18 months and a 90-page document.
5. Depend on uncertainty
At any point, something crucial about your business could change. But you don’t know what or where yet. In “97 Things Every Software Architect Should Know” Kevlin Henney describes an important approach to thinking about uncertainty: This framing is great for explicit decisions, but what if you don’t know you’re making a choice? Many times, the choice isn’t even visible yet but will reveal itself later. In these situations, the answer is not to overgeneralize, building abstractions everywhere “just in case.” Implement abstractions in only the places you have identified that have multiple implementations, i.e. items with a high cost of change, where you also have high confidence that there will be a change. Building perfect abstractions all over the place will certainly protect you against inevitable change, but will also be impractically costly. Instead, keep things as simple as possible so you can understand them later if you have to make a change. By merely separating concerns and keeping like with like, you still have work to do when it comes to making changes, but the cost of doing the work is low. Build in a way that minimizes the cost of being wrong, and then watch change closely.
