As a start up you need customers. You never know where the next one will come from or what new business segment they will represent. At one of my start up companies we had a brash CTO who was constantly on the road teaming with either marketing or sales to make us known, to demonstrate our product concept, and to reel in the next customer candidates. I knew from attending several that these customer meeting trips were quite grueling and the customers always had ideas for how our product concept could better satisfy their specific needs. Our CTO had a philosophy that regardless of what they ask, it is already built into the product. If their question is, “Does the product have a certain feature?”, the answer was always yes. If they want that feature, it is there. This may be dishonest on the surface, but his thinking was that by the time the business agreement was likely to be in completed, the engineering team will have enough time to implement the feature.
Needless to say, as the VP of Engineering, this practice used to drive me nuts. We had fast paced two or three week product update cycles. These cycles were overcommitted and understaffed. There was a feature list a mile long already in place. I felt that the work kept backing up and having a couple new features added following each customer visit did not help. I came from a development environment where we wrote a requirements document, a functional spec, a design document, a Gantt charted development plan, a test plan document and then we performed rigorous testing cycles to drive the defect count down to an acceptable threshold. In other words, it was a waterfall world. I learned that developing for the web can’t work that way. For one thing, 18 month release cycles are unacceptable. In many cases even an 18 day release cycle is considered too long.
I learned how to pare back on the planning and preparation and adjust the plan as we went. In effect, to create an agile environment, before the term agile was in general usage. I insisted that the developers test their features before they check them in and then provide their test tools and results to the QA team as part of the code check in process. It became possible to hand pick features from anywhere in the pipeline and move them up in delivery timeframe depending on their stated dependencies, something that ultimately allowed us to adapt the features coming in “over the transom” from sales and CTO customer meetings.
These were early days of learning how to be flexible and timely. Those are two traits you cannot live without in a start up and they are generally useful in life as well. If the customer wants it, yes it is there. Then go off and make it so!