NetApp - Dave's Blog

Thinking Styles for Developing Successful Products

I originally wrote this entry for NetApp internal use, because we've been talking this week about the most effective way to organize engineering groups and business units, and I wanted to share some thoughts on the subject.

I have a simple model of product development. To develop a successful product, I believe that you need three distinct styles of thinking:

Technology-centric thinking is about how things work, about new emerging technologies, and about changing trend-lines in existing technologies. A good example is our CTO Steve Kleiman's observation, years ago, that disk was going to get cheap enough to replace tape for backup. (Disk-to-disk backup is now one of the fastest growing parts of our business.)

Management-centric thinking is about resources and time management—the people, dollars, labs, schedules, action items required to complete a product.

Customer-centric thinking (aka product management) focuses on the pain-points that customers have—the problems that they care so much about that they are willing to spend money to solve. Tom Mendoza's summary is, "Customers don't open their wallets unless they are in pain."

According to my theory, you get pathological behavior if you are missing any one of the three styles.

Without customer-centric thinking, you get a wonderful design that works great and ships on time, except it turns out that customers won't pay money for it, even though they might admire it as a technical achievement.

Without management-centric thinking, you get a great idea for a product that customers would definitely pay lots of money for, except you never manage to build it or ship it.

Without technology-centric thinking, you get a product idea that customers would love to buy, and plenty of people and money to build it with, except you can't build anything that actually works. Here's a story to make this pathology more vivid:

A product-manager says to an engineer, "Here's my plan for a great new kind of wallpaper. You know how wallpaper is a pain to install? Like the glue is all messy, and it wrinkles, and you can never get the pattern to align from one piece to the next. Well ours won't be like that. It'll go up clean and easy and perfectly aligned. But it won't cost any extra. Customers will love it!"

The engineer says, "Wow, how does that work?"

The product manager replies, "I have no idea. That's your department!"

You not only need all three styles of thinking, but I believe it is best if you can organize to keep them close together. Startups can be so amazingly productive because all three are in close, day-to-day proximity. In larger companies, business units (BUs) can make engineers more effective by pulling the three styles closer together. (Ideally all three should be physically close to each other as well.) If the same person can do multiple styles, that's best of all, although hard to find. The smaller the startup or BU the better, except that you can't tackle such big problems. Of course, having too many BUs in a large company creates other problems, so in the end you have to balance the advantages and disadvantages of large and small.

Strategy Thoughts on Decru Acquisition

I thought people might be interested in the strategic thinking that went into our acquisition of Decru last summer. (Decru builds appliances that encrypt data on disks and tapes.)

Three years ago we decided to broaden our product offerings, in part by doing acquisitions. One promising area we identified was data protection. We were already strong there, and we liked the idea of expanding in an area of strength. At first we didn't consider data security to be part of data protection; we were thinking more of protecting against data loss from disasters, mistakes or failures. But as consumer privacy became a hot issue, we realized that preventing bad guys from getting your data is an important form of protection.

We considered three companies: Decru, NeoScale, and Kasten Chase. Our assessment was that Decru and NeoScale were well ahead in both technology and in the market, so our first decision was to rule out Kasten Chase. Comparing Decru and NeoScale, we concluded that Decru was ahead. They were the only one to support SAN, NAS and iSCSI, which fit well with our philosophy of building storage systems that support all three protocols. Decru was also ahead in getting the certifications needed for the Department of Defense and various intelligence agencies. Finally, we liked Decru's enterprise key management. Even if the encryption engine itself moves into the storage system over time, people will always need some way to manage keys across their entire company. We did view NeoScale as a solid competitor, but in the end we concluded that Decru was a better fit for NetApp.

When we talked with customers, we discovered that they wanted someone big to acquire Decru. Customers often encrypt data, like backup tapes, that they may need to access years later, so working with a small startup scared them. An acquisition by a company with deep pockets would make customers feel much safer, and thus accelerate Decru's growth rate.

Finally, we wanted Decru to keep partnering with all storage vendors, so it was important to consider how they would respond to our acquisition. For our sales strategy with Decru, we copied EMC's with VMware. EMC has done a great job keeping the VMware sales force separate from their storage sales force, and although we were initially nervous about partnering with VMware after EMC's acquisition, we have learned to trust them. Similarly, we knew that other storage vendors would become suspicious of Decru, but we hoped to build their trust over time by keeping our storage and encryption sales forces separate. (We even copied branding: "VMware: An EMC Company", "Decru: A NetApp Company". Imitation is the sincerest form of flattery, right?)

Of all the storage vendors, we felt that EMC was the most likely to respond negatively, since we compete the most intensely with them. We figured one of two things would happen. Either EMC would buy NeoScale, or else they would not. It seemed less likely that any other vendor would acquire them.

If EMC did not buy NeoScale, then Decru with deep pockets would be competing against NeoScale without. Given customer fear of startups in this space, that would be a big advantage. And don't forget, Decru had the better technology and market traction.

If EMC did buy NeoScale that would obviously make it harder for Decru to partner with them. However, the rest of the storage vendors would have an interesting choice: Are they more comfortable partnering with EMC or with NetApp? We felt that we had the advantage. For one thing, we are smaller than EMC, and therefore less threatening. In addition, EMC's recent acquisitions have put them in broader competition with other storage vendors, especially companies like IBM and HP that have broad data center offerings.

Our preference was that EMC not buy NeoScale, but either way we felt that we could partner effectively with the rest of the industry and even with EMC in cases where the customer preferred Decru.

All of this thinking was a bit over a year ago. How have things turned out? Kasten Chase went bankrupt, so I guess we called that one right. So far nobody has purchased NeoScale. Decru is performing well, especially in financial services and in the military. Best of all, we have continued to partner with the major storage vendors. I admit that our acquisition has made salespeople nervous at some of NetApp's storage competitors. For instance, I think it's fair to say that EMC's sales force now prefers NeoScale over Decru, if the customer doesn't care. Even so, Decru has partnered successfully with EMC on many deals since the acquisition, and I am still hopeful that their sales force - along with the other storage vendors'—will learn to trust Decru, just as we have learned to trust VMware.

One thing we did not anticipate was EMC's acquisition of RSA. Over time, this may create the situation that we feared with NeoScale, but in the short run I think it does not. RSA is very strong in public key encryption, but they don't have any products that compete directly with Decru in encrypting SAN, NAS, iSCSI or tape.

Avoiding Vendor Lock-In with Storage Virtualization

An earlier blog entry focused on virtualization in general. This one focuses on storage virtualization. You can virtualize at many levels:

• Disk-level—cutting disks apart, gluing them together, cloning, thin provisioning.
• Homogeneous Systems—virtualization spanning multiple systems with the same architecture (Isilon OneFS, Equallogic, ONTAP GX).
• Heterogeneous Systems—virtualization spanning multiple systems with different architectures.

This blog focuses on the third type, because I've found that's usually what people mean when they say "storage virtualization". I suspect that's because they see the first two as features of one vendor's storage, perhaps valuable features, but not part of a bigger strategy. The third type includes products like Acopia, NeoPath, Hitachi TagmaStore, EMC Invista, IBM San Volume Controller, and NetApp V-Series.

When people get excited about an esoteric technology, I like to ask what business problem they were hoping to solve. A typical customer desire for storage virtualization is:

I don't like vendor lock-in, but I also don't like managing different storage systems. I want 'storage virtualization' to make everyone's storage look the same. Then I can buy storage from multiple vendors, but still manage it easily.

I'm afraid that customers aren't going to get what they want. Today there is both thin virtualization and thick virtualization, and neither solves this problem. (Don't bother Googling these terms; I just made them up.)

By thin virtualization, I mean products that add some niche-capability, like migration or global name space, but the virtualization capabilities are limited (thin) so you still have to manage the underlying storage for things like snapshots, cloning and remote replication. Thin virtualization may add a feature you like, but it won't make storage from different vendors look the same. Pretty much all of the storage virtualization startups are doing thin virtualization.

By thick virtualization, I mean products that provide the full set of storage services: RAID, mirroring, cloning, thin provisioning, backup... everything. You really can ignore the underlying storage. The problem is that thick virtualization is pretty much a storage system. Hitachi leverages the TagmaStore architecture for thick virtualization, and NetApp builds the V-Series using ONTAP. You can make all your storage look the same, but now you have lock-in to the thick virtualization vendor instead of to the storage vendor.

Thin virtualization is useful because you get the niche-capability that it offers, whatever that is. But what is thick virtualization good for? Maybe you like one vendor for the storage itself, but another vendor has better features for one particular application. (NetApp's cloning is great for database test and development.) With thick virtualization, you can get that feature where you need it, without swapping out the underlying storage infrastructure. Or maybe you are switching to a new vendor, but you still have un-depreciated equipment from the old vendor. Thick virtualization lets you manage the old storage as if it came from the new vendor.

Even though thin and thick virtualization are both useful, my fear is that customers will become disillusioned if virtualization vendors aren't careful, because neither form solves the problem that customers wish it would, making storage easy to manage while eliminating vendor lock-in.

The root cause of vendor lock-in is lack of standards and interoperability. Standards don't tend to emerge when innovation is fast. And innovation tends to be fast whenever customers have unsolved problems that make them unhappy. In the storage industry today, I see unhappy customers driving lots of innovation that makes it hard for standards to keep up. I predict that this cycle of unhappiness and innovation will continue for a while, because the problem keeps getting harder: installed storage capacity keeps doubling, and data keeps getting more business critical.

Market Share

Dan (our CEO) once taught me: “The goal of every strategy should be to gain market share. Therefore, every strategic discussion should begin with a market analysis.” Last weekend I printed almost two-hundred pages of IDC market data, and since then I’ve been working my way through it. They cut the data in so many ways – by dollar, by terabyte, by price-band – it can be tricky to figure out what really matters.

To calculate “market share” you have to figure out which market segment to examine. According to IDC’s 2005 revenue numbers for all “disk storage systems”, NetApp is in 7th place with 3.9% share. For “networked storage systems”, NetApp is in 4th place with 8.0% share. What’s the difference? The first market is $25 billion and includes DAS (Direct Attached Storage) and “internal storage” (disks inside servers). The second market is $12 billion and includes only storage accessed over some kind of network – mostly SAN, NAS and iSCSI. Since NetApp only sells networked storage, our share is larger if you look just at that segment.

The question is: Which is the “correct” segment to analyze? It’s tempting to find the market where you have the biggest share. “We’re number 1!” But it’s more useful to look at “natural” markets that reflect what customers care about. It makes no sense to analyze the market for light-blue cars, but it makes great sense to consider cars separately from motorcycles and dump trucks. Buying patterns can change over time. Years ago, cars and SUVs were distinct, but today I would consider them together.

For NetApp, I believe the most natural market is the combination of SAN, NAS and iSCSI. These protocols aren’t completely interchangeable, but there’s lots of overlap. For Oracle on UNIX, you can generally use either Fibre Channel SAN or NAS, and iSCSI is gaining traction. For Exchange on Windows, FC SAN and iSCSI are both good. Being 1st in iSCSI without a strategy for NAS or FC-SAN is like being first in SUVs without a strategy for cars. It’s not bad to be first in a sub-segment. It’s just not a sustainable strategy if customers don’t see the sub-segment as truly distinct. (Still, I’m happy that NetApp is 1st in iSCSI. :-)

Another question is exactly what to measure. Dollars are always an obvious choice, but terabytes are also important. (Pop quiz: Would you rather be the car company with 20% of dollars and 10% of cars, or the one with 10% of dollars but 20% of cars? As you consider your answer, remember all those cheap cars Honda and Toyota sold in the 1970s.)

Here is an interesting fact: in “networked storage systems”, NetApp has 8.0% share measured by dollars, but 14.9% share measured by terabytes.

To summarize:

Disk storage system revenue		7th largest vendor with 3.9% share
Networked storage revenue		4th largest vendor with 8.0% share
Networked storage terabytes		3rd largest vendor with 14.9% share

Which is a better measure of NetApp’s position in the market? Personally, I trust the TB numbers more. Given how different vendors charge for software and support, it’s hard to be sure that IDC’s number really compare apples with apples. It’s easier to count disk drives.

The other reason I prefer the TB numbers is that it’s a better measure of how much you are helping customers. Never mind how much money we are collecting, we are holding 15% of all networked storage. In the long run, I believe that our success as a company will be based on how much data we help customers store and manage, not how much money we collect for it.

Here’s another lesson that I learned from Dan: “If you take care of your customers, the numbers take care of themselves.”

Note: All of the numbers above are from IDC’s “Worldwide Disk Storage Systems 2006-2010 Forecast and Analysis”, May 2006.