Experience ↔ Design ↔ Policy

People often ask me how I ended up working in venture capital, and more specifically in a role that deals with policy issues ("policy" broadly speaking, including public policy, legal, "trust & safety", content & community policy, etc.).  Coming from a background as a hacker / entrepreneur with an urban planning degree, how I ended up here can be a little bit puzzling. The way I like to describe it is this: From the beginning, I've been fascinated with the "experience" of things -- the way things feel.  Things meaning products, places, experiences etc.  I've always been super attuned to the details that make something "feel great", and I'd say the overriding theme through everything I've done is the pursuit of the root cause of "great experiences". From there, I naturally have been drawn to design: the physical construction of things.  I love to make and hack, and I geek out over the minor design details of lots of things, whether that's the seam placement on a car's body panels, or the design of a crosswalk, or the entrance to a building, or the buttery UI of an app.  Design is the place where people meet experience. But over time, I came to realize something else: what we design and how we design it is not an island unto itself.  It's shaped -- and enabled, and often constrained -- by the rules and policies that underly the design fabric.  That's true for cars, parks, buildings, cities, websites, apps, social networks, and the internet.  The underlying policy is the infrastructure upon which everything is built. This first really hit me, right after college (16 years ago now), when I was reading Cities Back from the Edge: New Life for Downtown, a book chronicling the revitalization of many smaller downtowns across America, written by my old friend Norman Mintz.  Before I started the book, my main thinking was: "I want to be an architect, because architects design places".  Norman had told me "you don't want to be an architect."  But I didn't believe him.  But I distinctly remember, about halfway through the book, having an a-ha moment, where I scrawled in the margin: "I don't want to be an architect!  I want to do this!".  Where this was engaging in the planning and community engagement process that ultimately shaped the design.  It hit me that this is where the really transformative decisions happened. I spent the next three years at Project for Public Spaces, working on the design of public spaces across the US (including Times Square and Washington Square Park in NYC), with an emphasis on the community process that shaped the policies, that would shape the design, that would determine the experience.  The goal was all about experience, but the guiding philosophy at PPS was that you got to great experience by engaging at the people/community/policy level, and letting the design grow from there. Being a hacker and builder, I've always been drawn to computers and the internet.  During my 6 years leading the "labs" group at OpenPlans, a now-shuttered incubator for software and media businesses at the intersection of cities, data, and policy, I made a similar journey -- from experience, to design, to policy -- but this time focused on tech & data policy and the underpinnings of that other world we inhabit: the Internet.  I started out building product -- head in the code, focused on the details -- and emerged focusing on issues like open data policy, open standards, and how we achieve an open, accessible, permissionless environment for innovation.  The most satisfying achievement at OpenPlans was working with NYC's MTA (which operates the buses and subways) to overhaul their data access policies, and then helping to build the cities first real-time transit API. So the common thread is: great places (physical AND virtual) are a joy and a pleasure to inhabit.  Creating them and cultivating them is an art, more than a science, and is a result of the Experience ↔ Design ↔ Policy dynamic. To apply this idea a little further to the web/tech world: I think of the "policy" layer as including public policy issues (like copyright law or telecom policy) which affect the entire ecosystem, but also -- and often, more importantly -- internal policy issues, like a company's mission/values, community policies, data/privacy policies, API policies, relationship to adjacent open source communities, etc.  These are the foundation upon which a company (or community, in the case of a cryptocurrency) are built, and the more thoughtfully and purposefully designed these are, the easier time the company/community will have in making hard decisions down the road. So if you think of companies like Kickstarter, or Etsy, or DuckDuckGo (all USV portfolio companies), they've invested considerable effort into their policy foundations. But it's not just "feel good" or "fuzzy bunny", mission-driven companies that this applies to.  USV portfolio company Cloudflare announced yesterday that they've been fighting a National Security Letter from the FBI, under gag order, since 2013, in order to protect their users' data, reinforcing their longstanding commitment to their users.  This **very hard** decision was borne directly from the hard work they did at the founding of the company, to ground their activities (and the subsequent design of their product, and the experience they provide to their users) in foundational policy decisions. Or look at all the trouble that Twitter has been having recently combating the abuse problem.  Or Facebook with the fake news problem.  Policy in the spotlight, with a huge impact on product, design and experience. Or look at the internal turmoil with the Bitcoin and Ethereum communities over the past 12 months as they've dealt with very difficult technical / political decisions.  Lucky for us, there is so much innovation in this space, and every new cryptocurrency that launches is learning from these examples -- take Tezos, an emerging cryptocurrency that explicitly ships with mechanisms to handle future governance issues (democracy, coded). So I guess the purpose of this post is to draw that through line, from Experience, to Design, to Policy, and show how it actually shapes nearly everything we encounter every day.  What a profound and exciting challenge.  


Beam should have a hardware API

We've got a few Beam telepresence robots at USV, and use them all the time.  Fred has written about them here.  We had a team meeting today, and we had two beams going at once -- Fred and I were the first to arrive, and we were chatting beam-to-beam -- he in LAUtah, me in Boston, both of us in NYC by robot:

Talking beam-to-beam w @fredwilson - him in LA, me in Boston, talking in the USV office in NYC pic.twitter.com/1ma4RGMsFD

— Nick Grossman (@nickgrossman) January 13, 2016

It works amazingly well.  It has now become somewhat normal for robots to be roving around the office, having conversations w people, USV team folks and visitors alike. One idea that keeps coming up is an extensible peripherals API -- the Beam robots already come w a USB port (used for initial setup), and it should be possible to use that to extend it with hardware.  We joke about jousting (and have done some), but I could seriously imagine bolting on devices such as additional displays / LCDs, sensors of various kinds, devices that can perform human-like gestures (the way the Kubi can nod, shake and bow), etc. Thinking of Beam as a platform in this way would certainly extend its capabilities (in particular for industry), and would also position Beam in a much stronger position at the center of an ecosystem.  Would love to see that happen.


The Blockchain as verified public timestamps

Two weeks ago at USV's annual CEO Summit, Muneeb Ali from OneName explained the blockchain in a way I hadn't heard before, and which I thought was really helpful: the blockchain is time. That's a somewhat abstract way of saying it, so more concretely we could say that: The blockchain is database of verified public timestamps. Every bitcoin transaction is kept in a public ledger, and that ledger is verified and maintained by all of the computers participating in the Bitcoin network.  This "chain" of transactions is known as the blockchain, and each transaction is essentially a public timestamp that can contain data. The key aspects of the blockchain's timestamps are: decentralized (no one entity controls the database of timestamps, and everyone in the network confirms that timestamp has happened -- this is "mining"), immutable (once a timestamp has been verified and recorded, you can't un-do it), public (all of the timestamps are publicly visible, though some aspects of the data are encrypted), and programmable (you can write code against the blockchain -- for example, triggering some sort of action based on the details of a "smart contract" embedded in a timestamp). Importantly, each of those timestamps contains a packet of data which can hold lots of things: details about a financial transaction, details about a contract between two or more parties, a hashed version of almost any document, etc. One way I've described this is similar to the way people used to use postmarked envelopes to verify that something had happened at a certain time.  For example, signing a will and putting it in an envelope, and mailing it to yourself -- the post office's postmark on the envelope, which has the date of the stamp, proves that whatever was put in the envelope was done so before the date of the stamp.  IIRC, more than once, a mystery on Colombo was resolved using this technique, where a witness dramatically unseals a postmarked envelope before the judge. The blockchain is essentially a digital, public, programmable version of that.  Which we've never had before. Previously, every app kept its own notion of time. So if I post something on Facebook, Facebook saves that post and timestamps it.  We have to trust them to get that right, and not to change it ever in the future.  This is fine for cat photos, but less fine for a financial transaction, or a deed to a house. Here's that same idea in diagram form:

So in some sense, the Blockchain is a public database -- it has the effect of moving data that was previously kept within the walls of one or more apps out into a shared public database.   But to get a little more specific, it's really a public database of timestamps -- a new ability for anyone to state, publicly and immutably, that a certain thing happened at a certain time. Maybe that is obvious to folks who have been working in this space for a while, but I found it to be a really helpful way of thinking about things -- and of explaining it to people who are new to the idea.  Thanks Muneeb!


The more things change...

Here's a slide from 2009, when we were convincing transit agencies to open up their data, and then later building MTA BusTIme:

  And here's one from yesterday, from a talk I gave at the Shift Conference (blog post to follow w more on that):

Screen Shot 2015-06-13 at 2.56.20 PM



Anti-workflow apps

"Workflow" apps hold so much promise.  Whether it's a CRM, project management tool, to-do list, or some other tool, the promise in each case is to clean up our messy lives and help us be more organized and effective. The problem, though, is that getting people to adopt a workflow is really really hard.  That's why there are so many to-do apps out there, each one with a slightly different user experience, and none of them "just quite right" for everyone.  Workflow apps are like Goldilocks' porridge.  Everyone is a little different, and it's hard to get people to change. A solution, then, is to take the "anti-workflow" approach.  Make me more productive without shoehorning me into a new workflow. For example, Zander has been building a side project called Ansatz, which is the "anti-CRM".  All you do is auth it into your email, and it builds intelligence your whole team can use, about who you know and how well.  It's a CRM with out the CRM. And yesterday, I found out about Taco, which is the "anti-ToDo" app -- gives you a handle on all of the things you need to do (as defined by starred emails, github tasks, zendesk tickets, etc), and puts it right where you want it: on the Chrome new tab screen (side note: Taco should merge with Momentum, which I love).  So now, I can track and prioritize what I need to work on, without having to adopt a to-do routine that I'm guaranteed not to stick to.  Already, using this has helped me manage my inbox, as I know that I can archive starred emails knowing they'll show up in my todo list, where I can prioritize them and work on them later when I have time. Both of these examples build on perhaps the biggest productivity treasure trove: the inbox.  For a long time, I've wondered why we don't see more and better email analytics tools (Rapportive was one of my favorites).  My inbox knows pretty much everything about me, and it's really poorly organized.   Maybe it's because entrepreneurs are afraid of Google Inbox (I suppose I would be). Regardless, it seems to me that there are countless ways to help me make my inbox more meaningful to me, and nearly all of them can accomplish that with an anti-workflow approach, which is a winning one IMHO.


The Indie Web

Last night at USV, we hosted the latest of several recent meetups on the “Peer Economy”.  We are in the process of organizing a number of companies and organizations that represent a certain sector of the internet economy in NYC, with an eye towards building a more formal coalition (perhaps in the model of San Francisco’s BayShare) at some point in the future. As is to be expected, we spent the bulk of the discussion trying to figure out what it is, exactly, that ties us all together.   I think there’s a pretty strong thread, but it’s not immediately clear how best to describe it.  So I hereby invite you, the Internet, into the conversation. So, as a thought experiment, how might you describe the common approaches and values between:

At USV, we have a word for all of this, which is simply “networks”.  That’s great and effective as an investment thesis, but it’s actually rather abstract as way of communicating the idea widely.  In Steven Johnson’s recent book Future Perfect, he uses the term “peer network”, which is better but still somewhat problematic (as peer means “pier” to most people and “napster” to others).  And our working description, as you can see, is “peer economy”. Anyway, rather than try to “draw a box” around all of this — we instead attempted to (at Matt Brimer’s suggestion) focus on the center — on the core opportunities, values, and methods that all of these communities believe in and operate around. The ones that stood out to me the most were:

  • valuing creativity, self expression & individualism;

  • increasing personal freedom through community support;

  • creating economic empowerment;

  • valuing authenticity and real human connection;

  • built on trust (as developed within each community);

  • and perhaps my favorite: Andrew Wagner’s “as New York as a slice of pizza”

In my world, I focus a lot on words like “innovation” and “networks” — but I think the thing that really stood out to me about last night’s conversation was the centrality of the human component.  Empowering “real people” to do new and awesome things.  To access new economic opportunities for themselves, while at the same time rediscovering community. The idea that stuck in my head last night is about the “Indie Web” — what’s so interesting about the web and the networks of people on it is that they are at the same time individual & independent AND hyper-connected.  The fact that we’re connected lets us be independent.  It’s almost a paradox. I like the idea that the web makes it possible to be an indie musician, dj or filmmaker, to be an indie craftsperson or manufacturer, an indie journalist, publisher, or even an indie scientist. And what makes most (if not all) of this possible is the ability to be an indie entrepreneur, whether that’s through an open source project, a meetup, a web app, or even a venture-backed company (which is, admittedly, a certain flavor of “indie”).   The point is, that on an open web, we have the unfettered ability to make new things that enable people to do new things.  Which is pretty awesome and exciting.


We Heart WiFi

Today at SXSW, we are launching a Wi-Fi network + advocacy campaign called We Heart WiFi.  Fred and Albert both have posts up about it this morning. Over the coming weekend, folks at SXSW will be able to hop on to one of our free “Super Wi-Fi” hotspots.  The “super” part is that each of these hotspots is connected to the internet backbone not by cable, but by another high-speed wireless link, operating in the “open” or “unlicensed” frequencies (meaning that anyone who wants to can use them).  These link back to a gigabit fiber connection (which is apparently higher bandwidth than the official sxsw WiFi network). The point we’re trying to make is that awesome things are possible when we open up our airwaves for innovation.  “Open spectrum” — or sections of our “wireless real estate” that anyone can build in, is a huge economic driver.   The fact that any person or company can build equipment (chips, laptops, phones, washing machines) and networks that run in open frequencies leads directly to massive innovation and broad choice. I like to think of it as a sky full of lego blocks:


The reason this is interesting is that the bulk of our airwaves are reserved for exclusive use — either by government actors, or by corporations (like AT&T and Verizon) that have purchased the rights from the government. We do this to encourage investment in infrastructure (by granting a monopoly), to avoid interference, and to raise money for the government (through up front fees). Of all of these reasons the last one is the most troubling — as we are consistently tempted to sell out our future to bring in some cash now. Part of our job — and I still don’t think we’ve done it well enough yet — is to make it really clear how massive the opportunity in the open approach is.  The same way that there are game changing dynamics in open systems like Wikipedia, Firefox and Android.  There is still more to be done there, and I’ll do some follow up posts on that. So for now: if you’re in Austin, please enjoy some Super WiFi on us.  If you’re watching from home, please join in with call to support the FCC in opening up more spectrum for innovation.


FlightCar - a Beachhead for Car Sharing

Despite the extent to which I talk and think about car sharing and other newly possible. web-enabled modes of transportation, the truth is I still don’t use too many of them on a regular basis.  Need to work on that.

It seems as though I need to travel to SF to get the urge to get around town in new ways.  A few months ago, I tried out Scoot’s new battery-powered short-term scooter rental service, which was really fun (and will get much better as battery life improves).

This week, I tried a new one: FlightCar.  FlightCar is a peer-to-peer car sharing service, not unlike RelayRides, Getaround, or Buzzcar.  The twist is that it’s all based around airport trips.  Here’s the idea:

Every day, thousands of people drive to their local airport and park their car in long term parking before they head out of town.  At the exact same time, thousands of people are arriving at that same airport — and guess what, lots of them need cars. Add a little web-based matchmaking, booking, and logistics, and there you go. 

What I like about this approach is that it builds on behavior that people are doing anyway — dropping off and picking up cars at airports.  It’s not a huge stretch to go from there to peer-to-peer renting, especially if the whole experience is really seamless.  There is something about that arrangement that helps overcome the awkwardness that is a factor in lots of peer-to-peer businesses.  Maybe airports is the perfect beachhead for entering the peer-to-peer car sharing business (or maybe not; we’ll see…).

My experience with FlightCar was pretty good.  The online booking was really easy, just like renting a normal car, but with the added bonus of getting to pick out the exact car you’ll be driving (I chose a 1999 Audi A4 with a stick-shift — not a car you’re often likely to rent; my second choice was a mazda miata).

A FlightCar valet met me at the baggage claim (after a bit of wrangling since I was 2 hours early and we were waiting in the wrong place) - I dropped the valet and signed the paperwork, and then Brad, Albert and I set out on our way.

I gotta say, I actually liked it a lot — just like you feel more like a local when you stay in an Airbnb apartment, there is something different about driving a “real” car when you’re traveling.  In this case, it’s a car I’ve always liked, and I don’t get a chance to drive stick that often, so it was definitely more fun than my typical rental.

FlightCar is still working out the kinks in the service, there are a few rough edges in the pick up / drop off experience that they’ re still working out, in this case the car wasn’t washed and was out of gas when I picked it up.  The former will continue to improve I’m sure, and the latter was likely a function of my showing up early.

I feel like with all of these peer-to-peer services, there’s an initial hump you need to get over before you can participate at all.  Something to get you past the “whoa that’s kind of weird” moment that many people have as their first reaction.  Like Airbnb did with their “crash the inauguration” website around the 2009 inauguration.

In this case, I thought FlightCar did a good job of doing that for me.


WebFWD: Accelerating a Better Internet

I’ve always loved Mozilla's mission and tactics - using awesome consumer products as the lever to make the web a better place to be. That’s why I’m happy to join their WebFWD accelerator program as a scout.  That just means that I’m one of many folks who are on the lookout for products and companies that would be a good fit for the WebFWD program. WebFWD is a slightly different kind of accelerator — it’s not a full-court-press in-person bootcamp, and it doesn’t take an equity stake for participation.  The idea is to give promising projects that advance the mozilla mission that extra boost they need to become real (or even more real). WebFWD recently graduated its second class, and has just welcomed its third.  You can see the whole list of projects and companies in the WebFWD family here. Here’s to the continued development of products and businesses that promote openness, innovation & opportunity on the Web.


Design, Policy and Infrastructure for Great Experiences

I consider myself an accidental policy person. In other words: I didn’t set out to study and understand how our policy decisions impact the world we live in.  Rather, I came at it from the perspective of design and experience (both real world and virtual) and ended up backing into the policy implications, almost my accident. This was the case both in my early career when I worked in city planning and in my more recent career in technology. When I first started studying cities, my core interest was at the design level.  What makes one building “feel” better than another?  Why are some streets nice to walk along and others aren’t?  What makes one neighborhood feel comfortable, intimate and vibrant, and another cold, lifeless and isolating? My initial idea was: well, they are just designed better.  As if any one person (an architect, say) had the power and vision to create a place that felt a certain way and that fostered certain kinds of activities.  So I studied architecture and urban design. What I ultimately learned was: good design is an important part of the mix, but it’s hardly enough.  Given any physical place, what it “feels” like is as much a result of the policy, political and historical contexts as it is a result of the design itself.   And: it takes a whole lot of effort to align the various forces present in any project in such a way that something interesting and wonderful can happen.  Take any great place, and there is no doubt a history of high drama behind how it got hat way.  For instance, the streets of NYC are nicer to walk around these days because lots of people fought hard to make them that way.  It takes big balls and political toughness to make these kinds of things happen. It’s the same way with technology and the internet. I was drawn into tech from the design side — I liked to design websites and build applications that looked good, felt good, and created a nice experiences.  But yet again, that was just the entry point for drawing me — unwittingly at first — into conversations about things like web standards, open data, network architecture, copyright, patents, privacy, and spectrum policy. It’s easy to look at the things we like on the internet: wikipedia, twitter, kickstarter, etc etc etc, and assume that they are the result of good design alone; and clearly they are the product of tremendous design effort. But they are also able to exist because of the infrastructure — both technical and legal — they’re built on. Clearly I am drawing on my internet centrism here by using cities and the internet as examples, but that’s just what I think about.  I’m sure you could look at other fields and tease out similar connections between design, experience and the underlying policies and infrastructure that make them possible. Anyway, I guess what I’m saying is that it’s important for us not to take for granted what we have, to try and understand what it really is that makes things great, and to get upset when we feel like we’re going down the wrong path.