Month: November 2004

Early stage companies have to be nimble and disciplined when creating and releasing product.  One of the important decisions a startup can make is how it chooses to manage its product releases.  In a software company a product release affects everyone.  A mistimed release can severely impact sales, cash flow, and the company.  We had a thorough discussion in a board meeting this week on this very topic.  I have to admit I was quite pleased with our new VP Engineering as she put forth her methodology and process, shared below.

There are a couple of different ways to manage engineering releases.  One engineering release is date driven, the other is content driven. In a date driven release, the team knows when the next release is out but does not know exactly what will be in it.  The release runs like a train schedule, whoever makes it to the station on time is part of the release.  The other release is content driven; the team knows what is in the next release, but does not know the exact ship date. The release runs more like an airplane shuttle, it takes off only when full.

While I may be oversimplifying the issue, the one that I like my companies to subscribe to is the date driven one.  Of course, just because it is date driven does not mean that there isn’t a highly focused theme.  It just forces the team to clarify the absolute minimum requirements necessary to deliver the right product for the market.  It also discourages feature creep and encourages highly disciplined prioritization.  Most importantly, having a date driven release can get everyone at the company aligned.  Everyone knows the ship date and sets their schedule accordingly to ensure that all pistons are running as GA hits.  This means marketing has to have its collateral ready, upgrade program in place, and product launch schedule set.  Sales knows when it can start telling prospects about the new product and time it appropriately so it can get customers lined up for the next quarter without delaying sales in the existing one. Engineering, of course, needs to deliver product and not get distracted.  While all of this discussion on product releases sounds great, none of it really matters if you do not have the experienced team that can manage them and instill the discipline.  So as you think about your next product release, think long and hard about whether you want the trains to run on schedule or the airplane shuttle to be full.  You know where I stand on the issue.

It has been awhile since my last post as I have been busy with a number of board meetings.  It is so hard to find time.  Anyway, one thought I wanted to share with you is a discussion we had in one of the meetings about the balance between closing large deals and adding new features.

More often than not, you will hear a sales person complain about their product and tell corporate that if they had these 5 features, they could sell more.  Since sales people look for the path of least resistance, they typically go back to marketing and development to ask for the fixes and changes to close a new customer.  Many times, management, in pursuit of meeting their numbers, will oblige and make the requisite changes to land a new customer.  If you fast forward into the future and continue this behavior, you will end up with a company that has a number of customers but also a support nightmare-too many different versions of a product which makes it difficult to maintain and support from a development and customer service perspective.  In addition, you end up constantly delaying the next release of your product as precious resources get sucked away.   You also have lots of features that the market does not want.  Finally, the profitability for each customer goes down significantly as you add new features just to close deals.

In the long run, having too many of the wrong customers can kill your business.  The more experienced and disciplined team will not build a new feature for every customer but rather have a seasoned and proactive product management process for gathering data from the field and prioritizing feature requests based on market and customer need. In some cases, it may make sense to give a feature request higher priority as a number of prospects and customers have asked for it.  In other cases, you will have to make a decision of whether or not to build a one-off feature to close a deal or lose it to a competitor.  While every situation is unique, in general, you have to be extremely careful of going down the slippery slope of customized versions of your product for every customer as the one-off requests will suck up your resources.  It is easier said than done, but the simple rule is don’t add features if the market does not need it.

In the end, I never like my portfolio companies to end up in feature/function wars.  That is a losing proposition.  Rather it is important to take a step back sometimes to see if you can change the playing field on your competition by positioning yourself differently.  This includes understanding the customer and market, pitching a longer term vision and product roadmap that maps to the customer and market needs beyond today’s purchase, and then making them feel that tactically you have enough of what it takes to solve their problem in the short term.  If done right, you can help the customer understand why one missing feature today may not be so critical since your company is the only one that can meet their needs in the longer term.