At virtually every stage of even the most successful software projects, there are large numbers of very important things that are unknown...
The goal in any product design is to have the best ideas become the basis of the product. Everybody on the team should be working to accomplish that goal.
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.
Concede the feature shoot-out, and go for the paradigm-shifter. It won't matter if you're missing a few features if you've improved your customer's working life by a few thousand percent.
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.
Another good expectation-setting line that software developers should borrow from doctors is, "Of course, there's always some risk in even simple procedures..." It that doesn't express the essential hazard of even the least tweak to a program, I don't know what does.
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.
Without someone to "make straight the ways of the team," you are doomed to wander around in the desert from one release to the next.