wrkng

I’ve said this before, but this time I think I really mean it.  I’m going to officially (for the moment at least close up this blog, and move the action over to my Tumblog.  The reason being that I just find it easier to write there, because I can take things in smaller pieces, and because posting by email is so easy. And, let’s be honest — I just don’t put out the volume of stuff to really justify a whole separate big boy blog.

So, if you follow the RSS here (anyone? anyone?) you should make a note of this: http://nickgrossman.com/rss

See you there!

One of my favorite phenomena over the past few years — and one of the stories I like to tell most about why the internet is awesome — is something I call “Prescient Markets”.  Marketplaces (or just producers in some cases) that take a large amount of the risk out of producing & selling products by only building what they know, in advance, that people will buy.

The original, and still my favorite example is Threadless. In case you don’t know it, Threadless is a t-shirt making/buying website where users upload the t-shirt designs.  Then, other users vote on the designs.  The highest-scored designs are then actually produced as shirts and put up for sale.  ”Winning” designers are given $2500 cash if their design is selected (in advance of any sales, mind you) plus $500 in Threadless gift certificates and $500 every time their design is reprinted.

With this system, Threadless drastically reduces their editorial role in deciding what to produce, based on the assumption that a shirt with many votes and a high average score is likely to sell.  (of course, it’s no guarantee, as the people voting may not actually buy, or may not speak for real potential buyers, but it’s a really good head start).  Then, perhaps my favorite feature of Threadless is what happens when shirts go out of stock — if you see an out of stock shirt that you like, you can sign up to order it in your size, and if enough people do that to justify a run, new shirts are printed and put up for sale.

Another site that takes this approach is Quirky, which is basically “Threadless for stuff.”  Through a structured, crowdsourced product development process, product ideas are honed, and ultimately a final product idea is developed. Quirky employs a presale process that proceeds to manufacturing once a certain threshold is met.

Quirky’s process is infinitely more complicated and collaborative than Threadless’, and to be honest, I’m impressed that they’ve been able to successfully architect, describe, implement and manage their scheme. Revenue is shared with each product’s “creator”, plus a (potentially quite large) group of “influencers” who have contributed to the development of the product in certain ways.  One really nice touch is that when you order a product from Quirky, the picture of the inventor and the names of all the influencers are on the outside of the box.

Another, super high-profile example of a related model is Kickstarter, which crowd-funds creative projects, using a pledge-against-a-threshold model.  The most incredible story coming out of Kickstarter is the TikTok+LunaTik kits that turn an iPod nano into a watch – with a modest fundraising goal of $15,000, the creator Scott Wilson raised $942,578 in pre-sales.  Last I checked he was on a plane to Beijing to scope out manufacturers.

Kickstarter is slightly different than Threadless and Quirky because there really is zero risk for the producers — they’re not committing to build anything unless they get the money up front — and I almost didn’t include it for that reason.  What I think is particularly interesting Quirky and Threadless is that they are using crowdsourcing and community to de-risk a product development bet.

Naturally, I’m wondering how this kind of a process can be applied to other sectors. In particular, it’s gotten me thinking about how it can be applied to the government technology buying/building market, which we focus on with our work at Civic Commons.  Government is under-performing in technology, procurement is a problem, and cities are running out of money.  So something’s got to give.

Somewhere within all this mess, I suspect that there’s an opportunity for governments, vendors, startups, and civic hackers to make something good out of this idea.

Whenever you start a project (and I’m thinking about building websites and web applications), you are balancing two somewhat opposed goals: 1) get something working right away and 2) satisfy all your hopes and dreams. The first, I think, is a good instinct.  The second is the real challenge — it’s your wildest hopes and dreams for a project which can ultimately stop you from just getting something working, now, that accomplishes the smallest essential essence.

Paul Graham and Eric Ries describe this as the Minimum Viable Product — I agree with that idea completely — but sometimes in practice it feels like even “MVP” ends up being bigger & more complicated than it should be.  I’ve worked on projects where the idea of “getting to MVP” looms large over the team — I feel like when that starts to happen you’re actually building more into your MVP than you should be.  The beautiful moment in building a product is the first time when it actually serves some basic need, and does that in a way that’s fun to use.  And that moment can’t come early enough.

So, if you find yourself debating problems you don’t yet have, or arguing the nuances of the perfect, most elegant data model, maybe the thing to do is stop completely and ask  yourself if the most basic essence of what you’re making has been built, and if it has, if it’s fun to use.  If it’s not built yet, you should stop and build just the absolute simplest thing that works.  Not for public consumption, necessarily, but for yourselves and your team. If it is built, then you should ask: is it fun to use?  If it’s not fun to use when it’s at its most simple, it’s only going to get harder to make it fun to use once it’s more complex.

Simple, and fun to use.

I’m not saying I’ve successfully approached every project this way, but I try to, and will keep trying to.

This past week, I spent some time cutting a hole in the wall in between our kitchen and our family room. It’s a project we’ve been talking about for a long time, and we considered lots of different ways of doing it before we actually got down to it. We were concerned about the cost, and also about the possibility that this was a weight-bearing wall and what to do about that.

In the end, we went with a relatively simple approach: just remove the drywall, plaster and lath, but leave the structural elements as they are, resulting in a hole that connects the two rooms nicely (the effect we were going for) without having to hire a contractor or do anything crazy. What you see above is the half-finished state of the project.

It’s amazing what you can do with some basic tools — in this case, a saw-zall (aka reciprocating saw) a circular saw, and a hammer.  I’m by no means a professional contractor, but I’ve got some tools and have done enough DIY projects to feel comfortable with the basics.  Most of the time, I make a bunch of mistakes the first time through doing something, and do it a little bit better the next time through.  (in this case this is illustrated clearly — I cut the jagged hole on the left on day one, and the nice, square hole on the right on day two).  But the point is, it feels great to be able to manipulate your environment using tools.  To make.  To build.

Where I’m going with this is that it’s the exact same thing in the digital world.  Every time I fire up a Terminal and execute some linux commands, I get the same feeling I get when I break out the circular saw.  I’m not a professionally trained programmer either, but I’ve picked up a bit of it over the years, almost entirely through reading books, reading online, and building stuff.  Being able to actually get your hands dirty and manipulate the digital world is a really great feeling, and it feels as fundamental to me as using IRL power tools to do a household project.

For instance, here’s the python script that powers the “latest activity” section of the civiccommons.org homepage:

You can argue that the era of the DIY handyman is winding down —  cars are too complex to really maintain on your own, etc.  But I’ll put forward that the era of the digital handyman is in full force and growing.  Thanks to the existence of open source tools and the “view-source” nature of the web, it’s easy to peek under the hood, figure out what’s going on, and tinker to your heart’s delight.  Of course, you can get yourself into all kinds of trouble doing this — the same way you can when you start cutting holes in walls — but that’s OK as you know when it’s time to call the electrician!

Last week at the Web 2.0 Expo, I gave a talk on The Opportunity for Civic Startups.  I was filling in for Code for America‘s Jen Pahlka, and the presentation itself is an hybrid of a version I did at the t=0 Entrepreneurship Festival at MIT a few weeks ago, a version Jen did at Future of Web Apps earlier this year and a version that Andrew McLaughlin has been giving.  Here are my slides.

I broke it down into two main sections: (1) trends that are setting the stage for civic startups, and (2) models/approaches that civic startups are following.  Unfortunately, the timing of the speaker notes on slideshare doesn’t match the slides, so the notes are in off by a few slides, but you can get the idea.

One of my favorite threads in this story is “the rise of the civic hacker” — folks who use their coding & product development superpowers to make cities work better, almost always from outside of official channels.  The “civic hacker ethic”, if you will, is about making shit, and it represents a pretty new way of getting civically engaged — less about arguing policy or politics and more about building something helpful.  What’s even cooler is that there are now a solid handful of civic hackers who have parlayed a passion project on the side into a real business or career: Dan O’Neill & Adrian Holovaty with Everyblock, Harper Reed (transit hacker and now Obama campaign CTO), Jon Wegener of Exit Strategy NYC, Joshua Tauber (GovTrack & Pop Vox), Ben Berkowitz of SeeClickFix and many more.

And there’s more where that came from.  I believe that we’re just at the beginning of a big wave of civic startups (here’s looking at you, Code for America 2011 graduates), and I am looking forward to continuing to follow them, help them, and learn from them.

This weekend, I built some shelves in my closet. It was pretty simple affair — some pre-finished shelving boards, wooden corbels, and a rod for hanging things. What’s funny is that the supplies for all this have been sitting on the floor in my office for about eight weeks now. Every time my wife asks me if I’m going to do the closet, I say “yeah, but there’s a lot I need to think through, to figure out how I want it.” I had big plans for super custom shelves, with beveled trim and all kinds of beautiful polish. And so while I thought about it, the pieces sat there for more and more weeks; meanwhile my clothes continued to pile up on the floor and become an undifferentiated mass because I had no shelves.

Finally, after more gentle prodding from Frannie, I took a few hours the other day and put up the shelves in the way that made the most immediate sense. It was quite simple in the end, but the change was dramatic. Now, instead of a big messy pile, I have shelves on three walls and everything is stacked neatly. My daily wardrobe has been refreshed as I’ve found shirts that have been on the bottom of the pile for weeks. Amazing! Some product is better than no product.

Now that the shelves are up, there are a few things that aren’t quite right. Lucky for me, it’s easy to put a few screws in the wall and move a shelf. So I did — and I added another hanging rod when I realized I needed one. Simple — a total of one more trip to the hardware store and 30 minutes of work. I’ll surely make more changes in the future.

The point of this is not to talk about my closet and awesome t-shirt collection. This is about iteration and product development. And of course I’m thinking about it in terms of my real job, building things on the web. Especially when there’ s a big team involved, it’s really easy to get into a pattern of “think think think! argue! mull mull! get it perfect before we build anything!”. When really, often times the best approach is to just build *something* and start using it, then go back and make revisions.

The old carpenter’s adage is “measure twice, cut once”. That makes sense when materials are expensive and decisions are permanent (i.e., you can make a rope shorter, but not longer). But with the web, like with closets, I prefer: measure, cut; measure, cut; measure, cut.

That’s not to say I don’t believe in planning; I do. I believe in working strategically from a strong thesis. But when it comes to building, less sooner is always better than more later.

This isn’t a new idea! Of course not — it has been written about extensively, and it’s an idea I’ve been a believer in for years. But I’m still surprised by how easy it can be to fall back into a “measure twice, cut once” mentality.

This morning while cleaning up my office, I came across an old sketchbook from one of my design classes in college, circa ~1999.  In it was a gem of a product idea (if I do say so myself).  Without further adieu, here it is: The Self-Hiding Alarm Clock:

Problem: I always turn off my alarm clock and just go back to sleep. It's too easy to reach!

One solution: move the alarm clock to the other side of the room. Problem: This doesn't work! Because you know exactly where it is.

The obvious solution is an alarm clock that hides itself!

Each night it schemes its way to a new hiding spot...

The next morning, you have to wake up, or it will never turn off...

Note the sweet Pentium 4 inside!

So, who’s with me to set up a project on KickStarter or Quirky and make this thing real?!  Or, we could all just learn to manage our sleep a little better…

Update: (5 min after posting) the Clocky Alarm Clock on Wheels serves addresses this nicely. Amazing! via @jordan_yee

Update 2: (+2 min) then there’s the Flying Digital Alarm Clock, which, in the words of the creator:

In pursuit of waking excellence… meet the alarm with a difference! Flying Alarm Clock. SAVE BIG! By its very purpose, the “perfect” alarm clock must be able to outwit the human who sets it! An interesting challenge, to say the least. This Flying Alarm Clock comes as close as I’ve seen. When the alarm goes off, a helicopter flies into the air, carrying the key to turn off the alarm. The only way to silence the alarm is to get out of bed and find the key! The true late sleeper has finally met their match!

Incredible!  via @hoosteen

Two weeks ago, we were joined by the newest member of the fam: Brieza.  Brieza weighed in at a respectable 8 lbs 9 oz and has been busy sleeping away her days since.  So far, having 2 kids hasn’t been as overwhelming as some people suggested it might be, but I’m sure we’re just still in the newborn honeymoon phase — apparently they start crying more and sleeping less at about two weeks.

Theo is super psyched to have a baby sister, and Frannie and I couldn’t be happier to have another member on our team.

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 of 11am this morning, buses in Brooklyn are telling the internet where they are.  And I’m proud to say that our work is behind it.

For the past several months, we’ve been working with the MTA on this one-line pilot, to demonstrate that it’s possible to achieve a workable bus tracking solution using existing hardware (in this case, farebox computers that will be rolled out citywide soon + GPS device + cell modem) and open source software (in this case, the excellent OneBusAway).  The hope is that this approach can work city-wide, and for a fraction of the cost of other approaches.

There is lots of good coverage out there in the blogosphere, particularly over at Second Avenue Sagas, which did an in-depth look prior to the launch, as well as a follow up post-launch.  You can also read our official reaction to the launch on the OpenPlans blog.

On a side note, in anticipation of some amount of attention related to the MTA launch, we also put up a new OpenPlans Transportation website today, showcasing our services and projects in the transportation space.  It’s nice to finally see the business that we’ve been building for the past year take a bit more shape.

I really love this photo — it is a huge honor to have something we worked on (in this case, the screen shot of the map behind the mobile phone) featured on an honest-to-god MTA transit ad.  That is super geeky, I know, but as a lifelong New Yorker and transit rider, it’s pretty cool.

Now, as Jeff Maki, our project manager for the MTA project, said on his way out of the office today: time to go to bed and dream about buses moving on a map…

// photo: Ben Kabak on Flickr