How to Ship Without a Deadline

10/15/2014, 5:14:05 PM

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:

  • you have publicly announced a public availability date
  • you are shipping a critical security/bugfix to existing customers
  • a client or business partner is depending on your product as part of their own publicly announced availability date (i.e. you are in their supply chain)
  • you are working with an undisciplined team and a deadline is the only motivating factor for completion of work
  • you are trying to ship something based on an external date outside of your control (e.g. having an iWatch app ready to demo at the Apple Keynote event)

Sometimes deadlines are helpful in other regards:

  • they provide a forcing function when trying to decide on feature scope/creep and can be helpful in eliminating (though not always successfully) cramming more features in the version before it ships
  • it provides a tentpole which an entire team can march toward as a goal
  • for non-creative endeavors they can provide structure for determining a training regimen in the case of needing to be in shape for an athletic event or studying for a test

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:

  • compromise. Not in the sense of "come to a compromise that makes everyone happy" but in the sense of "the building has been compromised by the earthquake and will collapse."
  • panic
  • unnecessary/artificial crunch time for the team as the deadline approaches and the amount of actual work left to do was underestimated as is always the case in software development
  • procrastination/laziness ("i have 3 months to finish this, i'll just wait a while to really start")
  • an artificial/unsatisfactory sense of accomplishment (i.e. "yay we shipped something, but it wasn't really what we wanted")

Lack of a deadline can have its downsides, too:

  • never shipping (this is the most obvious problem/fear of no deadline)
  • infinite feature creep
  • lack of a forcing function to hold feature/scope creep at bay
  • infinite breathing room to change direction at a moment's notice
  • lack of motivation for an undisciplined team

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.

HOW TO SHIP WITHOUT A DEADLINE:

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.