Brief background on the author

• been building consumer products since high school
• made a social application that grew to tens of millions of users
• Y Combinator S11

Lately, my goal has been to improve the health of democracy and bring about sound leadership in the US. The following is a case study in applying lessons learned from the startup world to this other domain. The exciting thing: it’s working! Despite the election being still five months away:

Thanks to the methods described below, there’s a product which is now exploding in adoption; we’ve raised $7 million in non-profit funding; some of the largest get out the vote programs in the country are going to be powered by this work; we just reinforced our engineering team with some extremely strong folks, and we’re hiring more engineers.

List of methods

I find it hard to learn just from specific examples or just from general statements. I love when the two are mixed together; let’s give that a shot here! The rest of this essay will examine the methods below by briefly describing them and then showing their concrete application:

1. Ask yourself: if the project were to succeed, would it be a big deal?
2. Establish a north-star metric
3. Set a large goal
4. Analyze bottlenecks to form a plan
5. Use momentum to get more momentum
6. Make your users happy

1. Ask yourself: If the project succeeded, would it be a big deal?

Generally

When examining a project, the first question I ask is: if it truly succeeds, how much does it matter? Try to imagine the largest plausible success case. In that case, how glad would you be to have worked on the project?

If the answer isn’t extremely obvious, you might have the wrong project. In technology, there’s a power law in outcomes, and so much of the expected value is driven by the “it worked crazily well” type of outcomes. If the great outcome isn’t that great, the project might not be a good choice.

Specifically

One of my goals was to get more people to vote. Because many possible methods of increasing turnout have been studied by random controlled trial ¹, it was actually possible to rank order the opportunities.

I read through most of the voter mobilization literature (much of it is only published to a limited audience on the progressive side) and compared marginal cost per vote across approaches. To my surprise, there were a couple of large gaps! (i.e, approaches that we knew worked well, but that we weren’t doing much of.)

One of the gaps was this thing called “relational organizing”, which is a fancy phrase for helping people step up by using their personal connections to get others more involved and voting.

A friend had connected me to an organization that had a software tool for this purpose (it was called ‘MyRVP’, for ‘My Relational Voter Program’. Not a great name — more on that later!).

With that organization, I engaged in a back-of-the-envelope calculation that was informed by their results from previous election cycles:

1. At the most, how many swing-state organizations could possibly be a good candidate for employing relational organization?
2. Per organization, how many volunteers would they get having conversations with their friends and family?
3. Per volunteer, how many people would they have conversations with?
4. Per person who was being talked to, how many would vote who otherwise would not?

Multiplying the above together, it was possible to arrive at a maximal number of gained counterfactual swing state votes (~100,000). How are we to know the value of those votes? It’s possible to estimate the rough odds that that many votes proves decisive in swinging the entire presidential election.

The takeaway: if things went extremely well, there was a rougly 1 in 50 chance that these efforts would swing the entire presidential election. That seems like a lot. Good sign.

This next step may strike many people as rather silly, but we can go even a bit further. Intuitions tend to break around smallish probabilities, so it would be nice to convert it into something more concrete.

What would the value be of a 100% chance of swinging the presidential? Well, in the case of Gore vs. Bush, we ended up with the Iraq war, which had a hard cost of at least $2 trillion (thanks to Robert Wiblin for this thought!). Elections seem to matter. In the case of Trump, let’s say there’s $4T in social value due to global warming policy alone, and not even bother adding in more for, you know, things like continuance of democracy, or sane leadership under crises.

A 1 in 50 shot of 4T = 80 billion dollars of social value. I felt comfortable: even if the calculations were off by two orders of magnitude, my time would have been well-spent.

At this point, I decided to help this particular organization. A bunch of factors went into the decision:

• the founder was willing to listen and to think big
• they had already grown a bunch from 2016 to 2018 despite having awful software that people hated using but used anyway (a strong sign they were serving a real need)
• their approach was the one that had actually been properly measured by random controlled trial
• their approach could scale up
• they actually knew how to run a relational organizing program; they weren’t just sitting in a room dreaming up a product and throwing it over the fence.
• they were very in touch with their users and had a great mindset around supporting them
• they had lots of connections to possible users
• some of the reasons they were being overlooked were irrational, e.g. they didn’t have much cachet compared to some of the other tools in the space.

2. Establish a north-star metric

Generally

Having a north-star metric can help you make all sorts of decisions, since it lets you ask yourself, “Which option seems like it would maximize the metric?”

Attributes of a good north-star metric:

• Measurable
• If it were low, it’d definitely mean you were doing badly
• If it were high, it’d be hard to picture how you could be doing badly

It’s important to keep Goodhardt’s law in mind; remember: the metric isn’t the actual thing you care about, it’s just a helpful heuristic guidepost. Don’t optimize for it at the expense of common sense.

Specifically

In this case, a natural metric was the endpoint in some of the controlled studies: the number of folks in swing states that volunteers manually added to their list of people to reach out to. It made sense to roughly weight this by the propensity-to-vote of the person that was being reached (i.e., you don’t get any points for talking to someone who we have reason to believe already plans to vote). It’s definitely an imperfect metric, but it’s serving for now:

• It’s measurable
• There’s no way we could be doing well if it were low
• If it were high, it’d be a strong sign that we’re doing well, but it is possible to imagine a situation where volunteers add people to their list and then never follow up with them. So, we want to make sure we don’t fall into an over-optimizing trap on account of this!

To be honest, we probably need some more work here: I think this metric isn’t quite right yet.

3. Set a big goal

Audacious goals seem to have have lots of positive effects. They help set the scale of your planning, and also seem to have lots of subtler effects. As is often said, even if you don’t reach your massive goal, you’ll often get further than if you’d set a smaller goal.

Remember the “How big could this plausibly get, at maximum?” question? I’d recommend taking the answer and adopting it as your goal.

4. Analyze bottlenecks to form a plan

Generally

When something isn’t happening yet (e.g., there isn’t yet a ton of relational organizing), there must be at least one critical bottleneck that is preventing it. In the event that a bottleneck seems unconquerable, it may mean that the problem is intractable. If all the bottlenecks seem tractable, then your plan can just consist of focusing on beating them!

This planning process is perhaps a bit contrary to some of YC’s early wisdom. In the original view, a heuristic was to just work on something that seems like an interesting toy or notion, as long as users like it. The hope was that the fact it was so easy to dismiss meant that it was more likely you were on to something that others had overlooked. That may work sometimes, but personally I hate the bit that relies on just crossing your fingers and hoping that it turns out that you’re onto something which can become a big deal. Executing against a plan also offers plenty of opportunity for serendipity, as long as you keep your eyes open.

Specifically

In the case of this project, we identified three bottlenecks that were preventing organizations from adopting and scaling relational organizing:

1. Product: the existing software was a buggy hairball with an arcane and confusing user interface that required a bunch of specific training in order to use. It was authored by a single part-time programmer over an 8 year period, and whenever he made changes, it tended to introduce bugs.

2. Training: implementing a relational organizing program properly requires lots of know-how and best practices — it’s not plug-and-play. There was a dearth of quality training; in the 2018 cycle, many organizations picked up the tool just a couple of months before the election, and didn’t know what they were doing.

3. Funding: implementing a relational organizing program requires a person to run the project, engage with volunteers, etc. Some of the best organizations to work with are in marginalized communities were fewer people vote; in those places, many of the organizations are too short of money to even afford the $500/mo the tool cost, much less a whole staffer to run a relational program.

With the bottlenecks identified, now it was just a matter of planning to solve them:

1. Product: rebuilding the product from scratch
2. Training: hire a team of trainers to coach organizations
3. Funding: converting ourselves to a non-profit and raising money to give away the tool for free and to offer grants to suitable organizations so they could afford to hire an organizer ².

In total, reaching the huge goal would require about $8.5 million and involve reaching about two million low/mid-propensity voters with repeated conversations from high-affinity friends and family.

This was going to have to be a big step up for an organization that had been scraping by on $60k/year for the previous 8 years, and who had reached 100k people in 2018.

5. Use momentum to get more momentum

Generally

What is momentum? Momentum is something good having happened recently. (More precisely: something good having happened in or over the last n days, where the size of the thing relative to the amount of time portrays an impressive trajectory.)

For example,

• “We just raised $y from $impressivePerson”
• “$impressiveOrganization just started using our tool”
• “$impressivePerson just joined our team”
• “Over the past $timeSpan we’ve been growing by $impressivePercentage”

Momentum is valuable because it can form a positive feedback loop: you can intentionally use your current momentum to create more momentum, repeatedly. Two caveats: It’s important though that you’re building momentum by actually executing on your plan — otherwise, you’ll just end up with hot air.

Personally, I don’t know how to build initial momentum other than to work really fucking hard. Lots of people seem to think you can do tons of great things without tons of hard work — maybe some people can, but if so I guess I’m not one of them.

Specifically

Now for the fun part. Ready?

Initially, MyRVP (as it was called at the time) did not have a lot of momentum:

• It had been running on a budget of $60k/yr for the past 8 years
• It had a reputation for being knowledgable about relational work, but the software was buggy and hard to use
• Few organizations were signed up to use it, and those were, were having second thoughts. Things were in fairly dire straits.

In order to generate momentum,…

1. I built new mobile apps from zero and launched them to the iOS and Android app stores in multiple languages in 14 days.
   • Users liked the new product a lot
   • We also now had a recent impressive fact (aka: momentum)! We told our users what had happened, and they now knew we could grow fast alongside them.
2. The plan required significant funding, and we didn’t have much. It was necessary to generate more momentum to prove to funders that this project was worthwhile. The best way to do this was to demonstrate need in the form of a list of organizations that needed funding. In order to do this, in the course of two weeks, we…
   • Converted ourselves to a non-profit and started offering the tool for free. (Note: this was in line with the plan, since cost was bottlenecking relational organizing!)
   • Rebranded from MyRVP to Empower so folks would take note of the new software
   • Announced the grant program (also in line with the plan)
   • Relaunched with all this at Netroots (a digital political tools conference)

3. Now that we were armed with a growing list of organizations that wanted the tool and a plan towards a big goal, it was time to fundraise. Conventional wisdom says that fundraising is so distracting that the person fundraising won’t be able to get anything else done, but it simply was not an option to stop other work: we needed to keep momentum going with users by launching new and improved parts of the product. The mobile apps were now decent, but people were still having an awful experience with the rest of the tool.

4. I did 100 hour weeks for two months straight in order to raise $1.5m from Bay Area political donors ³ whilst also building out the tool. This sucked. I find it very hard to switch between such tasks. It really sucked. But it worked, and now we had new momentum: “We just raised $1.5m” — and we could also actually give out grants to organizations! And hire more organizing trainers to meet the growing demand by organizations for the tool! It was an explosion of momentum along many dimensions.

5. Given this explosion of momentum along many dimensions, a super talented friend got excited about the project and came and helped with engineering full-time during a break from work…

6. And now the tool is better, and so more organizations came on board,…

7. And now that super talented friend gave a positive recommendation to another engineering friend, who came on board full-time…

8. And so on.

6. Make your users happy

Generally

Making your users happy is a (the?) sustainable way to grow. When they’re happy, they keep using it, and they also get other users on board. Making a user happy is itself a form of momentum. In general, your momentum had better be in service of making your users happy, or else it will all eventually go up in a puff of smoke. I’ve seen this happen in the political tech space ⁴!

To make your users happy:

1. Understand their needs
2. Quickly turn your product into something that meets those needs.

Or, as Paul Graham put it: you should spend all your time writing code and talking to users.

It doesn’t work well, in my view, to merely A/B test every change or somehow make all product decisions with quantitative data: the space of all possible changes is enormous, not all changes are amenable to tests, and product launches are necessarily sequential and path-dependent. But that doesn’t mean you have to rely on vague “intuition”: you can instead rely on a carefully calibrated mental model of your users and their needs which is informed by what your users are doing (or not doing) and saying (or not saying) ⁵.

Understanding users is only useful if you can make your product meet their needs by quickly advancing your product. Optimize hard for high product velocity.

Specifically

In the case of Empower, the initial mental model of our users came from extensive interviews with the existing organizing talent at the organization (Mike, Christian, Amanda!), and with some external interviews. As we’ve scaled up, our training team are in touch with our users continually, and talking with them has been a great way to understand needs.

Organizations that use Empower are pretty heterogenous, so it has been helpful to identify organizations that are prototypical of particular clusters of users (example clusters: “local group in marginalized community” or “national multi-state organization”)

Some of our choices to optimize hard for product velocity:

• We keep a high bar for engineering talent and code quality: compromising here can quickly turn a codebase into a mess in which it’s laborious to make changes and a high portion of time is spent fixing bugs ⁶.
  • In general, code is terrible no-good stuff. Try to get away with as little of it as possible.
• We share a bunch of typescript across our web client, our mobile client, and the server
• We keep the product focused by searching for patterns in needs of users and saying “no” a lot.
• We cut a tremendous amount of stuff from the old legacy product that might feel essential if you were zoomed in on it, but could be done without.
• We make multifactorial tradeoffs between technical debt, product design, launch times, etc — having one person who could hold as much of this in their head as possible has worked well (for now).

High product velocity combined with an understanding of users is magical. One organization told us that after they saw how their product feedback had led to a major design change, their organizers were so excited they cheered.

Once you meet a user’s needs, they’re now able now to do something they couldn’t before: they’ve entered a new realm, and they may now have new needs. This is good. One of my favorite emails I’ve gotten from an organization started, “The Empower app has provided a breakthrough for us in fully leveraging people’s existing networks that they have saved on their phones, but there is a set of capacities that Empower does not currently have that we need in order to run our program this year.” Good! We’ve met their needs and now they have additional ones. Their demands are a sign they care.

Where should we apply these methods?

These methods seem applicable across a wide range of domains. There’s power in your choice of where to apply them. In a healthy society, our best minds would be engaged in creating public goods⁷, not in getting people to click ads.

Current momentum and what’s next

At first, building momentum was like pushing a boulder up a hill; now, it’s crested and is rolling down faster and faster and we’re chasing after it as best we can.

• Since COVID-19, we’ve trained 2,700 organizers
• Several huge national organizations are using us or planning to; we may end up powering the largest organizing efforts in the nation outside of the Biden campaign (and possibly including it.)
• The Wisconsin State Democratic Party is moving all its 70 organizers into Empower
• We’ve raised $7 million
• Ultimately, it’s hard to predict how big this will get. There’s strong growth so far, but how things go depends on our execution and lots of unknowns about the world.

There are many valuable product advancements that we need to make quickly or we’ll be leaving too much potential on the table. Currently we have a product/eng team of three four five (just found another two fantastic people!). We’re looking to add another two or three senior generalist engineers very quickly, before we freeze hiring so everyone has time to ramp up.

Given our possible scale and the importance of this moment in our history, I’m confident that this is the most important work I’ve done so far, and it may prove the most important work I ever do. We’re hiring senior people for engineering — come join!

Footnotes