Creating the Sandbox

Our Process

Creating the Sandbox

This is the second in a series of blog posts about the process JSTOR Labs uses for its Discovery Projects. You can read the introductory post about the process here, and learn about discovery projects here.

Let’s say you’re an explorer, about to set sail for uncharted lands. What do you know about the territory that you will map? Nearly nothing: perhaps there have been rumors that “there be dragons,” but if it were charted and known, why bother exploring? By definition, an explorer cannot know what she will discover. And yet, she still has to set a direction for her crew.

That’s the challenge that the JSTOR Labs team faces every time we begin one of our discovery projects. The purpose of these efforts is to learn, we can’t know in advance what we will learn or else why bother with the project; and yet, we still need to direct our efforts enough to be fruitful. After all, it wouldn‘t be valuable for an explorer to chart known territory. (“I’ve discovered London!” says Henry Hudson.) Explorers would have a compass point to follow. When JSTOR Labs begins a new project, how do we direct our efforts and still manage to not end up discovering London?

Let’s start with what we DON’T do: we hardly ever start with an “idea,” or a theoretical innovation or solution to bring to some set of users or customers. This is a common misconception -- people think they need an idea before they start a discovery project. You don’t! In fact, it’s often better NOT to have any kind of potential solution, since that can help you be more open to opportunities you encounter along the way. If you do happen to have an idea before you begin, that’s fine, you just need to be very careful to truly open yourself up to learning, and not just seeking to affirm your own assumptions and biases.

If not an idea, what do we start with? After all, we don’t start our projects open to any innovation from an improved preprint service to a nuclear toaster. For us, things usually begin with at least one and often a combination of three or four of the following:

-A user. This is the easiest, and perhaps most important, place to start: identifying the person you’re trying to help. This identification should be as specific as possible. For us, it simply wouldn’t do to say “people conducting research” or “students,” since those categories are wayyyy too broad. Instead, we often add at least a discipline and often an experience level to it. Some example users that JSTOR Labs has targeted: “Shakespeare scholars,” “public health undergraduates,” or “academic or academic-adjacent people researching the cultural history of baseball.”

-A use case. This is often paired with the user: the specific thing the user is doing that we want to explore. For example, “Shakespeare scholars going between the plays and the scholarship about those plays” or “teachers identifying readings for their class.” Focusing on a specific action or need makes the conversations with users a bit more targeted and grounded, which can be helpful. (We’ll talk about these conversations in a future post.)

-A problem. Best when paired with the user. For example, “it’s annoying for readers having to pan and zoom to read large PDF page scans on a small phone screen,” or “it can be hard for scholars doing multidisciplinary research because they lack the foundation of language and canonical articles that define a new field.” I would be careful when the problem you’re exploring ISN’T tied to a user -- for example, “creating this widget for those people is too expensive for us.” Those problems can be important too, but we find it can be more motivating and impactful to keep the focus on the people we’re serving, not us.

-An opportunity. Sometimes, an opportunity presents itself and needs to be explored. This can be a new use for something that already exists, or it can be a new asset to leverage. For example, on the Zambezi project, we looked at JSTOR Global Plants material for an audience outside of the taxonomists who normally use the site. Similarly, with the Interview Archive, we started with permission to use the full-length interviews from the King in the Wilderness documentary for educational purposes.

-A technology. This might be better viewed as a subcategory of “opportunity.” Technology can be a tremendous enabler, and we often start projects either with a hypothesis that a technology could be helpful in a particular area, or with the express purpose to explore the potential of some new technology. Examples we have used include: topic modeling, image matching, and linked open data.

-A partner. Partnering on a discovery project can be incredibly energizing. Partners bring new perspectives as well as capabilities and assets that you might not have. They are an important enough part of the way that we set up discovery projects that it’s worth busting out of this bulleted list and into a full-blown section called:

Developing Partners for Discovery Projects

For discovery projects, we seek open, exploratory and collaborative partnerships. These are not the kinds of contractual relationships wherein both sides enumerate precisely who will deliver what and when. Instead, it’s more like a play date: you bring your toys, we’ll bring ours, and let’s go play together in that sandbox and see what happens. Let’s break that down:

-You bring your toys; we’ll bring ours. It’s best when both sides of a partnership are bringing something to the table that the other side doesn’t have. For us, the JSTOR Labs team usually brings itself, a development team, along with access to the rich corpus of material in JSTOR. Our partners have brought: new content (such as the Folger Shakespeare plays), APIs and developers (such as the Eigenfactor API), access to the target users (either via a society or a library) or some combination of these.

-Play together. These projects are exploratory, and it has to be okay to not find something. Approaching this as play can lower the fear of failure, and make it easier to be creative.

-In that sandbox. The above bulleted list for how to define the area to explore.

-See what happens. Each side of the collaboration needs not only to bring something but hope to get something out of the exploration.

One benefit of partnerships with discovery project is the limited scope -- these are not perpetual relationships, they are limited in time and risk. They’re not a marriage, they’re a date. As such, it can be a really great way to explore a potential more long term partnership.

I should flag that developing these partnerships and defining the “sandbox” for a discovery project does not happen quickly. It takes time, intentionality and many conversations to define a direction that will truly help your team of explorers as they set sail.