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.
As I was reading I was thinking three things:
1. “Amen.”
2. “We should circulate this phrase because it perfectly encapulsates a key idea that many people are familiar with but didn’t have a word for until now.”
3. “This is exactly how open source has always gotten in the door!”
So you can imagine how I smiled when I got to the section where you point to Open Source as the classic example :-).
This can be very effective for internal tool and process development as well. The really diffiicult problems in an organization are often still there because their is some institutional barrier to getting it resourced. I have been most successful when I have solved a problem enough for individuals to see the potential and then assume ownership of the backlog and drive requirements, resourcing and adoption. they see themselves as the problem solver and I just become a facilitator.
Yeah, there’s a measure of “ask for forgiveness not permission” here
Enterprise End-Run. Three words that brought clarity to Socrative’s business model. The assumption here is that the enterprise listens to the employees. Do you believe that’s the case in gov’t and education? -Slava@socrative
Great question. Surely not always, but my working assumption is that a groundswell of actual use (assuming you can generate it!) is a powerful thing. My other working assumption is that this is perhaps more likely to work in difficult environments like gov’t and education, where front-door change is that much more challenging.
Bryce Roberts actually wrote a post with a very similar point of view yesterday; worth a read: bryce.vc/post/4749320567/a-story-about-disruption
Great post, Nick. Much of the work Code for America is doing with the City of Boston is an end-run, although I never thought of it as such until I read your piece. We are coming in through the front door and doing our best to reach end-users directly. Hopefully they’ll use and like our software, building a compelling case for broader distribution and city-wide adoption. It’s fascinating, challenging, and hopefully effective.
It’s a little less clear-cut, but I do like the idea that end-runs (especially across an industry or sector) can actually be initiated through the (one of the) front door(s). That’s sort of how it worked in the cases of GTFS and Open311.
where my dad mel gibson