The New York Times Product Discovery Activity Guide
For the product development teams at The New York Times tasked with building products and features, we face the same challenge as many other companies: how do we figure out what’s worth spending our time on? How do we figure out as quickly as possible what our customers will find both useful and easy to use, that we can plausibly build? And how do we make sure we understand why something works (or doesn’t work), so that we can learn from it in the future?
The answer, we know, seems straightforward: test your ideas with real customers, leveraging the expertise of your product, UX, and engineering talent. Figure out the smallest test that you can come up with to validate a specific hypothesis, gather data and insights, and keep iterating on it until you know whether the problem is real and your solution will prove valuable, usable, and feasible.
As part of our efforts to adopt such a data-driven, experimental approach to product development, we recently kicked off a product discovery “pilot program.” Small, cross-functional teams were paired with coaches and facilitators over a six week period to demonstrate product discovery and Lean methodologies as they apply to real-world customer opportunities at The New York Times.
Beyond demonstrations, of course, we could (and did) learn a lot from the pilots about the nuances of how to make product discovery work better throughout the organization. From here, we wanted to know: what challenges did our pilot teams encounter that we could help ease for the next set of teams?
One of the first things that we learned about the process from our participants was that they wanted a “toolkit” — something to help them figure out what they should be doing, asking or making to get as quickly as possible towards the validated learning, prototypes and user tests that would have the most impact.
To facilitate the learning process for our dual-track Agile teams, the Product Architecture team here at The Times (Christine Yom, Jim Lamiell, Josh Turk, Priya Ollapally, and Al Ming) with some guidance from our coaches (Kent Rahman and Natalie Hollier) built a “Product Discovery Activity Guide” that rolled up activities, exercises, and testing techniques from all our favorite thought leaders.
These included brainstorming, collaboration, research, test-and-learn, and discovery techniques from Gamestorming, Innovation Games, Google Ventures, Eric Ries (The Lean Startup), Jeff Gothelf (Lean UX), Steve Blank (Customer Development) and our spirit guide, Marty Cagan (Inspired), among others.
Each page in the Activity Guide includes a brief description, estimates of how many participants it supports and how much time it takes, what you’ll get out of running the exercise or implementing the test, and a short description of how to do it.
The pages are grouped by milestones (like “Narrow the Field”, at left) rather than phases, that represent what teams are trying to accomplish. The idea is that when a team decides it’s time to take their prototype and validate it with real customers, they can fan out all the red “Validate with Users” cards and pick the one that makes the most sense.
We distributed the guides to our teams both digitally in PDF form and as physical books (binders, really, since we want them to be updated regularly), which we placed in our project and “war rooms.”
Our goal was to make it a tool not just for learning how to get started, but to be a living document for teams to share lessons about the process itself. What techniques worked and didn’t work? What tactics did they learn elsewhere that might be worth sharing with the rest of the company?
As we started mentioning “The Book” to our friends and colleagues outside the company, they really wanted to get their hands on a copy of it to try themselves. So, we thought it would be a good thing to share it with anyone who’s interested, with the goal of widening that learning effort outside our company to the community at large.
Here it is on SlideShare, for your sharing (and remixing) pleasure. We’re in the process of converting it to a more easily editable format in Google Docs, that you can edit directly, so stay tuned.
We hope you find it useful, and whether you’d like to share with us what you’re doing with it, or you have suggestions (big or small) to improve it for future product generations, please let us know!
