How We Launched 4 Features in Less Than 6 Weeks with a Culture of Shipping

Here at CoSchedule, we just completed a major sprint to launch four major new features in less than 6 weeks. Whew. It was a lot of fun. https://twitter.com/garrett_moon/status/803656889384845312 In case you missed it, here’s what we launched. If you only want to learn how we did it, feel free to skip ahead. Long story short, that’s a lot of code to ship in short amount of time. So, how did we do it? I call it a "culture of shipping." It's one of our core values:

Bias for Action. We know that ideas don’t matter unless they become action. We always err on the side of shipping, failing fast, and getting better as we go along.

But before we get too far, I want to let you in on our dirty little secret. We don’t launch 100% of our features all at once. Don’t get me wrong, these were great features, but they were the 1.0 version. This means that for every aspect of the feature we actually launched, there are between 3 and 4 major improvements that were left on the to do list. In general, I believe that the common concept of a “launch” is very misleading. Most of the time, we think of a launch as a singular event. We slave away for months in hiding while building something brand new. When it finally comes time to make it public we launch, and make a big splash. There are blog posts, tweets, press releases, and sometimes fanfare. And then it’s over. We move on to the next project and look forward to another “big launch.” But, that’s not really how things work. Your audience will never absorb your launch the way you expect them to. They’re busy and distracted. You’re probably going to have to tell them about feature XYZ three or four times before they actually pay attention. In short, launches shouldn’t be a singular event. They are just the beginning. They should really be just one singular step in an overall process of iteration. Iteration is really at the heart of what makes for a great “culture of shipping.” Everything is iterative, including your skills and abilities, your marketing efforts, and your feature launches. A process of getting something out there and then making slow and steady improvements over time is what defines CoSchedule’s culture. It isn’t sexy, but dang it if it doesn’t work. So, let’s get practical. What can you do to make sure your team builds a culture of shipping? Here are a few of the things we do every day to keep the shipping alive.

1. Wins Make for More Wins

When planning something new you are bound to develop big visions of excellence and grander. Take it easy cowboy/girl. Rather than trying to build the biggest and best right out of the gate, break your project into pieces. Think of it as a series of “launches” rather than one massive unveiling. Breaking projects down into tiny launch-able pieces will give you and your team some early wins. Wins can easily turn into momentum and momentum is exactly what fuels a culture of shipping. Around here, we like to break feature development into a series of 1-2 week projects—each one ending with a launch of some kind. We try not to focus on the whole enchilada. Rather, we focus on the smaller iterative goals that will need to be met in order to succeed. This ultra simple framework keeps us focused and motivated, and ultimately leads to the big win.

2. We Assume that Our Customers Know More Than Us

When planning a new feature or launch, it can be easy to assume that you are the smartest person in the room. Work on a feature long enough and you’ll believe that no one understands it better than you. Unfortunately, you’ll probably be right. So, what if no one understands it but you? Feedback matters a lot. The world loves to emphasize the myth of the “lone genius” or the Steve Jobs personality in all of us. WRONG. There isn’t a such things as a lone genius in real life. In real life those geniuses had spouses, colleagues, or competitors that drove them and made them better. For a startup like CoSchedule, those drivers are our users. With every feature we launch, we try to leave a lot of room for customers to influence version 2.0. When a new feature goes live, our list of back burner items becomes irrelevant. From that point forward, customer feedback shapes version 2.0.

3. We Focus on Failing Fast

Most of us try to avoid making mistakes. If we can’t avoid them, we at least try to make sure no one notices them when they happen. But, this reflex is in itself a mistake. Instead, the better approach is to assume that you will fail and build it right into your process. We call this failing fast. Rather than trying to be perfect, aim to fail as quickly as possible. If you’re building something new, show it to someone else as soon as you can. Even before you’re ready. Get feedback. Figure out what’s wrong The sooner you know what’s wrong, the sooner you can improve it, and that will help you move faster. My background is in graphic design, and this can be a huge problem in that industry. Designers love to “move pixels” and make things perfect before showing their work to anyone. But, this is a mistake. It makes them slow and oftentimes damages the end result. Don’t assume you know it all. Assume that you will fail, and build it right into your process so that you know to expect it.

4. We Keep Things Simple

Complicated features are bad for users (and for you). At CoSchedule, we’ve paid that price before. For example, the first version of ReQueue was overbuilt. Because we didn’t ship soon enough, the feature ended up getting too complicated and messy. When we gave it to a set of beta users and they were confused. They didn’t understand how to make the feature do what we said it could do. We ended up scrapping the entire project and building something different that was much simpler and more iterative. It was a lesson we don’t want to have to learn twice. Over time, we’ve learned to keep things as simple as possible. Sometime complex features are necessary, but it is better to iterate our way into them, rather than building it all at once.

5. Despite What You Believe, Launch Day Doesn’t Really Matter

I’ve already mentioned that launch day barely matters, but it bears repeating. Teams routinely put a lot of time into their big unveiling to find out that no one was really paying attention. The true art of the launching comes from realizing that launching is a process, not an event. It’s about the process of shipping, not just launching. From a marketing standpoint this means that we should be talking about new features for week and months after they launch. From a product standpoint this means that we should be building and perfecting a feature for months after they are live. This isn’t a one and done type of scenario. We are so conditioned to believe that launch day is an event. We believe that our marketing is a narrative and that customers read every page, but they don’t. Marketing is messy. Shipping is messy. You’re better off with a process that embraces the mess than one that works against it.

Create A Culture Of Shipping

I’ve written about how everyone who works at CoSchedule does a book report during their first 90 days. The book they read and review is Linchpin by Seth Godin, and the reason we have everyone read it is in part for it’s message on shipping. We believe in taking action, shipping, and always improving. Because, why not? Isn’t that how everything in life works? You weren’t the best eater the first time you tried it. You smashed food instead of eating it. You missed your mouth entirely. You dumped your spoon over before it left your plate. As toddlers, we’re miserable eaters. But, we are also shippers. We tried, we worked at it, and thankfully we got better. This is what shipping is all about. It’s a process. Shipping early and often is simply a willingness to embrace failure as a natural part of the process of our work. Expect it. Plan for it. Ship it. Failure is our work ethic at CoSchedule, and why not? It makes our mistakes a whole lot easier to take.