Photo: Rudy (Loïs) Pignot
I am in Paris this week for OuiShareFest, and spoke yesterday morning during the opening session. OuiShareFest is in its third year as a large international gathering of folks interested in the peer/collaborative/sharing/networked society, put on by the community organization OuiShare. The topic of this year's fest is "lost in transition", and the prevailing feeling from the community here is a growing concern about the relationship between peer economy platforms and participants, specifically regarding distribution of value, control, etc. This is not really a big surprise, given the huge financings and staggering valuations that many corporate platforms in this space are putting up. At the same time, the rise of the blockchain as an application platform has put a lot of people (ourselves at USV included) on to the possibility of a practical, functional alternative to centralized web services. So, whereas I gather that the tone of the first OuiShareFest in 2012 was unabashedly glowing about the peer economy in all its forms, this year's fest is much more pensive and reflective about the power dynamics built into web platforms, and in particular their relationship to established power in the form of capital investment. For my talk, I wanted to take this issue head on, place it in a historical perspective, and help people think practically about what might come next and how to get there. I'll give a condensed, annotated version of the talk here:
The title "venture capital vs community capital" is an intentionally provocative strawman. The point I want to make is that of course there is a natural tension here, but it's not a brand new dynamic, an either/or choice, or a zero-sum game. Rather, it's part of a recurring pattern that we can see dating back decades (if not much longer) in the history of technology. Viewed this historical lens, we can see the patterns of this cycle and use them to help us understand where the viable opportunities will be in this phase.
But first, I want to point out that the reason we're all here is that we believe in the power of networks -- of the connected society -- to expand knowledge, deliver economic opportunity and solve big problems (energy, health, education, etc) in ways that haven't been possible previously. Right before my talk at OuiShareFest, Robin Chase went on and made a compelling plea for us to come up networked, scalable solutions (both venture-backed and community-backed) to the biggest issues facing the planet today, her biggest one being climate change. I am a firm believer that this model will continue to have profound, deep impacts on how we live, how we work, how we learn, and what we make, and that we are still in the very early stages. But, as we become more and more familiar with this model, we're starting to pay more attention to the particular architecture of these networks, and the power dynamics built into them.
So, the problem that many in this space have identified is a growing concern about the imbalance of power between peer economy platforms and the participants they support, especially as the most mature platforms (Airbnb and Uber being the elephants in the room, but there will be many more) grow to be very large, wealthy and powerful companies. The problem is essentially one of trust. And specifically in the case of peer economy platforms and workers, it's about economics and control. One way to think about this is that as this space has matured, platforms have a tendency to "thicken" -- to do more, take more, and exert more control. So the question becomes, are participants here getting a fair deal, and do they have an appropriate amount of freedom and control? There is a growing sense that they may not be, and that alternative architectures need to be investigated. While this may feel scary to many observers of the space, especially those coming at this from a public interest perspective, we shouldn't be surprised to see this happen. Rather, this is what always happens as companies explore new spaces and establish profitable business models. So rather than look at this phenomenon simply as a brand new problem to be solved today, it's more useful to see it as yet another phase in a recurring cycle, that presents both known challenges and known opportunities. Looking back at the history of major tech platforms over the past 30 or so years, we can see this cycle turn (note: this is not intended to be exhaustive or complete):
(Note: the green boxes are companies, and the blue bubbles are "open" technologies like free software and open protocols -- i.e., venture capital and community capital, respectively) IBM and AT&T once had a monopoly on the PC and the telephone network, respectively, which was opened up by the PC clones and the modem going over-the-top of the telephone network (not to mention the government break-up of AT&T). Next, Microsoft had a lock on PC software through Windows and Office, and AOL (along w Prodigy, Compuserve, etc) had the online market locked down. This lasted until the proliferation of Linux and IP protocol stack, which poked a hole in Microsoft's desktop OS as well as AOL's walled garden, giving us the open internet. Then, on top of that newly open platform, today's leaders in web (Facebook, Google, Amazon, Twitter, etc) and mobile (Apple, Google, Xaomi) built their businesses. It's worth noting that, with the exception of Android, there hasn't been a really meaningful hole poked in the business positions staked out by this generation of companies (though there have been attempts, such as Diaspora for Facebook and Pump.io for Twitter) Finally, we're left with today's peer/sharing/collaborative economy marketplace platforms. These are the new, venture-backed companies staking out territory and building what will become the next generation of powerful incumbents. And while we have seen the beginnings of open protocols that directly challenge their power (like the La'Zooz ridesharing protocol), it's all very very early. So there's the pattern: tech companies build dominant market positions, then open technologies emerge which erode the the tech companies' lock on power (this is sometimes an organized rebellion against this corporate power, and is sometime more of a happy accident). These open technologies then in turn become the platform upon which the next generation of venture-backed companies is built. And so on and so on; rinse and repeat. So, all that is to say: this is not a new thing. And that seeing this as part of a pattern can help us understand what to make of it, and where the next opportunities could emerge.
Given this moment in the cycle -- where we have a small number of large and powerful platforms in some sectors, and a growing sense of discomfort about that power -- how might people who affect change go about doing it? In this section, I want to really stress the "how do you get there part" more than the "what might an alternative architecture look like" part. It's quite easy to imagine a "driver-owned uber" (as many people here have suggested) in its fully realized form, but it's much more difficult to think about how such a thing might come into being. The history of technology is strewn with failed attempts to replace closed/proprietary systems with open ones. Here, I'll point out four ideas that may be helpful in thinking about this:
“Convenience trumps just about everything” -- Steve O'Grady, analyst at Red Monk (link)
Today at OuiShareFest, Aral Balkan from Ind.ie talked about a major failure of the open source movement over the past several decades: to sacrifice short-term usability and experience for long-term (and abstract to most people) freedoms. He framed this problem as "respect for experience" and "respect for utility" (or something along those lines) as the two partner values along with respect for human rights. I would agree with that, and anyone following this space can note the failure of past attempts at open platforms that just weren't usable enough (for example: openID).
"The Lindy Effect is real. Disruption is rare. But it does exist and it is caused by non-linear changes in technology." -- Albert Wenger, USV (link)
My colleague Albert discusses the Lindy Effect: the idea that every day that a platform idea exists extends its expected overall lifespan. In other words, technologies and ideas have momentum -- the longer they're around the longer they'll stay around. It is possible to "disrupt" them, but that requires a profound, non-linear technology change. And even then, they don't just disappear overnight. For example, Microsoft has endured two decades of disruption from the web -- first against Windows as the dominant OS, and then against Office as the dominant productivity suite -- but it still alive and kicking. So the disruption that challenged Microsoft didn't put them out of business, but it did open up the market for many many many others to enter. Looking at today, Uber clearly isn't going anywhere, though "open" challenges to them could open up the market for others. To my mind the non-linear change in technology that has the greatest potential to challenge today's incumbent platforms is the Blockchain (and related decentralized technologies) that are in the process of externalizing data from web and mobile applications (more on that below).
"Your margin is my opportunity" -- Jeff Bezos
This profound idea is not new to the business world, but it's nevertheless instructive for new technologies looking to compete against the new incumbents. Along the lines of "convenience trumps everything", cost matters. For example, I met a blockchain entrepreneur/hacker recently who was incensed about the margin that Etsy takes on transactions (and to most people Etsy is about as fuzzy bunny as you can get as a large web platform).
"The first transaction in a block is a special transaction that starts a new coin owned by the creator of the block" -- Satoshi Nakamoto (link)
This is a line from the original Bitcoin white paper, and I include it to point out the importance of powerful incentives in deploying open technologies. There are two primary innovations in Bitcoin: 1) the distributed, open ledger; and 2) the financial incentive that drives participating computers to cooperate: mining bitcoins. To the extent that this incentive-to-cooperate model can be extended in other directions, we may be on to something big.
Given all of the above, here are a few things we're looking for at USV: Collaborative platforms in greenfield sectors To the first point about the value of networks (to society), there are many many important sectors still operating under inefficient bureaucratic hierarchical models, which are ripe to be re-architected in a network model (I'm thinking energy, health, education, and many others). I suspect that these sectors will be developed by "traditional" networks (e.g., venture-backed, centralized networks), as these have the ability to move the most quickly, to experiment with new models (failing often), and to help train sectors/cultures that a networked model is possible. Worker support services A major concern with the emerging power of web platforms (especially in the collaborative/sharing space) is worker power. We are already beginning to see platforms emerge to serve workers in this environment (e.g., SherpaShare, Coworker, Peers, the venerable Freelancers Union, etc) and will see many many more here. My belief is that "union 2.0" will be a platform, more than an organization, and its power will derive from the data leverage it's able to attain over the the platforms that employ its workers. Thin platforms One way to challenge "thick" platforms is to build "thin" platforms that do less, take less, and exert less control. We have invested in several of these (DuckDuckGo, compared to Google, Twitter, compared to Facebook, Sidecar compared to Lyft, etc) and are looking for more. Often times, "thin" also means decentralized in some way, pushing power, economics and control further out to the edge. New protocols Finally, new protocols that radically re-architect power, information and control. Inspired by Bitcoin and the blockchain, there is now tremendous energy in this space. It's early early days, but it does feel like this has the potential to become the next "open layer" that washes over the latest generation of big companies (see the diagram above) and cracks open the market even further. At USV, we've made several small investments in this space (
A while back, I wrote about Anti-Workflow Apps -- apps that solve problems for you without forcing you to adopt a workflow that you may never fully be able to adopt. Workflow apps (CRMs, to-do lists, project management tools) are super hard to drive adoption towards, as everyone works differently and really resists this kind of change. (of course, it's possible when the reward is super good -- e.g., slack and git/github -- bit those times are rare and more often than that an attempted re-workflow goes splat) So I've been on the lookout for Anti-Workflow tools. Solutions that solve a problem that you think requires a new workflow, but may actually be more effectively solved another, more clever way Today I want to talk about to-dos, because I seem to have found my own personal anti-workflow solution. I've always struggled with to-dos -- I've used every to-do management tool on earth, and have never been able to adopt a workable, effective system. I've tried everything from complicated tracking systems like OmniFocus to simple to-do lists of every possible flavor. Nothing has stuck. For years and years, I kept trying, trying and trying again. In the end, I just gave up and said, fuck it, I'm not using a to-do list anymore. Not going to even try. What happened was that I ended up keeping track of my priorities in a totally different way -- a way that was actually more in tune with my existing workflows. One part of the solution was pretty obvious, and one was surprising. On the obvious side: the calendar. For things that I absolutely must do, and that require dedicated time, I just use my calendar. I'm in my calendar all day long, so it's the perfect place to block out time for important things. So now I set calendar entries for myself, to make sure I set aside time for things that need focus. The calendar is good for things I know I need to do, and that I know are important. What it's not good for is capturing notes, ideas, and small to dos, which often just need to be captured in the moment and prioritized & dealt with (or not) later. This is the use case that has always drawn me back to to-do apps, to no avail. In particular, the really bad thing about a to-do list for this use case is that all it does is make you feel guilty. Items get added to the list, and whether you really need to do them or not, you feel drawn to. And then when it doesn't happen the to-do list just becomes a giant pile of guilt that you do your best to ignore (that's what happens to me at least). That brings us to the less obvious solution. What I've found is that a great way to handle both the capture / prioritization issue and the guilt issue is to use a Sparkfile. Long time readers will know that this blog is named after my favorite idea from Steven Johnson's Where Good Ideas Come From: the "slow hunch" approach to developing ideas. Another idea from that book -- unearthed by studying epic thinkers of the past like Darwin and DaVinci -- is the Sparkfile: a long, running list of thoughts & ideas. Fragments that pile on one another over time. One way to cultivate the slow hunch is not only to keep a sparkfile (in addition to other kinds of journals), but to constantly pour back through it re-reading and reconsidering your previous thoughts, ideas and observations. Turns out that this is also a pretty good way to filter inbound ideas of things to do. Just add them to the spark file, continually review the list, and occasionally do things (immediately or via calendar), and then add new stuff to the top as you think of more things. No pressure -- and absolutely no expectation -- to do everything on the list or turn it into a perfect set of priorities. Just let the mind run, capturing as you go. For me, this idea ties back into anti-workflow because I've been keeping a personal blog/journal for about 7 years now. Which was in many ways a sparkfile, though it started out slightly more long form (starting with a private wordpress blog). The big revolution happened last fall, when I switched over to using Diaro. Diaro is a personal journal tool, with both a desktop web client as well as a mobile app. The mobile app is the key, as it makes it possible to really quickly jot down a thought -- as quickly as you'd do on a to-do app, or email, or notepad. So in the end, the solution to my to-do workflow was not to add a new to-do workflow. Rather, it was to extend the workflows I already had going, calendars and the sparkfile. Boy it feels good.
Photo: Rudy (Loïs) Pignot
I am in Paris this week for OuiShareFest, and spoke yesterday morning during the opening session. OuiShareFest is in its third year as a large international gathering of folks interested in the peer/collaborative/sharing/networked society, put on by the community organization OuiShare. The topic of this year's fest is "lost in transition", and the prevailing feeling from the community here is a growing concern about the relationship between peer economy platforms and participants, specifically regarding distribution of value, control, etc. This is not really a big surprise, given the huge financings and staggering valuations that many corporate platforms in this space are putting up. At the same time, the rise of the blockchain as an application platform has put a lot of people (ourselves at USV included) on to the possibility of a practical, functional alternative to centralized web services. So, whereas I gather that the tone of the first OuiShareFest in 2012 was unabashedly glowing about the peer economy in all its forms, this year's fest is much more pensive and reflective about the power dynamics built into web platforms, and in particular their relationship to established power in the form of capital investment. For my talk, I wanted to take this issue head on, place it in a historical perspective, and help people think practically about what might come next and how to get there. I'll give a condensed, annotated version of the talk here:
The title "venture capital vs community capital" is an intentionally provocative strawman. The point I want to make is that of course there is a natural tension here, but it's not a brand new dynamic, an either/or choice, or a zero-sum game. Rather, it's part of a recurring pattern that we can see dating back decades (if not much longer) in the history of technology. Viewed this historical lens, we can see the patterns of this cycle and use them to help us understand where the viable opportunities will be in this phase.
But first, I want to point out that the reason we're all here is that we believe in the power of networks -- of the connected society -- to expand knowledge, deliver economic opportunity and solve big problems (energy, health, education, etc) in ways that haven't been possible previously. Right before my talk at OuiShareFest, Robin Chase went on and made a compelling plea for us to come up networked, scalable solutions (both venture-backed and community-backed) to the biggest issues facing the planet today, her biggest one being climate change. I am a firm believer that this model will continue to have profound, deep impacts on how we live, how we work, how we learn, and what we make, and that we are still in the very early stages. But, as we become more and more familiar with this model, we're starting to pay more attention to the particular architecture of these networks, and the power dynamics built into them.
So, the problem that many in this space have identified is a growing concern about the imbalance of power between peer economy platforms and the participants they support, especially as the most mature platforms (Airbnb and Uber being the elephants in the room, but there will be many more) grow to be very large, wealthy and powerful companies. The problem is essentially one of trust. And specifically in the case of peer economy platforms and workers, it's about economics and control. One way to think about this is that as this space has matured, platforms have a tendency to "thicken" -- to do more, take more, and exert more control. So the question becomes, are participants here getting a fair deal, and do they have an appropriate amount of freedom and control? There is a growing sense that they may not be, and that alternative architectures need to be investigated. While this may feel scary to many observers of the space, especially those coming at this from a public interest perspective, we shouldn't be surprised to see this happen. Rather, this is what always happens as companies explore new spaces and establish profitable business models. So rather than look at this phenomenon simply as a brand new problem to be solved today, it's more useful to see it as yet another phase in a recurring cycle, that presents both known challenges and known opportunities. Looking back at the history of major tech platforms over the past 30 or so years, we can see this cycle turn (note: this is not intended to be exhaustive or complete):
(Note: the green boxes are companies, and the blue bubbles are "open" technologies like free software and open protocols -- i.e., venture capital and community capital, respectively) IBM and AT&T once had a monopoly on the PC and the telephone network, respectively, which was opened up by the PC clones and the modem going over-the-top of the telephone network (not to mention the government break-up of AT&T). Next, Microsoft had a lock on PC software through Windows and Office, and AOL (along w Prodigy, Compuserve, etc) had the online market locked down. This lasted until the proliferation of Linux and IP protocol stack, which poked a hole in Microsoft's desktop OS as well as AOL's walled garden, giving us the open internet. Then, on top of that newly open platform, today's leaders in web (Facebook, Google, Amazon, Twitter, etc) and mobile (Apple, Google, Xaomi) built their businesses. It's worth noting that, with the exception of Android, there hasn't been a really meaningful hole poked in the business positions staked out by this generation of companies (though there have been attempts, such as Diaspora for Facebook and Pump.io for Twitter) Finally, we're left with today's peer/sharing/collaborative economy marketplace platforms. These are the new, venture-backed companies staking out territory and building what will become the next generation of powerful incumbents. And while we have seen the beginnings of open protocols that directly challenge their power (like the La'Zooz ridesharing protocol), it's all very very early. So there's the pattern: tech companies build dominant market positions, then open technologies emerge which erode the the tech companies' lock on power (this is sometimes an organized rebellion against this corporate power, and is sometime more of a happy accident). These open technologies then in turn become the platform upon which the next generation of venture-backed companies is built. And so on and so on; rinse and repeat. So, all that is to say: this is not a new thing. And that seeing this as part of a pattern can help us understand what to make of it, and where the next opportunities could emerge.
Given this moment in the cycle -- where we have a small number of large and powerful platforms in some sectors, and a growing sense of discomfort about that power -- how might people who affect change go about doing it? In this section, I want to really stress the "how do you get there part" more than the "what might an alternative architecture look like" part. It's quite easy to imagine a "driver-owned uber" (as many people here have suggested) in its fully realized form, but it's much more difficult to think about how such a thing might come into being. The history of technology is strewn with failed attempts to replace closed/proprietary systems with open ones. Here, I'll point out four ideas that may be helpful in thinking about this:
“Convenience trumps just about everything” -- Steve O'Grady, analyst at Red Monk (link)
Today at OuiShareFest, Aral Balkan from Ind.ie talked about a major failure of the open source movement over the past several decades: to sacrifice short-term usability and experience for long-term (and abstract to most people) freedoms. He framed this problem as "respect for experience" and "respect for utility" (or something along those lines) as the two partner values along with respect for human rights. I would agree with that, and anyone following this space can note the failure of past attempts at open platforms that just weren't usable enough (for example: openID).
"The Lindy Effect is real. Disruption is rare. But it does exist and it is caused by non-linear changes in technology." -- Albert Wenger, USV (link)
My colleague Albert discusses the Lindy Effect: the idea that every day that a platform idea exists extends its expected overall lifespan. In other words, technologies and ideas have momentum -- the longer they're around the longer they'll stay around. It is possible to "disrupt" them, but that requires a profound, non-linear technology change. And even then, they don't just disappear overnight. For example, Microsoft has endured two decades of disruption from the web -- first against Windows as the dominant OS, and then against Office as the dominant productivity suite -- but it still alive and kicking. So the disruption that challenged Microsoft didn't put them out of business, but it did open up the market for many many many others to enter. Looking at today, Uber clearly isn't going anywhere, though "open" challenges to them could open up the market for others. To my mind the non-linear change in technology that has the greatest potential to challenge today's incumbent platforms is the Blockchain (and related decentralized technologies) that are in the process of externalizing data from web and mobile applications (more on that below).
"Your margin is my opportunity" -- Jeff Bezos
This profound idea is not new to the business world, but it's nevertheless instructive for new technologies looking to compete against the new incumbents. Along the lines of "convenience trumps everything", cost matters. For example, I met a blockchain entrepreneur/hacker recently who was incensed about the margin that Etsy takes on transactions (and to most people Etsy is about as fuzzy bunny as you can get as a large web platform).
"The first transaction in a block is a special transaction that starts a new coin owned by the creator of the block" -- Satoshi Nakamoto (link)
This is a line from the original Bitcoin white paper, and I include it to point out the importance of powerful incentives in deploying open technologies. There are two primary innovations in Bitcoin: 1) the distributed, open ledger; and 2) the financial incentive that drives participating computers to cooperate: mining bitcoins. To the extent that this incentive-to-cooperate model can be extended in other directions, we may be on to something big.
Given all of the above, here are a few things we're looking for at USV: Collaborative platforms in greenfield sectors To the first point about the value of networks (to society), there are many many important sectors still operating under inefficient bureaucratic hierarchical models, which are ripe to be re-architected in a network model (I'm thinking energy, health, education, and many others). I suspect that these sectors will be developed by "traditional" networks (e.g., venture-backed, centralized networks), as these have the ability to move the most quickly, to experiment with new models (failing often), and to help train sectors/cultures that a networked model is possible. Worker support services A major concern with the emerging power of web platforms (especially in the collaborative/sharing space) is worker power. We are already beginning to see platforms emerge to serve workers in this environment (e.g., SherpaShare, Coworker, Peers, the venerable Freelancers Union, etc) and will see many many more here. My belief is that "union 2.0" will be a platform, more than an organization, and its power will derive from the data leverage it's able to attain over the the platforms that employ its workers. Thin platforms One way to challenge "thick" platforms is to build "thin" platforms that do less, take less, and exert less control. We have invested in several of these (DuckDuckGo, compared to Google, Twitter, compared to Facebook, Sidecar compared to Lyft, etc) and are looking for more. Often times, "thin" also means decentralized in some way, pushing power, economics and control further out to the edge. New protocols Finally, new protocols that radically re-architect power, information and control. Inspired by Bitcoin and the blockchain, there is now tremendous energy in this space. It's early early days, but it does feel like this has the potential to become the next "open layer" that washes over the latest generation of big companies (see the diagram above) and cracks open the market even further. At USV, we've made several small investments in this space (
A while back, I wrote about Anti-Workflow Apps -- apps that solve problems for you without forcing you to adopt a workflow that you may never fully be able to adopt. Workflow apps (CRMs, to-do lists, project management tools) are super hard to drive adoption towards, as everyone works differently and really resists this kind of change. (of course, it's possible when the reward is super good -- e.g., slack and git/github -- bit those times are rare and more often than that an attempted re-workflow goes splat) So I've been on the lookout for Anti-Workflow tools. Solutions that solve a problem that you think requires a new workflow, but may actually be more effectively solved another, more clever way Today I want to talk about to-dos, because I seem to have found my own personal anti-workflow solution. I've always struggled with to-dos -- I've used every to-do management tool on earth, and have never been able to adopt a workable, effective system. I've tried everything from complicated tracking systems like OmniFocus to simple to-do lists of every possible flavor. Nothing has stuck. For years and years, I kept trying, trying and trying again. In the end, I just gave up and said, fuck it, I'm not using a to-do list anymore. Not going to even try. What happened was that I ended up keeping track of my priorities in a totally different way -- a way that was actually more in tune with my existing workflows. One part of the solution was pretty obvious, and one was surprising. On the obvious side: the calendar. For things that I absolutely must do, and that require dedicated time, I just use my calendar. I'm in my calendar all day long, so it's the perfect place to block out time for important things. So now I set calendar entries for myself, to make sure I set aside time for things that need focus. The calendar is good for things I know I need to do, and that I know are important. What it's not good for is capturing notes, ideas, and small to dos, which often just need to be captured in the moment and prioritized & dealt with (or not) later. This is the use case that has always drawn me back to to-do apps, to no avail. In particular, the really bad thing about a to-do list for this use case is that all it does is make you feel guilty. Items get added to the list, and whether you really need to do them or not, you feel drawn to. And then when it doesn't happen the to-do list just becomes a giant pile of guilt that you do your best to ignore (that's what happens to me at least). That brings us to the less obvious solution. What I've found is that a great way to handle both the capture / prioritization issue and the guilt issue is to use a Sparkfile. Long time readers will know that this blog is named after my favorite idea from Steven Johnson's Where Good Ideas Come From: the "slow hunch" approach to developing ideas. Another idea from that book -- unearthed by studying epic thinkers of the past like Darwin and DaVinci -- is the Sparkfile: a long, running list of thoughts & ideas. Fragments that pile on one another over time. One way to cultivate the slow hunch is not only to keep a sparkfile (in addition to other kinds of journals), but to constantly pour back through it re-reading and reconsidering your previous thoughts, ideas and observations. Turns out that this is also a pretty good way to filter inbound ideas of things to do. Just add them to the spark file, continually review the list, and occasionally do things (immediately or via calendar), and then add new stuff to the top as you think of more things. No pressure -- and absolutely no expectation -- to do everything on the list or turn it into a perfect set of priorities. Just let the mind run, capturing as you go. For me, this idea ties back into anti-workflow because I've been keeping a personal blog/journal for about 7 years now. Which was in many ways a sparkfile, though it started out slightly more long form (starting with a private wordpress blog). The big revolution happened last fall, when I switched over to using Diaro. Diaro is a personal journal tool, with both a desktop web client as well as a mobile app. The mobile app is the key, as it makes it possible to really quickly jot down a thought -- as quickly as you'd do on a to-do app, or email, or notepad. So in the end, the solution to my to-do workflow was not to add a new to-do workflow. Rather, it was to extend the workflows I already had going, calendars and the sparkfile. Boy it feels good.
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.
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.
Share Dialog
Share Dialog
Share Dialog
Share Dialog
Share Dialog
Share Dialog
