Fog Creek Software
Discussion Board

Versions: planning or features

What is more important for an ISV, having new versions delivered when planned or featureful as planned?

Let me explain: imagine you are an ISV. You plan to deliver a new version of your product (say v3) next month containing features X, Y and Z. You then realize you can't make it with feature Z for next month. What is better: deliver v3 without feature Z on due date or wait till feature Z is ready to deliver ?
I mean, you already told everybody (clients, parnters...) about your v3 next month. What do you say now? v3 will be on time but without Z or v3 is postponed for some months.

Wednesday, June 30, 2004

The answer is: it depends on too many variables, like:

- Are there customers waiting for X and Y that don't need Z?
- Are there sales in the pipe that require X and Y but not Z?
- Is this a hosted web app, or a client-maintained app? (i.e., what's the upgrade pain if you release v3.01 6 weeks later?)

Brad Wilson (
Wednesday, June 30, 2004

You release during the month you said you would.

Lacking features Q,N and K, the ones that don't matter and were scrapped to make time for important feature Z.

If you can't include z, then you notify the specific customers who were waiting for Z that Z WILL be ready in a free update to alll users on <date>. Make <date> later than you think - it is very important that you deliver Z on this 2nd date.

Dennis Atkins
Wednesday, June 30, 2004

It is more an ASP-like scheme. So, my idea is that it is more important to deliver --and do the upgrades-- WHEN planned, trying to have all the important features and communicate early enough to those who will lack something.

BTW, it seems to be common sense. But I have worked before for an ASP and neither was done: versions were delivered late without all the features...

Wednesday, June 30, 2004

It is much more important to deliver when planned, than to have the full set of features delivered later.

A classic approach is to do as much as you can toward the full feature set, "declare victory" for this release with as much features as you have implemented, and deliver with a diminished feature set.

One caveat:  Never deliver 'broken' code.  So you have to stop developing at some point before delivery, and spend time to test and verify that the feature set that you HAVE implemented is fully working.

Delivering a function that 'mostly' works, but breaks some of the time, is a very quick way to give your application a very bad reputation.  And bad reputations are VERY hard to get rid of.

Wednesday, June 30, 2004

Yeah late without the features is the standard but its also a conclusive symptom of sloppy, er, incompetant management who is unable to make decisions and is unrealistic about deadlines and just lets everything go to hell.

If you ship when you say you would minus a few minor features but with a concrete date for them, many will consider you a hero just for being honest and somewhat reliable, compared to the dishonest and unreliable ones that seem to be everywhere and can't deliver anything on any date as promised.

Dennis Atkins
Wednesday, June 30, 2004

Yes Allan's right too - don't ship without testing. Broken first revisions are expected, but that doesn't mean that it won't still ruin your reputation.

Developing a reputation as someone who is reliable will separate you and place you head and shoulders above the 95% that are idiots in this industry.

Do it a few times and you'll never be lacking for clients.

Dennis Atkins
Wednesday, June 30, 2004

Ditto the above. Ship what you have that is rock solid.

Are you charging for the upgrade? In that case promise your customers a free upgrade to the .xx version that gives all the features you promised.

Like someone else said, make sure you do deliver on this second date.

- Not releasing will piss off *all* your customers waiting for the new features

- Releasing broken code will piss off all *all* your customers

- Releasing some features will piss off *some* of your customers but please the rest.

It's a no brainer.

Just don't forget to admit that you messed up and that you are making amends.

Wednesday, June 30, 2004

Also try to be sure you know which features people are really waiting for. Don't waste time on a feature the CEO thinks is cool at the expense of a feature that everyone is waiting on the next version for.

[and yes, I realize this post may be ironic :-P ]

Wednesday, June 30, 2004

Does this sound stupid:

· tell them the next version with X,Y,Z *will be delayed* to (original_date + delay), sorry


· tell them "as you are so important and sensible and bla,bla,bla software company" you are able to let registered users get *on original_date* a beta version of the next version, sadly feature Z not included.


You are releasing broken code, true, but it's a B E T A, just be sure there is not a very very ugly bug in it and you are not going to loose reputation; let very clear to users that only impatient ones should get it, and that it can have some bugs.

Ross Sampere
Thursday, July 1, 2004

As it is a web based app, I can't allow client to "choose" their version. And I guess it is not a good thing to have too many concurrent versions in maintenance.

Thanks to everybody. Your advice confort me in what I thought I should do.

Friday, July 2, 2004

*  Recent Topics

*  Fog Creek Home