I recently participated in a design sprint for a new feature our team is building, and I thought I'd share my experience with you, dear reader.

The team didn't have the five days needed to do a proper design sprint, but we still wanted to get together to solution for the customer problem. I was not the facilitator of the design sprint but rather just a participant. We had a group of 9 participants from UX, product, and engineering, and only 2 days to make some progress.

This post is Part 1 of a is a 3-part series. Part 1 will go over Day 1 (whoa, fancy that!). Part 2 will go over Day 2. Part 3 will go over feedback from the team and pushback from engineers. This series assumes you're already familiar with the definition of a design sprint, but if you're not, read this 2-minute overview first.

This post describes the first day in our abridged (two-day) design sprint.

She's running really fast, because she only has two days instead of five...

1 - Product and Problem Definition (30-60 min)

The first thing the facilitator did on Day 1 was to define what the product does today, what problems we're trying to solve, and the gaps we're trying to fill with this feature. Product must be prepared to speak about the problems to solve (and customer feedback), as the facilitator may not have intimate knowledge of this.

Information should also be sent out ahead of time, so that others can do 'homework' before the design sprint starts. It's ideal that everyone has a basic understanding of where the product stands today, and what problems you're trying to solve for, going into the design sprint. Otherwise this could take an entire day to discuss!

2 - Review Personas (30 min)

UX worked on this ahead of time, so you should be reviewing personas during the design sprint, not writing them from scratch. As a product manager, you should be prepared to give input and fill in the blanks when needed. You may already have detailed personas written/ published for your product, but it's important to review them for the rest of the team who may not be thinking about these personas every day.

3 - Use Cases (90 min)

This is where everyone starts to participate. Everyone should take index cards (or post-its) and write down all of use cases they can think of for the problem set.

Example: If you're building a TV app, one use case could be "I want to search for movies starring Jennifer Lawrence," or "I want to see the most popular TV shows that air tonight." You get the idea.

Everyone's ideas should be considered, and no one should be made to feel ridiculous for coming up with weird use cases. In other words, maintain an environment of intellectual safety during this exercise!

4 - Facilitator Groups Use Cases into Categories (15 min)

At this point, there will be a lot of use cases on the board/ wall. Possible over a hundred, depending on the number of participants you have in the session.

As participants continue to write down use cases and tape them to the wall, the facilitator is grouping similar(ish) use cases together. For example, our use cases were grouped into five categories - Research, Discovery, Prescriptive actions, Analysis, and Visualization.

5 - Everyone Chooses 3 Use Cases + Discussion (45 - 60 min)

At this point all participants are given three stickers. Everyone mulls around, reading the use cases, and chooses only three which they find most important.

The goal is to pare down all of the use cases to focus on what are the most important micro-problems to solve for.

Once you have your top use cases identified, discuss what they are with the entire group.

6 - Take-aways, Notes Documented, What to Expect Day 2 (30 min)

As you wrap up for the day, make sure that you:

Make sure someone is documenting all of the use cases, and which ones were chosen as priority by the group, use cases + their corresponding 'categories.' This can be done in Confluence, or just in Google Docs - somewhere where everyone has access to review it.

Document all notes taken during the day in general. These can go in the same Confluence page/ Google doc.

Set up for Day 2, so participants can start thinking about it. Let everyone know that tomorrow they can expect to be storyboarding customer journeys, and making paper prototypes of possible solutions.

Product Popcorn

A zealous product manager endeavors to fix everything.

For me, being a product manager doesn't stop on the weekends. When I'm out and about doing everyday things, I am still thinking about end-to-end user experience, and why things were built the way they were.

I also think about the way things are going to be in the (near) future. And how we can make everything better.

Disclaimer: The views and opinions expressed in this blog and on the podcast are mine alone, and are not necessarily those of my employer. This blog expresses my opinions on product management, and are for informational and entertainment purposes only.The only exception are my views and opinions on red pandas, which are clearly correct and true for everyone :-)