Overview

Motivation

Outside of specific domains like healthcare, “transition” is a key weakness of the ARPA model, and  research programs more generally. There are many factors that go into why so many technologies die when they transition between organizations, but a big overarching theme is “building something that nobody wants.”

Design decisions early in a technology’s lifetime have profound effects on its ability to be something that somebody wants and survive beyond the R&D cocoon. Small differences can have a huge impact on its ability to interface with existing technologies or be useful in an early application.

Figuring out what these differences need to be depends both on a strong hypothesis about what is going to happen at the end of the program and a deep understanding of what the technology actually needs to do in that situation.

Furthermore, a technology’s ability to transition is sometimes a function of long preparation for multiple parties. A team of researchers who reach the end of a project and say “ok! Let’s become a startup now!” will often fail. A big organization needs time to wrap their head around a new technology (especially if it is a different paradigm) and often wants specific proof-points that aren’t obvious or derivable. Even if it’s something that would drastically help their business, you often can’t just show up with a brand-new technology and expect them to absorb it with open arms.

We believe that strong answers to the questions “who cares?” and “what happens after the program ends?” are critical for a program’s success. “Who cares?” is subtle — it’s more like “who will care when the program is completed” or “who should care”. Another framing is “what is the technology’s serious context of use?”

Outside of the situation where the answer is “me, in a past life” figuring out the answer to this question is a hard job very similar to customer discovery in a startup: it requires talking to a lot of people, reading between the lines, constantly pounding the digital pavement, and shrugging off rejection.

This job exists because:

  1. Keeping up with what a wide range of external organizations need (especially beyond what they explicitly) is a hard, full-time job.
  2. Many program managers don’t come into the role with “customer discovery” skillsets. I suspect that having someone to both help and push them critically on that front is important.
  3. Figuring out “who cares?” And “what happens after the program” is one of the hardest parts of designing a program and having a second head pushing on answers and trying to find new ones is incredibly important.
  4. I don’t have the bandwidth to do that, especially for multiple PMs.

What you’ll do

Here’s a sketch of what the role will entail:

Spend a lot of time building relationships with decision-makers at organizations who might provide homes or support for our technologies after programs end: these could range from large companies to government organizations to large foundations. Understand what problems these people are facing that our programs could potentially solve and