Amy Luby
CEO, MSP Services Network
aluby at mspsn dot com
http://www.mspsn.com

Amy Luby
CEO, MSP Services Network
aluby at mspsn dot com
http://www.mspsn.com

I wish there was an event we were at right now so we could have one of our very good debates over beers about this. Maybe involve Erick and Karl? I think this one could go on for a long time and will definitely get livelier as the weeks and months progress through 2009.

First, good point about dev cycles. Having dealt with the existing top tier “mature” products for the past 7 years I have not experienced a higher standard of quality with a lengthening development cycle. I have experienced exactly the opposite unless a full re-write is initiated, but that gets us all back to the beginning where dev is fast, focused and meets the needs of the end user. In fact, the longer the dev cycle it seems that the less confidence any of us can have in an eventual quality product. The most common response I get when asking for features to simply work as advertised is (I am not talking about new features, but core functionality), “Wait until the next release, then it will work like it should.” This isn’t a good thing and indicates an improper development foundation that can only be cured by a re-write. One of the most recent tools I worked with has been “developing” their most important competitive feature for over two years now. They announced in November that they pushed off the release date again. If a software developer cannot produce a feature that is really the number one feature they lose sales to their competition for for over two years, that tells me they either don’t know how or don’t have the proper underlying foundation to create it. In other words, the core product is flawed and the new feature set cannot be built on top of it until the core product is fixed. Either answer is a bad one for you and I.
I am not saying you’re wrong, but I think there is definitely a cycle in dealing with software companies and the more “mature” contenders have not been producing and will continue to lose ground in providing the features that the mature MSP needs to compete going forward. Also, I don’t necessarily think it’s is a bad thing that we have new and emerging tools to look at. Competition is good, and the more tools we have that come into the marketplace, and really disrupt it, only forces our “mature” vendors to step up their game to stay in it. I don’t think the top tier tool vendors will give up without a fight, but I do think it’s going to be a bloody battle.

I am sure you’ve noticed a number of deeply seated proponents of “mature” product vendors beginning to change tools, process and procedure? If you haven’t noticed, keep your eyes peeled. This is a result of maturing the MSP business model and needing a mature tool set to support it. Our “mature” tool developers certainly paved the way, and I wish that they could step up today to deliver what the mature MSP needs. It just isn’t reality and the choice you and I are left with is do we wait it out with our “mature” product vendors hoping that they will eventually get it right? Or, do we switch tools now so that we’re ready to compete going forward? If we wait, how long? One year, two years, more? If we change tool sets now, what if the new guys don’t live up to their promises? Either answer isn’t easy and one isn’t necessarily the best one as they are both fraught with risk, problems, and pitfalls. The issue then that you and I as business owners have to deal with is do we want to deal with the risks, problems and pitfalls of a new product or a “mature” product? The answer is more and more complicated as your MSP model matures and includes or accommodates for distributed computing, cloud services, traditional LAN/WAN architecture, outsourcing, and all of the peripheral managed services like spam control, email archiving, remote backup, virtualization, etc.

The real complication I see among MSPs in the Channel today, which I will challenge that the “mature” vendors will use to their competitive advantage at least in the short term, is that some will see this as a repeat of the major issue we had about 4 years ago which was the “my tool is better than your tool” argument. I am sure you remember those long debates? Some MSPs are still having them. Right now the focus shouldn’t be on why your tool is better than mine, but you and I should be focusing together on whether vendors are creating or have created the right foundation to take us all into MSP 2.0 and beyond. I would argue that this discussion would result in a conclusion that included some of our “mature” product vendors and some of the new and emerging vendors. The MSPs who will lose out on this debate are those who refuse to consider all options going into 2009, stick their heads in the sand and don’t take this opportunity to look carefully at how their model has or has not matured and how their existing tools have or have not matured. The “mature” vendors who will lose out on this debate are those who stick to the “My tool is better than their tool argument” too long which is the equivalent of sticking their heads in the sand. They won’t mature or deliver for us and will lose market share to the new and emerging tool vendors who are willing to deliver for us.

Where’s the beer?

Amy Luby
CEO, MSPSN
http://www.mspsn.com
aluby at mspsn dot com

There’s no magic in software development speed — smaller companies always start off fast, and then are forced to slow by QA and support requirements.

Important to consider as product roadmaps are compared.