Every month at USV we have an internal hack day, where we work on various fun tech projects. We hack on USV.com, we build internal tools, we play with fun new hardware, try out new APIs, etc. It's a nice change of pace, and an opportunity to get a little closer to the tech we spend most of the time talking about. One area we've spent some time on recently is building tools for the USV Network. We have about 60 active portfolio companies, and it's Brittany's job to help them learn from each other as much as possible. She's the human router within the portfolio, matching up skills, questions, needs, and experiences. As part of that, she runs over 50 peer-driven summits ever year across functions (engineering, mobile, people, trust & safety, etc), where members from each company come together to talk shop. Each summit produces a long list of notes, follow-ups, questions, contact info, etc. One persistent problem has been making that document accessible, hackable and shareable, both during the summits and afterwards. Version 1 was a google doc later ported into a Yammer document for archiving. We recently moved the portfolio network from Yammer to Slack, where we are now approaching 1000 members. As part of that, we decided to see if we couldn't hack something together using the Slack API to easily share docs across this large and diverse group. Last Hack Day, we built a "login with Slack" workflow into USV.com, and created a simple CMS for group-editable documents using Firepad (an excellent open source collaborative document engine built on Firebase). After doing that, we realized that it would be just as easy to open this up to anyone, regardless of their Slack team, and the result is Quackpad:
It's very simple: go to Quackpad.io and sign in using your Slack account. You can create a simple group document that's immediately shareable with anyone else who is a member of that Slack team (and not to anyone else). It's particularly good for Slack teams made up of people from across organizations, who wouldn't otherwise have an easy way of sharing docs privately (vs., say, a company, where everyone is on gApps). This is alpha software! So use at your own risk and let Brittany and me know if you run into any trouble. Big props to: Michael Lehenbauer from Firebase, the primary author of Firepad, the whole USV team and network for helping build this and test it, and Slack for having a really nice API to work with. Enjoy! (and vote it up on Product Hunt!)
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.
Today, we announced that USV is investing in Hailo. I am psyched about this for a number of reasons, but primarily because it’s infrastructure that connects people to their city in new ways. What’s most fascinating is that we almost certainly don’t yet know what those ways are. I want to point out one quote from Fred’s interview in the Wall Street Journal. He says:
“We think this is a kind of Trojan Horse to get people using a large network on their mobile phones to actually transact and get real stuff,” said Fred Wilson, managing partner at Union Square Ventures. “From there, I think lots of interesting things can happen. Alone in the taxi cab market, there’s a pretty big business to be built, and the fact that there’s potential beyond that gives us a lot of confidence.”
We talk a lot about backing into your network - in other words, starting with a thin edge of the wedge and ultimately finding a secondary purpose that may in fact be more profound than the first. For instance, we often say “twitter backed into identity” — when Twitter started out, it didn’t start by announcing itself as the de facto identity provider on the web. Instead, it became that after achieving ubiquity in public messaging. Relatedly: a few weeks ago at the election campaign tech / data postmortem event held at google, Oscar Salazar (co-founder of Uber, now founder of Citivox) had my favorite line of the day. He said ”I hate the term ‘civic apps’. All apps are civic. For example, Waze has submitted more pothole reports than all of the other ‘civic apps’ combined.” I love that. A few years ago I wrote about the idea of the Enterprise End-Run, which is related — the idea that we can cause big shifts in enterprise behavior by drawing the change out the back end, rather than pushing it through the front. I just love the idea that the direct approach is not always (or perhaps is hardly ever) the right one. It’s so interesting to think of other areas where this is happening or could happen.