How to condense the 5-Day Design Sprint without giving up key outcomes

Transcript

Adam:

Welcome everybody. Thanks for joining Openfield. Today, we’re going to be covering how to condense the five day sprint. Please feel free to submit questions during our time together today. We are leaving some time at the end for Q&A session so we’ll try to answer as many as we can.

I’m Adam Sonnett, Vice President at Openfield. I’m a passionate user experience leader, strategist, designer and educator with over 15 years of experience working with global brands. Over the course of my career, I’ve been able to lead multidisciplinary teams across North America and Europe on initiatives for clients such as Macmillan Learning, Wolters Kluwer, Wiley & Sons, P&G and Unilever.

Sarah:

My name is Sara Freitag, Research Lead at Openfield. I have an academic background in design and business making me the perfect person to advocate for your users while keeping business needs in mind. At Openfield, I focus on making human-centered design decisions that are driven by data and empathic insights. Prior to Openfield, I worked as a researcher, consultant and designer spanning many different industries including consumer packaged goods, banking and EdTech.

Adam:

First, I’ll give you a little bit of background on Openfield. We provide specialized UX research and design services that help EdTech companies deliver world class user experiences that drive greater learning and teaching success for millions of students and instructors. We’ve become highly integrated long term collateral collaborative partners with our clients, and now since we’ve become their UX team. Being that UX team means that we work in lockstep with product owners and engineering teams to uncover and prioritize user experience opportunities, determine key success metrics and execute against clear goals and objectives. We are now in our 14th year of business and our team has grown to include a passionate group of researchers, architects, designers and front-end developers, all working in sync to deliver awesome experiences for both our clients and their users.

Today’s agenda and what we’re going to cover, we’re going to give you a quick overview of a sprint. We will go into detail of an actual client example of a one day sprint. We will share out some modifications we’ve done on other projects. We will help you understand how you can facilitate a successful sprint. And at the end, we’ll leave some time for Q&A.

Some background on a sprint: The five day sprint was invented by Jake Knapp and perfected with more than 150 startups at Google Ventures. It was then shared with the world in the best selling book Sprint, which you can find at thesprintbook.com. There you can find some great resources like checklists that can help get you started.

What is a design sprint? Design sprints allow teams of any size to rapidly solve and test problems in anywhere from zero to five days. Sprint teams typically consist of designers, prototypers, researchers and engineers and is led by a sprint master who facilitates each stage of the sprint. Now that we know what a sprint is, what are the benefits?

Besides offering a clear path to solving your biggest problems, test new ideas, get more done and be faster, your team can gather user feedback before it’s too late. Your team will become aligned to the same vision. You can foster a culture of innovation. There’s less risk and your team will be focused.

Here’s a typical outline that you might see for a traditional design sprint. On Monday, there is a series of structured conversations that will build your foundation and focus for the week. That structure allows your team to boot up as much information as quickly as possible while preventing the usual meandering conversations of meetings.

Tuesday’s all about solving your problem. Using a method optimized for deep thinking. Instead of a typical group, brainstorm each individual sketches their own detailed opinionated solutions followed by a four step process that emphasizes critical thinking over artistry and we’ll cover that a little bit more later.

On Wednesday, you and the team will have an entire stack of solutions. You’ll have many different sketches to look through and put up on the board. Now you have to decide which one of those sketches should be prototyped and tested. On Thursday, the design team builds a realistic prototype of the solution so you can simulate a finished product for your users. The sprint prototype is all about a “fake it till you make it” philosophy. So, we’re not trying for something perfect, we’re just looking for something realistic to get the best data possible from Friday’s user test. That way you’ll learn whether you’re on track or not.

So lastly, it’s time to finally prototype. On Friday, you get to throw that prototype in front of five different users in five separate interviews. Instead of waiting for launch to get that perfect data, you’ll get quick and dirty answers to your most pressing questions right away.

Who should be in the sprint? A traditional sprint it’s recommended that seven or less participants are involved. The more people you have in the room, the slower the sprint moves. You take more time than necessary to keep the room focused and productive. You want to try and get a diverse set of skills along with the people who work on the project in the day to day.

So on the left, your two must haves are really important. The facilitator, they manage time, the conversations and the overall process, and the decider. Who is going to make decisions for your team. It could be the CEO of the company or perhaps the “CEO of the project.” It’s really important to have this particular person in the room the whole time. Once you have those two, it’s time to mix in your experts, the people who work on the project in the day to day. It could be a product owner, UX people, UI people, researchers, engineers, business experts, really pick any or all of these to join in the sprint.

Remember that each of the projects you have are unique, each product is unique. Google doesn’t recommend shortening the sprint because it’s likely you won’t finish the prototype or even get to testing it. We also know that five days it doesn’t work for everybody for a multitude of reasons. You can condense that time spent together and still achieve the outcomes you desire.

Now I’m going to hand it over to Sarah to share some examples with you starting with our client example. This is a global information services company with $4 billion in revenue. So Sarah, take it away.

Sarah:

Thanks, Adam. I’m really excited about this example because it was such a perfect way to kick off the project. We found so much value in getting everyone together in one room for the design sprint. The learnings from that day are still top of mind as we design today. Let’s start from the beginning.

Our client came to us looking for help. They wanted help defining their users, defining their user journeys, defining their product’s true purpose, and looking for ways to streamline the experience across all their products, resources and sites, so that they could really feel like one company. Of course, we were thrilled to help but in order to give effective recommendations, we needed more background on the business goals, current state of the product and team’s vision of where they wanted their product to be in the future. An ideal state.

Everyone we talked with on the project team represented different pieces of the project, each with our own goals and areas of expertise. In talking with them, it became clear that we needed to get everyone together so we could align on common goals, build a comprehensive understanding and work toward a unified future state that would solve their current problems. This is exactly what Google design sprints are made for. And we were going to bring in students and instructors and for some prototyping and validation, we were excited.

We pitched the idea five full days, and I wish I could tell you how thrilled their entire team was to stop what they were doing and make time for our design sprint. But ultimately, they came back to us and said, we only have one day. Everyone was busy and it was hard not only to get people to put aside their work, but also to plan travel so everyone could be in one room together. And by the time everyone’s calendars aligned to schedule a session, it was winter break, making students and instructors unlikely to participate.

So, we said, okay, that’s no problem. We understand that the traditional sprint doesn’t work for everyone and we’re agile enough to pivot our plan. We’ve begun testing a condensed version of the design sprint that we’ve had a lot of success with. In our condensed version, we preserve the pieces of the traditional sprint that benefit most from having the whole project team working together in one room, map or understand, sketch or design and decide phases. And we saved the prototyping and validation phases to be run by our team following the session.

So what could a typical day look like? The most important part of a design sprint is understanding our project’s goals and vision from the perspectives of each stakeholder in the room. That’s why we recommend spending most of the morning mapping and understanding. This proved not only to be a crucial step in aligning our client’s stakeholders around common goals, but also in helping our team understand the nuances found across the client’s products.

Now I’ll tell you a little more about each activity. The welcome and introduction phase is not only a good time to set ground rules and expectations, but it’s also your chance to set the tone for the day and get everyone aligned to a common goal by sharing a sprint challenge. We’ll talk a little more about that later. But when you have all the right people in a room together for a design sprint, you’ll likely notice that not everyone works together on a daily basis They’re busy, they’re from out of town, or maybe they’re new to the team. This was the case with our client here, but you’ll want to foster collaboration by making sure everyone feels welcome and comfortable with each other from the beginning.

So this is a great opportunity or chance to do some icebreaker activities and to get the team who’s working on this sprint to think outside of their product space. Since our session was around the winter holiday season, we had everybody talk about their favorite toy. It was kind of awesome to see everybody loosen up, smile about a childhood memory, and immediately started to engage with each other, which sets the stage for a really great session with this team.

Absolutely. And so, following the introduction, we recommend lightning talks as your first activity. Google recommends lightning talks as an opportunity to build ownership in the design sprint challenge. So, before the sprint even begins, you’re going to want to prime your stakeholders so they come prepared and ready to present. lightning talks typically last about 10 to 15 minutes and each cover a wide variety of topics. For our session, we had stakeholders present their business goals, any previous research they had done on their users, even if it was just things they’d heard in the field. We had them share their thoughts on the current experience and information about their competitors. We also had the tech lead present on the current state of technology.

Everyone who comes to a design sprint is an expert on their piece of the project. The goal is to provide a format that gives everyone a chance to share and absorb knowledge, creating a baseline to build off during the session and a list of assumptions to validate later. In our client sprint, we used the business goals that were presented during this time as a basis to align the rest of our activities throughout the day.

While the lightning talks were taking place, we encouraged everyone in the room to be active listeners by participating in Google’s note taking method that frames each note as an opportunity statement starting with How Might We. How encourages everyone that the answer’s out there but removes any pressure to have a solution right away. Might opens the door for success or failure, letting everyone know that their statement might or might not work and either way is okay. And we remind everyone that the design sprint is about collaboration and building on each other’s ideas throughout the day. After all the How Might We statements were recorded, we invited everyone to share what they had written and then used affinity mapping to group the theme statements, to group and themes statements together and organize them according to the business goals identified earlier in the lightning talks.

Adam:

So you probably noticed there’s a lot more than seven people in those images, specifically, this one. There’s seven in there and that doesn’t count that Sarah and I were behind the camera here and the other two in the corner. So, there were 11 people. I just got done telling you that seven or less is really important but we also have to be flexible. We needed to accommodate the VPs ask to have her entire product team here as a part of that session. Did make it challenging to keep everybody on track. But as you will see, once we get through and show the afternoon session, we were able to create some really awesome sketches and get great output from this team.

Sarah:

Absolutely. So after that affinity mapping exercise with the team, we focused on the current product experience to extract any additional knowledge from stakeholders about their product end users. User journey mapping is a common design sprint method that gets everyone to map out a user’s experience step by step as they interact with the product. This method enables the team to get in the mindset of the user and it’s great for uncovering pain points, marked with x’s if you can see in that picture above, an additional opportunity areas and wins. This was especially eye-opening to our client team because they didn’t only identify opportunities to streamline their product but they also identified a handful of opportunity areas to streamline their internal operations.

Adam:

Let me jump in there a second. So, that was a really good example of things that come out of sprints. So we went in trying to recreate an instructor or student experience, but the end result of that morning was the product team realized that like, wow, we do a lot of double up or triple up on communication and there are some internal processes that we can fix with the way we’re working together. So, the note here is that you might go in with a specific goal but always know that you’re going to, the team is going to figure out other areas to improve upon that might not have anything to do with the product. So it’s typically what we see.

Sarah:

No, it’s always great to watch everybody come together. And these are the sorts of themes that we identify and we’ll talk about a little bit later today. And as a recap of the morning, we got everyone together, we focused on sharing knowledge through lightning talks, framing that knowledge as opportunities through the How Might We and affinity mapping exercise. And then we split apart to develop journey maps for the different user types. In the afternoon, we came back together to share the journey maps and talk about the additional opportunity areas uncovered. Then the rest of the day was spent brainstorming and prioritizing solutions.

So we’ll start with Crazy Eights. Crazy Eights is a great design sprint method that challenges users to look at one opportunity area from multiple perspectives. I’m sure you’ve all heard the expression, your first idea isn’t always your best one. Well, this is an exercise to encourage innovation and help teams quickly generate as many ideas as possible. We encouraged everyone to fold the paper in half and then in half again, quickly filling it with as many solutions as they could. It also gave our team a glimpse into their thought process, which was extremely valuable to understand as we moved into the prototyping and validation stages later.

Adam:

And this one moves really quickly, so eights meaning eight sketches in eight minutes. So you get one minute for each panel. That’s not a lot of time as you can see on this example, I think this is mine actually. I ran out of time. So, I only had six of the eight but the point is, I was able to get six sketches in eight minutes times the 10 people in the room. All of a sudden we had 60 sketches to look at, it’s incredible.

Sarah:

And then once we share the Crazy Eights, we encouraged the team to pick their favorites out of the 60 or so that Adam mentioned, and it can be their favorite idea or it could even be a combination of ideas to sketch in more detail. So we asked them to create a storyboard around how the user would interact with the product and the various screens or stages the product could have. This helped us further understand the team’s future vision for the product, let us know what they were excited about and it opened the door to some interesting conversations around feasibility when thinking about short term and long term solutions.

These conversations the feasibility started naturally in the storyboarding phase, but they continued as we moved on to a prioritization activity. This was a chance to understand which ideas had the most support and excitement from the room, and it helped our team more clearly understand what will be important to stakeholders as we planned our prototyping and validation phases. So, in an effort to prioritize, we gave everyone in the room three dots to vote on their favorites. You’ll see dot votes a lot in design sprint activities. And the solutions that rose to the top were the ones we focused on prototyping first.

So to recap, we finished the day ideating and prioritizing solutions to fill the opportunity areas identified earlier in the morning.

Adam:

So as you can see, the team, we packed a lot into what was less than an eight hour session. So I’m going to ask Sarah now to share a little bit about the outcomes of that day. So, we talked earlier about prototyping, we talked earlier about validating with users. That was not included with that eight hour session, seven hour session. We just didn’t have time to include them. Like we said, they were on winter break. We only had seven hours, we have to cut some things. So, what were the things that we left with and what did we do next?

Sarah:

Absolutely. So our original goal was to help our client define their users, define their user journeys, define their product’s true purpose, and find ways to streamline the experience across all their products, resources, insights, they could better feel like one company. Journey maps uncovered some opportunity to streamline the experience but our client’s future vision of the product was made even more clear through the sketching exercises. The sketches that came out of that day were incredibly valuable but it’s never easy to get a team of stakeholders sketching. That’s always the number one fear we hear. I don’t know how to sketch. But no worries, this was a sketch and this was a sketch. Valuable sketches came in all forms of fidelity. Some people wrote out their ideas on paper, like this example here while others grabbed giant pads of paper to sketch their interface and tell a story.

Adam:

I think that’s really important to convey to the sprint team when you’re in the room is that ideas and sketches come in all shapes and sizes. The point of the exercise is to quickly get as many ideas down on paper, like I mentioned before. Then as a team, we get to vote and decide which ones are best. It’s not who’s creating the best and the most ideas, it’s the fact that we are creating the best and the most ideas. Then we get to vote as a team so that the design research team can prototype and then validate those decisions that we as stakeholders and experts in the room decided are the best.

Sarah:

Exactly. The form of sketching didn’t matter. It was the outcome from the day. So with everyone aligned to the same page, there’s always a high amount of energy and excitement coming out of these design sprints. We certainly shared that level of excitement but we benefited from what we learned, making it possible to jump into the prototyping and validation stages much faster than we could have without the outcomes from the sprint.

Adam:

So we spent a day on site with the team and we facilitated a full session and extracted a ton of ideas and information. Since this was a compacted sprint now, what did we actually deliver?

Sarah Freitag:

Well, we wouldn’t want everything from this spring to be forgotten once everyone left the room. So we synthesized the day two report. After typing up all the opportunity areas, we were also able to identify some additional key themes that emerged from the day. The themes we found served as a way of grouping the various design solutions that stakeholder sketched in the session. We helped form recommendations to prioritize the rest of the ideas from the session based on the number of business goals each solution related to. We also created final graphics to represent the user journeys and serve as a reminder of the pain points our solutions needed to solve. This example here shows screens, but the results of a journey map could be completely processed based as well.

Sarah:

So all of these steps led up to the prototyping phase. During the session, we focused on flat sketches. One concept at a time with crazy eights and several ideas strung together for the storyboard. While both of these approaches are helpful to conceptualizing solutions, we ultimately designed products or experiences that are meant to be interacted with. So, we can’t stop the flat designs alone.

Adam:

So that’s where the prototyping comes in is it allows us to explore interactions, gain a holistic view of a design concept before it goes into development. Like I mentioned before, it doesn’t have to be perfect, it just has to be something that can be used by the user to express an idea. Very iterative our process and the process to do prototyping, starting with wire frames, the team can add UI and eventually get it introduced to the users or stakeholders in something that will look like the final product but actually isn’t the final product.

Sarah:

Exactly. So as Adam just mentioned, user validation is invaluable to the iterative process of design. It helps test the hypotheses we built earlier in the design sprint and it also helps eliminate subjective opinions through our user centric process. It’s crucial to collect user feedback early in the design process to make informed design decisions. After each validation session, feedback is distilled into insights and recommendations that further drives the design as it evolves into a solution that meets the needs of your users.

Adam Sonnett:

Some product owners, some VPs think that usability testing is very costly and complex and it should be reserved for big design projects with huge budgets and lavish time schedules, and that’s not true at all, is it?

Sarah:

Not at all. Not at all. So the best results come from testing no more than five users and running as many small tasks as you can.

Adam:

So that was a great example of a one day sprint on site. But obviously, that doesn’t apply to everybody. Can you share other modifications with us?

Sarah:

Absolutely. So the beauty of a design sprint that Google has created, sorry, so the beauty of a design sprint is that Google has created multiple building blocks that you can arrange to fit the needs of your situation. So in our first example, we didn’t have access to users because of winter break. But what if we did? It would be amazing to invite them into the process and mix them up with your product team. If they can be part of the lightning talks and how my we sessions, that would be ideal. But their strongest value lies in the journey mapping and solution sketching exercises. We’ve seen users bring invaluable insights to a product team, expanding their perspective as they worked hand in hand co-creating a future vision for their product custom fit to meet the needs of the very people they’re ideating.

Adam:

So you can imagine in the last session if we didn’t have just product owners and stakeholders in those journey mapping, the solution sketches we did, imagine how an instructor or a student would have a sketched their experience with the product versus our perceived experience of the product. That’s why it’s really important if possible to get users to be a part of these sessions because like Sarah said, it’s actually the needs of the people who use the product every day.

Sarah:

Absolutely. So that would be best case scenario where everyone could get together. But what if no one can actually get together? This was the case for another one of our clients. They had plenty of time to spare but they couldn’t get their entire team together in one location. Well, recommended a remote sprint for them. Breaking up the sprint to 45 minutes to two hour meetings stretched across multiple weeks. So, we had all the stakeholders join via Google Hangout to share their goals and lightning talks. While stakeholders were presenting, we had everyone typed their How Might We statements into a document but we’ve also used a running list in Google docs in the past. That was one meeting.

In the next meeting, we might just share the How Might We statements and identify themes. After that meeting, the facilitator grouped all the How Might We statements into themes and invited the team to log into the document and vote on their favorites. The third meeting involved discussing the favorite How Might We statements and the team started some solutions sketching. Since everyone was remote, we took photos of our sketches and shared them digitally. So you can see it through this process, even though our team was remote, we still got valuable results.

Adam:

So if anyone wants to connect and hear more about other examples we might have of shortened sprints, please feel free to reach out. We’d love to keep that conversation going and share out more with you. The last thing that we’re going to cover before we get into Q&A, I’m going to ask Sarah to share out some tips here on how to, how can you successfully facilitate a sprint?

Sarah:

Absolutely. So there are multiple ways to condense a sprint but what makes it successful? Well, it’s all in the facilitation. We touched on this earlier, but your first order of business should align everyone to a common goal. Here’s an example of a sprint challenge we created for the global publishing company we talked about earlier.Starting the sprint out with a challenge like this one motivates everyone towards the same outcomes for the day and sets expectations.

Adam:

Putting a timeframe on it is really important. The buy for is really kind of scary, but that’s where the facilitator comes in to make sure that we stay on track.

Sarah:

Absolutely. You want rapid iteration throughout the day. And you also need to set some ground rules. Ask for people’s full attention and time. Ask them to step out of the room if they need to take a call and explain that laptops should stay closed until they’re needed and their mobile phones should be put away, because your job as a facilitator is to create an environment where people are fully engaged throughout the day.

Adam:

You want to make sure that you’re warning them that the session will be moving fast. So, those ground rules are really important and you need to cut them off if needed because it’s called a sprint for a reason. We have to move quickly so point made next point or step out of the room, take your call, you’re making it difficult for everybody else to concentrate.

Sarah:

Exactly. Because time moves so quickly and it’s so valuable, we really suggest that you keep it front and center throughout the session. Help everyone understand where they are in the sequence of events for the day and how much time they have to focus on each activity. One great tool we use is a time timer, you’ll see it in the Sprint book too, this is a shameless plug because they are one of our clients actually. But the most important part of facilitation is listening. Design sprints bring together a team of people all who are experts in their own focus areas and all who are willing to share as much of their expertise with you as you can soak in. They all have busy schedules but they’ve offered you a piece of their time. Listen closely because after the sprint is over, it’s up to you to interpret and translate what you hear into a plan moving forward. A plan that’s made possible in such a short amount of time because so many people came together to work on it.

Adam:

Thank you, Sarah. That was great examples all the way around. Hopefully, like I said before, if you guys have any other examples that you want, please feel free to reach out, we’d love to continue that conversation. So, we have a few minutes left. We’d like to answer any questions that might’ve been posted during the first 30 minutes of this. So we’ve got a few.

Adam:

So, first question, why do you recommend only validating with five users? I did say that before during the validation phase. We hear this question a lot. Comes in a few different forms like I said. It sounds expensive, it’s time consuming and it’s hard to find a lot of users. We touched on it a bit earlier but why do we, Sarah, why only five? Why five?

Sarah:

Absolutely. So the best results come from testing no more than five users and running as many small tests as you can. So, the most striking truth is that zero users gives zero insights. So, as soon as you can collect data from a single test user, your insights shoot up and you’ve already learned almost a third of all there is to know about the usability of that design. The difference between zero and even a little bit of data is astounding. So why five? As you add more and more users, you learn less and less because you’ll keep seeing the same things over and over again. There’s no real need to keep observing the same thing multiple times and you’ll be very motivated from the knowledge you have to go back to the drawing board and redesign the site or the product to eliminate the user ability problems you’ve identified.

Sarah:

Typically, what we find is after the fifth user, you’re wasting your time observing the same findings repeatedly, but not learning much new. You can actually find 85% of the problems just by asking five users. So after that, the rate of return becomes lower and lower.

Adam:

Awesome. So, touch a little bit on, we’ve got a few coming in, this is great. So, I’m trying to see them both here. Do you have any recommendations for telling participants what to expect ahead of time so they are bought in and prepared? From James. Thank you James. So how do we prepare users ahead of time? Do we send them anything? What do you do, Sarah, to get people ready for lightning talks, let’s start with there. We always prepare them for lightning talks.

Sarah:

So we’ll send an email ahead of time to the users or to the participants outlining our expectations for the day. So we’ll say you’re going to come in, we’re going to start off the day with lightning talks. Here are the five categories or the four categories, however many questions we have for that day that we want you to address.

Adam:

A good example is technology. That’s the easy one to address is when you have your technology expert in the sprint, we always ask them to do the lightning talk because if there’s some technological constraint that we’re not aware of or need to be aware of, as the design team, you don’t want to design something that can’t actually be built. So it’s really important to have that tech expert prepped for his lightning talk to tell us you’ve got five to 10 minutes, tell us how the system is built, tell us the technology you’re using, anything that might be relevant for the people in the room for that day so that we get a baseline understanding of what to expect.

And we do that for everybody because a lot of times, it’s kind of out of the blue. Like, wait, you need me to give a five or 10 minute talk, that’s scary. What do you want me to talk about? So a lot of times what we’ll do is we’ll give them bullet points. Like here are the things that you should be covering, but they end up, you give them those first few and then you end up having to cut them off, typically. It’s like, nope, we have to stop because we have to move on to the next expert from a lightning talk perspective.

All right, next question. Oh good one. What happens when you have more than seven people who want to participate in a sprint? We shared this a bit earlier. Like I said, in reality, you kind of have to be flexible to the needs of the team and the client. I think really what it comes down to is if they are really hell bent on having more people in the room than we suggest, which in reality is only like five or six from their team, it just comes back to being a good facilitator. And now I’ll let Sarah speak a bit about some of the techniques she uses.

Sarah:

Absolutely. It’s back to those tips I gave earlier. Crucial to set a sprint challenge for the day. Set directives and rules. Make sure that you’re strict about the no devices. Make sure that as the facilitator you’re cutting people off, you are keeping things moving, keeping things paste and going throughout the day.

Adam:

And a lot of times it’s just trying to get them to get the lead that you’re dealing with to buy into, why is it valuable that only five or six people get to be a part of this sprint? And if you explain moving fast, if you explain getting results and management of so many people, a lot of times they come around to it. So if you have the data to share with them, it’s a lot easier. There another?

One more question. How do I get buy in from my organization to invest the time to do this? Also, another great, great question. So, we like to arm our clients with the rationale behind this. It does seem like a lot. So if we’re talking about five days and we’re talking about seven people, we’re looking at 35 to 40 hours a week times seven people. That is a big investment. But it’s also a timeout. So how do we explain that?

The explanation is that it’s a focusing mechanism for the team, it gives us the speed to prototype and validate all the ideas that come out in five days or less. Really what that means is that afterwards, we’re going to come out with something that’s real. We’re going to be able to move much faster afterwards. So, the team is going to be focused on here are the themes, here’s what we voted on, here’s what the users like. These are the things we need to work on in the next sprint, the next epic, the next quarter, the next year, however far out that roadmap might be.

So again, it’s not that it takes a week, you’re not taking a week off, that’s the easy way to explain it. So what about, I’ll follow that up and ask Sarah from a team perspective. So you deal a lot with product owners, you deal a lot with the UX team, the researchers, the designers. How do you explain it to them? Maybe they’re already bought in because they love design sprints just like we do. What if they say we don’t have time? Probably more like a product owner would be coming back and saying, I don’t have time for this. How do you as the research lead talk to a team member like that?

Sarah:

Absolutely. And I think it really comes down to streamlining. So maybe you don’t have the time right now, but it’s really just a conversation of, you know, with this particular product with our global publishing company, we were able to pull the product leader aside and we were able to talk about, at the end of this sprint, we’re going to have a plan. We’re going to come back to you, we’re going to have focus areas, we’re going to have ideas to start validating. One week is actually pretty short runway to hit the ground flying. So, that’s kind of the conversation we typically have there.

Adam:

Awesome. I think I’m not seeing any more questions. Those are all great questions, so thank you for submitting. All right, so we’ll wrap up a bit early. Thanks for joining. As a reminder, we will be uploading this webinar video along with the transcript of today’s conversation that Sarah and I had to the website, the openfieldx.com, the page where you guys signed up to view. You should get a notification when that’s uploaded. I’m not sure exactly how the system works, but if you don’t, check back in a couple of days and then please feel free to share it with your colleagues and we look forward to connecting with you all in the future. Thank you so much.

Sarah:

Thank you.