Beyond the Product Roadmap: Lessons in Tackling Exploratory Research

At Yammer, we experiment and iterate on more than just our product. At times this means rethinking our org structure, product planning, and even how we communicate. Recently, we revisited our approach to how we do exploratory research — the kind of high-level thinking that well predates the prioritization, constraints, and feature-level thinking that comes with executing on our roadmap. We aren’t new to this type of exploratory research, but we want to make it a regularly integrated part of how we work. So for one week, we adopted a time-boxed process designed to encourage true creativity and the ditching of old assumptions. We believe that by consistently opening up our product (and process!) to experimentation, we will become a better product team.

A Peek Into the Process

We started by choosing three big product areas (e.g., messaging, integrations, team workflow) inspired by challenges our users face. These are areas where we wanted to step back and gain additional perspectives. Whatever product areas we chose needed to be broadly defined: challenges that aren’t easily prioritized — ones big enough to allow for many interpretations but narrow enough to keep us on topic. This wasn’t a design sprint, which we’ve done before. We wanted to stretch our thinking wide and imagine how big challenges could be turned into opportunities.

To do this, we needed a crack team and process for our exploratory research experiment. To tackle each product area, we got three teams together. We included product managers, engineers, and designers in the exploration, drawing on each team member’s expertise to get diverse perspectives. We also tapped two user researchers, Emma Beede and Soumia Fares, and one design lead, Manuel Muñoz Solera, to act as team facilitators. Each facilitator was assigned a product area and held the responsibility of leading their team in daily exercises. So it was important that they have experience coaching people in creative ways. Designers and researchers tend to have a knack for this.

As a starting point, we borrowed from IDEO’s Human-Centered Design Toolkit and Google Ventures’ Design Sprint, to design an exploration process that would require no more than a two-hour commitment from the teams each day. In order to meet our long term goal of consistently flexing our exploratory research muscle, we felt that squeezing this experiment into a typical work week would be a great first attempt.

We had our team. We had a plan. Here’s how it went down:

Day 1

All three teams kicked off the experiment by huddling in meeting rooms armed with sharpies, sticky notes, and whiteboards. Each team shared what they already knew about their product area. Next thing we knew, there was a huge list in front of us. Then a list of questions and insights turned into opportunities. We did this using IDEO’s How Might We framework. For example, “People love to feel productive at work” turned into “How might we help people feel productive in Yammer?”

Day 2

We started with an analogous inspiration exercise: each team spent time brainstorming examples of other products and services that tackle similar challenges. For example, Venmo shows use cases for their product by highlighting friends’ transactions in their activity stream. Then, much to the delight of each team, we moved away from ambiguous concepts and started brainstorming real possibilities for Yammer (with hundreds of sticky notes).

Day 3

What do all these crazy ideas look like, and how might they work? Each person sketched their ideas in user experience storyboards.

Day 4

At this point, teams came up with about 10 user experience concepts, each related to their challenges. Team members spent a couple of hours giving each other feedback and building on those concepts before the final presentation day.

Day 5

After 4 days of tackling the product areas, each team presented its concepts to all the other teams and product leadership to show off all of the ideas.

This is the framework we executed, but it was by no means perfect; there are plenty of things we would change if we did this again…

So what did we learn?

Zooming in and Zooming Out

If we had one concern as a team going into this week, it was the fear of being too limited in our brainstorming. Our original goal was to come up with as many brave ideas as possible. We were wary of being constrained by previous ideas and methods we’ve explored in the past. This led to our one rule: when in doubt, dig deeper. There are always more layers to your idea than you realize.

However, during the final presentations, we realized that we had zoomed in too much and that our ideas were actually too well fleshed out. Having over developed so many ideas was distracting. Instead, we needed to zoom out and recognize the many ways one problem can be solved, rather than focusing on one particular implementation of a solution. Within the product area of team workflow, for example, there are multiple themes: getting caught up on what people are working on, having a space to call your own, being able to get outsider feedback as a conversation evolves, etc. There are many features you can build for team workflow, but those themes help us to see what directions in which we could go, and whether or not we should invest in them, instead of evaluating specific features.

Takeaway: Before we started this experiment, our product team had maybe 2 or 3 ways of thinking about each of the product areas. We now have 5 or 6 — this opens up the future of Yammer beyond our immediate roadmap. Finding new opportunities for each product area was the ideal finish line, but we needed to zoom in and zoom out before we realized that. In the future, we’ll know to continually adjust our focus.

Be okay with thinking, instead of doing

For our teams of designers, engineers, and product managers, this exploration was uncomfortable during the time we were still evaluating the product areas. At Yammer, we’re generally always ready to make a prototype, A/B test our hypotheses, get user feedback, and move forward. We’re proud of this way of working because it helps us fail and adjust course fast. However, we also need to get better at taking enough time to explore and expand our views beyond our roadmap.

Takeaway: Be comfortable in the moments when you’re exploring the depths and facets of a problem. Be careful of jumping to solutions: if you’re talking about how teams keep track of tasks, don’t start designing a task calendar and getting into the weeds of why it will or won’t work. It’s tempting and much more comfortable to talk about solutions, but you might be missing the bigger picture. The gems that you’re really going to come across happen in the laborious thinking process itself.

Be Flexible

Don’t be afraid to mix and match exercises from different methodologies and tailor them to your schedule, user challenges, and business needs. While this felt risky, especially from a facilitator’s point of view, it paid off. It put less pressure on everyone to have a perfect process, since we all knew this week was an experiment. This lowered the time commitment for our facilitators, who were also working normal weeks. It also helped us learn more during the process because we were trying more stuff.

Furthermore, we needed a flexible process because each of our product areas were so different, having their own sets of challenges. Each facilitator sometimes had to improvise and focus on what was most important for their team at the time. Manuel cut things short when the discussion wasn’t going anywhere. Soumia didn’t want to lose good ideas and captured each of her team members’ thought processes by holding on to all their rough sticky notes.

Since this was an experiment, we wanted to make sure facilitators were learning on the fly. To do this, they acted as participants as well. That way, they knew when to move on to the next exercise, switch to a backup plan, or even cut a session short.

Takeaway: Don’t be afraid to scrap an exercise and tailor it to fit your team’s needs. If a brainstorming exercise doesn’t land well with the team, look for what’s needed at the moment, and switch to a different exercise.

Moving Forward

As a product team, we established a weekly practice of doing Product Teardowns, where we sit together for an hour each Friday and reverse engineer the newest products. This is one way we continuously develop our product instincts. Our hope is that we can create a similar habit that keeps exploratory research going within our day-to-day.

While we learned a lot during this experiment, our current goal is to spend less energy belaboring feature ideas and instead experimenting with ways we could explore user-centered challenges. We’ll need to push our boundaries, dig deeper to find unique ideas, and zoom out to see the big opportunities.

We’d love to hear — what you do to keep your team looking beyond its roadmap?

Emma Beede and Soumia Fares are UX Researchers at Yammer. We’d like to thank Stephanie Hsu for her help with this article and Jiajia Chen for illustrations.

Special thanks to the rest of our product team for encouraging us to experiment both at Yammer and in the kitchen, where we like to compete and cook up a storm!