Ask 37signals: When do I launch?

Mike asks:

I’m at a crossroads with a new project where I have a concept that can be executed in two ways. One execution is significantly more complex to build (and would take much longer) than the other, but could be the deciding factor of how successful the application is. The other execution gets the concept out there faster, but I fear it may lack the profoundness of the full execution and may fall short of its potential.

Assuming you have a vision for what a product should be before you begin development, where do you draw the line between your full realized vision and a core release that gets the concept out there. How do you make the choices about which features define the “soul” of the product versus the features that are not critical for a first release but which you plan to implement later?

My advice is always to err on the side of simple. The more complex something is the greater the chances that something will go wrong. And things will go wrong. You’re better off with less things going wrong early on. Wrong can be overwhelming.

Further, your initial assumptions about how critical a specific feature is often wrong. You don’t want to spend all the extra time up front on something that may or may not be the deciding factor. You’re better off executing the basics at a very high level and then adding on from there. What you thought was essential may surprise you.

Lastly, the longer a product takes to develop, the less likely it will launch. Long projects zap morale. Things get in the way. Life changes. Your time demands shift. Opportunity costs mount. We believe you’re better off launching something small quickly and then building from there. You’ll know more about what the product should really do once it’s actually alive.

As far as knowing exactly where the cutoff point is, that’s more art and gut than science and stats. The way we usually do it is to ask ourselves: “Does what we have now solve most of our problems now?” There’s always more to add and plenty of things to refine, but does what we have now get the job done reasonably well most of the time? If you’re using your product as you build it, and as long as you’re careful not to confuse your needs with “wouldn’t it be cool if…” then you’ll naturally get to the “yup, it’s good to go” point soon enough. That’s when you launch.

Whatever you choose to do, good luck. We hope you succeed.

Got a question for us?

Got a question about design, business, marketing, etc? We’re happy to try to provide some insight into how we’d tackle the problem. Just email svn [at] 37signals dot com with the subject “Ask 37signals”. Thanks.

Jason Fried wrote this on Jan 15 2008 There are 11 comments.

Matt Brown

on 15 Jan 08

Priceless… I went by this advice launching my new website a few days ago and I’m glad I didn’t wait until every feature on my wishlist was implemented and polished. I had less problems at launch time and now I can work on the wishlist of features WHILE my users use the core features of the website. What’s there is much easier for them to digest and they will appreciate new features as I add them.

Did I use the word “features” too many times in this post? LOL

DjD

Here here to that.

I know my app is far short of what I have in my mind and it’s not that beautiful to look at but much of that will come with time. For this being my first attempt at Rails I’m pretty happy to have been able to put this up with only a few hours a night of programming in just the past 2 weeks.

Justin Reese

Good advice. There’s an unspoken desire all devs have that a week after launch they’re going to get Dugg and make a million dollars, but the reality is almost always a slow, methodical uptake. “Perfection” might matter if you only had one shot at greatness, but you’ve really got more time (and chances) than you think to refine it post-launch. Go for it man.

Mike Gowen

Thanks guys, much appreciated!

Noah Everett

Great question and response. I needed to hear this as well. Scope creep is very sneaky.

J Lane

That was an awesome question. I find it’s one of the hardest things, deciding when enough is good enough.

On one hand, you don’t want to launch something and have everyone go “yawn”. On the other hand, you actually want to launch something!

Thanks for the Q and A.

Jeff Denton

This is great advice but I always have a hard time following it. Usually, I start with what seems like a simple idea and begin coding. Then, 6 months later I look around at this monster I’ve created and have to decide whether to severely cut back or go live with buggy modules of code and hope users just ‘understand’. And they usually do but then you have to run around picking up all these little pieces and tying up lose ends. It’s a drag. Much better to be ruthless in cutting your feature set up front and implement features gradually once the core is live and stable. Transparency is good also. Let your users know what your feature implementation time-line looks like as best you can, solicit lots of feedback and keep everyone posted on development progress. You’ll find that users can be extremely forgiving for lack of features if they think you’re listening to them and being up front about things.

Best of luck. Launching a new project can be fun.

Simplegeek

I’m wondering how did you do all that while developing Campfire, I mean it’s relatively a very complex product?

Moreover, did you cut-off anything? Will appreciate if you can tell us more about that. Thanks.

Ben M

To add to this question, what about pricing? I have something that is releasable now, but the price I researched / settled on is higher than I think my product is worth now. This price will be justified in the upcoming months. Should I start with the higher price now or wait and increase it later?

Rohan Almeida

on 16 Jan 08

I like Ben’s question (above), although I don’t have an answer to it. Maybe it (or the pricing topic) deserves its own “ask 37 signals” thread.

Steve Schwartz

Ben M, that is a very good question, and one that we also encountered when we went to launch our site. We followed the agile mantra very closely and are glad we did. Our app underwent a complete overhaul within the two weeks after launching in response to user feedback.

My advice for launching early is to first estimate about how long it will take you to reach that desired point where your service matches your price. Add a little padding, and then give all new users that signup between now and then a “free trial”.

So, if it will take you 2 months to get the site to that point, offer all new users a “3 month free trial”. This will allow you to go ahead and launch, it will promote more registrations than might otherwise happen, and it will preserve and reinforce the intrinsic value of your site (it won’t force you to start charging later on for a service that users have gotten in their heads is free).

Make sure that you emphasize the “savings” when the users sign up, so that they understand the value they are receiving. Also, solicit their feedback often. They’ll actually be very happy to give it to you; allowing them to contribute to the project and actually affect its evolution makes them feel more connected with the community and the brand that you are building.

Of course there is the issue that you are now giving your service away for the first three months. But, hey, if you waited to launch, you wouldn’t be making any money either ;-)