SIDEKICK Delays The Release of Composer

SIDEKICK Balance Featured Image
photo credit: diffendalecc

Among the festivities at WordCamp Toronto 2014, was the planned release of Composer by SIDEKICK. Instead, Composer has been delayed and the release date is to be determined. According to the announcement, the plugin and its architecture are not ready for customers just yet. In a FAQ accompanying the post, SIDEKICK Co-founder, Ben Fox, gives more details on what’s not ready.

A little bit of everything really. The new architecture which is going to power SIDEKICK Composer and the new version of our Player is kick-ass and working but the integration between it, the new account centre, the billing system and Composer itself is still “fragile”.  Add to that the fact that the new version of our website, which is necessary to power the front-end of the new Account Center, isn’t complete yet and we have a recipe for launch disaster.

Although it is disappointing to those who expected to purchase Composer over the weekend, at least one person cites the news as a good example of what to do when you’re not ready to launch a product.

Since the news broke, SIDEKICK has received an unexpected outpouring of support. “Something like 30 direct emails, numerous tweets and FaceBook messages plus we were approached at WordCamp Toronto by many people who offered their support for our choice,” Fox told the Tavern. Several people have commended SIDEKICK for its transparency. “What really got me though was not just the understanding our customers and community have shown but also the praise for our direct and transparent communication.”

Finding The Balance Between Good Enough and Don’t Ship

Despite a lot of talk in the WordPress community around the idea of “just ship it“, SIDEKICK decided to hold off to fix a few loose ends. In an essay by Matt Mullenweg entitled “1.0 Is The Loneliest Number,” he uses Apple as an example of a company that’s not afraid to ship a rudimentary version 1.0 to the public. The essay goes on to describe the idea of ship early, iterate often and how it’s the approach used to develop WordPress.

By shipping early and often you have the unique competitive advantage of hearing from real people what they think of your work, which in best case helps you anticipate market direction, and in worst case gives you a few people rooting for you that you can email when your team pivots to a new idea. Nothing can recreate the crucible of real usage.

You think your business is different, that you’re only going to have one shot at press and everything needs to be perfect for when Techcrunch brings the world to your door. But if you only have one shot at getting an audience, you’re doing it wrong.

The challenge of releasing the first version of a product or service is one many companies are familiar with. Composer is not ready for prime time but the question is, how will Fox and his team determine when it’s ready? “SIDEKICK will never be perfect in our eyes and we waited until the last possible moment to make the call because we wanted to make sure we weren’t releasing simply out of a need for perfection,” Fox told the Tavern. “I can’t speak for the entire community or other startups but I can tell you that while we’re not afraid to release a product that’s not ‘perfect’, we will never release something that doesn’t work as advertised just for the sake of making a release date.”

Where is The Happy Medium?

When it comes to releasing a product, there appears to be a happy medium of being good enough for consumer adoption but not bad enough to delay the release. As a product developer or service provider, how do you determine when your product or service has reached the happy medium and what factors go into the decision? Let us know in the comments.

5 Comments


  1. Scale back features if things are buggy. Better to ship a product that works with less features then add updates frequently to add those features back in.

    Report


    1. Agreed. And we did, we’ve stripped out quite a bit from v1.0 but there when it’s the underlying architecture that’s not talking to billing which is needed to activate users…we couldn’t launch.

      Report


  2. For my own plugins, I only release 1.0 when I feel it’s as perfect as I can make it, and subsequent releases will add functionality. Of course, there’s always bugfixes, but *ideally*, 1.0 is bug-free. I will never release something when I *know* it contains bugs.

    For larger/trusted/established brands, they can get away with releases that contain bugs (and use the “release early, iterate often” method), but this often has to do with a hard deadline. Sidekick’s decision surprises me, but it’s understandable. The examples they give speak for themselves.

    Finally there’s also the matter of “unfinished” vs. “buggy” — it’s not nearly as bad to release software that has some functionality modules that are not ready for use yet, than to release something that doesn’t work as intended.

    Factors that I didn’t address here; money/price (commercial software), reputation and liability. Those also have an impact on delay/cancel/release decisions….(irrelevant to most small, homebrewed plugins).

    Report

Comments are closed.