Role: Product Designer
Collaborating with: Prospective Client teams
Challenge: Kickstart projects without a clear scope.Solution: I developed a workshop series to help show prospective clients what working with 20spokes would be like and also give them actionable takeaways to help them move their product forward.
Many of the companies that came to 20spokes were at the initial phases of their product journey; they had ideas for their product but hadn’t yet visualized their product through design or development. Given their early phase in the product lifecycle, they were often hesitant to commit to a full product design or development project, so I developed a Product Definition and Roadmapping Workshop Series to help show them what working with 20spokes would be like and also give them actionable takeaways to help them move their product forward.
The series was comprised of 2 workshops over about 2 weeks. I asked the client to deliver any documentation they had in advance of the workshop so I could tailor the first session, but the focus was really to have them talk through their ideas, goals, and any documentation they provided. I found it helpful to have the client walk me through this thoroughly as they would often point out features that they had received passionate feedback or areas where they were unsure of how to proceed. This additional layer of nuance was helpful to adjust my focus for the work to be done during this short workshop.
Given the tight timeline, one of the biggest challenges in this workshop series was to limit the scope of features to truly the “Critical Minimum Product.” I tried to differentiate from a Minimum Viable Product, that may include supporting feature sets that the application needed to function but that may not be the key feature set to the user. For example, while working with a client on a musical instrument organization tool, we focused the workshop on organizing the user’s gear into a specific set. We knew the MVP would need to include the ability to create pieces of custom gear to then add to the group, but for the workshop, we assumed that all the gear the user needed was available so that we could focus on the building of the set.
It was important to me that the workshop format was flexible to tweak the different deliverables and process elements as I learned what was working and what exercises were maybe less helpful. One seemingly simple addition to the deliverables that went a long way was product-specific definitions. Working from a shared language about the product’s different features and user types was an impactful way to show the client that I heard them, understood what they trying to achieve, and also documented the work for them to use moving forward.
Generally, the client’s favorite deliverable in these sessions was the Key Screen Visualizations. I was careful not to call these “wireframes” as they wouldn’t (and couldn’t) contain all the features and states needed for true wireframes. Though they may lack some functional detail, these visualizations were powerful tools to showcase how the features would connect and start to give the client a sense of how their product would come together on a screen.
One of the most important elements I delivered in this workshop is the preliminary feature requirements table. Though it is less visually exciting than the visualizations, I frequently expressed my affinity for this document to clients as it becomes one of the most important pieces of product documentation in a full design and development project. My goal in the short workshop format was to build the foundation for this table knowing that it would grow and change over time should my work with this client continue.
Very often, this work was used and built upon. 3 out of the 4 clients who participated in this workshop over 3months converted to larger engagements with design and development.