S1E6: The 2 Hour Design Sprint

When rolling this method out on a new team or a new team that hasn't kind of worked together on this process,
the biggest gotchas are really trusting one another with the process, getting everyone to actively participate and engage in the solution.
When you roll out a process like this, not everyone understands that everyone has the opportunity to bring an idea or a solution to the problem.
That is hard for many organizations to understand that everyone has a voice.
So that's really the biggest gotchas, making sure you have the stakeholders prepped and ready to be engaged for that full two hours of engagement.
Hi, I'm Karl.
And I'm Danielle.
And this is productly speaking.
We're product managers by trade.
And here we explore the world of product management.
It's people and their stories.
We promise to keep it entertaining.
And maybe you'll learn something.
Shall we give this a go?
Let's do it.
On today's episode, we will talk about talking through problems before jumping to solutions, which product managers are often under pressure to do.
We discussed the concept of the two hour design sprint that allows you to solve problems in two hours and helps energize and unite a whole team around the solution.
We also talk about incorporating some best practices, including ideas to help level the playing field so you ensure everyone has a voice.
Teresa is an award winning author and public speaker with over 15 years experience in product management and design thinking.
She really knows how to accelerate teams towards their goals.
Teresa is the director of product and UX design at TreviPay, where she has driven product vision, strategy and user experience for multiple fintech SaaS platforms for nearly six years and as coach businesses and startups around the globe.
Teresa authored the book Solving Problems in Two Hours.
Diane Kander writes on the book.
This book is great for entrepreneurs, product managers, researchers, designers, startup founders and business professionals who want to accelerate their problem solving skills and improve their business strategy.
It gives some great tools for solving problems, whether you're an in person or working remotely, and it provides a different perspective on problem solving.
And with that, we'd like to welcome to productly speaking, Teresa Kane.
Thank you for having me.
I'm happy to be here.
Thank you.
Yeah, thank you for coming on.
So let's jump into the first question for PMs that haven't worked in organizations with mature design thinking and maybe don't know what they're missing out on.
How would you describe the value of design sprints and specifically the two hour design sprint?
With the two hour design sprint method and really what I'm seeing a lot of these days with product organizations is the product manager is really meant to be the mini CEO.
And sometimes that means you're holding roles of UX design, project management and product management.
And so the two hour design sprint and really the intent of the book, Solving Problems in Two Hours, is you're able to have a product manager execute and fulfill that design or UX role that they're not getting from their organization because of budget or resources.
With the two hour design sprint, they can encompass all of design thinking and making sure they're thinking through and researching a problem that they have that they're looking to solve and also being able to execute it pretty quickly.
Since most organizations are using Agile today versus Waterfall, which is what I started off in years ago.
So while design thinking is definitely a well-defined piece of work already, could you give us just a little bit about on what your perspective is on design thinking and how that can benefit a product manager?
So I'm obviously a really big fan of design thinking.
So in addition to being over product management, also over UX and design and have been for years, the value of design thinking is not just coming up and working through what you're solutioning.
Oftentimes, I think in product management, we have client requests, we have requests from the board or the executive team of getting features out as quickly as we can.
Sometimes that means missing steps are not thinking through everything.
The value of design thinking really allows you to take a step back and think through a problem before you come up with the solution and kind of work through that design.
With design thinking, that concept in general, which was started back in the 50s and 60s, is something that used to take months to years, you know, depending how long you want to spend.
Fast forward to 2016 when the team at Google created the five day design sprint.
So ultimately, kind of in rendition and with the times of making sure that we're really keeping up with the amount of startups that are kind of happening in the disruption in the technology space,
the two hour design sprint now effectively allows you to skip past months to years, skip past five day design sprint and have an effective way to solution in two hours.
Do you think somebody who hasn't experienced the five day sprint could execute on the two hour sprint with the same amount of successes?
Absolutely. And actually, I think sometimes those that have experience in design thinking or the five day method sometimes are blocked with I need to do crazy eights.
I need to do, you know, all these other things in the process.
Yeah, and they don't they don't need it with the two hour method.
You know, they have everything they need to really execute from beginning to end.
Is there value in having that background?
Absolutely. I think that you could have someone that's run multiple five day or multi day design sprints kind of common and know in their head how they need to
condense it and move the team through it.
I think sometimes I've seen it be a blocker more so than a new entrepreneur or a new business or a product manager that doesn't have that background being able to take the process and implement it pretty quickly.
Right. You're not labored with any of the shoulds in terms of we should do crazy eights.
We should do the storytelling. Instead, you can just focus on that crux of the problem.
Now, when you guys talk about crazy eights, because I'm not familiar with the five day design sprint, what's a crazy eight?
It's really just a different way to look at the different features of the problem that you're solving and kind of run through the process quickly.
More so a problem solving method within a problem solving method.
Layers and layers of problem solving methods.
Yes. How deep does the onion go?
Yeah. So what are some of the gotchas to look out for things to pre-work beforehand for people that haven't done this before?
How much work am I going to be doing to do a two hour design sprint?
With the two hour design sprint process, you can do pre-work or you cannot do pre-work, and it really depends on the problem that you're going in with.
So for seasoned teams like at Trevipe, you know, we have 27 engineering teams and we're running anywhere from 30 to 40 design sprints a year, sometimes higher than that.
When we have a seasoned team that's running these quicker methods, it's pretty routine and you're able to move through and know everyone's role and be able to solution quickly.
When rolling this method out on a new team or a new team that hasn't kind of worked together on this process, the biggest gotchas are really trusting one another with the process, getting everyone to actively participate and engage in the solution.
When you roll out a process like this, not everyone understands that everyone has the opportunity to bring an idea or a solution to the problem.
That is hard for many organizations to understand that everyone has a voice.
So that's really the biggest gotchas, making sure you have the stakeholders prepped and ready to be engaged for that full two hours of engagement.
Yeah, what would you recommend for organizations where that's not part of the culture, where the best idea could come from anybody?
And if people don't have that in mind, what are some of the things that you could think to help them get to that point of thinking?
I've coached a lot of organizations where I've seen that and oftentimes, you know, not to pick on CEOs, but when you have the startups or smaller businesses, everyone's usually looking to the CEO to approve what they're saying or another senior leader in the room.
Really, the intent of having a process like this is everyone is on the same playing field with their ideas.
It's not the CEO's idea.
It's not the product manager's idea.
Everyone in the room, whether it's support, marketing, anyone you have involved.
So sometimes how I've gotten around that is I've anonymized the ideas.
I do use Figma FigJam quite a bit for the solutioning, but I also do old school Post-it notes and whiteboards.
There's a lot of organizations that still are not wanting the virtual environment and are back to in person.
With that, I anonymize everything.
So not everyone knows who it came from.
And that is how I get around that is you do the voting and you do the entire process, not knowing who actually came up with it.
And it makes it a little more fun and allows that buy in.
That's a really good way to do that.
Do you then turn around and reveal the answers afterwards?
Yes. What I like about having an executive join these, if an organization can and has the ability to, is it's only two hours, right?
It's not like they're joining a full 40 hours of a five day method.
And it also allows that buy in before you get to the solution.
So you're getting their buy in for the journey, for the solution you come up with as a group.
And that's going to allow the executive team to kind of trust the solution and allow you to deliver on it quicker because you have that buy in already.
So when you cut from five days down to two hours, obviously you can't do everything in two hours that you can do in five days.
Do you get an expected quality drop?
How do you go from five days to two hours?
You don't get a quality drop, but what you're able to solution for becomes different.
With a five day method, you're really looking to solve for complex solutions.
For example, maybe you are coming up with a brand new website for your organization that's going to be filled with brand new navigation.
It's going to target a new audience and it's going to be a big new launch for your company.
You're not going to solve that in two hours for the two hour design sprint.
And for that method, you're really focusing on features, small, medium or even large problems that you're able to kind of solve during that time period.
The value there is organizations are just doing nothing.
They're not doing any method.
They're just moving through without getting any feedback, without really thinking through why they're solutioning.
The two hour design sprint method really puts a construct around making sure that you are putting some sort of method and listening to research and delivering on it in a way before you bring it to the customer.
So when you get it to them, you're not getting incredibly negative feedback on what you've delivered them.
It makes it accessible rather than thinking like it's this insurmountable mountain.
You can really like two hours.
It's so easy to agree to two hours of your day with the five day method.
Usually you plan these out, you know, six, three to six months in advance, and you're only doing two to three of them a year for an organization.
That means you're solving for a problem that you're planning to have, you know, 40 people with six months from now.
What's going to happen six months from now?
I work in fintech.
There's a lot of changes that happen.
In fact, six months from now, I could have 10 new competitors under the market and five competitors leave.
Look at the explosion that's happening in fintech right now of new entrants to the market, as well as those that are folding and going under or just the banking industry in general.
That's a long time to wait on problem solving.
If you wait six months out, ultimately, that's the entire concept is to be able to solution.
Now you could schedule within two hours, usually within a couple of days, maybe a week if you have to push it out even further.
Totally. You mentioned you have 27 teams, seasoned engineers and groups of humans.
Do you think there's a maximum number of people that you can invite to that two hours to make it a really good session?
Or could you have a representative from each of those teams to make sure you're really driving alignment?
If I were to invite everyone from all 27 teams, we probably wouldn't get anything done because that would be a lot of different viewpoints.
So across those teams, you know, we have over 100 in our product and technology organization.
There is a maximum specifically for a two hour design sprint.
I'd like to maximize it at 20.
Now I have run a two hour design sprint with 50 people and a couple of times with 100 people.
What you lose during that isn't necessarily ideas, but it's engagement.
You will not have everyone engage and there'll be too many ideas.
So typically when I have a larger group that's wanting more than 20, I break it out into multiple two hour design sprints.
So instead of a five day design sprint, I'm usually doing one day where I'm breaking out multiple two hour sessions,
where if I have a group of 60, I'll do three two hour design sprint each with 20.
And then I'll come together with the entire group with the final solutions and we vote and move through it.
That's something I also use for large problems, problems that you have multiple personas that you're solving for.
You're not just focusing on an admin role that's doing the setup for a dashboard.
For instance, you're actually focusing on the admin role in one session.
You're focusing on who's going to use the product or the dashboard in another session.
That's really how I go about breaking out those sessions.
So when you talk about these larger design sprints, these two hour design sprints,
how do you make sure that that two hour design sprint doesn't devolve into a multi day affair or even a four hour design sprint?
How do you keep it bound by that two hour time?
In order to really time box, it really takes you as the moderator, first of all, kind of controlling the crowd, right?
It's crowd control of who's participating, who's actively engaged in the design sprint.
And the best way to really do that is there's something called the parking lot that is well known for design sprint,
where anything that's outside the scope of what we're talking about in that design sprint gets put on the parking lot and comes to another meeting or sometimes even another design sprint.
And that's the best way to really have focus.
Drawing that focus isn't really just the parking lot,
but the entire two hour design sprint has focused times where I'm using either a virtual or a physical timer and we're time boxing what we're thinking about.
Oftentimes, if you were to take one concept and let a group spend an entire week on it versus a two hour design sprint.
So we've kind of run a couple of different problems where we've taken the same problem with the two hour design sprint and then run it with a five day method.
And we came pretty close to the same solution.
So I think what goes on with the five day method and how, you know, arriving at this two hour method is it's usually pretty early on.
You have the solution in mind, but then you're spending the extra days really thinking about that solution and drawing it out further than you need to.
So that's really what the two hour method allows is you come up with a solution pretty quickly as an organization.
So why not test it out quicker with customers versus spending another five days mulling on whether you have the right solution?
Go get it to them right now after two hours and then get your answer.
Whether it's two hours or five days, you're going to get feedback from the customer.
And you'd rather have wasted two hours versus a whole 40 hours once you get that feedback.
Yeah, that's a great point. And you said that you came up pretty close to the same answer, two hours versus five day for some of these.
What were some of the differences between the answers?
Was it just that it was a little more fleshed out or?
Yeah, definitely more fleshed out prototype.
So in a five day method, you are flushing out like a little more robust prototype.
So when you go to a customer, you're able to show a much more robust prototype.
But what I found is when I've taken those robust prototypes versus concepts, it really is no different from the customers.
And sometimes a prototype is actually more confusing because you're actually already providing them with a solution
instead of listening to some of their problems when they're talking to you about the feedback.
So if you show them a wireframe, for instance, or maybe a lower fidelity prototype as a visual and you're asking them,
where would you expect to click next on the screen?
You haven't shown them where and they tell you versus where you're actually putting it.
And you're saying, hey, would you click here?
So sometimes I feel the five day methods lead to guided solutions instead of a solution you think is going to work
that you're able to talk through and further solidify with the customer.
It really forces you into customer empathy, right?
Like if the whole point is to spend the two hours to get something you could share with somebody,
it just increases the amount of loops that you can do.
One of the things I'll also do with empathy is I'll run the method with my clients
and I'll run the exact same method to see if I get to the same solution with my clients as I did internally.
And it's always different.
You don't get the same answer when you just run it with them because they want everything,
everything in the moon put into the solution.
What I'll often do and I found the best mix is sometimes I'll run a method with a mixture of
internal folks and external customers that really creates an environment where you're actually
getting the live feedback right there with a representative sample.
And then once you have that construct solution after two hours,
you're then still getting more feedback after to validate the rest of your customer base.
To me, that's something that wasn't even a constructive part of the five day method
that I think works really well.
If you have the opportunity to bring them into that process,
you're getting instant feedback while you're solutioning together.
What sort of impact have you seen that have on the teams?
When you run those sessions that have internal folks and external folks,
how has that impacted the team once the session is over?
Really, it allows everyone to move a little quicker.
First and foremost, it's always energizing.
Clients love being part of these brainstorming sessions.
In fact, just in this last week, I think I'm planning out five of these this year alone in
the next couple of months where I'm going to be going on site and running this in person.
This is something that I continually roll out with clients and usually with the clients,
I'm either running it or I have my head of UX running it.
One of the outcomes of having that is not just the energizing effect,
but now you have a group of product managers and engineers that already know how they're
going to execute on user stories and a little bit about the architecture to move forward.
It saves time.
When you involve stakeholders like engineers and customers alongside the product managers,
you're answering questions that you might not have answered if you weren't in a group already
together, then especially in the world of remote.
We're a hybrid organization.
We have several in product and technology that are remote.
We have some in office.
We have some that are hybrid coming in a couple of days a week,
and we have offices all over the globe.
In the United States, we're in the Netherlands.
We're in Australia.
We're in Costa Rica and a few other places.
This becomes really critical to get everyone on the same page when you don't have that in-person
time sitting next to each other all day like we used to before the pandemic.
So that brings up a really interesting point.
You're talking about hybrid work, and this is kind of
sidestepping where we wanted to go with this, but it's fascinating to me.
You've got people in an office.
When you get people in an office and you have people dialing in remote,
because I remember doing this pre-pandemic, the people that are remote can often feel
very disconnected from the process.
So what ways have you guys found that actually work to make sure that all the people in the
office, all the people that are remote, they're all connected using the same technology
and actually feel part of that process?
I look at it as an iteration.
I don't think things are 100% perfect right now.
And I think organizationally, everyone is moving towards that perfect environment.
But I think for TreviPay as an organization, we do it pretty well.
What we really allow is we allow the employee to really decide,
do you want to be in-person?
Do you want to be hybrid or do you want to be remote?
And then effectively from a team management standpoint, we offer all the options.
Every single meeting, we have the option of an in-person room, a team environment.
We have a virtual board.
We have physical boards that can be virtual when you're writing on them there to show
for the rest of the team.
Really, if you look at where we've kind of gone as an organization, I remember the days
where you are having to be remote and you're not there and no one used video and you feel
disconnected to where today every single meeting I'm on has a mixture of people in the office,
at their home offices, sometimes at cafes even for those that are wanting to get out.
This is kind of the new normal of being able to think effectively.
That's where I think this method really excelled and kind of came out of the pandemic.
I don't know if you guys remember, it's been over four years now at this point, but it was,
okay, we'll go back in a couple of days.
Oh, probably next week.
And then several weeks later, we're all remote.
So how do we find a way to work effectively together?
And while this method provided an effective way to do that, we're constantly morphing it.
So now we have in-person sessions, we have hybrid sessions, and we have fully remote sessions,
and we're being effective with all of them.
And the condensed method really allows us to excel using all three types.
To somebody who isn't maybe as comfortable moderating a session, hosting a session and
having people physically there, remotely there, you've already mentioned the parking lot.
What are the moderator like top tips or tools that you rely on heavily to make sure that that
cross-functional, cross-geographical thing really works out?
The great thing about the two-hour method is anyone can be the moderator.
If you as the product manager or designer or solopreneur,
you don't have to be the one that moderates.
You can have anyone from the team.
Really what I found is having someone that is a subject matter expert on the topic
allows for that efficiencies.
With the five-day design sprint method, the big piece of that was
you can't have a subject matter expert.
It will add a biased opinion.
When you bring in a third party that you're paying $50,000 to $100,000
to run a five-day design sprint or multiple ones, and you're asking an outsider that
knows nothing about your product, your solution or industry to make a recommendation and pick
out the solution when they have no background, that never really made any sense to me.
You can run and moderate without being biased.
And in fact, you are expected as a product manager to be the expert for your solution.
All you're doing with this method is you're getting buy-in.
You as the mini-CEO, you're getting buy-in immediately
for that feedback based on a new feature or solution that you're putting together
for your customers.
How is this any different?
You as the product manager should be the moderator.
If you don't want to have someone else on the team, be it.
But you can help be there to guide the whole team through that process and come to agreement.
Yes, that's an interesting point because it's really talking about driving the alignment
within those larger teams, getting buy-in to the idea.
What are some of the activities pre and post-session that are critical to driving
alignment, especially when your stakeholder map is as large as it can be?
So I've worked with organizations that have a shop of one to a shop of 20, 100, 20,000.
What I find is you want to make sure you have that right mixed stakeholders.
But when you have too many in the room, that becomes a problem as well.
So you know you have a cap of what you would like to be 20.
So making sure that for the solution, you're doing that pre-work to understand
who are the key stakeholders that have the touch points with customers
or have any background on this concept.
So that is how you want to go about thinking about your solution.
So let's say you have a brand new mobile app that you're putting together
that's going to be focused for something on your pets.
That's going to allow you to really hone in on who in your organization has a history
with mobile. Mobile apps in particular has a history with pets.
Maybe someone that has a medical background.
So these are just ways you're thinking through who are going to make relevant folks
to understanding who the solution is going to be beyond typical ones such as support roles
or the customer or the product manager that could add value to validating your solution.
Thank you.
We touched a little bit earlier when you were first kind of rolling out this method
or testing it or playing with it or when we hit the pandemic and started to work remotely
and you needed to find a solution. How did that look like for you
and how did that turn into this incredible book and momentum that you've got behind this?
It really solved a need for the most part. There were kind of two things happening
and I don't talk about this like completely in the book.
When the pandemic happened, in addition to coming up with this method,
I was actually also finishing my executive MBA.
There were kind of, there was a lot going on in my life that I needed efficiency.
I'm also a mom. You know, you could see kind of the world of efficiency here of
how do I solve all the things that are going on?
In one of the needs that was going on, we had been remote for three weeks at this point
and I had some pressure from above on a particular problem that we needed to
solution pretty quickly as a group and already been condensing five-day design sprint.
So I had planned a multi-day design sprint that was going to be two or three days in the office
and I kept pushing it back and pushing it back and pushing it back.
So I started to research like, is there any way to run like a virtual one?
And it's so funny because if you go look today, you will find a thousand articles on
how to go run things virtually. There was nothing.
What I did is I went and created my own process knowing that I already had my plan out of my
three days and I just started kind of picking and piecing it together.
And the first time I ran it was actually a four hour, so a half day virtually.
So the first couple ones I did were four hours, three hours, and I landed on two hours
as the sweet spot after running it a few times.
And it took some buy-in with my team, but also everyone was forced into it
because we were all remote. There was no way to physically be there.
So everything we were doing, they were being forced to participate in.
And I will say from the very first one I ran, no one was on camera whatsoever to what I recommend
today, which is everyone is on camera. Everyone is engaged.
So that's really the transition of I'm in person, I'm accountable because you can see what I'm doing
to, okay, I'm virtually accountable. How do we keep everyone virtually accountable and engaged?
Yeah, that whole on-camera thing. We have now been on camera by default for so long.
It's almost hard to remember a time when we would all join these conferencing platforms
and everybody would have a black box because nobody wanted to turn on their cameras.
When you were working through this, you're prototyping the idea, you're moving into,
here's how I can do this virtually. Did you run into any pushback within
your organization that you think others might experience when they try this out
or want to try this out in their own organizations? Yes. Yes and yes. So in my organization,
from a pushback standpoint, it's really more proving the value, right? And the pandemic
has been four years. The first and second edition had come out more recently. The research started
over four years ago, right? So initially, yes. If you're not familiar with an executive MBA,
it's basically an MBA except you're an executive. So you have a lot more pressure
and stress than a normal MBA. So I basically turned it into a thesis and I said that I could
get buy-in for my executive team and other organizations to make this process work. And
so I have inherent pressure on myself to test out my hypothesis that I could turn this into
something that my organization would buy in and that I could get other organizations to buy into
it as well. And luckily I got an A and I proved my hypothesis correctly, but that buy-in was tough.
And how I got that buy-in is I involved executive stakeholders. And the biggest piece is not really
getting buy-in in the two hour design sprint, but also what you do with that buy-in after.
So in order to really keep stakeholders happy and this process successful, you must follow through
on the solution and make sure you're either going right into customer feedback, you're
communicating out what happened, you are solutioning, prototyping, whatever you're
needing to fix up in that two hour design sprint afterwards and communicate it. That is the key
part for stakeholders. For external organizations, what I'm finding a lot these days is it doesn't
really matter whether it's five day or a two hour method. There's a lot of organizations that are
not investing as much in UX and research and design as I think they should. There was a report
by Nilsson Norman that before the pandemic predicted a 10X increase in investment in UX
for organizations over the next 50 years. And I'd like to see what that looks like now with the
pandemic, because what's happened since then, right? We've had chat GPT, the takeover of AI,
and there's a lot that are fearful that some of the components that were happening with UX,
research, design, even product manager roles are now potentially being replaced by artificial
intelligence. So that's something that we really need to be keeping an eye on. And that's why this
method becomes so relevant, because it's much easier for an organization to say yes to 20 people
for two hours than 20 or 40 people for five days. I'm hesitating because that really struck a
struck a chord with me of you can get buy in for the two hours, but it's what you do after it,
like the following through on the solution to make sure that you have that continued
support really hits for me. Thank you for sharing that.
Absolutely.
So while you were going through the process of getting these learnings, there's a lot of
research that went into this. What inspired you to document that formally and write your book?
So I actually was a journalism major for my undergrad and I had started off in writing
and I did writing on the side for years. So writing has always been something that has been
a passion of mine and actually is what led me into product management, because I feel like I get to
do all the things I get to talk to customers, I get to sell, I get to write, I get to engage.
That's really kind of part of it of what really allowed me to do that is I always knew that I
was planning to write a book. So I kind of just started writing. Fortunately, I had a kid during
the pandemic. He really struggled with some health issues. And so this book was kind of an outlet
for me to be able to overcome some of that and get through it. That is something that I don't
often think about. But for me, writing is like doing a workout at the gym in a way. It's a
workout for my mind in addition to a workout at the gym, because that's obviously very important
as well. So for me, really making sure that I'm focusing on writing and kind of keeping a creative
mind is important. So I'm actually working on another book right now that is more geared
towards product management with a couple other authors. And I think it's just something that we
should always be exercising mentally, whether we have something going on or we just have a new idea
or concept. What did that look like moving from writing into product management?
Yeah, I was really fortunate at the time when I was doing my undergrad, I was pretty dead set on
being a journalist. When I had a couple offers come out, you know, out of college, you know,
this is back like 2006, 2007. So you know, quite a bit of time ago, I realized how low the salary
was. And I was like, Wow, how do you pay rent on the salary? What was interesting is I had a
offer from hnrblock.com. And one of the things I didn't mention with writing in addition to
actually writing, I also edited HTML, and I also had a background in SQL. So I actually got my first
job writing and editing tax articles at hnrblock, which they then hired me into a product role. So
it's kind of funny how that ended up happening. But I guess my writing was good enough that they
decided to kick me over to the product side. And that's how I got my start. Like I was lucky they
took a chance on a college grad and put me right into the the world of taxes.
I don't think we've yet to find a person whose story isn't I stumbled into it in some form or
fashion. And everybody's slightly different, but it's fun. Actually, I had a similar journey of I
stumbled into product management through writing and editing QuickBooks tax documentation. Oh,
funny. Yeah, gotta love taxes.
hnrblock, which, you know, is still pretty prominent company, they they were going through
a really challenging time. So TurboTax was taking over the market, the mortgage crisis
happened. And so part of one of the roles that I had to do, like even when I first joined the
product team was to do my taxes and every self service system and find out what's wrong with
the other programs as well as ours. That's what's super interesting is, you know, hnrblock is a tax
company. TurboTax was a technology company with no tax background, they came in and they wiped out
the market, which if you look at what's happening today in the technology space, it's not always
about having the expertise, but sometimes about having the shiny object and how many customers
you can get to it. So it's been something that I've been able to carry with me through my whole
career in really thinking about who is the user that's using the product? Are they a soon to be
college graduate? Did they graduate college? Are they a baby boomer? And thinking through
the generational aspects of who's using your product. So that's been really valuable and
something I think about often. That's very cool. Danielle, did you want to move us to the final
question? Yeah, I'm really glad that we've already kind of started on this getting to know you better
set of questioning. The last question that we ask each podcaster is just to learn a little bit more
about what their perfect day looks like. So the environment is you could wake up any place tomorrow,
you could take anybody with you. Where do you wake up and who do you wake up with?
That's a tough one. So, you know, we're talking about writing, right? So first,
first of mine is like, you know, a beach with a glass of wine, laptop, you know, pieces of paper,
but then you but then you realize that you think about the wind blowing and like the papers flowing
into the ocean, the sun getting in the screen. Yeah, the sun blocking it. No, I mean, I think
that, you know, it's spring break this week. So I mean, I would say as a mom first,
I would I would choose to have a family vacation that has no stresses work or writing with the
family and everyone is getting along and enjoying each other's company and just having the best time
eating ice cream together. You know, that would be an ideal day. But from a work standpoint,
if it was strictly working, I mean, I do think I talked a bit about, you know, writing is a passion
for me regardless of product management. So I would say, you know, having that time
to write in a quiet place with, you know, wine and chocolate that didn't have any calories,
you know, in a room. That sounds perfect. Yeah. Well, thank you so much for coming on the show.
Thank you for having me. Thank you very much. That was amazing. I took so many notes. Karl,
what were your takeaways? Yeah. So like you said, it was really great session. Some of the things
that I really liked a lot were her discussions around how to keep the conversation contained
to the two hours by doing things like using a parking lot concept for ideas that don't fit
the focus of the session and also using visual timers to ensure that you don't run over. I also
really liked how she talked about having the session moderator be someone who actually is
a subject matter expert in the space because somebody who knows the space better is going
to be able to better run the conversation in the short period of time. That's certainly an
efficiency driver. And while there is the opportunity for bias to be introduced, if that
person is properly trained in how to run a session, kind of limit how far that bias can actually go.
And then I liked her whole idea about what do you do with the buy-in afterwards? You know,
you get this buy-in to run this session, you need to follow through and actually deliver on the
solution to show that it works so that you can build momentum within your company and to get
momentum around the ideas so that it becomes an acceptable practice and that when you do those
things and you get that acceptable practice, you're in good shape. Danielle, what did you
take away from this? Yeah, I really agree with all of your points and I think it's so valuable
thing to capture that what you do after the session can be just as important as what you do
during the session and to make sure that you're really delivering value on the things that you
talked about and all of the input that you had during that time. I think the things that I
came away with were if you're thinking about running a session like this, then a group of
20 is kind of the sweet spot and then discussing a single user persona is also really critical.
Anything more than that tends to get quite complicated quite quickly and that's where you
start to lose time. And then ensuring that if you're running these things virtually,
that you have folks use their cameras and make sure that people are visually accountable.
My final point would be that using the two hours doesn't waste five days of time before getting
feedback from customers. So either running the session with directly your customers and
consumers or just running a two hour session and then going out to get feedback to come back
and then regroup on that. Because if you're doing the five day sprint and you don't have customers
coming in through those five days, then you've taken five days of team time without getting
direct user input. And so I really liked that call out too, just that speed and the feedback
loops. Let us know what your takeaways were. What comments made you think? What new thoughts did
you have listening to the podcast? You can also find Teresa's book on Amazon. Drop us a line at
hello at productlyspeaking.com or join the chat on matrix at hashtag productly speaking colon matrix
dot org. Also follow our page on LinkedIn to get the latest updates. We'd love to hear from you.
This has been productly speaking. Thank you for tuning in. If you like what you heard,
subscribe. Make sure you don't miss any episodes. Also share our podcast with your friends and
anyone you think might enjoy listening to an American and a Brit natter on about product
management. I don't think you can call it nattering. I guess actually we did stay on topic and it's not
technically nattering. Exactly. Well, what did you guys think? Leave us some feedback. Make sure
to visit us at www.productlyspeaking.com. Send us an email at hello at productlyspeaking.com
or join the chat on matrix at hashtag productly speaking colon matrix dot org.
Thank you all again. And until next time, cheerio.