Our Recipe
In a recent post, I described discovery projects as one of the two types of projects that JSTOR Labs tends to work on. Discovery projects, sometimes called innovation projects, are projects where the goal is to create or find value in an idea. We’ve been doing them for many years now, making enough mistakes along the way that we’ve developed something of a repeatable and reliable process for them. Over the years, we’ve made many videos and given many, many presentations showcasing this process, but each one only hints at our methods: they’re an Instagram picture of a tasty-looking meal, not the detailed recipe for creating it. So, I’m pleased to announce that this post is the first in an “Our Recipe” series that will run throughout the summer. Each post will dive into a different step of the process, describing it in detail with examples and templates and everything else you might need to try this recipe in your own kitchen.
Credit where it’s due: most of these methods were invented by other, smarter people (at the end of this post is a brief bibliography of resources that we’ve found especially useful, and I wholeheartedly encourage you to dive into it. We merely encountered them, mostly from the design thinking and lean startup movements, and then adapted them for our specific context. There are so many ways in which this context has influenced this process, but I want to highlight a few key ones:
1- Research is personal. We make experimental tools for research and teaching, and as you’ll see in these posts part of our process for designing these tools is to show unfinished versions of them (aka prototypes) to prospective users. The thing is, research is very personal and field- or discipline-specific. We can show users pictures of a tool, or sample searches, but we won’t truly know whether an idea is working until people use it for their own research. For us, this means the live data prototype is incredibly important (a live data prototype is one where the back end, for example the JSTOR database, is real, not mocked-up).
2- JSTOR is big. We have the privilege of working with the incredibly rich corpus that is JSTOR, but its sheer size can make it difficult to get to the all-important live data prototype. We’ve responded in two ways. First, we’ve adjusted methods like “flash builds” (time-boxed efforts ending with working software) to have the data prepared in advance of rather than during these weeks. Second, we often focus our prototypes on a particular discipline, field or topic, in order to make it limit the scope of the live data we need to provide.
3- We’re a non-profit working with the academic community. Last, because we work in this specific community, we’ve emphasized the opportunities to conduct these discovery projects with partners wherever and however possible, and to share our findings and work as broadly as possible.
Over the forthcoming series of posts, you’ll see how these elements have informed our process, and perhaps consider the extent to which they might be relevant to you as well.
Before we get to that series of detailed posts, it may be helpful to describe the overarching process so that you can see the forest as well as the trees. Each project is unique, but at the highest level we’ve found this process to be repeatable and reliable:
1- Create the sandbox: Discovery projects, at least for us, seldom begin with a specific idea. Instead, they usually begin with a particular territory we want to explore. That territory could be a particular type of user, a particular problem that user faces, a new technology and the opportunities it might present, or a partner who brings with them content or capabilities that would be interesting to mash up with our content and capabilities.
2- Research and preparation: Once we’ve identified the territory we’re interested in, we explore it through user research and by “purposefully tinkering” with the relevant technology and data to understand their capabilities.
3- Ideation: Informed by this research, we generate as many possible solutions as possible in a very short period of time. This usually takes the form of a structured brainstorming workshop called a “design jam” (aka design studio, aka idea jam).
4- Select an approach: Design jams end with an exercise to identify the most promising ideas. We then test those competing concepts or ideas with users in order to settle on a single one to further explore. We do this with paper prototypes, or hand-drawn representations of an idea. Each paper prototype represents a different value proposition, which is a single statement that expresses how the tool or idea will benefit our target user.
5- Refine the approach: Once we have settled on a single concept, we will rapidly iterate on how exactly to implement it. Usually, we iterate on the product design very rapidly by user-testing a series of increasingly high-fidelity prototypes (a high-fidelity prototype is one that looks exactly like the proposed end product).
6- Release and measure: Once we have taken our concept as far as we’re able, we release the tool publicly, and then measure the impact and response, in order to further validate the idea or to help us find opportunities we hadn’t foreseen when building the tool.
In the coming series of posts, we’ll dig much deeper into each of these steps, with the goal being that by the end you’ll have the information and material you need to conduct your own discovery project. If there are particular topics or questions you’re interested in us addressing, please let us know!
Bibliography
Marty Cagan's Inspired: How to Create Tech Products Customers Love and blog
Alex Osterwalder's and Yves Pigneur's Business Model Generation and Value Proposition Design
Eric Ries' Lean Startup
Dave Gray's Gamestorming
Ash Maurya's Running Lean and Scaling Lean
Jake Knapp's Sprint