Current Articles | RSS Feed RSS Feed

On the Importance of Being Incremental

Posted by Andy Singleton on Fri, Oct 26, 2007
  
  
When a person or company tries to build and release a very complex product, it usually doesn't happen.  They are much more likely to succeed if they can make a series of smaller releases, with incremental improvements. Fortunately, it is always possible to "incrementalize", but it takes some creativity.

For example, consider the problem of building an operating system. Giant companies have been suffocated under the burden of building and releasing new operating systems, which then go nowhere. But if you start with a student project that has just a few features, and add new contributions to it every day, with releases to real users who then figure out improvements, then you might end up with something like Linux.

Startups have a short schedules. If the startup can release a product, even a simple product, the startup will live. If the project gets more complicated, and the startup can't get a release out the door, the startup will die.

So, “incrementalizing” the product roadmap – breaking it down into small releases - turns out to be a critical skill. As linux shows us, it is possible to build and release even a very complex product in an incremental way.

I ran into this problem when I started designing the staffing business at Assembla. It is the most complex business process that I have every worked on. It includes an entire suite of collaboration and social networking software, with many of the features of Sourceforge, Basecamp, Collab.net, and Linked-In. It includes all of the legal machinery of an international staffing company. And, it contains the payment processing and accounting machinery of an online bank. It's not, at first glance, a bootstrappable project.

The first thing we did was to design an open source license – I call it “open but not free” - that would allow us to release something – code – to developers who could help us, even before we had a releasable product.

The second thing we did was to just start releasing. We released our online services for team collaboration. We released it to the public even though the design was embarrassing. We also forced our early users to suffer from experimentation with feaures, and reliability problems. But over the months, the product got better, and our user base grew, and they did provide us with guidance.

The third thing we did was to offer bits of the process that were useful to users, even if they weren't linked to our business model. The collaboration apps were free. Then we added recruiting – job posting and response – also for free.

The fourth thing we did was to release features to our closest friends – our full service customers and our employees. They can use the new payment machinery, and test it, as a supplement to our old hands-on billing and payment.

Increasingly, I am called on by startup companies with a stalled release process. They want me to get the product released. We can do it. The first thing we do is roadmapping to cut down the initial release of the product and make the rest of the development incremental. It's always possible.

Tags: , ,

COMMENTS

"But if you start with a student project that has just a few features, and add new contributions to it every day, with releases to real users who then figure out improvements, then you might end up with something like Linux."
Very interesting observation. And on feature and timing, what if a project/package that presents few features (hence more probable of ease of use), then automatically kick in additional features when users need them based on context etc. I feel the new approach's dilema is that it may give the users a wrong impression that the software does not do much for them...

posted @ Sunday, November 11, 2007 11:47 AM by Don


"Minimal releases are a great development strategy, but we shouldn't pretend that we do them for the users.", Andy, if I understood you correctly about the above, I respectfully disagree. The truth in my case is I do it for both myself and users. Without users' acceptance the software is just selfware.

posted @ Sunday, November 11, 2007 8:45 PM by Don


We want the users to use the software and get something out of it. That is the goal at every stage of the release process. The software is for the users, and the release is targeted at serving some very particular set of users. However, the incremental release process is for the developers. The users would be perfectly happy if the software sprang fully formed from the brow of Zeus. All of those imperfect releases, while hopefully delivering extremely useful software, can be irritating. But they are very helpful for the developers. And eventually, the developers help the users. There really are two different constituencies. This is an important point because it is easy for someone to argue against the incremental process by claiming that the users want a more complete release. Then you get stuck without the release the developers need. I resolve this with the observation that you have to satisfy one user before you can satisfy many users, so any given release can be very narrowly targeted to get you the next step.

posted @ Sunday, November 11, 2007 10:31 PM by


Very thoughtful, Andy.
Thanks.
Don

posted @ Monday, November 12, 2007 2:20 PM by Don


Comments have been closed for this article.

Follow Assembla

twitter facebook youtube linkedin googleplus

Subscribe by Email

Your email: