I couldn't sleep last night, and was up around 4am lurking on Twitter.  I came across an old friend, Elizabeth Green, who is an accomplished and awesome education writer -- you've probably read some of her recent NYT mag cover stories, and it turns out she has a new book out, Building a Better Teacher.  I know Elizabeth because back in 2008 at OpenPlans, we worked with her to launch GothamSchools, which eventually spun-out and became Chalkbeat. I said to myself: oh yeah, that was such a great project; I had totally forgotten about that. So awesome that it is still up and running and thriving.  And I dutifully headed over to update my Linkedin profile and add it to the section about my time at OpenPlans. During my nearly 6 years at OpenPlans, we built a lot of great things and accomplished a lot, and I'm really proud of my time there.  But it's also true that we made a ton of mistakes and invested time, money and energy in many projects that ranged from mild disappointment to total clusterfuck. Looking at my LinkedIn profile, I started to feel bad that I was only listing the projects that worked - the ones that I'm proud of.  And that's kind of lame.  The ones that didn't work were equally important -- perhaps more so, for all the hard lessons I learned through doing them and failing.  So rather than be ashamed of them (the natural and powerful response), I should try and celebrate them. So I decided to add a new section to my LinkedIn profile -- right under my work history: Self.Anti-Portfolio.  Projects that didn't work.  I started with things we did at OpenPlans, but have since added to it beyond that. Here's the list so far:

• OpenCore (2005-8) - a platform for organizing/activism. Hugely complex, too much engineering, not enough product/customer focus, trying to be a web service and an open source project at the same time and basically failing at both. (now http://coactivate.org)

• Homefry (2008) - platform for short-term apartment sharing.  Seemed like such a great idea. A few friends and I built a half-functional prototype, but didn't see it through. Maybe a billion dollar mistake. (more here).

• Community Almanac (2009) - platform for sharing stories about local places. Really beautiful, but no one used it (http://communityalmanac.org)

• OpenBlock (2010) - open source fork of everyblock.com, intended for use by traditional news organizations.  Stack was too complicated, and in retrospect it would have been smarter to simply build new, similar tools, rather than directly keep alive that codebase (https://github.com/openplans/openblock)

• Civic Commons Marketplace (2011) - a directory/marketplace of open source apps in use by government. Way overbuilt and never got traction.  Burned the whole budget on data model architecture and engineering.

• Distributed (2014) - crowd funding for tech policy projects. Worked OK, but we discontinued it after brief private pilot.

Looking through this list -- and there are certainly ones I've forgotten, and I will keep adding; trust me -- what I noticed was: in pretty much every one of these cases, the root cause was Big Design Up Front - too much engineering/building, and not enough customer development.  Too much build, not enough hustle.  Another observation is that these were mostly all slow, drawn-out, painful failures, not "fast" failures. I thought I learned these lessons way back in 2006!  That was when I first read Getting Real, which became my bible (pre-The Lean Startup) for running product teams and building an organization.  The ideas in Getting Real were the ones that helped make Streetsblog and Streetfilms such a big success. And they are what helped me understand what was going wrong with the OpenCore project, and ultimately led me to disassemble it and start what became OpenPlans Labs. But it turns out the hard lessons can lurk, no matter how much you think you've taken them to heart.  Perhaps tracking the Anti-Portfolio in public will help.