We’ve recently gone through some exercises here at Veeam as we prepare for 2010. Of course we’re working on our sales goals and marketing plans, but we’re also talking about our product set for 2010. One of the most often questions I get asked by our sales teams at quarterly business reviews (QBR’s) is what is our roadmap and can they share it with customers and partners? This is always a tricky question since if we give too much away we risk our competitors finding out and getting to market first with certain functionality. If we don’t say anything it makes us appear like we don’t know what we’re doing or where we’re going.

Since we’re getting ready for our 2010 kickoff meetings we’ve had a lot of discussion about roadmaps and the Veeam philosophy on sharing product directions, specifically around Veeam Backup & Replication. We need to give something to our sales teams to share with partners and customers but at the same time we need to protect our intellectual property (IP) and also be able to react to an ever changing market.

We’ve also watched as other vendors and competitors have talked about their roadmaps and plans for the future and then continually missed their release dates or promised feature sets. Does this mean they’re lying to their customers? I would tend to say no because at some point they truly believe they’re going to make their release dates but then something happens and they miss it. Customers and partners are now left waiting and wondering when the next version will be coming out…the more times this happens the more and more customers will no longer trust you and start looking at other solutions.

Time, Features and Quality

These are the words our development lives by. Anytime someone asks for more features, it takes more time. Want it faster? Then features will get dropped. Of course development could achieve both but then they end up delivering a poor quality product because there wasn’t enough time to test all the new features (see the relationships here). Some might say just throw more developers at it but then of course there’s the saying: “9 women can’t make a baby in a month”.

The other issue of locking in feature sets too far in advance is what if there’s a great new feature that comes along that more and more customers are asking for and you promise to deliver? Do you ditch your previous plans and deliver the new feature? Do you wait until you deliver what you originally promised and then add the new feature? In either case, someone is going to get called a liar and that’s not good for customer and partner relationships.

It’s the History, not the Future

One of the things I learned early on in the software industry is “sell what you have”. If we don’t have features X, Y and Z today but we do have features A, B, and C then that’s what we’re selling. If I try and sell you X, Y and Z and promise you that we’ll have them at a specific time in the future, I’ve most likely just lied to you. But there is a fine line…if I know development has features X, Y, and Z “feature complete” and we’re now going through testing I’ll let you know. I still won’t tell you exactly when except for maybe something like Q1 or beginning of Q3. Again, I don’t want to lie to you, something may come up in testing that delays the product, something significant enough that it would put the quality at risk and we won’t knowingly release poor quality products to the market.

Rather than trying to sell the future, why not take a look at the history? The truth is, history tells more about a company than any roadmap promise of the future. History is verifiable, history is real. Roadmaps are the future, the future may change, history doesn’t. If a vendor is trying to sell you on the future and not on today, what does that say about the quality of the products or feature set they have today? Are they lying to you?

Others Promise, Veeam Delivers