Software can be Useful Before it is Complete

August 28, 2009

“Complete” is an interesting term in the software business. A book is complete when there is a beginning, middle and an ending. Who would want an incomplete book?

When software products are released, there is invariably a laundry-list of features that did not make the cut. That does not mean that the software is unusable, it only means that some features that you might like to have simply will not be available – at least not until another release of the software.

The major trick for those of us writing software is to wisely choose what features will be included, particularly with the first version of a product. The company that I work for sells software, and our livelihood depends upon fulfilling a need in the marketplace with products that compel a prospect to open his or her wallet and exchange money for our goods.

It is easy to get yourself into this, but trying to build a product with depth and breadth because something like it already exists and you “must have everything that the other application has” is an exercise in futility. Instead of spending time and effort duplicating something that already exists, focus on how your product will differentiate itself. You will save yourself a lot of aggravation.

I've had the experience of leading a team that was chartered with building a large, enterprise product that our Product Management team insisted on being very broad. Since there were other products already in the marketplace, it was felt that we needed to offer what they did as a baseline. At the time, I was guessing the plan was to figure out how we were different later. (I was wrong on this point, as I will get to.)

I tried to fight this. I pulled a meeting together to talk about focusing on one area, keeping the scope down so that we would have something to enter the market with at an earlier date.

I was told no. We didn’t want to sell to a subset of the market; the goal was to have a product that could be sold to the entire market, and as a consequence our product needed to match competing products feature-for-feature. The keep-it-small-and-focused door was slammed in my face, but I felt that it was important to try before we went down a long and difficult road.

We went ahead and built the product, and it was a struggle. As we approached the first release, I became involved with the marketing efforts. Guess what question our Product Management team had for me, as the Manager of Software Development?

You guessed it! It was: “So, what differentiates our product from other products in the marketplace?”

While I stifled my disbelief, I was at least as prepared as I could be. We didn’t have specific business features that differentiated our product, but we had – fortunately – put a lot of thinking into the design of the product. We had a great user interface, and we had other technological options that enabled this product to easily connect with other systems. We had something, not as much as we could have, but some things were out of my control.

Flash forward a few years. We now have a product that we’ve stripped out some code and greatly simplified other areas because we found that we didn’t really need what we thought we did early on. We’ve also got a much better idea on what should be a part of the product in order to differentiate ourselves.

Part of this understanding became possible because we actively demonstrated the product to prospects and at conferences. If we had focused our efforts on delivering a smaller product to the market earlier, we would have been able to perform this activity much sooner, and would have been much further ahead of the game. And we would have generated revenue a lot sooner!

Need another example?

Google acquired a privately-held company named Upstartle, who had a Web-based word processing application called Writely. What was the appeal to Google?

Upstartle didn’t waste time and money building a product that had the same capability that already existed with Microsoft Word. Can you imagine all of the time and effort that would have been spent? And to what gain? Instead, Upstartle emphasized collaborative features – designing new, differentiating, and compelling benefits as part of a basic, no-frills word processing application.

The net result was that Upstartle was able to build and market a solution in a very short period of time. Upstartle felt that collaboration features were more important in today’s world than duplicating a variety of word processing features that only a subset of customers would find useful. Google agreed and bought the company, and the Writely product became Google Docs.