Category Archives: the business end

Acceptable Downtime

Brad Feld has a great post about the difficulty in quantifying the acceptable unexpected downtime for software sold as a service, and the delicate ongoing balance between minimizing risk (investing in redundancy and infrastructure) and driving demand (new features).
At QuickBase, our umbrella term (coined by Jana, the GM) for these efforts was “Business Reasonable.” Vague? Yes. But the important idea behind it is that any notion of reliability and redundancy has to be defined relative to the kind of customers you have at the time, and how they’re using the product. So instead of reflexively falling back on axioms like 5 nines, you use your empathy and sense of the customer to try to answer the question: what sort of downtime they will they consider reasonable? Just as Geoffrey Moore’s early adopters and visionaries are willing to overlook holes in a product’s functionality, those same customers are often, by temperament, willing to give away more more “free passes” than later stage customers.
During our periods of early rapid growth, we definitely used up one or two of those precious free passes. We all spent time calling customers to explain. And ultimately, after some incredible efforts by our engineering and operations team, we became a service our customers could depend on.

Web services and lock-in

The always-interesting Jon Udell posts about next-generation web services and data lock-in. It’s a topic we’ve considered at length at QuickBase, a web service that revolves entirely around helping customers make better use of their data.

Sure, it’s partly the nature of our service, but we’ve never considered not making it easy for customers to get their data out. We provide them with a number of different ways — either by saving to CSV, XML or programmatically through our HTTP API. Every page displaying more than one record has a “Save to spreadsheet” command.

We do this for two reasons:

  1. It’s a selling point.
    When you’re trying to convince customers to entrust you with their data and their applications, the idea that “you can always get it back out” is very comforting.
  2. If you’re really doing your job as a product, “lock-in” is about much more than holding customers’ data hostage.
    Typically, our customers use QuickBase to manage some kind of of process. It could be about running an event, managing an issues list, or running a project. Our customers get addicted when their process becomes embedded in QuickBase — through the email notifications they set up, the views they create, and the permissions they set up. They can always take their data somewhere else, but they lose the way their team can work with it. That’s the value QuickBase adds.

Ultimately, as a subscription service, we’re earning our customers money again each month. But if you’re really confident in the value your product creates, you know that “lock-in” happens when your customers can’t imagine working any other way.

Software and commodities

I’m a big fan of Doc Searls, but I think he’s got some basic ideas wrong when he says that the stupidist conceit of the software business is that commodities are bad.
“Commodity” has a number of different meanings dependent on context, but for the purposes of this conversation, let’s take the definition as I understand it to mean in this case: a commercial service or good that is undifferentiated from other goods offered by other producers of the same good.
Going from this definition, commodities in a business context are almost universally a bad thing, because it implies that you, as the producer of an undifferentiated good, have no pricing power in the market. Take Doc’s example of food producers. Over the last hundred years, it’s become harder and harder to eke a profit out of food production. The farmers who still exist (and I’m including large agribusinesses in this mix) are able to do so only by virtue of massive subsidies from the government. Were it not for those subsides, the food producers would go out of business — not a nice place to be.
Producers of food-related commodities, however, are much better off than a hypothetical producer of a software commodity. The economics of software are actually much closer to the railroad industry, where there was tremendous capital costs associated with laying the tracks and buying the trains, but the incremental cost of each train voyage is relatively small.
In business, you always want to be producing something that’s different in some way — ideally, in a way that will induce customers to pay more for that good over the goods offered by your competitors. In the case of stupid networks, that differentiation could be about customer service and reliability, but unfortunately, those often don’t factor into the decision process most consumers follow when choosing a network. Markets producing commodities — where no player has any pricing power — will always tend toward consolidation and monopoly.