Running A Successful Product Workshop, Utilizing “Design Sprint” Principles

“Design Sprint” is great for starting big projects, here is a practical guide on how it can be utilized in a half-day workshop to jump-start a new feature.

“I hope it’s not a permanent marker”

So there I was, 3 weeks into my new position as a product manager in a SaaS startup, and my director of product told me: “Hey Max, we have our roadmap vision presentation in 3 weeks and we need to figure out what we are planning for feature X next quarter. You should schedule a half-day workshop for the team”. It was exciting to lead my own feature from the beginning. I’ve scheduled the meeting for the next week and got down to work. My goal was to plan a productive 4.5 hours workshop for 6 people that will not cause everyone to kill themselves after 2 hours (3 Product Managers, 1 product director, 1 designer, and 1 developers’ team lead).

Framing the workshop concept

First thing first, I’ve refined the workshop high-level goal: “Formulate the product vision for the feature, define the MVP concept and create enough clarity to allow rough effort estimation for roadmap planning”. Once I was clear on the goal, I’ve got to define the method. In a previous company I was hosting a Design Sprint, that changed my perception of group meetings, and I knew that I’ll have to follow the same principles in my workshop (more on DIY hosting of Design Sprint can be found in my previous article: A DIY Design Sprint — notes from a first-time facilitator). The core principles that I’ve set for the workshop were:

1. Everyone should have the same starting point (user needs, opportunity, competitive solutions)
2. No more than 20 minutes for a group task/activity
3. No open-ended group discussions — first we think, then formulate our thoughts, then present them on paper with everyone else, vote, and only then discuss — no egos, no time waste

Workshop preparations

Now I had to plan the way to align the team on the needs, opportunities, and competition before the meeting. I’ve decided that the best thing to do was to have 2 short meetings (25 minutes each) with everybody BEFORE the workshop:

1. Meeting 1: Sharing the user voice and common use cases
2. Meeting 2: Share inspiration from similar products

The main guideline for those meetings was pure knowledge sharing sessions and not discussions. The reason to have those meetings before the workshop is to allow everyone to “sleep on it”, digesting the new information and formulate their own take on the subject, before the workshop.

I’ve headed to bridge my knowledge gap on the subject. I’ve collected all the feedback related to the feature and references from products with similar functionality. The first meeting was a bit challenging since it’s hard to keep a bunch of product people to focus on listening, and not discussing. Luckily, with my Design Sprint hosting experience, I was able to cut the unnecessary discussions and to pass the entire meeting scope in only 25 minutes. For the references meeting, I asked everyone to prepare 2–3 examples that they found useful from similar products, to share at the meeting. The meeting went great, and although not everyone had the time to prepare, we had a good spectrum of references to kick off our creativity.

After the meeting on references, the designer and the development team lead told me that the meetings got their creative juices flowing and each of them had a whole bunch of ideas on how we could tackle the feature — that was the perfect state of mind for the workshop that was happening in few days.

Workshop planning

For the planning of the workshop itself, I’ve used some of the concepts from the Design Sprint to make it as much efficient as possible. The final agenda for the meeting was:

14:30–14:45 (15 min) — Workshop intro and setup

14:45–15:25 (40 min) — Vision formulation

• (5 min) User’s voice
• (15 min) Main use-cases and pain points
• (5 min) Individual vision formulation (“In 2 years time…”)
• (15 min) Presentation and discussion + decision

15:25–15:55 (30 min) — High-level product architecture

• (5 min) Presenting baseline scope to start with
• (10 min) Adding missing parts and concerns (individual work)
• (15 min) Discussion + decision

15:55–16:05 (10 min) — Break

16:05–16:55 (50 min) — High-level UX concept

• (20 min) Map
• (5 min) References recap
• (15 min) Sketch
• (10 min) Discussion and voting

16:55–17:10 (15 min) — Break

17:10–17:55 (45 min) — MVP

• (15 min) Choosing the high impact/low effort case
• (10 min) Mapping the user flows
• (20 min) Addressing the user flows

17:55–18:10 (15 min) — Summary and Action items

With the plan above, I was aiming to set the product vision, have a product architecture, a high-level UX concept, and a clear MVP.

The day of the workshop

Trying to figure out everyone’s handwriting

In the morning of the workshop, I’ve personally talked with everyone on the team, to make sure that they aware of the workshop and I need them there on time, fully minded to the meeting — no phones, no laptops.

A few minutes before the meeting I’ve printed out the meeting schedule for everyone. I’ve washed some fresh fruits and put them in the meeting room, along with a few soda bottles and glasses, making sure that everyone has everything they need to stay focused and productive. I brought a pile of sticky notes, A4 sheets, adhesive tape, sharpies, and pens. We were ready to rock!

I’ve started off by aligning everyone that we are going to move fast and that I was going to cut some discussions, but we will achieve great progress.

The meeting went great. For some items, we weren’t able to achieve the exact planned outcome, but thanks to the workshop, we were able to progress and collaboratively come up with great ideas that brought the feature into a very clear shape that everyone was aligned on. Based on everyone’s feedback after the meeting, it was a great team experience that everyone felt involved and was amazed by the progress we’ve achieved.

Key takeaways from the process

1. Aligning everyone to the same baseline of knowledge prior to the workshop turned out to be super effective
2. Having a strictly constructed short meetings for knowledge sharing are very much achievable and productive, and can fit into almost everyone’s calendar in a short notice
3. Time constraint is a great tool for making decisions
4. A strict workshop schedule should be taken as a guideline — as a workshop host, you have the power to bend or change the schedule based on the reality of discussions and insights during the meeting (after all, that’s us being agile)
5. Not every workshop goal must be achieved during the workshop, as long as you got to the point where you have all the data to complete it offline

I encourage you to question the current methods of conducting ideation meetings and to bring a fresh spirit of innovation into your organization as well🤘