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.