Question of the Day: What R Your Pre-Launch Priorities?


I spent yesterday afternoon in an hours-long strategy session with some former Y Combinator grads. The team is in the final week of preparing their startup for its Beta launch, and they were having difficulty yesterday deciding what the ultimate hierarchy of the pre-launch tasks should be. I’m sure all founders struggle with this, so it forms our Question of the Day, below.

Their service is cool, and promises to make a very painful business task — document sharing between parties — much easer. (Google Docs is fine, but these guys can make it slick to share documents even across multiple software platforms. I’ll tell you more about it when they come out of stealth.)

Sexy Features

The founders were eager to add one last feature to their product — so they could promote it at launch for its compatibility to some existing big names in the market (like Google Docs). Great marketing value in that for sure, and it shows the founders recognize they’ll need traction immediately to survive in a crowded space. A headline-grabbing feature would help.

But one of their investors grew concerned that this risked jamming to much stuff into the launch.

Functionality, Stability & Performance

He wanted to seem them focus instead on the the stability and performance of the core product — stop needling with the code and to “take a week and just let it sit” so they could perform thorough Q&A. “The worst thing that can happen is a journalist goes to test the product and something doesn’t work. That’d be terrible.” You can always roll-out new features later, he offered.

A/B Test

Still another advisor wanted the team to take the opportunity to build-out primary and secondary home pages of their site, so they can use their Beta launch as a proper A/B Test of the company’s pitch. “Traffic will spike. We could get 10,000 new users, so that’s a good opportunity to test [our] message,” he reasoned. Post-launch traffic always wanes a bit, and they might not get another chance to test the effectiveness of their product positioning.

I definitely see the value in A/B tests, so did a marketing consultant who was in the room. But it seemed like a lot to dump on the founders’ plates in the last week.

The founders put on a show of unflappability – but they also acknowledged that they’re still fixing bugs!

I expect most founders struggle with these launch issues, and so this forms our…

Question of the Day: How would you prioritize your time in the last week before Beta launch?

1) Headline-Grabbing Feature: is it worth spending pre-launch time on a feature that might add some sizzle, and help you draw attention and traction in a noisy market? You might not get this chance again.

2) Functionality, Stability & Performance: Or do you drop all the bells and whistles to focus on Q&A of the base offering to guard against media fiascos? And roll out new features and add ons later?

3) A/B Test: How critical is it to test your product message at launch? If you don’t do this right away do you miss the best opportunity to amend the message? Or is this a task that can be taken on later?

Tell us what you would do! Or offer any other pre-launch priorities that you’d add to this short-list.


kevin gao

all depends on your short and long-term goals –

if you’re in a crowded space and need significant publicity/broad user generated buzz initially, makes sense to add sexy features and push the PR side

if you’re in a less crowded space and looking to slowly build momentum/a solid user base, then makes sense to thoroughly Q&A and focus on stability/performance

i think 3 is something that can be layered onto both but should be second priority


I would go with something that is a compromise of sorts between points 1 and 2. Don’t roll out the feature for beta, but blow your trumpet all you can about it being launched soon. Even declare a date if possible. Secondly, nowadays, users/journalists are linient on any bugs in the system (hence the beta logo). Ofcourse make sure critical bugs are fixed, but you can very well ignore minor ones which have some or other way of a workaround. After the launch, focus on the new feature roll out, burn midnight oil, and meanwhile, keep a track of bugs that users so far are facing and keep fixing them.

Scott Gatz

In my mind, there’s no question – the investor is right – take a week and let it sit.

When you are in the last week before a final launch adding new features is absolutely the wrong thing to do. It’s tempting – I’m sure they could actually get a new feature done (and A/B testing is actually just a feature really). By trying to add in something new you risk adding instability and you risk just having the new thing be “bolted on” and not make any sense. And if you feel that your product won’t standup in the marketplace without it – then change your launch date and do it right.

But more importantly, if you are chasing that “one last feature” during the last week, you are missing the chance to do all the other stuff you need to do (press, marketing prep, QA, etc). Take the time to signup for the product from a clean browser, watch friends signup and use it for the first time. Fix anything glaring and note all the rest. This is your time to see the product as the world will see it – that one broken “help” link will stop a user – did you find it?

And most important: sleep. The launch isn’t the finish line – it’s just the start.

Allan Leinwand

For the markets where I have built products, there comes a time near the end of the product development lifecycle where you need to decide if it is time to launch the product or continue pounding away on features and bugs. I believe that the product has “to look good or to work good.” If the product has achieved one of these two goals, it is time to launch. If it has achieved neither, it may be time to go back to the drawing board or to feed the engineers more pizza.

The utopian world of shooting for both looking good and working good is never really achieved – product designers will always find ways to make their products look better (remember the first iPod?) and engineers will always want to rework the product to make it perform better or have more features (anyone want to go back to iTunes 1.0?). I could concede that given nearly infinite time and resources a product could be made that both looks good and works good, but I have personally never had access to or desired to work in that environment.

So, let’s say that you make a product that looks good. Yet, the product has limited functionality and may not have all of the features to hit your target market perfectly. Good looking products get to market and attract attention for their companies, even if they lack features and performance. If done correctly, say like the Apple MacBook Air, the product still gets good visibility and adoption. Further, because the product looks great, customers can see where the product is headed and usually attracts early adopters.

On the other hand, let’s assume that the product does not look good but works good. If the product is loaded with features and functions and just needs some work to make it look good, then it can also attract the attention of the target market and early adopters – think about early Blackberry products and early versions of RedHat Linux. A product that works good but does not look good gives the customer the ability to justify using the product because of features while waiting for the company to refine their look in subsequent versions (which both Blackberry and RedHat have done).

The death zone for products are those that fail at either looking good or working good. For a product to be successful it has to excel at one of these two objectives – if you are not there with your product, keep working and hold the launch.

Comments are closed.