Never trade a bad date for an equally bad date. You're just hemorrhaging credibility if you do that. Generally, you know you're going to be late before you know when you're going to be done... The absolute worst thing you can do is take the estimated amount of the current slip and add it to the end of your schedule. This amounts to taking the one thing you're certain is wrong (your current schedule) and putting it back in your path.
One classic move is to out-produce your competitor to the extent that you seize overwhelming feature advantages. The goal here is not merely to leapfrog, but to do a double leapfrog such that your competitor won't be able to catch up in a single product cycle... The difficulty with this approach, of course, lies in the expanded complexity of producing and communicating the double leapfrog. And as it is loaded up with feature upon feature, the product will grow ever more bloated and brittle. Stabilizing the product will take more and more time. Sluggishness is almost certain to creep in as size becomes a disadvantage.
Don't pre-announce. Although you'll be tempted to brag about software you haven't shipped in order to salve your pride and give your customers a ray of hope, don't do it. Pre-announcing is a treacherous game to play. Inevitably, it takes the bang out of your launch and the sizzle out of your product.
Burn the boats. Continue to take big, ineradicable risks. Settle the new territory you've conquered. Demonstrate to everyone that you're committed to your course by burning the boats, precluding all thoughts of going back. This may mean not being handicapped by your installed base. Compatibility kills. Provide your market with sufficient incentive to move at your pace, and compromise on compatibility. Pull them forward, but don't let them go back.
Trying to build configurability into either the software tool or an application to compensate for individual variation can complicate the software beyond the acceptable range for large numbers of people... There is a natural tension between ease of use on the one hand and ease of changing use on the other. Usually you can reach a broader market by tacking the ease of use problem. Ease of use is a hard problem, but it's substantially simpler than the problem of dynamic adaption.
For now, we really need to learn to be like doctors. They are able to say, quite comfortably and confidently and with conviction, "These things are never certain." Doctors seldom if ever state with certainty what the outcome of any procedure might be. Yet software managers, operating in a far less disciplined and less data-driven environment... blithely promise features, dates, and outcomes not especially susceptible to prediction.