Why we don’t provide time estimates

Yesterday a customer contacted us to ask if a specific feature was available. It isn’t, but it is something we’re working on. However, we never commit to a specific timeframe on releases for a number of reasons:

  • Doing so creates an expectation. Even if the customer understands it is an estimate, there is still disappointment if the timeframe isn’t met.
  • We have multiple projects going on at the same time. We might juggle them around depending on how well things are progressing or how big demand is. Not publicising any of the ongoing projects or timeframes gives us the flexibility to do this.
  • Projects might be held back or not released at all. Some of our projects have been completed for a while, but we’re still not completely happy with the end result and are working on new/different ways to implement them. If we stick to the original planned date, the end result might not be the best we can do.
  • It is difficult to accurately predict how long something will take. It’s not a promise, it’s a guess.
  • We want customers to buy based on current features, not the promise of future features.

I fully understand that it can be frustrating when you don’t get a timeframe for something you really want, but I think not providing estimates is the best approach.

This entry was posted in Business, Company, Programming. Bookmark the permalink.

4 Responses to Why we don’t provide time estimates

  1. Great post. I generally take the same approach, despite many potential and existing customers’ persistence. And there’s always some who say they’ll definitely buy once feature X is implemented, and of course they never do once you launch that feature. Never. Ever.

  2. Neil Henegan says:

    Try being the customer, then you will see why you need time estimates.

    • David Mytton says:

      I do try and approach everything from the view of being a customer, and there are a number of points above that do take that into consideration. I know why a time estimate is useful but I don’t think it’s ever “needed” because if you don’t have one you just assume it’s not coming soon (or at all).

  3. Hi David,
    Uuuuh, this thread it not commented for more than a year, but I’ll take my thoughts on this also..
    This is an interesting approach :)
    From my point of view it really allows great flexibility, especially if you have multiple projects you are working on at the same time, as you’ve described.
    I am not sure if this will work for any project/customer/team, as major part of customers always want estimates to be specified from dev side, as they also have customers and need to solve their “new features” and of course for this they need to know answer on the question “When?!”
    But in case if you have end-user as your customer and he is working with you for some time, he might consider himself when he will get more awesome features from you based on previous ones.

    Sergey N.