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

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