philcrissman.com

What we call “Web 2.0″ products have, so far, been web applications targeting the average user. Every new app and startup seems to follow this same pattern. I think there’s a few reasons for this:

• Quicker launch. When you’re targeting the average consumer, you can usually launch quicker; you just need something functional for the user to play with. It doesn’t need to integrate with other systems (though it may eventually), it just needs to do something.
• Lower barrier to entry. You have no gatekeepers; just put it out there and try to generate a little buzz and/or publicity. Depending on how crowded the space is where your product fits, this may take less or more effort, but you don’t need to ask anyone’s permission; you don’t need to get your foot inside the door of Microsoft, IBM, Oracle, SAP, Sun… Just put it out on the web.
• More agile (possibly). You can change direction quicker, easier, if you’re just out there meeting consumers needs/wants. Want to rewrite your application in Python? Go ahead! Suddenly decide you’re more of a “file transferring” service than an “instant messaging” service? Great!

That’s an incomplete but (I think) not completely inaccurate list. So yes; there are advantages to what has become the typical model for modern web applications.

At the same time, the enterprise is becoming more and more interested in “web 2.0″. In truth, this is partly just because it’s cool. Not that the enterprise is too concerned with being “cool” (though it would be great if corporations tried to be a little “cooler”, a la Tom Peters’ style re-imagination) — but if something is generating a lot of buzz, the enterprise will assume that it is providing value for someone. In this case, for many someones. The enterprise is very interested in “adding value.” They want to add value for their customers (so that they can keep and grow their customer list) and they want to add value internally (to lower costs/raise productivity, ergo affecting the bottom line and ergo pleasing the shareholders).

So the enterprise will be looking very carefully at anything they think will add value. They might do it a little later and a little slower than the early-adopter alpha geeks, but if persuaded that there is value to be added, I think we can rest assured that the enterprise will check it out.

Buy Me!

As they do this, the enterprise has the same two choices it has whenever it contemplates a new product: develop it internally, or acquire a smaller company that is doing what they want to do. The choice that they make will probably based on cold, hard, budgetary numbers and projections. Will acquiring the small company add enough value, in a short enough time, that the cost of acquisition and integration is less than the cost of developing the tool internally? If the existing tool is mature enough, I’d say that acquiring the small company is going to win a fair number of times.

It costs how much?

Not only that, but part of your monetization strategy is solved quicker. For typical “web 2.0″ applications, the idea is to release some very cool, free service into the world, and then figure out a way to make money from it. Usually this is with advertising (which is still currently working very well) or with a subscription for a version with enhanced features.

The enterprise, on the other hand, expects to pay money for software. Not only that, but they’re used to paying quite a bit for good software. That’s not a bad paradigm to walk into as a new startup, versus giving something away, and earnestly trying to convince your investors that you can, somehow, generate revenue.

Pros and Cons of selling

Normal web 2.0 apps don’t really spend a lot of time trying to “sell” the user on their service. They generally rely on their uniqueness (hopefully) or their buzz/momentum/word of mouth. Selling to the enterprise isn’t going to work that way.

There are pros and cons to having to sell someone on your application. One of the first is that you’ll realize very quickly whether or not it meets a need. Someone said once, if you can’t state your position in eight words or less, you don’t have a position. Similarly, if you can’t tell me the need that your product meets, or the problem that it solves, you don’t have a product. You have a software toy. The enterprise wants to buy solutions, not toys. “Solutions” may be a bit of a buzzword, but regardless, that’s what we need.

(Now, technically, all you have to do is convince someone that your are solving a problem — but it helps if you actually are.)

Once you get used to the idea of needing to sell the product, though, there are some potential pluses. With a consumer product, if you want 500,000 users, you need 500,000 people to be convinced that your product is worth using. With an enterprise product, you may just need to convince 500 IT directors, CIOs, or other management. Is it easier to make 500 sales than 500,000? Well, I suppose the real answer is “that depends”, but the bottom line is, if you sell one person, you may wind up having just gained a thousand users (or more). Not bad.

Enterprise 2.0

However, you don’t want to create Yet Another Enterprise Application. There are a lot of those; if you’re reading this and thinking about it, you do want to keep your application “2.0″ — which probably means social, network-y, highly communicative, simple, etc.

Now, here’s where I interject with my opinion. It seems to me that what has made “Web 2.0″ explode can be in a large part attributed to open APIs — in some cases, completely open source applications. If you want to make your widget work with systems X, Y, and Z, you can; because they all told you how.

Conversely, in the enterprise, the tradition seems to be mammoth “solve-all-your-problems” application leviathans. They might have an API, sure; but plan to call in several $500/hr consultants for 6 months to integrate anything.

If Enterprise 2.0 is going to add value in the same way that web 2.0 has, a huge component will be simple, open APIs. By simple, I mean, you don’t need to be a J2EE/Oracle DBA/UNIX Guru to understand the documentation. That doesn’t mean you can’t use those technologies, but make the API something that a junior programmer can use. If the IT department then wants to add a little modules, they can do so with some quick PHP, Ruby, or Java.

OpenSocial could be a big one; if developing for the “Enterprise 2.0″ space, I’d think twice before ignoring OpenSocial. If companies and applications start adopting this (and it looks like they will), then having compatibility with it could be a very large selling point. Not having it could be an automatic loss.

Conclusion

I think that Web 2.0 applications targeting the enterprise have a bright future. If it sounds good to you; go make something! ;-)