Aurelius Podcast – Episode 69 highlights with Teresa Cain:

• Evolution of the Product Management role over the years
• Tips for collaboration between UX Research and Product Management
• Vital role of UX research in product strategy
• Stakeholder engagement in the prioritization and delivery of and UX Research
• How to solve problems in 2 hours

In this episode we have Teresa Cain, Director of Product Management, User Experience and Design at TreviPay and author of “Solving Problems in 2 Hours”. Teresa has an interesting background with a mix between UX and product management across several industries and companies.

With that, we talked about the evolution of product management over the years and the overlap and relationship between product management and UX and UX research. Teresa shared the details on the vital role UX research plays in building products at TreviPay and how they plan, execute and prioritize over 100 research projects a year.

She also shared a bit more about her approach to design sprints and her book with solving problems in 2 hours, more especially how to engage stakeholders in that process as well as including research insights to guide the sessions.

Links from this episode:

• Solving Problems in 2 Hours book
• Teresa Cain on Linkedin
• Teresa on X

Episode Transcript

(this transcript was automatically created using our very own transcription feature in Aurelius and has been minimally edited 😀 )

Hey Theresa. Hey Zach. I appreciate you jumping on join us for this episode. We were chatting a little bit before we started hitting record here about your background. And it’s a pretty unique blend of, I think, a lot of folks who probably listen to our show.

And so before we even jump into anything, I don’t want to not do it. The property, the proper justice, maybe tell folks a little bit about yourself, your background, and kind of where you’re coming from so folks understand some of your perspective as we have this conversation. So I’m Theresa Cain. I’m the director of product user experience and design at Trevi Pay, which is a global b two b fintech. And I’ve been there about six years and then I’ve been in the product, tech and ux space for about 16 or 17 years in leading different teams, products across b two c, b two b.

I’m also a leader and coach for startups, entrepreneurs and have a few courses out on udemy and teach live courses as well. Right on. And author to boot. Right. And I wrote a book.

Yes. That’s probably a good topic to talk about. Yeah. Wrote a book called solving Problems in 2 hours. I’ve had a couple editions of it and it’s been fun to kind, kind of see where the journey has taken me, uh, all over the globe.

Yeah. So, you know, as you describe your background, I think one of the big questions a lot of folks often have, maybe yourself, and who better to answer it than somebody who literally, you know, essentially straddles the line between both product management and ux, you know, for you. And it’s, I think it’s fair to perhaps answer in your day to day work, uh, maybe not for the industry at large, but you know, what’s the big difference between those two things? Because I think there’s a healthy overlap. I feel like a lot of people who work in both probably acknowledge that, but it could be a little different depending on where you’re at.

I always like to ask folks who are in both, where do you see the differences, the overlaps and perhaps not. So I guess that depends. Are you saying between product and UX or B, two b and b to. C product management and UX specifically since. There’S challenges across the board?

So no, that’s a really great topic. So there has been a lot of overlap between both of those. So when I started off in actually really lucky, I got my start in product pretty early on in my career after leaving college and in the mid two thousands. And that’s a rare find and I will say it’s just changed over the years, especially now as a leader. So, you know, product managers used to be called the mini CEO where they held different roles.

And I know that’s a term a lot of people don’t like and, but with that it’s really morphed over the last 1520 years. So now we have these other areas of the business, user experience and research and design, you know, being some of those areas, well defined sales role, strategic innovation. So really with those differences, a product manager role really kind of comes down to a much smaller version of what it was 20 years ago. So you really are focused on features, working with engineering teams, really defining scope, understanding who the customer or businesses that you’re creating these different products for, whereas user experience and design is really segmented out into deeper research and understanding to help the product manager. So it really is an adjacent role that is integrated well to help the product managers with things that they don’t have time for.

And it sounds like you’ve experienced, I don’t know, for lack of better term downsizing of that role. You said it used to be kind of referred to as Mini CEO. I’ve definitely heard that as well. It sounds like you’ve experienced a sort of more consolidation or more a tighter focus brought to that role over time. Yeah, I definitely think a tighter focus has been brought at both the product and leadership level.

And I really kind of akin this to the transition from waterfall to agile. So if you think, you know, back 1520 years ago, a lot of software shops especially were practicing waterfall where, you know, you’d work on a large product for two to three years. So you really were a subject matter expert of this product. You spent a number of years focused in on a set strategy. You weren’t bringing in anything else into that release.

That was your set. Where now most software shops, especially over in the US, I would say globally, worldwide, you know, there’s still actually quite a bit of waterfall going on, but particularly in the us areas where a lot of organizations, most of them have moved to an agile methodology, so their product managers. So you now have broken down different chunks of product management where you’re managing, you know, small segments of teams focused on different feature areas. And at Trevvy pay alone, we have 27 engineering teams. You know, we have around 700 employees, 27 engineering teams, over 100 in product intact UX design altogether.

So each of these teams are focused on different bite sizes of information. So that in itself has changed the role of a product manager from being the mini CEO of these massive solutions to really owning a tight space of a solution that they’re focused on for that strategy and executing on that product. Got it? Got it. So really the change in approach to delivering this stuff almost required also then a change in responsibility for those roles.

Absolutely. And akin to UX and research that tied into that, a lot of organizations really relied on product managers for this role. In fact, I’ve held a, I’ve worked for a number of startups, Fortune 100, 500 organizations in my career and I have had product roles where I was the mini CEO, I was selling, I was doing the design, I was doing the wireframes, I was doing the customer research, I was launching, I was implementing, I was fixing bugs, I was doing it all. And really it’s not really just for startups or entrepreneurs. Were those mini CEO roles.

This was for large businesses that had tons of dollars to spend more elsewhere, but that’s how they focus that product role. So now kind of what you’re seeing, you see these little different departments of user experience and research. And in fact Nilsen Norman Group had come out with a report before the COVID pandemic. I would love to see how their report has changed or morph since then. But they came out with this report that said they expect the area of user experience, which is inclusive of design as well, to grow by 50 x over the next 50 years.

So a huge jump in this number and research and so, and part of that is because of the segmentation of this product role. So you have these dedicated departments of user and experience. You have what was encompassed in product roles, product marketing, which is now their own separate divisions out of marketing for a lot of organizations. Um, you have dedicated QA departments that were put on the product manager and you have more robust, dedicated sales operations role. So it’s really just all kind of divided out into other departments for most companies now.

Yeah, thats really interesting. I mean, to hear a little bit about the history on that too, because I think that there is, like I said, kind of beginning of this, a healthy tension and shared responsibility that a lot of folks are still trying to figure out. You mentioned several times, Ux and research specifically. So because thats the majority of folks who listen to our show, I have to ask about that specifically and how a youth, how you’ve managed that even maybe in your role today. You know, the, the balance between responsibility of learning from the customer, acting on it, and then making sure, you know, everybody on the team is, is benefiting from that.

So I’m super passionate about UX research and design. And I’ll have to say like, I’m very lucky. I have a really fantastic team that works for me at Trevi Pay. And it probably wouldn’t be the success it is without those individuals, and not just because they’re probably listening to this podcast. I mean, I mean it full heartedly, but no, I mean, I think in terms of, I’ve always really been attached to the customer.

You know, it’s all about customer happiness. And so whether you’re in a product role or UX research role, and here’s how that UX research role has morphed over the years. So when I got my start a while back, I had first implemented a product called Clara Bridge. They are since then now more focused on text analytics than they were strictly VoC voice of the customer, or NP’s. And that was really the start of where I think UX began in terms of understanding who the customer is, what data inputs are you getting, how happy are they as a customer?

And then we’re all familiar with the term, it takes three extra happy customers for every customer that leaves, it’s unhappy. You have to work that much harder to get those customers back to create happy customers environment. And now you look at a world where the market’s saturated. When I started at Trevupay five, six years ago, we had five or six key competitors, and we now have a spreadsheet of 30 to 50 competitors that may be direct or indirect in our industry. So this is where UX teams and research teams are critical.

You can’t just do research one time and put it aside, which really, you know, the construct of the book, solving problems in 2 hours, kind of came about. A lot of organizations were using five day design sprints and scheduling them out six to twelve months in advance. They had these big problems they were going to tackle later in the year, and that becomes a problem, especially being in the world of fintech that I’m in now. There are competitors popping up every day. If you wait to schedule your research for the second half of the year or the year after it, you’ve already missed your opportunity to grab those customers and really go to market.

And so really encompassing research, you need to be doing research every single day. And I believe that in terms of how I operate the team as well. So our teams are running over 100 research projects a year, and that could be anything from customer interviews. We do a little bit of surveys, but not full focused. But my favorite part of research that’s become more expansive now that Covid has kind of gone in a little, is getting back on site.

So the best research, in my opinion, is being on site, understanding the problems of the users firsthand and seeing those workflows firsthand. So that’s really how I approach that and bringing that back in with product managers. I usually like to have the UX researcher running those sessions and the product manager is there to learn, but they don’t have to do the work of putting together the concrete evidence while making those decisions. Thats great. And I appreciate that you also took the liberty to define what research is for you, because I was going to ask that anyway.

So I was really glad that you jumped into that sort of unprompted. One of the things that made me think of this so you said over 100 research projects a year, which is certainly sizable, especially if youre considering each one of those might take a week or two, three, four, depending on the size of study. One of the big questions that popped in the back of my mind is how do you determine what research to do? How do you determine which research projects to act on? I’d be really curious to hear what inputs there are to that, how you prioritize it, how you plan for it.

So there used to be an old saying, follow the fire. So I won’t say that’s necessarily the approach, but I think in terms of prioritization, you have to prioritize it a couple of different ways. So in terms of following the fire, what is really the highest topic or item that’s going on right now that you need to have a better understanding of? And this could be twofold. This could be from a competitive standpoint where you’re getting hit really hard on a particular feature and you need to do immediate research.

Or this could mean simply you have a fire with a client that’s complaining and you need to put a new feature in. And so in terms of that criticalness, we have a method that’s called steering. So every quarter, and I have this for product management as well. In addition to UX indesign, we have a quarterly steering process where we have stakeholders from across the advocating internally and externally for customers on what we’re going to steer and prioritize. So we set this and prioritize it every quarter.

And then we work on agile. We’re an agile shop, so we work on a two week sprint cycle. And that really sets, sets a tone for how we prioritize at a quarterly level and then for our yearly roadmap. But then we have something called resources. If we have an urgent matter we need to go address, for instance.

You know, this is something that happens for a lot of organizations. You have a forgot password on your website, but you’re still getting a lot of phone calls or emails in about it, even though you have it there. So you need to gain a deeper understanding of why users aren’t clicking on it. And this is something I’ve had to do for multiple companies. And it’s something so simple, the forgot password.

But it for, if it’s not in the right place or doesn’t have the right experience, users won’t use it. Yes, there are little things like that that exist in every single product that get overlooked, and I could share stories about that as well. Makes a ton of sense. So really this is happening quarterly. It’s based on, it sounds like a much higher, essentially executive level leadership steering committee to say, hey, you know, this is what’s important to us.

And then this gets back to the teams and they say, well, this is the kind of research we can do to essentially fulfill on that. And, and, you know, really what it comes down to is to be able to provide intelligence to act in that next quarter. Am I getting that right? Right. Not only just intelligence on how to act, but by doing a quarterly steering, you’re getting buy in not just from the leadership team, but from stakeholders across the agreeing on that.

So if that strategy does go wrong, it was a decision together as a group to say, hey, we made this decision together. Do we need to reconsider it for another quarter? But this isn’t something again. So in addition to running it with UX indesign, which is kind of much smaller, we’ve got around five to seven on that team. We have over 20 product managers.

And so the product managers are each running their own steerings. And then the same with UX indesign as well. Got it. Now, are some of these topics for research coming from the teams and bringing it back up each quarter to say, hey, these are things that, you know, each, each of these teams, respectively. And then, you know, someone like yourself and others are representing at that steering.

Yeah, it’s usually a mixture. So for product managers that are constantly in the weeds, you know, working with customers, understanding what’s going on, working on features, there is a request process, so they are requesting research. But then some of it is really from a leadership strategic standpoint of, hey, we’re seeing a lot of this going on. We probably need to research it and understand. And then being a progressive fintech organization, we do a lot of progressive research on where we should be going and where the market is going.

And a lot of that is learning from your existing customers, your prospects, and then really, again, getting on the grounds and understanding where each area of the business is out in the field. Yeah, that’s a really big deal. And I think a lot of researchers, especially more veteran folks, like doing that quite a bit, that sort of future facing stuff. But keeping the lights on is just as important of like, well, what’s working in the product now, what’s not, and make sure that we’re adjusting appropriately. It’s interesting to hear that you’ve got that mix going on.

So as were talking about, all this research is obviously important to product. Youre doing it nearly every day, over 100 projects a year, which is awesome. Talk to me a little bit about then how that work and that responsibility plays out between these two roles as a product manager and as a UX researcher. I think the UX researcher part is maybe a little self obvious, even in the title. Right.

But I’m really interested in how product managers work with those folks to, to both capture that, prioritize it and then act on it. Yeah. And I think the best way to talk about it is to talk a little bit about the history, you know, and I think I have been in product roles where I have, I have a little bit of a design background. The designers I have on my team now are about 100 times better than me as a designer. That’s why I’m a leader.

No, but, you know, I’ve been in product roles where I was creating wireframes and I’ve had designers create high fidelity mock ups. I’ve had them where I’m creating high fidelity mockups and transition to, you know, today and how it’s working. At Trevi Pay, our product managers are not doing wireframes like they were, you know, several years ago, where even where they’re creating basalmic, they might be doing some workflow management. And that really has attested to a lot more work that’s been put on the UX researchers and designers. And in fact, the designers I have are not just designers.

Each of them are doing UX research as well, and maybe have one or two that are a little more design focused. But every single designer that works for Trevi Pay has to have that UX research background, but so does the product side. So the best way to kind of work this together is we have around five to seven on the UX design side and around, you know, 25, 27 on the product side and so we have a goal for every product manager to make sure that they’re completing and working on a collaborative UX research project, at least for like once a quarter or four times a year with a UX researcher and designer. So this gives a really healthy goal to say, hey, every quarter I should have a touch point. And that could be a few different things.

One, we have a pretty robust set of user Personas. So we have over 30 user Personas. We have a really heavy focus in retail, automotive, marketplace. Like we’re kind of in a OEM manufacturing. We are a little bit everywhere, and Personas vary across those different industries.

So that could be one research project that a product manager could say, hey, I think we need to have updated Personas, which for, I know, I know everyone on this podcast knows what Personas are, but for anyone new listening how we go about Personas, we like to again go on site when we can. When we have to be remote, that’s fine. But a really good Persona match is five to ten visits or interviews and being able to encompass that and validate that. We’ve also seen a change in the likeness of Personas. I don’t know if you’ve seen this, where a lot of people don’t like Personas like they used to, and a lot of people have moved to, you know, just strictly jobs to be done.

They don’t want to focus on that. So I like to offer up both, both terms in terms of research for that. And that’s just one. One type of user experience project. Another one is, you know, really just a survey.

So one of the really great things that we’ve done, we have a partnership with Medallia, who is NP’s focused. We also partner with amplitude. So we have a lot of different data elements that we’re able to incorporate that’s not necessarily on the role of the UX researcher or the product manager. It’s data that’s automatically happening when people take a survey through Medallia or someone just clicks on your site and does a different exercise like the forgot password. That’s a way to understand what are they doing when they go to your site or your portal.

So those are different activities as well that I put on the product managers to say, hey, what are you going to do with this data? Looking through and filtering with the data. And we actually have. I talk about another role that’s taken off the product manager’s plate here. We have a head of customer experience now, a director of that that focuses strictly on that to provide data to the product managers on him.

And so as you look at this, and I’m talking about this, look at all the different things that are now taken off the product manager’s plate so they can focus on keeping happy customers. Yeah. So there’s a couple of things that you said in there I definitely want to dive deeper on. The one I love is that you actually set up, it sounds like you set up goals for each product manager or product team, however you have it structured that they should be able to report back insights from a research project every quarter, or maybe it was every month. Every quarter?

Yep, every quarter. I love that that setup is a goal. Can you talk a little bit more about like that specifically and maybe more to that end, how you’re measuring that goal and how you’re keeping, you know, holding people accountable to it and things like that? Yep. Um, so in addition to it being a goal, we do use OKR.

So objectives and key results. We also do KPI. So really making sure that it is accounted for from accountability standpoint is making it an OKR for a larger objective. And with that, in terms of it being a quarterly, what I really have, so I’m super fortunate I’ve got a head of UX that rolls to me, and so I have him that I actually, both of us, we meet with the product managers and we talk about what are projects that we could work on for your product or your program. And, you know, I think one of the things that’s different, so every product manager has a different workload.

So not every. Not everyone is a product manager. One, some folks are senior product managers, some are manager products. Everyone’s got a different workload. And so really making sure that we’re not overloading the product managers.

But sometimes we do get pushback saying like, hey, I don’t have time for this. And so there have been times where we come to agreement that it’s only going to be three for the year instead of four. But everyone’s been pretty good. I would say, like over 90% success of everyone completing at least one per quarter. And I will say our UX and design team have made it pretty easy.

I mean, they’re running basically all of the exercises here. They just need to be there to understand what’s going on in the results and the impact to their product. But I like to have at least a minimum of one. But two, have the product manager run the exercise instead of utilizing the UX research team, because ultimately, we’re all on our career and life journeys here. You know, the likelihood of a product manager staying at a company for more than three to five years, especially in the millennial generation and certainly the Gen Z generation, it’s more one to two years, you know, so I want to make sure they’re prepared not just where they’re at now, but in their future.

So I think it’s important to be able to run that on your own. You’re going to have different roles at other orgs where you still have to do wireframes, you still have to do high fidelity. You’re the project manager, and you’re running all this on your own. So that’s the value there of that balance. Got it?

Okay, I’m curious, what form does that usually take? So let’s say study wraps up. Doesn’t matter what it is. Maybe we’ll use an example. You did 1015 interviews to learn about a certain topic.

Once that finishes up, what happens next? How does that get shared out? I think a lot of people listening to this would probably be pretty curious just to hear how you and your teams handle that. Yeah, so we’ve got a pretty robust library of how to. So, best practices for running a user interview, best practices for running a focus group, best practices for analyzing survey data, and we’ve kind of got a variation of those with different degrees that are able to analyze the data as well.

And so ultimately, how this plays out, let’s say. Let’s just go with the survey, because we’ve been running a few surveys lately, and actually where I worked at before Trevi Pay was service management group, which is a really well known survey company that does a lot of omnichannel CX solution. So also a big passion of mine is I’m a big data geek because I love data, and that’s what I did there. So, in terms of a survey, let’s say you have a client and you have a sample size of 10,000, and what you’re really wanting to understand from this customer is what they like or don’t like about the portal. So you probably set up seven to ten questions, and you ask a series of interactions, and, you know, you validated already that they log in.

You have this data from amplitude, you have data from Adelia that they took an NP’s survey. So we have opt in for customers to say, hey, not only can you contact me, but I’d love to take a survey, or I’d love to do a design session. And when we have this opt in on a lot of the elements on our site, we actually have over 30% of our customers saying that they’re willing to participate in these, which is like a huge number. But this is your database. This is your database of customers to interact with.

And that’s how I go about building. It is I build in opportunities for those to opt in. So that’s how I built my sample size. So let’s say based on that sample size, I now have 10,000 emails that I’m going to send a survey to. And there’s two different ways to really prompt this.

And again, I mentioned we partner with Medallion. We also use surveymonkey for one off events, but it really just depends on the industry you’re going. So in the retail and restaurant space, and again, I’ve got, you know, pretty big background in CX, you tend to have a higher response rate when you get into the automotive space or airline space. You have a lower response rate from that realm. That’s just how it is.

That’s been statistically the way it’s been since I’ve been into this research. So you send that out and you kind of start seeing your sample size. And so you might get a response back 15% from retail customers and only 1% back from your automotive. And so ultimately, while the product manager’s role here is they’re helping refine the questions based on what they know their users are clicking on in Google Analytics or amplitude and based on the survey data, and then the UX researcher is kind of structuring the survey, making sure we’re not having any bias and so forth and sending it off. And so then it becomes a partnership of looking at the data together to say, hey, are we understanding this data correctly?

And the biggest value from the data isn’t necessarily what you’re getting statistically. Like, 5% took the survey. Here’s how everyone answered x. But it’s usually the verbatim or the comments that come back of like, hey, did you know this button’s actually broken on your screen? Or, hey, I’d really like it if you could generate, you know, this report for me.

And those are the, you know, morsels that you get to analyze as a product manager, you now have to action, and guess what? You now also have the customer that wrote it because they opted in. So that’s kind of how we organize it. And then presentation wise usually involves a deck. The deck invites everyone at a leadership level or that is a stakeholder of that program or project, and there’s a presentation, a deep dive of the data, and then from there, it’s actionable tasks, on who’s going to execute on the deliverables.

Nice. And who’s usually giving that presentation? Is it the researchers, the product manager? Is it both partnered together? Partner together?

So usually I’ll have the UX researcher and then the subject matter expert, the product manager for the program or the content, do it together. Because ultimately you have to be involved with it as a product manager because you need to understand the outcome of it. You can’t just be listening as someone on the sidelines. You need to understand deeply what you’re actually going to change. Yeah, that’s really, I agree.

That’s really critical. It reminds me of a quote from Jared spool long ago saying that if you outsource your UX research, it’s like outsourcing your vacation. You get all the pictures, but you didn’t have the experience of it, so you didn’t actually get the benefit from it. So I think that that’s great that those folks are involved sort of hand in hand. The other thing that I thought of is I have heard a lot of discussion and debate of who owns recommendations or action items that comes out of this research.

Talk to me about how that happens, because you said that is part of this. There is this presentation, it’s a joint effort between product managers, UX researcher. Then there’s the so what, who owns the so what and what do we do next? So usually these are a complex amount of data points. So one would think to themselves, and in a product manager role 1520 years ago, it would all be on the product manager in the way that product manager roles work now, where data is kind of gone across different teams, and especially when you have products that have been around for a long time.

So some of the products have been around, you know, over 2030, you know, 40 years for the most part. So, so this kind of changes the path to that. So especially in the world of fintech, you know, I didn’t talk a lot about what we do. So we’re a global billing and invoicing solution. We process 7 billion in transactions a year across 27 currencies, which is a lot, a lot of data coming in and out.

So what’s on the onus layer of the product manager is really the global billing solution. But what happens to really support that solution is a white glove experience where you have an account manager, you have underwriters that are approving credit lines, you have compliance, you have all kinds of different teams that are supporting the product manager and helping out and kind of taking some of those roles in addition to that, you have, you know, an entire engineering team, Qa. We already talked about UX indesign. So a lot of this gets broken up depending on what’s going on. So something really simple with our product and very well known is, you know, invoices.

We generate invoices. So something as simple as the ability to quickly download an invoice or upload an invoice. So that’s something where, yes, the product manager would be responsible to say, hey, this is a new feature that we have coming out, and they would start doing the research on it. But in order to make that happen, they would need to go to compliance, especially if it’s international and there’s something called VAT. They would have, you know, different touch points within the organization that they would need to work with and possibly delegate different deliverables, too.

But that’s how it would all be on the onus of the product manager now to go execute on this task and then kind of come back around and say, hey, these are the things that we pulled in as user stories, and here’s the remaining items that were across support or underwriting or other teams across the board. Got it. So the research gets done. Joint effort between product manager, UX researcher to share this information, this knowledge with folks. And then product manager is really saying, okay, here’s what we do and in what priority, because there was a lot happening in back channel that was not part of that meeting, per se.

Uh, but then they can speak to those things and why the insight supports the priority and suggested next actions that they’re, uh, that they’re recommending. Is that. Yeah. Right. Yep.

You got it. All right. Very good. Um, you, you know, so you’ve written on the topic of solving these problems and figuring this stuff out, uh, specifically in 2 hours. Right.

I’m kind of. I mean, I have to ask, how does that all play in to some of this work that we’re talking about? Yeah. And this actually definitely played into how I came about creating the process of 2 hours. So even though the book has had a couple additions last couple of years, the research really started back in 2020, right around the time of the pandemic.

So we are a global team. We have around 700 employees, countries all over, Costa Rica, Netherlands, Australia, to name a few. And so there was already a challenge when we just talked about the product manager, all the things they need to go do. Now, imagine doing that with a team of remote people across the globe on different time zones. And so we’re constantly needing to innovate and solve problems.

And before the pandemic and before I even came to Trevi pay, you talked, something you talked about earlier was having to hire get expert advice from outside the versus inside the five day design sprint that was created, which is fantastic and I still think you use for complex problems as an.org that you want to solve and spend that time for. But the challenge with those is you were basically paying a third party to come in and make a decision for you in an area that you’re an export as an orgasm. That was something I always struggled with of why am I putting, you know, 100, $200,000 in my budget to bring in a third party to do this? And it wasn’t something someone at the time internal was running. This was a lot of third parties were running these and still do.

So I had already parsed down design sprints to a couple days where I was running them, and not just me, orbs all over were already doing this because no one has time for five days. So when the pandemic hit, had a really challenging problem, wasn’t related to invoice, but somewhere in that area, and I needed a solution on it. This is where the follow the fire goes, right? Like I needed an answer now, not three to six months from now after I got approval to go run a five day design sprint with 40 people from across the. And so at the time I did some research on, hey, how do I go run a virtual process?

And back then in 2020, there was nothing. If you go look today, you’ll find loads of stuff, but nothing all today someone would just go use chat, GPT or bar. But you know, back then, you know, it didn’t exist. And so I had already been reducing these down to a day at this point. And so I actually trialed and did several four hour design sprints.

And how I got down to 2 hours was strictly an engagement thing. Getting 4 hours of people engaged from all over the world not only didn’t work as well, but from a time zone standpoint, I’ve got folks in Australia, folks in the UK and folks in the US. So someone’s always got to give and take a little bit in the morning or night for some of the conversations that I was running. So that’s ultimately how the process came about. Tied with I’ve got the research and design team and product managers both running these, and we’re running around 52 hours design sprints a year.

So this is in addition to all the other research, and this is really at this point, an additional data point and research that allows us to go through a two hour problem solving exercise and move a certain direction for all these different features sets. Okay. So, you know, uh, pull the curtain back a little bit, talk about what this session looks like, this two hour session, what goes into it, and, um, you know, maybe, maybe even share a recent success of how that’s gone. Yeah. So, ultimately, with a two hour design sprint, you first need to have a topic.

Uh, so this could be something on your backlog. This could be a challenge that you’re experiencing every day with users, something that’s kind of coming up a lot, or an executive request, which, you know, also happens a lot for a lot of organizations. And the first part and differentiator of a two hour design sprint is, I like to keep it at 15 to 20 stakeholders. So this is a differentiator than the five day design sprint where, you know, you can have 50 to 100. And I’ve certainly run two hour design sprints with that many.

In addition to running these for Trevi Pay, I’ve run them for organizations around the globe. So definitely done that. Don’t recommend it. It’s good to cap it at 20. We could talk about why that doesn’t work later.

So once you have your stakeholder mix, you have your problem. You have your stakeholder mix and the intent and creativity around this process. Your key goals are getting stakeholder alignment and being able to work together to come up with a solution. In the differentiator. Between a five day design sprint and a two hour one is during a two hour design sprint, you as a group are deciding, you are the decider as a group on whether or not you move forward to testing, to prototyping and testing.

Whereas a five day design sprint, even if the entire design that you put together wasn’t good, and I almost cursed there, but I held it into myself. Even if it’s not a very good design, you still do prototyping and testing, and you’ve been so a lot of five day design sprints I had run over the years failed, and we wasted just so much money. Not just money, but time. And the biggest impact, though, was the morale was thinking you had a solid design, and then you put it in front of customer and they said, I’ll never use it. Like, why did you build it this way?

This is how I want it. So the intent of a two hour design sprint is to put that in front of the customer after 2 hours so you can know whether you are on the right track for a solution instead of wasting 40 hours and then getting that feedback. Got it. Got it. So, so, you know, really, really curious, like what’s getting removed, you know, in order to reduce it down to 2 hours as opposed to five days perhaps.

Yeah. So really first, I guess, first and foremost, a lot of just two days of the five day process is a lot of time that really doesn’t need to be in there. So a lot of organizations build in breaks, they built in breakfast, they build in all kinds of things that aren’t really productive. They’re counterproductive to solving a problem. Also, why that time was even built in was because a lot of organizations were using third parties.

So the biggest amount of time that you’re saving is you have all subject matter experts already, you don’t need a third party. And a lot of why the time in those five days is you’re really actually keeping up to speed the third party you’re bringing in. So they understand what the heck is going on. So now that you don’t need that, you’ve already chopped down two to three days of getting them up to speed on what your company does and what you’re trying to solve. So when you break it down from there, a lot of the things that are removed are really kind of noise.

So, so I will say again, for complex and large problems, I think there is still time and place for five day design sprints or even multi day design sprints if you’ve got something a little bigger. And so these are really small or medium sized features where you as a group are collectively trying to move forward with the decision. So let’s just talk about one of the design sprints that we’ve done and talk about the outcome. So let’s say you’re wanting to add a search box to your dashboard. So this is something I’ve done.

A lot of people are probably familiar with elasticsearch, which basically allows you, if anyone’s ever used Google or Amazon, you’re using elasticsearch, you’re using that capability where you could type in anything you need. You don’t need to use, you know, different metrics in the past like bullions and so forth. You’re able to type in whatever you need and it’ll find it. So this is the feature that you’re wanting to agree on as a group. So for this particular feature, you already know you have the data point.

Customers have already been asking for it, they’ve been complaining about it. You already have a rich data set, and that could come from your UX researcher or product manager. Those are two stakeholders. You add in there. Another stakeholder adding in here is a support representative.

They’re getting a lot of angry calls asking, saying they can’t find the invoices that you’ve been downloading. That’s what they’re wanting to type in there is find my invoice. So you’ve got your support rep, you have your account manager. They’re over the products or programs that you’re on there. So you kind of see adding different stakeholders from across the group.

You want to throw in a couple executive presence stakeholders in there as well. So you have your entire subject matter expert group here to talk about the value of implementing a search box and why. So during that 2 hours, first you talk about the why. You talk about the problem and who the end user is once you land on that. I like using Personas.

I also do, I get, I do jobs to be done. Also I talked about, it’s funny, not every organization I’ve worked with is a fan of Personas. So I always use jobs to be done as well. From there, you’re really kind of, I do a how might we exercise that really helps you reframe the problem into a challenge. And this is something that has carried on, you know, from the five day design sprint mentality a little bit.

And then from there, really what you’re doing is the biggest part of a two hour design sprint is moving the group to agreement on understanding whether you have the problem, the correct problem together, that you have alignment on how you could go about solutioning. And then the last stage is the solutioning. So the solutioning part, what’s interesting, when you have a small or medium problem and you have a seasoned team that has worked together, you don’t necessarily need to go into prototyping and testing. So this is something your customers have already asked for. So you know that you don’t necessarily need to go spend five days getting their feedback later on.

So for this particular one goes right into development. You get the user feedback during the acceptance of it, but this is kind of a way that it’s really meant to help organizations do something they haven’t been doing before. Sometimes organizations are just skipping over solutioning together and just putting what they want in there. And so that’s really the intent around the process. Got it.

So this is presuming you’ve got Personas or jobs to be done, laid out an understanding of the customer already, and in your case, likely some pretty good data through research, through customer feedback and all these things of the thing we ought to do. And then really it sounds like the two hour design sprint is let’s get everybody focused around that quickly share, quickly build consensus and then decide on a solution. You got it. Perfect. That’s part of my job as the host on this is really just trying to digest, digest down what the folks we have on are discussing.

And so that’s, that’s great. And I appreciate the fact too that, you know, you even call out like, hey, there could be bigger problems that multi day design sprints are still useful for. And if you don’t have this information, guess what? You should be probably focused on doing UX research and otherwise to make sure you have that foundation of understanding to be set up to do to our design sprints appropriately. Yep.

And, and you know, I will say the one caveat is it does look a little different for your startups or smaller shops. So I have worked with a number of startups, entrepreneurs that don’t have the resources or the amount of stakeholders that they really need to implement this process. And so that is something. And you could have, you know, ux researchers where they’re actually doing the flip side. They’re the UX researcher doing the role of the product, doing the role of the designer, and are on this island running these processes to try and get what are most of the time the CEO, the actual CEO’s of these companies that are running as kind of product in their, with their strategy.

So that’s really where this process isn’t just great for larger organizations, but also startups and entrepreneurs that are able to kind of come to fruition with an idea utilizing. A lot of times some startups will bring in external parties into that to replace the internal group they have, which is what I help with, and run a successful way with that external feedback. Got it. Nice. And I’m sure that there are people listening who are in that position probably wondering that question themselves too.

I realize that we’re coming up to the close of our time with you, and I have several other questions, but we got to be respectful of your time. The way we like to close these all the time is I ask if I got hit by a bus or developed temporary amnesia and somebody came to you and said, hey, well, what was that podcast all about? How would you summarize and how would you answer that question for them? Can I say that I have amnesia? No, I’m kidding.

Yeah, actually that’s the first time we’ve ever had that answer. That’s the best response to that. Well, we don’t know you just have to go listen. I have to listen to it. No, I mean, I think some of the core components we talked about are first and foremost, having a UX strategy as an organization will make you more successful.

And it doesn’t matter whether you have a UX team, a design team, a product team, or you’re running a solo shop. But there are ways for you to put in best practices by getting feedback from stakeholders, making sure that you’re implementing multiple research touch points with your customers and internal stakeholders. And that’s how you get ahead and stay relevant in your space. No matter whether you’re in a fintech, fintech or another area of the business, that’s how you stay relevant. And ways to do that are different research methods we talked about so you could run surveys, you can run focus groups, you could have different elements of internal research on site or running a two hour design.

Awesome. Awesome. Is there anything else you want to share with folks we didn’t have time to cover today? Well, if there’s any more interest in two hour design sprints, I know we just touched on it briefly. You can go to twohourdesignsprints.com.

I’ve also got a couple of courses out on udemy on two hour design sprints as well. Nice. And we’ll have links to those in the show notes where you listen to this. And of course, once the episode is out, folks will hear everything that we talked about, regardless of our amnesia, and hopefully reach out to you directly if they have any other questions in those channels as well. Theresa, want to say thank you again for jumping on and having this conversation, sharing your insight, and then also, you know, especially some of the work that you’ve done and how to our design sprints might help, folks.

Thanks for having me, Zach. It’s been fun. Absolutely. All right, everybody, we’ll see you next time.