What do you do when in "launch mode", above and beyond the norm?

We all have the normal day-to-day tasks and meetings and communications across functional areas. But what do you do specifically above and beyond that as you near a new product launch? It could be specific launch meetings, communication to employees, an employee celebration, incentive to hit a specific date, a big date on the wall...or 1000 other things.

Love to hear some ideas.

I learned a long time ago that developers over promise, marketing puts on higher demands and tries to slip in features without respect to timelines, and SHIT happens.

For web apps, and with a close team you can usually get into a groove where you can budget time appropriately. I multiply whatever timeline our development team gives us by 2 or 3 (on very complex apps), to give a realistic timeline to market.

There is a big belief in being agile, releasing often and quickly, but sometimes that goes against your business model, or cannot be done because of a very limited marketing budget or big promises for the app to be viable. Every situation is different.

Key things you can do.

• Make sure you know the difference of must have features, versus nice to have.
• Hold your developers accountable to timelines, not to grill them but to get a good understanding of delays.
• Dont set unrealistic expectations in regards to time, they only add pressure which usually is not a good thing
• If you can go to market with a lower feature set, then do it, but plan for growth. In web apps this is a lot easier than other forms of business or even traditional software. One approach my team and I make is to lay a huge foundation. If you think of a web app like building a house then the foundation is the DB storage layer, the functionality is the framing, and the UI is the finish work. By understanding the type of house you want in the future, you could build a 2 bedroom that allows for future expansion with the foundation already poured. This is key to understand, because when you pour your foundation you make it easy to build upon it later. You also take into account the future growth and make programming decisions that will allow for this in the future. IN other words you dont have to remove the kitchen to add 2 more bedrooms because the floorplan allows for this. In many of our apps we launch with a minim set of database tables used, but have a full schema of our "Dream App" which we build upon. This also allows us to get feedback on the UI layer (UI and performance is what 99% of our clients care about), as we build the future functionality.
• If your app will not be profitable until it is complete, or a 2 legged stool will hurt your future prospects with getting another 1st impression with prospective clients then you move your ship date.
• Dont make any promises or projections of income until the application actually makes income and you could use its true numbers as a basis to multiply against future possible growth. A lot of startups get into trouble assuming they could make x when they have made @#$@#. Thinking of a business as a tortilla machine is often helpful. Once you have the machine built, you can slide in the dough and tortillas come out. Over time you can make the machine faster, better, and more popular. But dont start counting your tortillas until you put in your first few peices of dough. This analogy is also helpful for those looking to raise investment for their 1st app. Think of an investor as just a provider of dough to put into your tortilla machine. Let them know that their 10000 lbs of dough will make 10000 tortillas which they can eat 25% of. If you have a hungry investor waiting around for the machine to be built (meaning if you get an investor early) it is likely he will be so hungry he wont settle for 25% of the dough that comes out, and might even take the machine you built away from you if he thinks he can.
• Last point, maintain morale. On long projects, specially with a few missed deadlines its easy for quality to suffer as morale does. Never put undue pressure and expect the impossible. There are instances where more labor can fix the issue, but usually adding more chefs late or making your team burn it at both ends so you can meet a poorly set deadline results in poor quality, and loss of passion for the project. Instead, you can see the time deficit as a debt, or a challenge that the company WILL MAKE UP with a BETTER PRODUCT. Remember good things are worth waiting for, and great things are worth pimping out your sister for.