Following our journey to validate, we set out to run problem discovery workshops with a subset of those we talked with. Our goal was to learn if the problems they stated in the initial call were substantial enough to deepen our focus in. Of course, we only knew that we wanted to learn more about their problems, not, how we should reach it. I came up with the idea that we should run these long-form meetings as a sort of workshop — to keep our participants engaged and so that they also leave the meeting with something they’ve learned about their problem or even a first draft of a solution. The format of a workshop helps to provide a space where our discussion with the participants can be less constrained, both in topics as well as time.
So, how did we start? Bruno and I first defined our goals of the upcoming meetings:
- know how the interviewee’s workday is structured
- learn about who is affected by the problems identified
- draft an initial solution they can implement right away
- see if they already have a solution in place
- validate the problem hypothesis identified in the first interview
- let the interviewee feel productive and inspired
- know if this breaks critical assumptions for our business case
After that, I went on to research how other teams tackled this issue. That is when I first discovered the idea of running problem discovery workshops. Similar to what is done in design sprints’ initial stage, those workshops set out to identify possible problems within an organization or target group. I highly recommend checking it out.
Knowing some of their problems already, the workshop is a good way to explore them further.
Outline
We set out to run the workshops with the following agenda:
- Short introduction
- Pain point discussion
- Stakeholder interview
- Short peek at tools
- Solution brain dump
- Identify possible users
We found that 1.5 to 3 hours work best for this kind of workshop. If you’re only talking to one person, doing it online yielded fine results — but we also liked how it spanned out in person. We felt exhausted after each of the workshops, so a longer workshop probably needs more participants on each side for more dynamic conversations. On the other side, a short workshop might not leave enough time for each problem.
Don’t forget to take breaks where it seems fit. To stay in flow, we took a longer break (>15min) after the stakeholder interview.
Short introduction
To kick off the workshop, we introduced each participant with each other. As we ran the workshops as a followup to the initial interviews, there was already some trust established with each other. Still, it helped us to reiterate where we’ve been coming from (trying to validate a problem, our professional backgrounds and personal convictions) to build rapport.
Pain point discussion
As the workshops might not happen a week after the initial interview but possibly weeks or months afterwards, it made sense for us to reiterate the pain points discovered in their interview and other interviews. This also opens up the space for the participants to state any additional problems they might want to discuss. We kept it at around max. 15 minutes.
Stakeholder interview
This is the primary part of our workshops. We mostly considered this as a long-form version of the initial interview — with an open discussion and no structured questions. With the pain points reiterated, we felt the participants easily opening up themselves about what pained them.
Short peek at tools
If it makes sense, it can be good to take a look at existing tools the participants use, especially if they mention it as part of the problem. This is also a good time to look at what their potential solutions look like. Note that it’s usually a good sign if the participants already have some self-made solutions in place — as it means that the pain is not just hypothetical.
Solution brain dump
We took a short break to brainstorm some possible solutions. If they already have a solution in place, this is a good time to discuss meaningful extensions. This can yield first mvp-ish drafts of what a product might look like, but it’s also a possibility to share experiences and learnings from other interviews and what others had as solutions.
Identify possible users
Extending on the solution brain dump, if you end up discussing a product, the workshop provides a good space to identify who might be most impacted by a solution. Sometimes, the participants are not involved much and relay pains, where this agenda point comes in handy. This allows you to address those users next in your journey to validate further.
What we’ve learned
The workshops we ran helped us understand the issues our interviewees faced much better. One of our goals was to know if the problem space is worth pursuing. While we felt that there was a strong problem at hand for those we’ve talked to, it did not seem like a good match for us — and probably not a problem that’s fixable with a majority-softwareish solution. Another thing we learned from the interviews was that there is a general exhaustion of that group with adding “just another tool” to their workflows, which possibly makes entering this market harder for teams not yet established in this space or as part of a greater toolset.
Where we’re going next
It’s time for a major pivot now. We’ve greatly examined the current iteration and saw that while there are diverse problems, not many matched our knowledge and skills. Of course, Bruno and I are not stopping here — and something new is already in progress. Stay tuned and subscribe to my newsletter if you want to learn more in the future!