top of page
Search
JJ Rorie

The Two-Hour Design Sprint

Episode 096


Teresa Cain is an author, speaker, entrepreneur and technology executive with over 15 years overseeing global product and user experience teams. Teresa has diverse experience leading product management, product design, research, strategy and innovation for digital solutions and as a consultant for startup technology firms. Teresa has helped many organizations solve problems faster and implement solutions using the concept of 2 hour design sprints.






RESOURCES









TRANSCRIPT



[0:02] Welcome to Product Voices, a podcast where we share valuable insights and useful resources to help us all be great in product management. Visit the show's website to access the resources discussed on the show, find more information on our fabulous guests, or to submit your product management question to be answered on our special Q&A episodes. That's all at productvoices.com. And be sure to subscribe to the podcast on your favorite platform. Now, here's our host, JJ Rorie, CEO of Great Product Management.


[0:36] Hello and welcome to Product Voices. I am so excited about my guest today. It's going to be an amazing conversation with a tremendous product and design expert that I've been following for a while and I'm really excited to have her with me. Teresa Cain is an award-winning entrepreneur, educator, speaker, author, and just an overall product and design expert. And so we're going to be having a really great conversation about her latest book and, you know, how product and design and AI and all of the fun things that we can think of come together. So a quick, a little bit of a formal bio of Teresa. She is the author of Solving Problems in Two Hours, How to Brainstorm and Create Solutions with Two-Hour Design Spreads. This has been an instant hit among tech teams worldwide. Teresa has over 16 years of experience in product management, innovation, UX. She is currently the Director of Product Management, User Experience, and Design at Trevipay, which is a leader in global billing and invoicing. She's also the founder of Lucid Startup Consulting, a training advisory firm for product and design. Teresa, I'm so excited about this conversation, about hearing more about your book, and about just the overall chat that we're about to have. Thank you so much for joining me.


The Two-Hour Design Sprint


[2:02] Thank you for having me. I look forward to it as well. Yeah, so first of all, tell us a little bit, your two-hour design sprints, you know, your work on that is quite famous, and I love it. But give us a little background on that. You know, what is a two-hour design sprint, and, you know, how did you come to work with it? and just give us a little bit of an overview on two-hour design sprints.


[2:26] So the two-hour design sprint, you know, really came about not because of the COVID-19 pandemic, but I mean, it really kind of sprung into action because of it. And ultimately, the reason is because a lot of teams during the COVID-19 pandemic went 100% remote, including the ones that I was over. And we've got offices global already, you know, so we've got offices in the United States. We've got offices over in Australia, the Netherlands, Costa Rica, you name it. And one of the challenges as an organization and a leader that was already running design sprints in general is, you know, I didn't really have a lot of time to spend solving problems on new features.


[3:09] And that was something being in a fast paced fintech that's already challenging in itself. So I had reduced design sprints down to one to two days over the couple of years before the COVID-19 pandemic. And when the pandemic hit, I had a really big challenge that we were kind of going through from a fintech standpoint. And I kept putting this meeting off. I was like, OK, we'll be back next week. We'll be back the week after. And we know how the rest of that history went. I think we stayed remote as a company for at least a year, maybe 18 months. And so ultimately the two-hour design sprint really is a process that takes the best of both worlds of not just design sprint methodology but also design thinking methodology and is an innovative way for teams either led by product managers ux researchers designers or startup founders to be able to take this process and come up with the solution in two hours to a problem feature, ID on a backlog, you know, anything that you're needing for a client. And that's ultimately kind of the root of the two hour design sprint.


[4:15] I love it. I love it. And you mentioned something that I want to pick up on and just dig in a little bit. You mentioned that product managers, designers, even startup founders can use this. So have you seen product managers use this resource in ways that helps them? Because a lot of times these design sprints are led by designers or UX and product managers or participants. But in some cases, you see that a little bit flipped. Is that something that product managers can take by the reins and lead themselves? Yeah, and I think that's really the big game changer of this process and why I created the book, Solving Problems in Two Hours. So depending on the size of organization you have, whether you're a startup all the way up to 10,000, 20,000, you know, or the size of Google is really going to be dependent on the resources you have and the tools you have to practice best practices for UX and design. I myself as a product manager, you mentioned a little bit of my background, 16 plus years, I've had product roles where I was everything. You know, I was the UX researcher, I was the designer, I was the project manager, I was selling, I was also writing user stories.


[5:22] So depending what type of role you're in, you need to be able to be versatile and take something that is a best practice and move forward with it. And what I've seen a lot in my career, in my roles and in organizations that I've coached, which I had coached around over 300 organizations before publishing the book. So I'll talk a bit about that as well. But ultimately, one of the things I've seen is a lot of organizations are just skipping that stuff. They're skipping UX research and design altogether. And what that means is they're not talking to customers. And ultimately, this is really to give away a small method investment of two hours versus a traditional five-day method that they could take on their own and be able to execute on this process and deliver it. And from some of the organizations that I've coached through workshops, one-on-one sessions, I mean, this has really allowed it to be done by product managers as well as startup founders with that two-hour method.


[6:17] Yeah, I love that. I think that's really, really important. And your point about we have the resources we have, depending on, you know, where we work and our


Writing the Book


[6:25] environment, and we need to do the best with that. So, so that's wonderful. So let's dig a little into the book. Tell me, before we get into the meat of it, tell me a little bit about what led you to the book and why you thought it was important to read and, or excuse me, why you thought it was important to write for all of us to read. Tell me a little bit about that and that process. Yeah, so I do have a background in writing. One of my undergrad degrees, I was English journalism undergrad, so I've always been a writer. I started off in newspapers years ago before I shifted into product management, which is a fun little fact. And I won't tell you the differences in a tech salary versus a newspaper, but it might have been more like the driver, so why I went the other direction.


[7:10] But what I love about product management is it does incorporate a lot of writing. And I was actually finishing my executive MBA, and I had already, you know, I have written probably several books over the years I've never published, just as someone that's always writing. And so I decided to go ahead and say, you know what, I'm going to take this topic that I've kind of been trialing as an experiment and talk about it and see what other organizations think. So before I actually wrote the book, I pitched this to a bunch of different conferences. I went and ran hundreds of workshops just to see what the feedback was.


[7:49] And I got a lot of positive. I mean, I got a little bit of negative feedback, not a whole lot, but it was like 98% positive, except for the 2% of people that are like, I don't like your idea, which that's okay. You know, I think that that's how we grow and learn and we work through things. But I decided to write a book about it because, you know, there was just a lot of organizations still interested. And in fact, you know, I've had product managers, you know, from large companies, like Google and Microsoft, you know, join the workshops. And I always learn something new. But the one thing that's constant across every organization I learned from the research is, every organization has their own set of challenges and you only have so much time in a day and what you're able to kind of position out. So whether it's a two hour design sprint method or another method, as long as you are investing in that research, you know, that's really what's valuable. So for me, that's part of what led me to, you know, go ahead and write the book. And I'm really lucky that the foreword was written by a really well-respected CX research leader, Bill Stikos, and then also a colleague, John Kelly. He has a PhD.


[8:59] He also speaks and is a writer as well, So, that's what's really great is the book really takes all the research from workshops across the board, and it really allows me to really get additional feedback, you know, like we're talking about it today. Product management and design and, you know, the whole, the whole kind of realm of, of what we do is it's complex, right? And, or at least it's got a lot of moving parts. And so, you know, any practical advice and any practical help that, that any of us can get is, is great. And I know that's one thing that's great about this book is that it's, it's practical and people can implement the tools and the advice and the resources


AI in Product Management


[9:41] that you've given, which is just a huge, huge value to product teams. So I want to ask a little bit about how you see AI playing in specifically to our sprints or design sprints in general, and maybe even more general than that, product management, right?

[10:04] You know, I was just at a big company this last week in a kind of Q&A session, and that was one of the questions that I got then and I get a lot these days is, you know, how is AI going to help us, going to hurt us in product management, all of the things? So I know you believe that there are some great benefits of AI-type tools, Gen AI-type tools, and you write a little bit about that in your book. So specifically, how do you see, you know, like a chat GPT, for example, you know.


[10:40] Stepping in, being an enabler, you know, you talk about them as maybe filling some gaps. Talk to me a little bit about that and how you see that tool coming in to help a little bit in our worlds.


[10:53] Yeah. So I think let's talk about the pros and cons of, you know, an AI or a chat GPT, right? So I have a background in building text analytics and NLP or natural language processing products. So I have dabbled in AI over the years, a little bit of machine learning, some Python in my past. So my perspective of it is super interesting. So incorporating chat GPT, let's talk about the pro first, is already happening. So, I mean, I think just in the last couple of days alone, you know, Apple is talking about striking a deal with OpenAI that's going to embed directly into our Apple phones. I don't know if you're an Apple or Android user, but that's huge. So that right there is, you know, OpenAI and what they've done with tools like ChatGPT. They've basically just written to become, you know, the next Google with what they're incorporating into things. And so the pros of that is really that problem solving, especially you think of a startup that doesn't have any team members to even run any ideas with for a two hour design sprint.


[11:55] And they're able to obviously I do never recommend putting anything proprietary into a product, but you can do exploration with these products without putting any proprietary information. So one example is a lot of organizations, whether they're pro user persona or not, if you ask ChatGPT what the best user persona is, you know, for a Twitter user, it is spot on. It gives you the average age of a 27-year-old female. It gives you a bunch of demographics about the user.

[12:27] So the reality is this is now a giant database full of data, just like you were getting already from searching the internet, except it's compiled everything into one spot and put it together for you. So that's an advantage, especially for the world of product management. Let's say you're writing user stories. Some of the tools that we have at TreviPay, we're already integrating AI. AI assistants are starting to integrate itself in a different product. So that's helping with user stories. We already talked about personas on the UX side. There's also efficiencies on the dev side as well from a coding standpoint, which has led to a lot of conversations where we're at everywhere, right? Because you want to make sure that you're keeping your data proprietary. So I think those are some of the biggest pros of how I'm seeing it. And especially with the two-hour design sprint and some of the startups I've worked with the last couple of years with OpenAI kind of taken a big hit. You've also got Bard. You've got other tools out there as well besides ChatGPT. So the biggest value there is it really is replacing the team that you don't have.


[13:32] So for organizations that are slim, they've got one person, two people, five people, ChatGPT gives you that extra oomph of research that you're not going to be able to complete with a full team. And frankly, it saves you time and money. So I will have for my workshops, I will have them use ChatGPT live during the workshops that I run strictly because this does, and usually we use a topic that's a little more broader anyway. So it's not a proprietary topic. So when I take into a proprietary topic, you know, we have different interactions there. But so that's some of the biggest advantages. So let's talk about the cons. We can't talk about the pros without the balance of the cons.


[14:10] So someone have, again, having built machine learning, text analytics products in my past, you know, the biggest challenge with ChatGPT or any AI product is accuracy. There is no such thing as 100% accurate artificial intelligence product. And even tools that OpenAI had developed are trained models. That means there is someone behind the scenes, even if they're not checking every piece, they're periodically checking it. And the issue with that is there is no way that you know whether the information you're getting out of the product is accurate or not. You need to go validate it. So that's the additional work as a product manager, product leader, UX person is if you are using AI, you need to disclose you're using it or you need to go fact check everything that you have seen in there for it to do that. And especially, you know, as a writer, you know, OpenAI, ChatGPT came out after I published my book.


[15:07] But, you know, that's something in the world of publishing, you know, you're going to hear from publishers like, hey, did you use any artificial intelligence? Well, no, you know, I've always been a writer, but that's something that, you know, as scary as a writer to see that people are going to be able to use AI, come out with books, which they have to disclose that they've used it. But there's a lot of repercussions of what people's perception of using AI is versus using their own, you know, creative authorship.


[15:36] Yeah, and it will be so interesting to see the next year to five, right, years of product management for all those things that you just mentioned, the goods and the bads, and to see how, you know, on what end of the spectrum we land, or, you know, I guess it could vary. Some of us will be more skeptical. Some of us will embrace it more.


[16:02] I'm with you, though. I see a lot of positives, a lot of pros with, you know, natural kind of trepidation, if you will.


Brainstorming and Collaboration


[16:13] But I think there's a lot of a lot of really good things that could come there. And I really love the fact that you can essentially augment your team. Right. I mean, I think about myself just as a kind of solopreneur or small business owner. You know, in addition to my work at Johns Hopkins, I have a consulting firm and a training firm and I have a new. new company I'm starting soon, TBD. And, you know, I think about that a lot about how I do a lot of the work myself. And that's not what I'm trained to do or used to doing in product management. And so I think, I think you're spot on. I think there's some, there's some good things there, if that, you know, follow up validation is there and, and, and, you know, done in the right way. So thanks for that. That's, that's always important. To me, I find very few conversations I have these days around products that we don't talk about. And I love that you've, you know, researched it and written it, written about it in your book as well, or written about it at least.


[17:13] So talk to me a little bit about the kind of the solving problems in two hours and the design sprints, et cetera. Are there guardrails? Are there types of problems that are better for this mode? Yes. So I think, you know, and especially, you know, if you think back, you know, we're in year 2024, you know, so a lot of the research for this began 2019, 2020, you know, even earlier since I've been doing design sprints for many years before that when the original book came out in 2016 on the five day design sprint. By Jake Knapp and team and the team from Google. So absolutely. So first and foremost, like I'm still a huge fan of five day design sprints for complex problems. So and even the method of design thinking in itself, the reality is organizations don't have time for that.


[18:06] You know, when I'm in the fintech space, when I started at TreviPay six years ago, we had four or five key competitors. Today, I've got a spreadsheet. Our team is tracking over 50 players in the space.


[18:19] I mean, that is the sheer nature of the differences. And some of that enhancement, and we know we talked a little bit about the disruption of chat GPT and open AI. I mean, that's really just the disruption of technology, right? So I think when you have the time, when you have months, when you have five days to go execute on a complex problem, absolutely use that time. But most organizations don't have the time or the budget of Google. And if you've never had a third party come in and run a design sprint, this could cost upwards of $100,000, $200,000, depending what you agree on for the year. And even if you don't use a third party firm and you have someone internal do it, you are spending the time of potentially anywhere from 10 to 50 people in a room, which is going to cost a lot of money and also time away from other projects. So ultimately, how I go about when you should use which, a two-hour design sprint, if you already have an idea of what the problem is and who you're trying to solve it for, go ahead and running a two-hour design sprint on it is really the best answer. The worst case out of it, I would say whether you're running a two-hour design sprint or a five-day design sprint, 80% of the time, you're going to be spot on. You're going to have that solution, but you're going to have a failure rate no matter what, 20% of the time.


[19:36] And that's when you really understand whether or not it's the right process for it. But some items that work really well for a two-hour design sprint are items on your backlog, client requests.


[19:48] Something that is already like a new enhancement, especially for a lot of organization, it's not necessarily a brand new product they're building out of the box, but it allows you to kind of build on existing screens. So we're running around 40 to 50 design sprints or workshops per year. And we have this completely integrated into our process across product managers running them as well as the UX and design team.


[20:15] From a five-day model, you can't really schedule that out immediately. You can't get that in tomorrow. You can't get that in next week. You're usually scheduling that a couple months in advance. And that really is limiting when you are in this like market, this tech market, you have the saturation, you have layoffs going on. You don't have months to wait on really ideating and solutioning a problem. So that's really where solving problems in two hours kind of comes into play is it allows anyone to take this process and execute it with the team, or if they're solo with ChatGPT, whatever it is you need to be able to take that and run with it.


[20:53] And I say that because I have worked with startup and entrepreneurs as well, that they're able to kind of take this process as well. And their problems could be a little more complex. It could be a new mobile app. It could be a brand new business idea. So this is absolutely adaptable really to any problem. So that's good to hear. And thanks for kind of putting that out there, because I think a lot of times folks get intimidated by even design sprints, which by their very nature, the five-day design sprints was meant to be kind of a contraction of what we did before or a kind of a newer way to look at that. And so there's still even some intimidation. maybe that's the wrong word, but, you know, thinking about, okay, how are we going to do this? How are we going to get this done? And to your point about, I mean, just literally the logistics of it, getting people together takes a long time and making sure that you've got the right, you know, the prep and the work done ahead of time. And so I love having some resource that, you know, you can just do almost immediately in real time.


[22:02] The other thing that you really, that you mentioned that I really, really love is that there's a margin of error and that's okay and embrace that, right? And the fact that there's an 80% or 20% margin of error, that's a 80% getting it right. It's pretty good in our world, right?


[22:21] There is no 100%. There is no batting a thousand in product management. And so I love that you've talked about that because I it's important for those out there listening to embrace the fact that anything we do, five-day sprint, five-month sprint, not that that's a thing. Probably. Yeah, probably. I wouldn't call it a sprint at that point, but whatever. But right, no matter how much work we put into something, you're never going to get it right because we work at dynamic markets. It's not like we, you know, we don't work in black and whites, right? So I love that you brought that up. I think that's really important. So I want to ask maybe one more question and then kind of a general question at the end. In terms of... Like, brainstorming ideas. You know, you've got a problem, you get to the point in whatever way your organization does it, to understanding the problem to a certain extent, or at least to the level where you feel comfortable moving forward. You know, who's impacted by the problem, etc.


[23:26] And, like, we all know that there are multiple potential solutions for any problem that could solve any problem. You have some good advice on how companies and product teams and even, you know, individuals or, you know, very small teams can brainstorm about a problem and then find one or two solutions to experiment on? Yeah. And actually, you know, brainstorming ideation is, that's actually my favorite part of a design sprint, you know, whether it's two hours or five days. But some of the best effective ways. So one of the really interesting things I wanted to touch on talking about brainstorming is really the generational shift in how brainstorming is done across generations. So I'm actually a geriatric millennial. I think that's what we're called.


[24:13] And that's a horrible name, but that's what I think. I think there's even like a new generation title for me, but I forgot what it's called. But I was fortunate enough to, you know, have been working in product for almost 20 years. So when I started off, Waterfall was, you know, the methodology Agile. I transitioned a couple of companies over from Waterfall to Agile earlier on. And the reason why I'm talking about this importance is initially in the world of product management, there really was only one solution. You know, you worked on a Waterfall method, you worked on a release for years at a time.


[24:51] And once you had that set concept in there from getting customer feedback, you had that solution. And even if you found out that wasn't the right solution, you're still moving forward with that release. And so I think historically, in the years of product management a bit ago, brainstorming was more challenging because you weren't able to have that iterative approach. A lot of organizations weren't agile at the time. And now I actually find the brainstorming to be a little more refreshing and less challenging. So I've led product teams during this entire transition the last 20 years. So today, brainstorming is easy. Everyone has an idea. In fact, there's too many ideas, right? So that's really the challenge. Not only that, you probably have, you know, I'm going to poke fun at, I'm a millennial, so I got millennials and Gen Z like on their phone, asking chat GPT for solutions probably during meetings now, right? So especially with this AI push with phones. So I think that the best way to offer brainstorming and that collaboration is to really be able to also put ideas out there and create that environment.


[25:58] So whoever is running this process or creating that session really needs to create the energy of the room that there is that open concept. And especially having worked with organizations of all sizes, you know, if you take a startup organization, whether it's a startup organization or an executive in a larger organization, when you bring an executive into the room, sometimes that limits the solutions that are brought up in the brainstorming. And part of that is because everyone wants to be able to side with their chief product officer or their CEO. And so really what I like to have is an open environment. And sometimes I do that by making things anonymous. I make things anonymous in different ways. We have a lot of collaborative whiteboard tools.


[26:43] In my past, you know, I use, I've rolled the whole team to Figma as on Figma right now in the past and vision and other products and tools in the past. But one way to do that is collaborative tools where you have everyone be anonymous and be able to put their ideas out there without who is there. Another way is kind of doing a little bit of team building. So you're able to have that team building exercise. And then I have done some other creative things with organizations, including a little bit of improv, which has been fun in the past to get people to kind of warm up and have that as well. But really, the more you can allow an open environment and really embrace agile, that really is the key. And really, the one thing I've learned in the last several years of this research is there are a lot of organizations still practicing waterfall, especially internationally.


[27:34] And so Agile, while it is very common at a lot of tech organizations in the U.S., it is not everywhere. And we have to be mindful of that. And not every team is Agile and not every team is practicing that concept. Yeah, you're so right on that. And some actually, it even makes sense to be doing waterfall. It's hard for people to hear that today because, you know, everybody thinks it's, you know, the dinosaur age. But there are some product types and some, I always think of it as kind of a risk profile. And, you know, whether it's regulatory approval of a medical device or, you know, a huge capital outlay of some physical product where, you know, you've got to be fairly certain before you make some certain decisions and some moves. And Waterfall just lends itself more to that risk profile or at least some version of Waterfall. And you can always inject some agile principles into it as well. But I think you're right there. And I think it's important to just recognize that. But I love the ideas of, you know, anything that we can do to get more voices in, more ideas, more people comfortable in whatever ways that is needed. I mean, because I think, again, no one person has all the great ideas. And I think it's really, that's one of the beauties of product management is it's diversity. It's bringing in different stakeholders from different perspectives. So I love that. So thanks for sharing that. And again.


[29:02] You know, it's one element of the design sprint, but I think it's a really important one is that product managers either tend to be very involved in or, to your point, sometimes they're stuck in that, well, here's the one idea that we have and we're running with it, even if they're not waterfall, that kind of mentality is still around sometimes.


Getting Started with Design Sprints


[29:21] So I thought that was an important one. So thank you for sharing that. So my final question for you, Teresa, is really more about how to get started and more about you do workshops, I believe. So I want to ask you about that. Like, how does someone get involved in that? If somebody wants to start to learn how to implement a tool, a resource like this, obviously, they need to get your book, which, of course, we will link in the show notes. But in addition to that, how do you go a step further? Or how does a team or an organization get good at using these types of resources? So I think ultimately, you know, if at first you don't succeed, try, try again. So I think it's not a one-time process, right? So as a team, you become better the more you run these processes.


[30:10] So ultimately, I don't recommend just doing one, two-hour design sprint. I recommend doing multiple on different topics and getting that fluidity with your team that And that really is the best way to kind of go about it. And in addition to the book, I have, I also have courses out on Udemy as well on two hour design sprints and different workshop options on 2hourdesignsprints.com as well. But ultimately the goal is, you know, if you have the book or you've taken a course or, you know, you've really just seen this process from content out on the internet, try this process out with your team. The worst you're going to lose is two hours. You know, you're not losing 40 hours. You're not losing that much time. And it's a lot easier to get buy-in from stakeholders during that process. And so first and foremost, you know, get started on what problem or feature you have going on that you think you can use this process for. And then, you know, press continue and repeat. What's the saying that we use sometimes? One-way door and two-way doors, right? Like the decisions or the time we use or the time we prioritize. You know, two-way doors, if we figure out it didn't work, we go back, right? We try it again or we tweak something or whatever.


[31:24] It's a wonderful resource that's not that risky to try, like you said. So I think that's a really good point. So, Teresa Cain, thank you so much for the conversation. I've loved it. So everyone out there, Solving Problems in Two Hours, How to Brainstorm and Create Solutions with Two-Hour Design Sprints. We will link to how to buy that book. We'll also link to the Udemy class so you can have access to that as well. And again, it is 2hourdesignsprints.com, some more information. So, Teresa Cain, thank you so much for sharing your wisdom and having this chat with me. I've enjoyed it. Thank you for having me. It's been great.


And thank you all for joining us on Product Voices. Hope to see you on the next episode. Thank you for listening to Product Voices, hosted by JJ Rory. To find more information on our guests, resources discussed during the episode, or to submit a question for our Q&A episodes, visit the show's website, productvoices.com, and be sure to subscribe to the podcast on your favorite platform.


[32:21] Music.

bottom of page