How to Ship Without a Deadline

Wednesday, October 15, 2014 – 327 views

— by jazzychad

Note: This post started out as an internal email I sent to the team at work. I got permission to post this publicly for a wider audience. These thoughts are my own, but as someone who has shipped a lot of stuff without any deadlines whatsoever, I thought I would share my thoughts on the subject.

Deadlines are a double edged sword. They can be helpful for getting something out the door, but they can also cause a lot of compromise in the finished product in the name of "shipping."

There is a natural tension between wanting to "ship the right thing" and wanting to "ship anything at all."

Sometimes deadlines are necessary:

Sometimes deadlines are helpful in other regards:

For creative/inventive projects like a consumer software product, I would contend that deadlines can cause more damage than good in the first version/product discovery phase.

Deadlines in this phase can lead to:

Lack of a deadline can have its downsides, too:

However, it is possible to ship a quality product that people will enjoy without needing a deadline. I have done it, others have done it. It is possible, and you can do it, too.


First, unintuitively, not having a deadline does not mean "there is no deadline" - it means "the deadline is ASAP."

When I am handed a deadline, I instantly try to figure out the latest date I can start working on it to make the deadline and I procrastinate. It's a bad habit. On the other hand, if I have a project to work on that I am highly passionate about and emotionally invested in, my main thought is "this has to exist in the world as soon as possible!" and I start immediately and usually don't stop until I have forged it from nothingness (as an example, Points - The Game was conceived, designed, built, and shipped to the App Store in 9 days using late nights and weekends).

Practical steps to shipping without a deadline:

Note: This is tailored for consumer web/mobile app development

  1. Distill the core idea of the product down to its essence. What is the point of the app? Make this the pillar of your product. This will help inform all the decisions in the following steps.

  2. Make a list of features required to make the absolutely minimal required functionality for users and still satisfy the point of the app.

  3. Re-evaluate this list. Remove things from it. No, seriously. You don't need all of them. Remember that just because someone else has similar features does not mean that you need them in v1 (or maybe ever!). Feature parity of a competitor is not a goal of shipping. Make as few assumptions about what the users will want/do with the product.

  4. side note for beta testers (including extended beta testers): Reduce the list even further. Seriously. You can ship a beta with rough edges and even entirely missing features iff what you ship them will let you learn about whether the core premise/pillar of the app holds true.

  5. personal bias: I prefer Function Over Fashion, every time. If the functionality is there, and it works, SHIP IT. Design polish and making everything pixel perfect costs a lot of time. Again, this is a personal bias, and you will have to strike the right balance between Design and Functionality.

  6. Work down the feature list and implement them as quickly as possible. DO NOT ADD FEATURES. DO NOT ADD FEATURES. DO NOT ADD FEATURES. If you have a feature you are dying to add, create a list and write it down under "things I want for the next version."

  7. When to add features: if you can convincingly provide evidence that the app is critically and fundamentally broken without said feature OR if during later iterations (after getting user feedback) the users are crying out with the rage of 1000 suns for a feature they want.

  8. Quick, time-boxed UI polish phase. Not every pixel will be perfect. As long as nothing makes your eyes bleed, you are done.

  9. Let it bake, for at least a couple of days. DO NOT TOUCH THE CODE OR UI. Just use the app as a user and make note of any glaring bugs/issues. Fix these things as quickly as possible.

  10. SHIP IT!

  11. User feedback. User feedback. User feedback. Get as much as you can, but don't dive straight into design/code at the slightest hint of an anecdote from a user. Make a list and prioritize it based on repetition of feedback and bugs. The less you assume about users and the more you make updates based on their feedback, the more they will like it, and the happier you will be about providing something people love.

  12. Rinse and repeat while iterating in small chunks of improvement/shippability.

If shipping is a main motivator for everyone on your team then the deadline will write itself. The trick is to be laser focused on the core set of functionality and relentlessly combat adding features/scope before something is out the door.