always be shipping

Always Be Shipping

In 2007, Jeff Atwood wrote Always. Be. Shipping.

Our job as software developers is to deliver features and solve business problems, not to generate neverending discussion

In 2010, Seth Godin wrote The Truth About Shipping:

Keep your team small. Smaller than that. No team at all if you can help it.

Ship often. Ship lousy stuff, but ship. Ship constantly.

Skip meetings. Often. Skip them with impunity. Ship.

Trick the lizard if you must, but declare war on it regardless. Understand that the only thing between you and the success you seek in a chaotic world is a lizard that figures out that safe is risky and risky is safe. The paradox of our time is that the instincts that kept us safe in the day of the saber tooth tiger and General Motors are precisely the instincts that will turn us into road kill in a faster than fast internet-fueled era.

The resistance is waiting. Fight it. Ship.

In 2012, Naval Ravikant wrote Build a Team that Ships:

People choose what to work on. Better they ship what they want than not ship what you want.

No tasks longer than one week. You have to ship something into live production every week – worst case, two weeks. If you just joined, ship something.

In 2016, Arshad Chowdhury wrote How to Build a Successful App: ABL (Always Be Launching):

I’ve always been launching in a quest to see which titles, search terms, and content meet demand. Without this rapid succession of launches, I would never have stumbled upon a working business model for apps.

You need speed to succeed.

If your first launch takes too long, your subsequent launches will be tragically slow. Slow development times, outsourced teams, firings mid-development all hamper launch time and can be poisonous to the early stages of your company.

Which is why a long-delayed launch of your first product is a really bad sign. It signals that you either lack focus, an ability to execute, or both.

If you’ve been developing your app for a long time but just can’t seem to launch on a reasonable, affordable timeframe, then focus on the things you can do instead. Is your product social? Start hosting social events. Is it a fitness app? Host free training sessions. This kind of revenue-generating learning will only widen your reputation and network and give you more insight into what your product needs to be.

In 2018, Adam Drake wrote Always Be Shipping (here and here)

You should always be shipping code, features, services, and every metric of value you deliver to the business. There may be times when more valuable output is produced, and times when the output lessens, but you must Always Be Shipping!

[...]

More than the fact that it isn’t necessary to stop shipping in order to do maintenance work, it’s outright detrimental to your system, team, perception as a leader, and your relationship with the business organization. Instead, adopt a process and culture of continuous improvement while continuously shipping, and you’ll be supporting the business as well as your team with sustainable, long-term strategies.

In 2018, Dinesh Vernekar wrote Always be Shipping

Shipping helps you take your theories in front of your audience, helps you get valuable feedback that can be used to test your assumptions. In the worst case it confirms that your hypothesis was incorrect.

Shipping also forces us to examine some of the minor use-cases we had ignored at the design stage. It gives us a sense of accomplishment. It keeps teams focused on the problem statement. Shipping solves business problems and provides value to users.

In 2019, Naval Ravikant tweeted:

<blockquote class="twitter-tweet"><p lang="en" dir="ltr">The Lindy Effect for startups:The longer you go without shipping product, the more likely you will never ship product.</p>&mdash; Naval (@naval) <a href="https://twitter.com/naval/status/1158964119023652864?ref_src=twsrc%5Etfw">August 7, 2019</a></blockquote> <script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>

In 2019, I tweeted:

In 2020, Pieter Levels wrote in Make:

You may need to try shipping 10 to 30 products for 1 to 3 years before you have anything that works. That's how this approach works. You build stuff and see what sticks. I don't know anybody who shipped one product and instantly became successful. It takes a long time to "get" it and even then it's a lot of luck and timing. If something doesn't seem to take off early on, it probably won't take off later, so make something new and try again.

As I, and this book practice radical honesty, there's a chance nothing you make will be successful. But by doing you'll have figured something new out, that might lead you to somewhere else, that will make you successful. Startups, and life, are about constantly pivoting when things don't work out. If you don't take action though, you can be sure nothing will ever happen. Stagnancy kills. So ship.

Always keep shipping.