The enterprise underground (II) - Designing your web app for them
In my last post, I described a group of people whom I call the “enterprise underground”. I described how they pioneer innovative social web tools inside large organizations. In this follow-up, I want to talk about some of the things the developers of social web apps can do to make it easier for their proponents inside the enterprise.
I hope I don’t have to convince anyone that the enterprise is a lucrative and appealing market place. While it’s definitely ruled by huge brands and high switching costs, the same high switching costs can act as a bulwark of security for your app in these trying times. Once you have widespread adoption in the enterprise it would be hard to find a substitute. The enterprise market is also dramatically poorer in innovation. Despite the fact that almost every single value addition in the enterprise market was originally pioneered in the consumer space, very few consumer companies take a stab at the enterprise market. So yes, you may be competing with Microsoft and Oracle, but it’s highly likely that their product doesn’t do what yours does. And the products that could directly compete with yours are probably not competing with you in the enterprise.
There are two main aspects to helping the underground evangelize your product. The first is to actually showing an interest in an enterprise use-case. A surprising number of consumer web startups are reluctant to deal with the enterprise. While this was perfectly understandable in the past, the underground changes the game significantly. Imagine having a sales person inside the company! The second aspect is to design and spec your product in such a way that it doesn’t discriminate against enterprise users. I’ll go into both shortly.
Most consumer-web startups see the enterprise as a distraction. It’s a waste of time, weighed down by long sales cycles, high overheads, services engagements, painfully crawling up organizational hierarchies and horror of horrors, having to hire sales people! All, while you could have been building features and delighting users. This simple scenario is not so much the case anymore. Exceptions are sprouting up all over the place, sometimes at the highest levels. I have personally seen more than one Fortune 100 CEO signup for tiny web apps nobody had heard of; imagine that! What this means is that it makes sense, even for tiny web startups, to keep an eye on the enterprise, especially given the potential upside.
Now that I’ve hopefully convinced you that you should pay attention to the enterprise space, I want to go into the bare minimum that you can do so that the underground has a fighting chance of bringing your app into the enterprise. Too many startups treat the enterprise as a place they sell a severely crippled consumer product in the name of security. The enterprise has unique needs, not just in terms of security, approvals and workflow, but also in terms of organizational dynamics and cultures. So here’s the bare minimum that you’d want to incorporate into your whiteboarding. Once again, this is not a checklist for an enterprise-focused app. This is for consumer and small business apps who likely have some enterprise underground users whom they want to nurture.
- Give your product a sane name: Tolerance for web 2.0 naming and dropped vowels has risen a lot in the last year, but do try to stay of teenagerisms and adolescent expressions. You won’t believe the number of times that this is an actual stumbling block: “Team, I’d like us to start tracking our projects on this new system called Gitrrdun.com.” Yeah, right.
- Make it easily customizable: One of the reasons that blogs are so popular with enterprises is because anybody can figure out how to slap a logo on them and change the colors. If you can let people upload a logo, add some CSS and Javascript to their pages, you’ve created a pretty compelling customization story. This will also help mask the fact that your service is being used.
- Stay open to non-obvious uses: Let’s say you’ve built an exceptional cat-picture captioning application, where users can collaborate on creating the LOL-lest LOLCATS. Watch out for the one user who’s using it to caption industrial designs or real estate promotions. It’s likely that your product is filling a need in an industry that is underserved. You don’t have to abandon LOLdom for real-estate, but it’s good to know when sometime in the future, real estate once again becomes a better business than LOLCATs.
- Keep your eyes and ears open: If you are a reasonably successful web startup, chances are very good that your app has been tested, if not in active use by some pretty large organizations. Do you know who they are? Even if you have only 5 people at Wal-mart using your app, the potential revenue you could get from selling to an organization that big justifies a higher level of attention paid to those users. And if steve@apple.com or barackobama@whitehouse.gov ever register an account, pay attention!
- Provide Reasonable Pricing: The ideal price for the enterprise underground is lunch money. About $25 can be expensed a month without too many questions asked. Many startups have no sales team (depending on the underground’s intro for sales) and still price themselves out of the lunch-money range with an enterprise product. Typepad is a great example of pricing a product right for the enterprise underground.
Lastly, and this isn’t entirely a shameless plug for my employer: if you think that at least 50% of your use case will be enterprisey, build it on a proven enterprise plaform like force.com. SaaS is still not the dominant software delivery channel in the enterprise, but trust me that you don’t want to make an offline version that you then have to support customizations and integrations on. And as far as SaaS goes, building on top of a trusted cloud platform can help ease the sell, as well as be easier to maintain.
In the next part, I will expand on my thoroughly disingenuous ideas on why and how Corporate IT should tolerate a level of social web apps in the enterprise.
