Make Sure Your Stuff is 'Must Have'

Wednesday, February 28, 2007

This is the first blog post on what I consider to be the "key DNA" elements that your product and company should have to be successful in the infrastructure software market. The DNA elements I describe in this and other postings are not in any particular order.

As I mentioned in my last post, key DNA #1 is luck, but enough said about that ...

Moving on to something you can more tangibly control, another piece of key DNA that is required for your infrastructure software solution to have a shot at being successful is ... drum roll please ... make sure your product is a "must have" solution. Now most of you are immediately saying "No sh*t Sherlock." Before you switch over to check how well your stocks are doing, let me say that, yes, it seems obvious. But you will be amazed at how many startup companies have a great idea on paper, raise money and develop a product that maps to that idea, and find that when they actually enter the market they have missed what customers are really looking for and/or their solution is perceived as not being a "must have." The end result is that one to two years of investment (and money) is down the drain, and they must dream up a Plan B real quick to survive. I have seen similar things when working at larger companies releasing new products. So it can't be that simple of a thing to get right if startup companies are making the same mistake of not delivering a "must have" solution to the market.

Undoubtedly because they have been burned a few times (and burned a few bucks), it is not surprising that this whole "must have" issue is one of the top concerns a Venture Capitalist ("VC") has when they see any startup walking in the door looking for money. That's why if you are pitching to VCs they will immediately start asking you questions such as, "Is your product a painkiller or a vitamin?" or "What is your compelling value proposition?" If you don't have a short, snappy and logically compelling answer to those questions, you are hosed. Not only are you not getting that VC's money, you should seriously reconsider what you are even getting into with this venture.

Before I give my 2 cents on how to help you make sure you deliver a must-have product, let's step back for a moment. At the end of the day, what we are really talking about with this "must have" stuff is whether or not customers will buy your software or not (often known as "Will the dogs eat the dogfood?"). So let's first look at how customers actually spend their IT dollars.

The reality is that 70 to 80% of typical IT budgets are already allocated for maintaining, sustaining and running existing infrastructure, and only 20 to 30% is available for new projects (at least that is what Microsoft says). By "infrastructure" I mean applications and the corresponding software and hardware to operate them, and that infrastructure could even represent typical infrastructure software such as a network management product or an identity management solution. Now for that 20 to 30% of the IT budget spent on new projects, some of that represents net new infrastructure (e.g. a customer forum website that previously did not exist), but probably a good deal of these new projects actually represent replacements of or upgrades to existing infrastructure for either cost savings and/or added functionality reasons. But these replacement projects count toward the "new projects" budget, because money first has to be spent to buy and deploy this new infrastructure while money is being spent in parallel to maintain the old infrastructure until it is replaced or upgraded (i.e., you have to spend some money to eventually save money).

So right off the bat your new product has access to only less than one-third the IT spend. And that remaining pie piece is actually sliced into a number of projects with corresponding costs that the IT organization has budgeted for and prioritized. And remember that those projects include other categories of software, such as application development, which may not have anything to do with infrastructure software let alone your product's niche within it. In addition, it turns out that in many organizations the CIO must actually present these prioritized projects at a summary level to the company's board of directors and get board approval. Thus, the business value of these projects must make sense to a bunch of non-techies who are concerned about keeping costs low, especially in the area of IT. So the point is that it is very rare that customers will have a pile of money lying around that is not already allocated to something else, and there is a formalized process for deciding what they will spend money on.

Defining what it is to be "must have"

So with that overview of how and where IT organizations spend their money, my definition of a "must have" product falls under one of these two scenarios:

1. Solves a "hair on fire" problem where no existing infrastructure exists to address the problem.

This is a great scenario to be in (often referred to a "greenfield opportunity") because you don't have to worry about competition from an existing installed system or the impact of ripping out a legacy infrastructure. Typically a "hair on fire problem" is triggered by a compelling event that has directly impacted senior management within an organization (or made them painfully aware of the problem). Our sales reps at Centrify like to refer to this as the "Compelling Reason to Act," and they will probe the prospect regarding the "Consequence of Not Acting" is if this problem is not addressed.

One example of this scenario was performance monitoring products for email systems such as Microsoft Exchange back in the late 1990s. As organizations deployed modern email systems like Exchange and Lotus Notes to improve communication within the organization and with customers and partners, it became readily apparent that those email systems were now one of the organization's most mission-critical applications whose health and availability needed to be managed. One of the reasons that NetIQ (a company I co-founded in the mid-90s) was so successful in the first few years of its existence was that its AppManager was really the first product on the market to monitor Microsoft Exchange, and the compelling event was often that an executive (or large groups of influential people within the company) could not receive email for a period of time because of some unplanned outage or performance problem. Most companies we sold NetIQ AppManager to in the late 1990s had never even had an email monitoring tool, because email up to then had not been deployed in a broad manner or not relied upon by the rank-and-file. Therefore we were not replacing an existing solution, nor was there up to that point even a budget for email monitoring. So in many cases the budget to buy such a tool was taken from the overall email deployment budget.

Other examples of this include archiving solutions such as those from Mimosa or Kazeon, with the compelling event being a document discovery in a lawsuit and really no existing infrastructure to help out. Another example is a startup called Zenprise (whose board I am on), which is addressing Blackberry monitoring. Many execs rely on their "Crackberries" and so while this service must always be up and running, most organizations really don't have an existing solution in place to do that.

2. Solves a "hair on fire" issue with a key component of the customer's existing infrastructure

This means that your infrastructure software solution is not selling into a greenfield opportunity but instead is replacing a pre-existing infrastructure, and the motivator to replace the legacy infrastructure is either due to lack of newly required functionality and/or excessive costs of maintaining the legacy infrastructure. The bar is higher than the scenario above, because the replacement must be a relatively painless swapout of existing infrastructure from a deployment and cost perspective.

Examples of this scenario include my current company Centrify and our DirectControl solution. A lot of our deals are driven by the "hair on fire" issue of companies failing audits (e.g. SOX and Payment Card Industry Data Security Standard, aka PCI DSS). Basically, their existing infrastructure is not up to snuff, specifically in the area of controlling access to critical systems and applications and auditing who is accessing what. A failed audit gets immediate executive visibility, and the customer is in a situation where they need to do immediate remediation. The nice thing about this (at least from Centrify's perspective) is often times this remediation was not budgeted for, but there is a compelling enough event (fines or bad publicity) that the customer will "make budget" for this. Clearly existing infrastructure exists to allows users to log on to systems (e.g. UNIX systems have /etc/passwd files or legacy NIS environments), but auditors will often find this infrastructure is not up to snuff from a compliance perspective. Centrify's solution addresses compliance but does so in a cost-effective manner: by extending Microsoft Active Directory to non-Microsoft systems, Centrify delivers functionality to meet their compliance needs, with a low deployment cost that outweighes the cost of replacing legacy infrastructure.

Other examples of this scenario are VMware and XenSource, where customers are moving new and existing applications relatively painlessly into a virtualized environment, thereby saving on operational and hardware costs, cooling and power, etc. In this case it is not a "compelling event" scenario that triggers the need to replace existing infrastructure, it is more of an "overwhelming compelling ROI" story. While many vendors create ROI calculators, most customers are programmed to be skeptical of them (which is not to say you should not have one; in fact Centrify has one here ). So in this case the ROI must be articulated and understood in an elevator ride; i.e., it must be a no brainer. Customers must be able to immediately visualize that they can save a lot of money with your infrastructure software stuff vis-a-vis paying to maintain the pre-existing infrastructure software stuff. For example, I bet a VMware or Xensource reps walks into a potential customer and says, "You have 50 servers today, but with my stuff you can reduce that to 10 servers, and do so relatively painlessly," and the customer can easily see the immediate cost savings without having to whip out a calculator.

Validating the Pain

Most of you are already thinking that your planned product or the one currently under development is in fact a must-have product that falls under one or more of these scenarios above. But ask yourself whether it is based on a "gut" feel or quantifiable data? How sure are you? My 2 cents of advice on that: before you really get rolling and start building the product (i.e., before going beyond the prototype), it would behoove yourself to get as much validation of the "must have-ness" of your idea as possible with real potential customers. You are about to devote four to 6 years of your life around a startup, and maybe $10+ million of other people's money, so do not forget to ask as many customers as possible what they think of the value proposition of your solution.

No kidding, you say. Now many startups do talk to customers ahead of time, but they interview a handful of former customers, friends of friends, etc. Many of those people already think you are a great person, so will give you the benefit of the doubt, or may be too polite to tell you have a stinker on your hands. My advice is to talk to at least 30 real customers to get validation of your idea, and ask them the hard question of whether they think this is something they would buy today if it existed. In other words, find out if the dogs will eat the dogfood sooner vs. later, and do taste tests with a meaningful sample. And yes, it is OK that not everyone you talk with says your product is a "must have," but hopefully enough will -- you can still be an All-Star even if you bat just .300.

Also try to figure out how they perceive where your product fits among the scenarios above. Do they have something today that does something similar to your product? If they see your product as a replacement of an existing solution they have in-house, really figure out if they are willing to do the fork-lifting necessary to swap your product in for an existing technology. Sure, a network monitoring product is a must-have solution, but figure out under what circumstances and what it would take for them to rip out the existing one; i.e., what needs to happen for you to shelve XYZ for my stuff? If it solves a hair-on-fire issue where no pre-existing solution exists within their environment, try to figure what the compelling event is that would trigger a customer to seek your solution out. And of course figure out for whom within the organization it is a hair-on-fire issue. Some people you interview may think your product is not a must-have solution, but are you talking to the right people?

And I can't stress enough that those "market research" customers not be just "friends of the family," but potentially get a third party to help you do validation from customers who don't know you from jack. Centrify talked to 10 to 20 customers that we knew previously to get initial validation, but our network eventually tapped out, and then we partnered with someone who introduced us to another 20+ customers to do market and "must have-ness" validation, Tom Garland, now at ACT Venture Partners, www.ACTventurepartners.com (and Tom is not paying me to mention him, but we did pay Tom to help us do this additional market validation). Tom not only did the introductions but organized the calls, acted as a moderator, wrote up nice summary reports on each of the conversations, and gave us honest feedback and analysis. He did a great job for us. There are a bunch of folks out there with rolodexes that can make those intros for you, such as former sales reps covering the various Wall Street firms. Sure it will cost some money, but is it not worth knowing if you are going down the wrong path within the first few months versus, say, three years out?

Now some of you may be saying, "But if I am talking to all those customers, am I not letting my hot idea out of the bag because a VC told me that 'stealth is everything'?" Sure, leakage may happen, but frankly most people will be willing to sign a NDA and will honor them. But to me the pros outweigh the cons. For example:

Most other existing vendors won't give a rats butt about your solution until you are actually out on the market, and they tend to be slow moving, so in most cases they will ignore some random chatter out in the field about a potential new competitor until the product really comes out and is competing with them in the field.
These "validators" you talk to can and will represent a great pipeline for your beta sites, and at the very least your discussions with them may encourage them to put you in the budget sooner rather than later.
You will get feedback on your positioning and functionality that will allow you to deliver a better and more crisp version 1.0.
If you work with a third party, you can get them to produce a huge honking report on the market validation process, which will be a great report to provide to the VCs that in effect does a lot of their customer due diligence for them.

As I document in this post on my Centrify blog, doing this validation early in the process really helped Centrify get the warm fuzzy that we were on to something that had a compelling value proposition that customers would in fact buy in a timely manner. It also helped us understand that compliance rather than improving an organization's operational security was the more critical driver for our solution, and allowed us to refine our pitch to investors but also potential beta sites on what pain points our solution could address.

I hope this helps. If you want more reading information on helping to figure out if your solution is a must have, there is a great book I read a few years back called "A Good Hard Kick in the Ass" by Rob Adams that I recall did a great job of emphasizing market validation. As I was completing this blog entry, I did a Google search of "must have vs. nice to have" and came upon this post by Don Dodge from Microsoft that covers the same themes of the need to have a painkiller versus a vitamin, and I thought it was a really good discussion on this subject. And of course most VC websites will emphasize to entrepreneurs this point in their "what we look for" part of their website.

Making sure you deliver a "must have" solution is a tough nut to crack, but it is not the only key piece of DNA your solution and company need to be successful. In my next post I will talk about determining if your product is just really a feature or a platform unto itself.

Categories: All

Bookmarks: