The Product Thinking Playbook in Action (Remotely): Research Planning
April 14, 2021
The Product Thinking Playbook is our adaptable, customizable way of designing project plans for building better products. Consisting of various tactics, techniques, and milestones borrowed from Design Thinking, Agile Development, Lean Product Strategy, and Jobs-To-Be-Done Theory, the Product Thinking Playbook helps facilitate conversations around what you will and (just as importantly) will not do to achieve your product goals.
On a recent project, Connected was engaged as an end-to-end product development partner to redesign a new web experience for a global workforce to discover and connect with the employer health and wellness services that appeal most to them in their well-being journeys. This article is the first in a series that will highlight specific Playbook tactics and techniques used during the project, with an emphasis on how we adapted them to work effectively in a remote setting.
So, let’s begin with the Research Planning tactic card. . .
Objective: What are we trying to achieve at this stage in the project?
The Research Planning card is often the first tactic card to be played when we use the Playbook to map out our discovery project plans. This project was no different. Just like the card states, we knew that we would need to “align the team and stakeholders on the activities that will effectively generate insights and areas of opportunity.” With this goal in mind, our questions were as follows: When should that alignment happen? Who needs to be involved? What are the activities to align on? And how can we best capture our understanding to inform the promised result of research planning—the research plan?
The Research Planning card is like a mini-research process of its own. Formulating a solid research approach, one that ensures the team will get the answers they need to gain confidence and clarity in their product direction, often requires several techniques and team members. This card is a critical tactic in the essential effort of weaving user insights into all product development efforts.
Approach: How do we action this Playbook tactic and adapt it to a remote setting?
To execute Research Planning, different techniques are appropriate, depending on the type of research we’re planning to do. For this project, we knew that our clients had a set of strategic objectives for the year ahead, had performed market research to understand their customers’ needs, and had used this work to develop well-informed hypotheses about how a new web platform could support their objectives and users alike. What our team needed to understand was how much of the previous work we could leverage and where lingering questions remained. Those questions would form the basis of our research plans for our own user, business, and technical research efforts.
After reviewing the client’s materials, we decided to use the Service Blueprint technique to visualize how our client’s existing products fit into the broader ecosystem of comparable solutions and to map business operations across the entire user journey. With a Service Blueprint in hand, we could clearly articulate what pain points in the user journey we believed the platform could solve, identify existing technical and service solutions supporting each journey stage that we’d need to consider, and highlight dependencies for our eventual platform. First, however, we had to create the Service Blueprint.
Before the transition to remote work, our approach to Service Blueprinting involved a massive whiteboard and wall of sticky notes, likely in a “war room” somewhere at our client site. Today, to build our Blueprint from the safety of our homes, which are scattered across North America, we use Miro. Miro is a whiteboard tool that Connected relies on for collaboration, especially since transitioning to remote work.
Among the many reasons we love Miro is its extensive library of templates for design thinking and project management. We were tight on time to set up our Blueprint and determined that the most efficient way to complete this complex document would be to host a pair of sessions with our client stakeholders. With Miro’s Service Blueprint template, we spent our preparation time adapting the template for our needs and plugging in what information we had rather than fussing around with setting up the framework.
We filled in the Service Blueprint as much as we could in advance because we wanted to use the time with stakeholders to verify and add nuance to our understanding. For each session, we had an even split of stakeholders who could address current state “front stage” touchpoints, which end users experience directly, and stakeholders who could help us understand the “back stage” processes that support the end user experience. We broke up into small groups, with a Connected facilitator leading each one, to cover different stages in the Blueprint, and we repeated the same process in each session to ensure we were gut-checking our assumptions with multiple stakeholders. Then, we cleaned up and combined the filled-in Blueprints to identify gaps, redundancies, and key dependencies in the current state that impact the user experience.
We shared our learnings in our next client touchpoint. Importantly, we did not stop at highlighting the issues that the Service Blueprint laid bare, but reframed them as opportunities. Some issues called for technical solutions, some required operational improvements, and several showed a need for a deeper understanding of users. With each of these opportunity areas clearly articulated, we could work with our clients to align on what the web platform could address and hone in on a clear scope of work for our team. At the same time, the Service Blueprint helped the client stakeholders realize what work needed to be done beyond the platform, giving them tasks to prioritize on the service side. Beyond buy-in to a research plan, creating the Service Blueprint gave everyone clear responsibilities and a shared sense of purpose.
Areas of Improvement: What can we do to ensure continuous improvement and progress?
Early in a project, when teams are still getting to know each other and build trust, getting everyone involved in a hands-on activity is incredibly useful. First, it is time to spend together to build rapport (the foundation for trust). Second, it gives us space to listen and learn about what’s important to different stakeholders. And finally, what’s particularly valuable about Service Blueprinting is that it enables a third outcome—a visual asset that offers clear evidence of where our gaps and opportunities are.
Service Blueprinting is also a great activity for large, cross-functional groups because everyone will have a role to play and something to contribute or ask about. Getting so many stakeholders involved isn’t for the inexperienced or isolated facilitator, though, especially in a remote setting. We were fortunate to have three experienced facilitators on our team, as well as several additional teammates who supported us by taking notes. With so many moving pieces (digital sticky notes were literally flying), we had to be on our A game to ensure nothing was overlooked and no one felt unheard. The stakes were high, but so were the rewards. For teams on a tight timeline with a ton of research to wade through, Service Blueprinting is worth the ephemeral stress of hosting a workshop.
The Research Planning tactic is a powerful tool for aligning teams and building momentum for early product discovery. For this project, we saw stakeholders and team members come into the “room” with different priorities, only to leave unified around a shared definition of what it would take to progress toward genuine product impact. It’s an outcome that would have been impossible without an intentional focus on effectively pivoting for the new world of remote work.
In the next article, we will look at how our team used the Concept Generation card on this project.
Subscribe to Our Newsletter
Join the Thoughtworks newsletter list to receive curated content that exemplifies our Product thinking approach.
Warning: Undefined array key "modal" in /home/customer/www/thoughtworks.dayshiftdigital.com/public_html/wp-content/themes/connected-2021/template-parts/newsletter-modal.php on line 2
Thu Dec 1
Global Day of Coderetreat Toronto 2022
Earlier this month, we hosted Global Day of Coderetreat (GDCR) at our Toronto office. After a three-year hiatus, we wanted to re-awaken some of the community enthusiasm when we hosted the event for the first time back in 2019. This year we planned for a larger event which turned out to be a really good thing as we nearly doubled our attendance. And in case you were wodering, this is how we did it.
Wed Nov 9
You’re Wrong & Don’t Know It: Process Biases
Process biases occur when you process information based on cognitive factors instead of concrete evidence, skewing your perception of reality, even if all the pertinent and necessary data is right in front of you. And in our third installment of You’re Wrong & Don’t Know It, discover some of the different types of process biases, their impact, and most importantly, how they can be avoided.