Before starting to design a new product feature, it’s useful to get everyone on the same page by asking a few important questions: What is the problem we are trying to solve? Who are we solving this problem for? What are the steps we should take in trying to solve this problem?
As we work remotely, collaborating on these questions synchronously isn’t generally an option.
Recently, the Monitor group was given the opportunity to gather in Berlin for a Fast Boot. We took advantage of everyone being in the same place and time zone to host a facilitated design session on incident management, where we could answer these questions together.
How the facilitated design session works
The session involved walking the group through three exercises, each focusing on one of the core questions we needed to solve.
We tackled problem definition through running a boundary critique exercise
Using the 1-2-4-All technique, we came up with a list of things incident management is and is not. Since we had engineers, designers, and product managers all working together, we were able to benefit from diverse perspectives and experience levels. We finished the exercise by agreeing on a definition of the space we wanted to work on together.
Next, we did an exercise to build empathy with our users
We took our four ops personas, broke into groups, and compiled empathy map canvases for each. We then took our deepened understanding of our assigned users and applied it to an imagined incident. We shared our users’ pain points, concerns, and goals with the group.
Finally, brainstorming product features
Having established a scope for our work and a sense of our users’ needs, our final exercise involved brainstorming product features that would fit the requirements we had established. We finished the session with everyone dot-voting on features, which left us with a prioritized list of features to work on as we move forward with this project.
Though working this way isn’t a part of our normal flow, the facilitation was a great chance for us all to engage with a product discovery process together. By tackling these questions as a group, we could all come to alignment on what was needed going forward. Participating in these early stages of planning also generates an extra level of commitment to seeing these features through the development process, since we had all agreed on the necessity for them.
We will continue to explore how to inject the energy and enthusiasm generated by this process into our normal, asynchronous workflow.
