A description of the stepwise process JSTOR Labs takes developing horizon-2 and horizon-3 opportunities, with emphasis on speeding up iteration cycles and using user-feedback for rapid learning.

1. BUILDING YOUR NEXT
GREAT PRODUCT
BY TALKING TO USERS
EACH STEP OF THE WAY
11 October 2016
Alex Humphreys, JSTOR Labs
@abhumphreys
SSP Webinar 2016

2. JSTOR is a not-for-profit
digital library of academic
journals, books, and primary
sources.
Ithaka S+R is a not-for-profit
research and consulting service
that helps academic, cultural,
and publishing communities
thrive in the digital
environment.
Portico is a not-for-profit
preservation service for digital
publications, including
electronic journals, books, and
historical collections.
ITHAKA is a not-for-profit organization that helps the academic
community use digital technologies to preserve the scholarly record
and to advance research and teaching in sustainable ways.

3. JSTOR Labs works with partner publishers, libraries and
labs to create tools for researchers, teachers and students
that are immediately useful – and a little bit magical.

4. THE TROUBLE WITH
H2 & H3 INNOVATION
Horizon 1 Horizons 2 & 3
• Horizon 1 = core business
• Innovation usually seeks
operational efficiencies
• You know the market, the
product, etc.
• You can make reasonable
predictions about both
cost to develop and how
market will react
• Horizons 2 & 3 = new
products, new markets &
new businesses
• “If you build it, they will
come.”
• You don’t even know what
“it” is
• Or who “they” are
Horizons framework:
https://paul4innovating.com/2010/09/10/the-three-horizon-approach-to-innovation/

5. Q: If H2 and H3 are so uncertain,
how do you find your way to a
sustainable new product or business?
The Design Squiggle, by Damien Newman:
http://cargocollective.com/central/The-Design-Squiggle/

6. A: Lots of short iterations + lots of
user feedback = speeding up the
learning cycle
Innovation isn’t one big “Eureka,”
it’s a thousand little ones.

7. HERE’S HOW
JSTOR LABS
DOES IT
1. Create the sandbox
2. Research
3. Design jam
4. Select an approach
5. Refine approach
6. Release & measure

8. 1. CREATE THE
SANDBOX
• Some combination of partner,
target user and new
technology/approach
• This is usually not the same as the
“idea”
Case study: Understanding Shakespeare
• Partnership with Folger Shakespeare Library
• We were interested in finding ways to link their full text plays with
the scholarship on JSTOR

9. 2. RESEARCH • User research & technical
exploration
• Understand users’ context,
language, etc.
• What does success look like for
them? What stands in their way?
• Entire team joins user research
• What stands in the way of that
success?
Case study: Understanding Shakespeare
• User research:
- Skype interviews w/ 5-7 Shakespeare scholars
• Technical exploration:
- linking based on citation (FAIL)
- fuzzy-text matching of quotations (SUCCESS!)

10. Ok, honestly? This
persona was from a
different project but it
gives an idea what kind
of info we seek at this
early stage.

11. 3. DESIGN JAM • Informed by user research
• Diverse participants
• Brainstorm as many approaches
as possible
• (8 sketches in 8 minutes) x 2
• Not constrained by feasibility
Case study: Understanding Shakespeare
• Design jam held at Folger
Shakespeare Library on Day 1 of a
week-long “flash build”

12. This agenda was from
yet another project, but
shows the kind of
“serious fun” that leads
to a good design jam.

13. 4. SELECT AN
APPROACH
• Create paper, low-fi or hi-fi
prototypes of product concepts
• Test with target users to find
most compelling concepts
Case study: Understanding Shakespeare
• 3 user-tests conducted on Days 1 & 2 of flash-build

14. A paper prototype for
Understanding
Shakespeare.
Create enough screens
to test the “big
concept.”

15. A low-fi prototype for
Understanding
Shakespeare.
Used to test multiple
approaches to the same
idea.

16. 5. REFINE
APPROACH
• Refine approach with ongoing
user testing
• Bring in live data, working
infrastructure
• The prototype is created
primarily as a learning tool
Case study: Understanding Shakespeare
• 2 user-tests conducted each day on Days 3 and 4 of flash-build

17. 6. RELEASE,
MEASURE
• Release prototype
• Measure impact
• Document and share
Case study: Understanding Shakespeare
• End of flash-build: working, designed prototype with Macbeth
• 1 month later: released ”MVP” – 6 plays
• 12 months later: released all Shakespeare’s plays; released API
• 18 months later: tested approach on a different text
(Understanding the U.S. Constitution app)
• Currently: exploring expansion to an entire Classics Library

18. labs.jstor.org/shakespeare

19. WHAT WE LEARN, WHEN
User Input!
Who are they?
What can we
do that will
help them?
How should we
implement it?
How’d we do?
1. Create the sandbox
2. Research
3. Design jam
4. Select an approach
5. Refine approach
6. Release & measure

20. THANK YOU
Alex Humphreys
Director, JSTOR Labs
ITHAKA
http://labs.jstor.org
@abhumphreys
alex.humphreys@ithaka.org
Further Reading
• The Lean Startup, Eric Ries
• Business Model Generation &
Value Proposition Design,
Osterwalder et al.
• Marty Cagan’s Blog:
svpg.com/articles
• Running Lean & Scaling Lean,
Ash Maurya
• Sprint, Knapp, Zeratsky, &
Kowitz

21. APPENDIX A
OPEN IN CASE OF
POOR INTERNET CONNECTION