Know Your Product Before You Ship Early, Ship Often

I’ve always heard from software developers to ship early and to ship often. This often goes along with the idea that you should let your users mold the direction of the application your building. I want to challenge this idea. I understand that there is a disconnect between software and hardware development and release cycles, but I’m going to reference Horace Dediu’s piece “The parable of the PDA: predicting the smartphone’s future.” 

Dediu follows the story of the PDA’s inception and where it separated itself from the devices it meant to obsolete. “The original PDA was built to mobilize contacts, calendars and notes. They replaced bulky paper organizers and seamlessly synced to PC productivity software like Outlook.” Retrospectively we see the value in that since our smartphones do the same thing. “The idea of adding a phone function to the device made sense insofar as contacts could be immediately dialed from the contact app rather than typed into another device’s phone keypad.” This made so much sense as a transition from the technology that was available. There were forecasts that these devices would sell hundreds of millions. Developers were on board.

Here’s where things went wrong with the PDA.

“Many people rejected the concept of a PDA with an integrated mobile phone. They liked the fact that the PDA was not bundled with a phone plan. They upgraded PDAs in a different cycle from phones and besides, phones are for talking and PDAs were for something else.”

Vendors listened to these early adopters and didn’t ship the products they should have.

I want to challenge “ship early, ship often.” I’m not saying it is wrong, I’m just not sure if people are doing it for the right reason. Apple has become the biggest tech company in the world for a reason. In both their software and hardware departments, they have the best talent money can recruit and they design ahead of where people are at and convince them they should buy in because it’s innovative. People winced at the thought of iOS meets OS X because they didn’t think the user experience met the use case, but looking at the previews of Lion I think Apple did it right. If Apple listened to it’s customers we wouldn’t have the iPhone, iPad, MacBook Airs, or so many of these products because consumers can’t conceive of them. They want more RAM in the next machine but couldn’t even comprehend going to a machined aluminum unibody.

Before you ship you need to know your product better than anyone else. Study it. Know the demographics and know their tendencies. Don’t rush your product to launch without thinking through these things, nay, KNOWING these things. What will happen is you launch at 1.0 and start seeing reviews, ratings, comments on your blog of features people want for your app for their use case. These lists start going on your dev wiki and then you add features as you have time without being critical of whether that feature will benefit your end goal of the product. Do people know what they want? Take a look at Apple again. If Apple shipped what people want we would have never seen the iPad. People didn’t even know it was possible, bother want it. People think they want more added to what they already have, when what they really want is “it just works” which happens when you don’t overload them with options; read, Windows Vista control panel. Remember, you know your product better than anyone else.

Instead of shipping often, develop a roadmap for what 1.X updates are going to take you to your end goal and trim off the crap people whine for if it doesn’t reach that goal. Apple’s app review team suggested that Dustin Senos, the developer of LittleIpsum add features to make his application more useful to fit Apple’s Mac App Store guidelines. This request didn’t fill the end goal of Dustin or the user’s goals of LittleIpsum, being quick and lightweight. Adding features wasn’t inline with his goals so he didn’t implement them. He knew his product and didn’t ship an update before comparing requests to his goals and product roadmap.

Don’t make “ship early, ship often” the first thing you write across the whiteboard by your desk. Make it something more like, “Know your product, ship that.”