This post has been a long time coming. It's the idea that keeps coming back; the slow hunch that's been brewing and brewing for months. For some reason, it's taken me forever to actually write it out. So here I finally go. Last Friday night, I had the pleasure of judging a round of the Harvard Ed School's Education Enterprise Competition, where teams of entrepreneurs compete for $10k in funding from the Gates Foundation. I channeled my best Randy Jackson and tried to give some helpful feedback to each of the four teams that presented, both on the ideas themselves and the delivery of their pitches. One of the competing teams was Socrative, a startup that produces a web- and mobile-based adaptive learning platform for use within classrooms. Socrative lets teachers create interactive lessons that adapt to each individual student's performance and abilities, while also creating a real-time report card. The idea is to provide a mechanism for teachers to concurrently personalize and scale (moving away from one size fits all, single track lesson), while speaking the language of today's students (texting and playing games on phones). They don't do hardware and they don't do content; rather, they focus on building the platform and API; a very scale-friendly strategy. All in all, it seems like a smart approach to me, and they've already got some early traction (I don't have the exact numbers handy, but something like 2500 users and 50,000 "actions" in the first 10 weeks). But, the part that stood out to me the most was their marketing approach: rather than go in the front door and try to make an upfront sale to a school or district, they go straight to the teachers, offering a free tool that they can start using right away without requiring institutional buy-in. This is an example of what I call the Enterprise End-Run. I've been thinking about this idea a lot because I spend my time in enterprise land -- the enterprise that I focus on is government. At OpenPlans, we sell software services to government agencies through our Transportation and OpenGeo groups and support collaboration in government IT through initiatives like Civic Commons and Open311. We want to help government "do technology" better, which is an enterprise problem with major economic and civic impacts. Broadly speaking, driving change within large institutions and throughout complex systems is hard (just ask anyone who's working in education). In some cases, there are mechanisms that are expressly created to slow down change (procurement policies, unions), and in others it's just a matter of size, complexity, and intrenched interests. So, recently I've been thinking a lot about the end-run as one approach to affecting institutional change. The Enterprise Approach For sake of simplicity, let's define the "enterprise" approach as selling a tool (in this case, software) to a gatekeeper who buys on behalf of many end users. With this approach, the challenge is to convince a major gatekeeper (gov't IT buyer, CIO, etc.) that your idea is a good one, and then sell/implement/deploy and ultimately reach the people who will use your product or service. The leverage in the enterprise approach is that by making a single sale, you gain access to many users. Sales cycles are long, but so are contracts and business relationships. If you're good, you'll build or sell a quality product that gains adoption and is effective at doing whatever it intends to do. And if you're sneaky (evil?), you can eventually lock yourself in to a relationship for a long time on favorable terms. The flip side is that the enterprise world is slow and conservative. It can take a long, long time to go from idea to execution. In addition, the government enterprise environment is political, making it even more risk-averse and short-term in its thinking. As a result, it's not a particularly easy environment within which to push an innovation agenda. Clay Johnson tells us that the problem is procurement; I'll add that the problem is permission -- going in the front door means asking a lot of people for permission before you actually make or deploy anything. This slows you down and is a steady tax on your innovation opportunity cost. And most importantly, when you "buy" your users through an enterprise sale, you've still not engaged them. The End-Run The Enterprise End-Run is about empowering enterprise users to be the enterprise change-makers. This is uniquely possible with internet-based tools, as distribution can be free, and you can easily put your tool directly in the hands of the people who will benefit from its use. As Albert Wenger from Union Square Ventures commented recently, "there is evidence though that if you let endusers adopt Internet technologies they become change agents for the kind of institutional change that will be needed." Bingo. The End-Run is about building a "magnetic endpoint" that draws change out of the machine, rather than pushing it through. It's typically lightweight, not "enterprise-grade". It's showing, not telling. It's more carrot, less stick. And, most importantly, it's permissionless. Here's how it appears to work:
Build a compelling tool (can be a web service, an open source package, etc.)
Make it easy or free for enterprise users to use it
Your user base becomes your advocates, your revenue base, and/or your sales force
The enterprise adapts to meet the demand created by the tool
The world is a better place
What Socrative is trying to do is one example of this. Here are a few other examples from government / civic tech land: Edmodo is a social network for teachers and students. Their end-run approach is the same as Socrative's, and they've been executing it for longer (now 2 years old, major venture funding, 500k users as of 9/2010). I am not exactly sure of Edmodo's business model, so I can't say if they are ultimately trying to make an enterprise sale at the school or district level, if they're going for ads, or if they will attempt to monetize activities within the network. But they are squarely targeting the teacher / student community to become their advocates and changemakers. Google Transit and GTFS: In 2005, Portland's TriMet and Google Transit changed the game in the public transit information space. By creating a "magnetic endpoint" (the google maps website and all its traffic), and by developing a lightweight data standard (the General Transit Feed Spec), they helped incentive the transit industry to publish data about its operations, such as routes and schedules for transit systems and real-time data. This data has gone on to become fuel for the hundreds of transit apps that have been developed over the past 5 years. GTFS end-ran a handful of standards-setting efforts within the industry. It was able to do this by being more lightweight (and less featureful) than the competing standards, and by being paired to a powerful consumer endpoint like Google Transit. In addition, and it quickly developed an ecosystem of supporting tools which filled out the technical picture, and a community of advocates who added some push to the pull. SeeClickFix: One of the first projects that got me thinking about the Enterprise End-Run is SeeClickFix. SeeClickFix offers a "non-emergency issue reporting" platform, whereby citizens can capture problems with their cities, then report them to institutions (both public and private) who are empowered or required to fix them. SeeClickFix is an end-run for two reasons: first, because in most cases the responsible parties don't sign up to receive these complaints -- rather, users of the system wire up connections between places, issues, and actors, and reports can go to anyone with an email address. Secondly, because SeeClickFix is not just about government: any organization with a presence in the built environment can receive alerts and potentially become the fixer. In both cases, SeeClickFix employs its citizen users to becomes the institutional changemakers. SeeClickFix creates an end-run in every place within which it operates, and it's also been part of a broader end-run across government IT, within the "311" space: Open311: Many cities operate their own online issue-reporting systems, which are generally described as "311". 311 was first developed in New York City in 2002, and has grown in popularity across cities since then. 311 is a really interesting data set; John Tolva of the IBM foundation once described 311 as "the best way to tell how a city is feeling about itself," and Steven Johnson recently did a great writeup for Wired looking at NYC's 311 data. While many cities have built 311 systems, until recently there hadn't been any examples of cities opening access to this data via an API. That changed in in 2009, with the District of Columbia built an API on its 311 data, in conjunction with the Apps for Democracy contest. DC's official 311 API and SeeClickFix's API became the first two endpoints to demonstrate the value of the institutional change required to "open up" 311. Building on the precedent set by DC, SeeClickFix and others, later that year OpenPlans began working with a number of US cities and private issue-reporting platforms on the development of a standard data format and protocol for these types of requests, called Open311. Since then, the Open311 spec has been implemented by the cities of San Francisco and Washington DC, with several more on the way, several enterprise vendors (including the major players Motorola and Lagan) have implemented the standard, and a number of consumer apps have been developed on the platform. Open311's end-run is somewhat similar to that of GTFS's -- the pull force of consumer endpoints (in this case, apps contests plus online 311 and 311-like services) plus the push force of the OpenPlans' Open311 organizing, helped move the industry to a place of greater interoperability and innovation. Open Source: Last, but not least, a classic (and broad) example of the end-run is the distribution strategy employed by open source software projects in enterprise markets: download for free, use at will, and then come back for enterprise service and support when the time is right. In this case, the end user is typically a technical staffer who, if things go well, will do much of the internal sales work for you. OpenGeo, a division of OpenPlans, operates in this way with great success. Towards a Push/Pull Ecosystem I believe there's something powerful in the end-run, but I'm not trying to say it's the only answer. I think what you ideally want is a "push/pull ecosystem," where some efforts pull change out the back door, while other projects come in the front door to help build new kinds of infrastructure. Through our work at OpenPlans, Code for America and Civic Commons, that's what we're trying to help put in place. So, there it is: the Enterprise End-Run. Phew. I'd love to hear feedback or other examples of this that are surely out there.