Archive for the ‘Articles’ Category

Social Jobs to be Done

January 19, 2018

I am a huge fan of Jobs to be Done theory (JTBD). It has really revolutionized my thinking about why customers buy a product, and what makes a product great. The founding principle of the theory is that customers don’t buy your product because they want your product, but because they have a job to do, and they think your product will help them. In thinking about the job that the customer is trying to do, the theory breaks them down into groups: Functional Jobs, Social Jobs, and Emotional Jobs.

The Functional Jobs are relatively easy – e.g. I need a cheaper way to get to work, or I would like to be able to check my email without carrying / starting up my computer. For functional jobs, we pretty quickly get to the kinds of performance metrics we are used to thinking about with products – the cheaper way to get to work might be satisfied by a car with better gas mileage, and checking my email might be satisfied by a smart phone or tablet. But what about the other two, Emotional and Social Jobs?

Christensen makes a point in his book to say that if the JTBD only has Functional components, then a person (or a computer) can quickly weigh the relative benefits, and there will be one obvious winner. All successful products will be forced to optimize to those dimensions, and you end up with a commodity. He wasn’t suggesting that there is no room for choice or variation in your product, instead he was highlighting the importance of thinking about the other two components present in most jobs. I think a lot of us, especially if we come from an engineering background, tend to ignore and misunderstand these fuzzier-seeming components of a customer JTBD. This is especially difficult when we try to understand the difference between an emotional job and a social job.

As I try to apply JTBD theory in my work, and teach it to the people on my team, this lack of clarity shows up pretty fast. My first advice to the team was “be aware that these factors are important, look for evidence of them in our customers, and capture them in our descriptions whenever we can”. In other words, take a swing at it, but we really don’t understand how to examine, much less compete in these areas. We could possibly be blind to two-thirds of the problem our customers are trying to solve!

So now I am collecting examples that I think help highlight social and emotional jobs, and the difference between them. Today, I was looking at Apple iMacs, and something along this line caught my eye. Look at this photo comparing a regular 27″ iMac with the iMac Pro.

There is a huge difference in price between the two computers, and the iMac Pro offers much a much more powerful range of CPUs, bigger storage, and (not shown in the picture) more memory and better GPUs. From a functional perspective, we can see the difference between the two computers. One is much more expensive, and much more powerful. I can decide if I need the extra capability, and whether it is worth the extra price.

Now notice the colors of the two computers. The iMac Pro is Space Gray, and comes with a matching Space Gray keyboard, mouse or trackpad. Why? It doesn’t have anything to do with the performance of the computer so it doesn’t solve a functional job for me (like enabling me to do advanced AI modeling). What about an emotional job? Maybe I just like the way it looks, so when I sit at my desk, I enjoy the aesthetic environment more? That makes sense, and we see that the laptops are offered in multiple colors to satisfy that emotional job. But why isn’t the regular iMac offered in multiple colors, so I can satisfy that job with either version?

I think Apple has limited the Space Gray to the iMac Pro to satisfy a social JTBD. When you spend that much more for a computer, you are probably doing it for a reason – you work on more advanced problems than most other people, or you can afford to buy the top of the line no matter the cost, or you are smart enough to know how to take advantage of the extra performance, or maybe the boss values you more than your colleagues. I work from my home office, so no one will know if my computer is Silver or Space Gray and there is not much social benefit to me of having that distinctive color. But imagine that I am a programmer or researcher or designer or video editor, and across all the adjacent cubicles and offices, there is a sea of 27″ silver computers. If mine is one of only a few Space Gray ones, it stands out as something different, something special, and by association, separates me as different and special.

A college professor once told me about an insurance company where all the employees had identical office furniture, right down to round trash baskets. Managers got square trash baskets. In this ocean of uniformity, the small differences were glaringly obvious. The professor said that if someone suddenly ended up with a square trash basket, other employees noticed and asked about when they had been promoted, and if they hadn’t been, accused them of some sort of social fakery for having a status symbol to which they were not entitled.

I don’t think Apple expects many people to buy the much more expensive Pro computer just to show off (although it seems inevitable that a few will be sold for this reason). I do think they made the Pro stand out visually as an extra benefit for these high-end customers. They are different / special / more valuable in what they do, and therefor what computer they choose (and how much they spend), and Apple wants to help them signal this to their social group.

When we are designing our own products, we should notice if the job our customer is doing when using our products is something that would elevate our customer’s social status, and look for ways to help them signal that to their social group.

Tesla Disruption

October 17, 2017

Many casual observers view Tesla as a disruption to the traditional auto industry, because they have delivered an electric car with range and high-end appeal that has been so far unanswered. The assumption is that the existing major automakers are incapable of understanding an electric powertrain. Professional observers, like Horace Diedieu, are more skeptical of the disruption claim. Horace is not a skeptic of disruption in general – he trained with Clayton Christensen himself, and speeks eloquently and often about disruption theory. But after investigating the history of automobile production and Tesla’s methods, his conclusion is that Tesla is not disruptive. I intend to argue that Tesla does follow Christensen’s pattern of disruption. My argument will be, perhaps, less rigourous that Mr. Diedieu, but I hope to be as persuasive. Note: Much of the analysis of Tesla versus the rest of the industry has moved forward to speculation over how autonomous vehicles might remake the auto market, transportation, cityscapes, and eventually society. I am starting with the assumption that wide-scale autonomous vehicles are far enough in the future that there is worth-while discussion to be had on how a company like Tesla will impact the traditional automakers in the meantime.

Disruption theory has several principals. The one that Mr. Diedieu focuses on suggests that disruption occurs only when the business model changes. If a new technology / feature / capability comes along and allows a company to adopt it without changing their business model, then it is called a sustaining innovation, and incumbent providers are generally expected to be able to defeat new market entrants. Mr. Diedieu argues that the most important component of the automobile business model is the manufacturing process. His research suggests that every significant change of leadership in the industry has been accompanied by an important change in the manufacturing process. Because Tesla is using traditional methods for most of their manufacturing, the change from an internal combustion power train to an electric one is almost certainly a sustaining innovation for the existing auto industry.

Another principle of disruption theory is that the basis of competition changes. Existing providers of a product focus on satisfying the ever-increasing demands of their best customers for improvements in a few critical performance metrics. Meanwhile, a new entrant provides a lower-level of these performance metrics to less demanding customers, and focuses on other metrics that are more interesting to that audience. One of the classical examples of this is the computer hard disk manufacturers working to deliver better cost per gigabyte, storage density, and total capacity to their large, demanding mainframe and mini-computer customers. PC manufacturers did not require the highest-end capacity or storage density in their applicaiton, and so could be satisfied by relatively low performance in these metrics. And because they were buying much lower capacities, they could tollerate somewhat higher cost per gigabyte. Because PCs would sit on or under a user’s desk, however, there were significant concerns about overall size and noise levels. The performance measurements for high-end applications could be ignored, and competition (in this market) shifted to new metrics.

If we think simply about exchanging an internal combustion power train (engine, transmission, fuel system, engine management system, exhaust system, polution control systems, etc.) for an electric power train (batteries, electric motor(s), motor controller, charge controller), we can easily believe that electric power trains are a sustaining innovation. Existing auto manufacturers should be able to make this change with as little difficulty as a model-year design change. Any benefits that Tesla gains from using an electric power train also accrue to the traditional manufacturers, and they continue to have the advantage of large-scale production. Instead, consider the basis of competition for each type of car manufacturer.

The competitive dimensions for a car can be grouped into a few buckets: power train (which directly or indirectly affects fuel economy, performance, ride smoothness, noise, etc.), styling (including exterior and interior appointments), and the increasingly important automation features (adaptive cruise control, intelligent braking systems, traction control systems, obstacle detection and avoidance systems, parking assistance, lane-departure, navigation, and eventually, self-driving capabilities). Note: safety is also a competitive dimention, but once you put the intelligent features like ABS, traction control, obstacle detection, etc. into automation, all that is left is structural features and restraints like airbags and seatbelts, most of which are mandated across all manufacturers by law). Auto manufacturers purchase many components from suppliers, especially bolt-on safety features like air-bags and braking systems, and most especially the infotainment systems. However, they invest lots of time, money, and internal expertise on their power trains. The power train defines one of the most important characteristics to distinguish one type of car from another. When a customer focuses on features like fuel economy, acceleration, corning performance, towing capability, freeway passing, reliability, maintenance costs, purchase costs, and to some extent, vehicle size / capacity, they are indirectly choosing one power train design over another. Many of these metrics are incompatible with each other – better fuel economy and lower maintenance costs are the antithesis of acceleration and towing capability, and so they cannot be maximized at the same time.

An electric power train can be designed to outperform an internal combusion power train for all of these metrics simultaneously, for a sub-set of vehicle types. Tesla competes in the mid-size luxury sedan market, and other than price and range between refueling, can easily beat every related power train metric for all other vehicles anywhere near its class, at the same time. Further, a Tesla can best the fuel economy metric for the most fuel-efficient car while simultaneously besting the acceleration of the highest-accellerating car. Some of this is due to design choices by Tesla, but most of these benefits come from the generic characteristics of an electric power train.

Traditional auto manufacturers absolutely can exchange their internal combustion power trains for electric ones, but this will eliminiate much of the traditional differentiation between brands and models of cars. Every car will be efficient, quiet, reliable, inexpensive to maintain, and high-performance at the same time. There will be little room for Porche or BMW to brag that their cars are better performance cars than a mid-grade Toyota or Honda. Likewise, there will be little room for Honda and Toyota to claim that their cars are more efficient, reliable, or inexpensive to maintain than Porche or BMW. If we assume that passive safety systems are mandated by law and therefore not a strong differentator, all that remains for competition are styling, automation, and in the case of a new entrant like Tesla, large scale operations.

To date, Tesla is meeting the minimum requirements for styling, but is not able to win on these dimensions alone. They are currently far behind on scale operations. The electric power train gives them a temporary advantage, which traditional auto manufacturers may be hesitant to adopt, but which they will as soon at the tide of consumer demand shifts far enough. This leaves automation.

Traditional auto manufacturers are far behind in this space. Although they have basic automation features in many cars, they are almost always purchased as bolt-on components from a supplier, are rarely integrated with other automated systems, and are generally designed to be static. Tesla, on the other hand, is developing their car as a automation platform, with a range of sensors and control points to deliver these active safety and automation features, most of which can be improved via an over-the-air software upgrade. This means that their cars can improve in this important competitive dimension at the speed of software.

This difference cannot be overstated. A new car shipping today might have a navigation system that was designed several years ago. The infotainment vendor designs a system, the auto manufacturer designs the new system into a new model of car (which only changes every few years), begins a production run, and starts selling cars with the new system. An infotainment system might allow minor updates, but this process is also very slow and sporadically applied. Imagine if your laptop computer could only have the software available when it was originally made, with few or no updates. This is normal in the auto industry. Tesla is delivering a more integrated, software-controlled system. It is designed to receive updates via wireless signals throughout its life. Although Tesla hardware doesn’t get updated any faster than other cars, the software that defines how it works does. A Tesla on the road today can receive a performance or convenience or even safety improvement from a wireless update.

This is a huge difference in how features are made (from software, not hardware), and how fast they can be designed and deployed. And developing integrated computer / software-based systems requires a specific style of management that the traditional auto makers have so far failed to demonstrate, and which cannot be purchased as a bolt-on component.

So the disruption argument can be summarized as: the electric power train neutralizes one of the most important performance metrics between different styles and makers of cars, and the automation platform of a car becomes the new area of innovation and competition. Tesla has built their company based on being first to the electric power train, but is making most of their investments in growing the automation platform. Traditional auto makers can adopt the electric power train, but this just brings them neutral with other makers, and destroys some of their differentiation. The automation platform becomes a new requirement where they have little or no historical expertise, and so far, are making few investments.

Tesla still needs to learn how to build cars at scale (GM is currently building the electric Chevy Bolt’s at higher volumes than all Teslas combined), but if they can learn to deliver continuously improved styling (which expertise can arguably be purchased), and maintain their lead in the automation platform, they can certain grow as fast as they like, and have the potential to capture a significant share of the automobile market.

So the final question is: can Tesla learn to build cars at high volume faster than traditional manufacturers can learn to design and operate as a computer hardware / software company? There is no clear theoretical reason why one should be more difficult than the other, but we do have one clear historical guide. Apple learned to scale-up production of iPhones faster than Nokia learned to be a software company.


May 28, 2017

Every rule, process, and procedure in your organization was created based on some combination of legal, technical, practical, and arbitrary limits.

Does your company ship everything in just a few standard-sized boxes?  Maybe it is because they fit nicely into a UPS truck, so you get a discount.  Or maybe your first box vendor recommended them, and you have just gotten into the habit of using them.

Are you forced to use 16 digit SKUs for all of your products?  Maybe it is because, years ago, someone arbitrarily set this limit in a database.  Or maybe it is because all of your distribution partners have inventory systems that use 16 digit SKUs, and won’t be able to manage your products if you use longer ones.

Some rules are made because if we do it any other way, it impacts our accounting all the way up to the annual shareholder report.  Some rules are made because someone had to pick a number, so a couple of people got together and guessed.

We get advised all the time to break the rules.  Facebook has (or had) the famous motto of “move fast and break things”.  This approach has the advantage of helping to clear out the rules that were based on assumptions or obsolete technical constraints.  It also tends to create a lot of havoc when the rules encoded important legal or safety constraints. (A supplier of medical devices probably wants to be a little more conservative when changing processes.)

If the consequences of breaking a rule are small, and the opportunity for breaking out of legacy assumptions is high (like for a new social-media company), “move fast and break things” is probably a good rule.  You probably need to supplement that with a team or process that follows-up and fixes any critical issues that result.

If the consequences of breaking a rule are large (people’s health or safety is a risk), you need a more formal change review process.

Most organizations are in the middle of these two extremes, so you need an approach somewhere in the middle.  The key is to unpack the rule and look for legal, technical, and practical influences, and confirm whether they are still relevant.  The rest is probably based on arbitrary decisions that can and should be challenged.

Naming the parts is not enough

March 19, 2017

Some people can name all the parts of a car, and have strong opinions about the various parts.  That doesn’t mean that they know how to build a car that will work, or one that other people will want to drive.  And it definitely doesn’t say anything about their ability to build cars at large scale with a price and features that will attract a large customer base and generate a profit for the company.

The same is true for building software.  We know that many successful software companies today are made from web pages, databases, and maybe some machine-learning.  Knowing this this doesn’t help us know how to build a product people will like, or how to build a successful software company.

First we fear it, then we are mad when it isn’t perfect

September 2, 2015

Self-driving cars seem like they are just around the corner, and one of the benefits they hope to offer is more safety. Depending on who you ask, this might be a huge boon to the world, or an impossible dream, or the beginning of the AI apocalypse. There is almost always fear about new technology, but there is also a predictable path for successful innovations: First we fear it, then we overestimate the benefits, then rich people get it, then everyone gets it, and finally we take it for granted and start complaining that it isn’t better.

Today, autonomous vehicles are in the “fear and overestimate” stage. Another life-saving automobile technology, airbags, were a new thing when I was young, but are now in the “take it for granted” stage. An article in the WSJ (2015-09-02, print edition: “Fewer Air-Bag Replacements Needed”, section B2) had a picture with a caption that caught my eye. “Faulty Takata air-bag inflaters have been linked to eight deaths world-wide.” The article is not completely clear, but it seems like those deaths are from the air-bag failing to inflate when required.

We have some work to do to get there, but soon enough, today’s fears about allowing AI into our cars will be replaced with outrage that some manufacturer’s AI didn’t avoid enough accidents.

Our Competitive Advantage is Ease-of-Use

March 7, 2015

When developing a product, often a desired feature is “easy”. Perhaps this is even the planned differentiation: being easier than the competition. But “easy” doesn’t actually exist. It is like “cold” – physics has no concept of cold, only its opposite, heat. To make something cold, you must find a way to remove the heat. Likewise, if we want to make something easy, we have to find its opposite: hard.

We will find it nearly impossible to specify (or later market) “easy” in our product. Instead, we can work to understand what is hard about existing tasks, and remove those hard things. Now we have something concrete to specify in our product development, and something specific to market to our customers.

Cloud Platform Wanted

April 28, 2011

Clouds computing is about buying just the amount of data center resources that you need, and having the ability to change your mind about that quickly.  Any IaaS cloud provider worthy of the name will let you spin up a new virtual machine any time you want to add capacity to your data center.  The hard part is getting your application to take advantage of that extra capacity.  (Despite what I wrote here, this applies to private clouds, too.)  Most off-the-shelf applications don’t go twice as fast if you have twice as many servers – in fact, most off-the-shelf applications are designed to run on just one server (or virtual machine).  Even the typical n-tier application is constructed from a handful of special purpose system – e.g. web servers, database servers, application servers, file servers.  Although the web layer in this architecture can often benefit from just adding more servers, the database layer typically doesn’t.  If you are building something more specialized than the typical “web server that displays stuff from a database”, you probably have to invent a way to distribute your work across many machines, and then you have to build admin or automation tools to support adding and removing resources.  Now you are hiring developers that are good at building distributed applications, and spending lots of time (and perhaps a limited supply of start-up capital or project budget) building out a robust platform that your real project will run on.

In Rework, the founders of 37signals suggest that you should not worry about the scalability of your application, because once you start making money, you can always buy a more powerful machine.  I believe that their point was that instead of worrying about a hypothetical scaling problem, you should get some customers and generate some revenue, after which you will have some money to throw at the problem.  I agree wholeheartedly with that point.  But more and more of us are in environments where we know that if we cannot support a large number of users, or a large data set, or provide fast response times, the project will fail.  And we sometimes realize that even if we buy the biggest server that Dell or HP makes, it isn’t going to be enough.

So what we need is a good cloud platform for developing distributed applications that can go faster when we add more hardware, but runs fine with a small amount of hardware.  It should be something that doesn’t require super-human distributed computing development skills, that lets the developer focus on his application rather than the plumbing, and that an administrator can configure for whatever scale the occasion demands (e.g. seasonal load spikes).

Got a solution like this?  I’d love to hear about it.  If not, I might have to go build it – feature requests welcome 😉

How Lieberman Got Amazon To Drop Wikileaks | TPMMuckraker

December 3, 2010

This story suggests that a senator was able to coerce Amazon Web Services into dropping a paying customer (Wikileaks), without any legal due process.

How Lieberman Got Amazon To Drop Wikileaks | TPMMuckraker.

Amazon refutes this, and claims that the decision was their own, because the customer violated the AWS terms of service.

From Amazon’s message, it seems like Wikileaks is in violation of the TOS:

It’s clear that WikiLeaks doesn’t own or otherwise control all the rights to this classified content. Further, it is not credible that the extraordinary volume of 250,000 classified documents that WikiLeaks is publishing could have been carefully redacted in such a way as to ensure that they weren’t putting innocent people in jeopardy. Human rights organizations have in fact written to WikiLeaks asking them to exercise caution and not release the names or identities of human rights defenders who might be persecuted by their governments.

The trouble is, Wikileaks has not actually been charged with or convicted of a crime, and the potential long-term effects of the leak are debatable, so these terms of service are fairly subjective.  The whole idea of Wikileaks is, of course, controversial.  The problem is that Amazon’s action feels like an activist action – like the Wikileaks service was suspended because Amazon doesn’t like them.

For those of us building a business based on the AWS Infrastructure as a Service model, this is very scary.  The one thing that we can count on with our own servers is that they don’t judge our content.  We don’t have to convince our disk drives that our cause is just, and our moral compass is intact.  Whether AWS responded to pressure from Joe Lieberman or acted on their own doesn’t really matter.  The message is that if AWS thinks you are up to something fishy, their policy is to drop your service first, and ask questions later.

When I am looking at a business plan, I worry about technology risk, market risk, and execution risk.  Normally, I would think that building a business on top of a cloud platform like AWS would dramatically reduce the execution risk, but now I have to worry about the risk that Amazon won’t like what I am doing.  Amazon has been leading the cloud computing charge, and has been saying every step of the way “don’t worry, you can trust us”.  I think banning Wikileaks was a giant step backwards in their credibility as a utility partner.



Network Effects

August 24, 2010

One of the easily overlooked features of cloud-based solutions is the potential for network effects.  Because a cloud (especially SaaS) vendor has some metadata about their customers, there is the potential to learn something interesting by analyzing that data.  Now, every superpower can be used for good or for evil, so let’s be clear about what I am proposing.  Evil usage is to try to extract personal information about your clients, and use it against them, or sell it to a random third-party without their permission.  Good usage is to use that data to make your service better for your customers.  The key to network effects is that the more users you have, the better the solution becomes for the users.  These benefits are potentially very valuable, and any solution that ignores them will probably be surpassed by a competitor that uses them well.

Here are some quick ideas on how to create network effects in your cloud-based solution.

  1. Best Practices: compare one user’s usage patterns to the average of all users, or of users in a similar class.  Financial ratios are a great example of this kind of thing, but your users probably have some industry / application specific metrics.  Everyone likes to know how they are doing compared to everyone else.
  2. Common Interests: based on usage or user selection, you can recommend people or things that a user might like, based on what other, similar users like.  Think about the “you might also like” feature in the Amazon book store.
  3. Busy / Free / Location: Which other users are available or nearby right now?  Obviously you want to use this in an appropriate way – not every solution should incorporate a “stalker” feature.  But if users want to communicate or meet with other users, you may be able to help with this.
  4. Viral Features: If users might want to pass on certain information, e.g. quotes, screen shots, photos, links, high-scores, etc., make it easy for them to do this.  You definitely want to make it easy for existing users to invite new users, and make it easy for the new users to get basic functionality. (remember how limited email was when half your friends didn’t have it?)
  5. Crowd sourcing: Let users tag or rate things to determine relevancy (e.g. once 10% of your users tag something as spam, you can automatically block it from all the rest), or answer questions to build a knowledge base.
  6. Social: Maybe your customers will be more interested in certain features or content if they know that other people are using them too – these could be their friends, or they could be influencers in the industry.  You can also help people discover hidden influencers, or hidden relationships.  Linked-In does this for your second-level network.
  7. Feedback: this is only sort-of a network effect, but it gets ignored by almost every business.  Every customer assumes that if you have lots of other customers, you should know a lot about what those customers want, and how they use your product. Most companies have no idea – they are only slightly better informed than any individual user.  If you make it easy for a customer to provide feedback, then 1000 customers can easily translate into 1000 real data points about preferences.

This is a place where first mover advantage can actually be defensible – if you have a bigger database of relevant recommendations than the new start-up competitor, they will have a hard time catching up.

Ten Cloud Computing Opportunities

August 23, 2010

Based on my recent work with Double-Take Software’s Cloud business, I guess I am now officially a cloud computing entrepreneur.  I am looking for my next project, and just decided to go open source with this.  Here are ten ideas off the top of my head – they definitely need some refinement, and some of them will probably not pan out, but feel free to steal them, offer improvements, or how about this – contact me to collaborate on one.

  1. Modify an existing open source cloud platform into a drop-in solution for hosting companies, with a global ecommerce site and management interface.  Hosting companies can get into cloud easily; customers get broad geographic coverage with a single interface.  (I know at least one company is already claiming this, but it is a big, big market).
  2. Take one (or more) existing open source web applications or frameworks (like MediaWiki, Django, Sugar CRM, etc.), optimize the deployment for a highly scalable distributed system (i.e. load-balanced front-end web farm, distributed / scalable db back-end, memcached, etc.), and make it available at a very low-cost for entry users, with the price scaling up with usage.
  3. Acquire an enterprise-class (or academic usage) simulation / analysis solution, and modify it to use map-reduce.  Deliver the results of massive calculations in a few minutes (or seconds), and only bill for the usage.  Commoditize massive calculations at a price smaller users can afford.
  4. Build a management platform to transparently migrate virtualized workloads from a private cloud up to a larger public cloud provider, and back down.  (This can be expanded to cross-cloud, or cross-region migrations.)
  5. Create a encrypting, deduplicating network transport protocol and file system that minimizes the bandwidth and storage required to keep workloads synchronized between private and public clouds. (Useful for #4.)
  6. Use one of the open-source cloud platforms to build an Amazon compatible cloud in places where Amazon doesn’t have a data center.  Amazon is expanding rapidly, but it is a big world, and most countries have regulations restricting businesses from hosting data outside the country.  Europe is an especially fertile market for this.
  7. Build a GUI macro editor with building blocks that include Amazon (or another, or all) cloud resources, ecommerce, and maybe some social and / or mobile features.  Let customers build new cloud-based web applications by drag & drop.
  8. Create a web app that lets a product manager or a sales person enter the typical problems their customers face, and the features of their product that solve those problems, and the ultimate benefit.  Let their customer walk through a wizard, checking the boxes to describe their needs, and automatically generate a beautifully designed, customized proposal, based on their requirements.  The whole thing is based on standardized templates, but it feels totally customer for both the vendor and the customers.
  9. Build a Linux-based file server appliance for SMB, with HSM and version archiving to the cloud.  It basically has storage that never ends, and the most current / relevant files are always local.
  10. Add virtual machine recovery and remote access capabilities to an existing laptop backup solution.  When your laptop blows up, you are happy to know that all your files are backed-up on-line.  Wouldn’t you be even more excited if you could boot up a virtual machine of your laptop on-line, and finish the task you were already late on?