Welcome to product mastery now where we simplify
the 7 knowledge areas for product mastery. These
are the product management practices that help you
elevate your influence as well as create those
products your customers love. To find all 7
simply go to product mastery now dot com.
I'm Chad Mc, a product management professor,
and your host, customers Now, in the past,
we've talked about the design sprints that was
with John R.
He c created a way to solve big
problems at Google and just 5. Days, resulting
in the popular 5 day design sprint. But
what do you do if you don't have
5 days? How about just 2 hours
It turns out you can still solve a
lot of complex problems in a 2 hour
design sprint if you know how. Think about
that, being able to confidently solve, complex problems
with the team in only 2 hours instead
of days. To tell us how to gain
that confidence.
Teresa Cain is with us, she is the
best selling author of solving problem in 2
hours, how a brainstorming and crate solutions with
2 hour design spreads. Whose first edition became
an instant hit among the tech teams worldwide.
There's an all new addition for, which includes
new Ai tools. She's currently the director of
product management, user experience and design for a
T pay leader in global billing and invoicing.
She's also the founder of Lucid startup consulting,
a training firm focused on research, strategy,
vision for product managers, Ux teams, businesses and
entrepreneurs.
As a reminder, we do create a written
article of everything we discuss, you'll find that
resource app product mastery now dot com slash
499.
Teresa, I'm so glad you're with us.
Thanks for having me, Chad. I'm looking forward
to being here.
I'm really looking forward to hearing more about
the design sprint in 2 hours.
So I thought maybe starting with some examples
of problems that you've tackled in in the
past or seeing others a tackle with a
2 hour design sprint might give us some
good context for this. You have some examples
for us?
Yeah. I've got a I've got a 10,
so you can... To touch on it. My
current role. So I'm currently managing team product
managers, user... User researchers and designers, and to
we actually perform around 52 hour designs sprints
a year and have done it that way
for several years, and then I've also,
coached a little over 300
organizations on this process as well. So I
could pull from a multitude of examples, but
what I like to
really pull from in that comparison for those
that really don't have that process exposure, when
thinking through what a 5 day versus 2
hour and how that condensing looks. So. A
5 day design sprint is really great for
a complex
problem. So you have something and you have
the time.
So that means you could schedule it out
3 to 6 months in advance. It's something
you can really sit on and think gone.
A 2 hour designs sprint has an immediate
demand. And you have to think. I work
in the fintech space. There are new competitors
coming out in the market
every single week, when I started there 6
years ago, we had 5 competitors, and we
are... We have over 50 now. I mean,
it's amazing. And so a lot of organizations,
like, the 1 I work for don't really
have time to sit on problems for 6
months and then go solve them later.
So the concept of 2 hours really is
meant for any problem that a, you need
an immediate need to go solve it, But
also something that you already have idea isolation
on either it's on your backlog. It's a
client request. And really any problem makes for
a good problem we're getting a team together
to talk about and I hate it.
So some of my favorite problems are... I
like to... It's funny. I saw this article
this week on, like... How people are saying
dashboards are, like, out now. So I'm gonna
pick on dashboards because I feel like every
single organization I've ever worked for in the
past 20 years. I have billed at least
1 or many dashboards there and where are
you driving the user actual dashboards. And dashboards
are 1... What I've done, like, I would
say 25 percent of the design sprints I've
done are on dashboards. And but what a
lot of organizations are hoping to do is
drive their users as a call to action
when they get to that dashboard.
And so most of the time what happens
is with a 5 day design sprint, And
I have run a number of design strengths
where we've compared
5 day versus 2 hours because this actually
started off from an academic perspective, I wrote
a white paper I compared kind of the
2, see if you got to the same
solution. Then from a dashboard standpoint,
from where a lot of organizations get caught
up in in a 5 day process They
go too big. They're trying to solve every
user persona in that 1 setting, and then
it ends up being really complex.
With the 2 hour process that really allows
you to chunk down the focus on the
action and who's driving to the dashboard. So
let's take an analyst
versus an executive role. Those are gonna be
2 different functions
of who's going to the dashboard. In fact,
the executive, if from a lot of the
research. They're not gonna even gonna look at
the dashboard. They're may gonna look at it
once a year. They don't wanna
log in to anything and and go there
and and click on filter,
whereas the analyst is gonna be in there
every day using it all day every day
for their role. So this is a great
example of a 2 hour process allows you
to bring a group, 15 to 20 stakeholders
together really idea and focus on a focus
on the problem that you're having with the
dashboard creation and come out with the solution
in 2 hours, and that's been something
I've been able to press on repeat multiple
times with organizations from that functionality standpoint.
Okay. So... And and you did do the
research. Right You said to started out. Kind
of a an exercise look at. What can
we accomplish in a 5 day design sprint?
And could we do that less? Right? And
it sounds like you ended up at the
2 hour point to really make some efficient
use of that time. Yeah. I know I
know you mentioned professor in your title 2,
so I went after 2 master's degrees, so
I mean, Yep. I really love studying and
understanding and part of this. I mean, is
complementary
to the the 5 day process. Right? This
is not meant to replace it. This is
meant to say,
Hey,
a lot of organizations don't have 5 days.
They don't have the time. They don't have
the budget or they don't have the team.
I mean, if you look at the number
of solar newer
organizations that are popping up today, tell me
how making use of 5 days, when you
have a team of 1 is it gonna
work for this... Process. So the adaptation to
2 hours is really for all types of
organizations whether you're enterprise or you're a solar
where... So I'm able to bring in experts,
and there's also a lot of third parties
out there that'll
supply
users for you, like, user interview interviews or
testing that you're able to work with, So
that's what kinda makes it fun, and I
like to talk about the academic part of
it because I want everyone to understand that
there is so much value in a 5
day and a 2 hour process.
Yeah. Absolutely. The... And 1 of the challenges
with the 5 day sprint some... Organizations ran
into our teams.
A lot of energy and effort goes in
that, right? Freeing up the team for 5
days is a big deal. And then afterwards,
I don't... I I haven't seen any research
to say what the percentage is if there's
anything collected on this. But action isn't always
taken. Right? We you spend those 5 days.
Mh. And then we end up with something
that sounds promising, but the there's not resources
and time to now take action on what
came out of that. So I like this
idea of creating the these smaller chunks like,
there's what can we do in 2 hours
and then put that actually implement it and
make use of it? So we'd love for
you to take us through kind of the...
Framework for how this happened.
Obviously, the details are in your book, and
p, we'll have a link to that too,
but solving problems in 2 hours is the
framework as the title of the book, very
clear title love that. But can you take
us through the the framework for how to
actually do this? Where do we get started
Yeah. So, ultimately, it's really parsing down. And
in this concept really takes the best of
both worlds of design thinking and design sprints.
Right? It's not...
Design transfer for for those who don't know.
That was derived from design thinking. So we
can't forget the days of Idea, Stanford design
school. So ultimately,
really taking in the mindset of thinking about
the user first. It's really kind of at
a high level broken down into 3 different
areas. So your understanding who your user is,
like who you're solving the problem for,
you're exploring the problem and then you're idea.
And as part of that, by parsing it
down into those 3 different elements.
What really holds up a lot of
organizations again with the longer design sprints, is
really being able to understand the user. So
a lot of the organizations that I work
with, what I encourage whether you're running a
2 hour or 5 day is know who
you're solving the problem for. Like, It's something
so simple that a lot of people just
think they have this really great idea. It's
gonna go out there. It's gonna make millions
of dollars and that's gonna be the win.
And they really don't think about who they're
solving it for. So, like, even just a
couple weeks ago, I was working with a
bunch of startup founders, and
The brought problem to the table and I
was like, alright. So tell me a little
bit about... They weren't familiar with user personas
I was, like, tell me who this product
is for. Who's gonna be using this product
and they're like, well, I don't know.
I'm hoping to put the product out there,
and then people will just, like, find it
and they'll use it. And so when you
think about that response, Right? I mean, inside
my eyes are burning as I'm listening or
I'm like, okay. Great. This is a great
problem in itself. Let's solve that first of
who is gonna use your product. So most
organizations that are season, like, the 1 I
worked for most that have product Ux and
design teams. Already are gonna know who your
user personas is, and that's kind of 1
of the key differences of first and foremost,
if you don't know who you're solving the
problem for,
that's part of that,
understanding. So you're not just understanding who is
using a product, You're understanding
what challenges are they having? Forget your product,
What are the problems that they're facing in
their day to day? And let's talk about
a little bit of Ai. Some of the
themes I've seen as of late is a
theme of automation. A lot of challenges
of, wanting to solve problems for users that
are doing a lot of manual tasks in
their day. It's taking up a lot of
time. Maybe they're popping between screens.
Maybe they are using their mobile device or
not even on a desk top computer, maybe
they're moving buildings while they're doing their different
tasks. Those are the problems that you need
to uncover of, let's take a step back
and understand, with this first stage of a
2 hour design sprint of who is the
customer? Who are they? What are their problems?
And, so that's really that first stage there,
being able to understand, the value of who
you're solving, the problem for.
And from there, you're, being gone. Go ahead.
Yeah. Just just to just underscore this, the...
My background is is engineering, and I I
remember
being in a group where or lead guy
who was absolutely brilliant, and maybe this worked
well for him because he was absolutely brilliant.
Would say, we'd never need to discuss a
problem for more than minutes because the first
solution you come across in the first 50
minutes is almost always the right 1.
And... But that never sat well with me.
Right? And I think there is a distinction
here between
engineering problems that might be appropriate that we're
reflect on internally? Like, what is the right
algorithm or data
for some mechanism in a program versus actually
knowing what... And with my... University professor had
on when teams are generating some kind of
innovation project and of course, I I always
ask them to create a business model canvas
that starts with. What was the customer segment?
And the customer segments always pretty broad. It's
like, no. We're gonna serve families.
Okay? Are these families with young kids or
these families with grown kids or or the
the these families with single parent.
There's a whole lot more detail here that
we need to understand who is it we're
actually serving. And so
diving into a a clearer understanding among everyone
on the team is really important because even
without that, we probably have different pictures of
who the customer is with just kind of
casual discussion. And so I appreciate you under
understanding the ports of knowing who the customer
is and what the challenges. I love that
you said that too. So I I have
run this process, not with just product teams,
but I've also run with operations teams, engineering
teams, even, like, teachers, schools, and
you make me think when I run this
with engineering teams, like, I married an engineer
first of. So I have, like, all the
love for engineers. But every time I run
a design for Got all engineers. They just
wanna go straight to the solution. They're like,
stop wasting my time. Like, I don't wanna
talk about the customers like, let's talk about
the solutions and I'll have to say. Okay.
Here's what we're gonna do. We're gonna we're
gonna not talk. I'm gonna mute you. Now
Kidding. But it... I think that's just, like,
the nature of the mindset of an engineer
right is, that is their role. Their role
is to, like, solve the problem in solution.
So it's kind of the first instinct. But
I do think when you think about it
in the differences of a 2 hour versus
a 5 day.
I just talked a little bit about the
academic, no, this research started 5 years ago
at this point, where I ran a number
of problems with 5 day and a 2
hour, and 80 percent of the time we
came to the same solution. So
I think that Wow. When you think about
what you just said there in the first
15 minutes,
right or wrong, you can agree with me
or not agree with me, but 80 percent
of the time in the test studies run
of 5 day versus 2 hours we ran
into almost the exact same solution. And so
I think for me, if I'm gonna have...
I've have so many problems I'm trying to
solve every day. We have client requests. Every
company,
organization wants to continue to grow, solve more
problems, release new features, Would you rather spend
2 hours and solve 50 problems in a
year or do 3 5 day design sprints
and solve 3 problems. Right? So The intent
is, I think a lot of organizations, we're
really looking at the 5 day model and
only doing it a couple times a year.
What I'm saying is you should be doing
it more.
You should be doing it much more than
you're doing it all the time. But organizations
wouldn't really have the capability
go run 55 day design sprints in the
year. Right? Right. So that's where this 2
hour design sprint comes in.
That's Brilliant. And I appreciate knowing that the
difference in your outcomes. They're are 80 set
as a really good number.
Okay. So so we're start. We have to
have clear understanding of the customer what their
challenges are and make sure we're grounded in
that as a team.
Yep. And next, you're probably familiar with the...
How might we framework of, how might we
frame a challenge
And so that second stage is really exploring
the problem a little bit more of rethinking
how you would kind of
reframe that into a question and really exploring
the nature of of how the problem got
there. So again, 1 of the key things
like, I just wanna talk about, 1 of
the biggest values of a design spread isn't
something that is always said. Right? Of course,
I say in the book, but it... Like,
when you think about it 2 hour design
sprint, it's not always about the customer or
the problem in the solution. But
about the stakeholders working together. And a lot
of what I see with organizations I work
with is they're not talking to each other,
they're... And therefore, they're not on the same
page, especially with the Covid pandemic, forcing
organizations on a lockdown,
some in a hybrid environment, some I'm still
remote. A majority of my team, I may...
I've mentioned I manage product Ux and design.
A majority of my team is still remote
for most of their entire work year. We
have once a month where everyone is required
to come in for a week type of
mindset. And so
I think with that type of mindset knowing
every organization is doing something a little different.
If you're not getting groups of people together,
they're just simply not talking.
And the 2 hour design sprint, when you're
rethinking and and challenging how you can solve
problems really allows you to get that group
together for 2 hours and 2 hours isn't
a big time commitment. So that's Right. Just
1 value I wanna like, point out during
this process, it's not just about talking about
the problems, but getting that group of stakeholders
together to talk about it together, that's the
value. So...
Yeah. Absolutely. Yeah. People who can fit that
into their schedules. This is just like extended
meeting where we're actually trying to get a
good outcome.
Right. And that's where the second stage, The
third stage, I could talk Dave about the
third stage because I as a product practitioner,
right, I love idea dating, and I love
coming up with solutions. At the third stage,
a lot of times I get asked when
I'll come with organizations that have run
design sprints in the past and broaden firms
is, like, there's no way we're gonna be
able to to solution. And usually what ends
up happening. There's a lot of shock and
awe sometimes during a 2 hour design sprint
when I come in and I moderate because
they're like,
oh, my gosh. Like, I did not think
we were gonna, like, come up
with this these solutions like in in a
couple hours. And it's not... You're really deciding
as a team,
what your solution you're gonna move forward with.
But that's kind of the shock all on
this idea asian, mean, again, some of the
biggest benefits were the cause of the Covid
19 pandemic. So I usually like to run
these at a collaborative tool. There's been a
lot of change in collaborative tools, but I
have migrated my whole team to fig my
years ago, and so I use Fig jam
most of the time, I also use Mir
and mural, and depending on the organization, but
some of the value there is also in
that collaborative tool. So The reason why you're
able to so quickly is you're spending 2
hours together looking immediately in a tool of
what everyone is doing. Even if we're in
person together, we're still using a collaborative tool,
and we in... If you think about the
difference of
walking in around a room with a old
school design sprint where you're writing on post
it notes. You're trying to understands everyone hand...
Everyone's handwriting.
That information is coming at you slower than
being in a collaborative tool where you're absorbing
it as people are typing. You're constantly thinking
and innovating. So this is really efficiency in
itself of, you can be more efficient by
using this process and solving problems more to...
More quickly as an organization. Right? So When
you get to this idea... Idea stage, this
third stage,
this is where the magic happens. Right? You've
now thought about the customer, you've thought about
the problem as a group and you're idea
and you're pitching on your concept as a
group. And as a group, you're voting on
what you think, what solution would solve the
problem the best. For the customer for the
problem that you have chosen. And
so again, in statistically, 70 to 80 percent
of the time,
you are going to come out with a
successful solution that you could move forward. And
I think 1 of the key differentiator is
a 5 day design sprint is With the
2 hour design sprint, you were deciding at
the end of the 2 hour design sprint,
whether you wanna move forward to test and
prototyping,
where a 5 day design sprint, no matter
if everyone in the group is not on
board with that, you are automatically bought in
to test the prototyping and testing.
And before I had parse down
design sprints to 2 days, 1 day, 4
hours, 3 hours, 2 hours,
over the years, I had a number of
prototypes where we brought into the customer And
like, this is this is horrible, like, no.
You're not hitting the market at all. And
this is when we brought in really expensive
firms to come in and run this process.
Right? I mean, I wasn't running as the
moderator at this point years ago. So So
I think that's something to keep in mind,
for you're saving time and money by getting
that iterative feedback earlier before committing to final,
prototype and testing
And for most organizations that have invested in
product, user experience and design, being able to
take something when you have a design system
is so much quicker these days. I mean,
look how rapidly
prototypes can be built these days. I mean,
even as a product practitioner, I can go
build 1 in a couple hours, let alone
my designers that can do it even quicker.
So...
K. Very good. So step 3 here is
really the idea ideology part where we're trying
to
take that... Well, back up there. Are understanding
of the customer who are actually serving the
understanding of of the problem now, how might
we solve something for the the that customer,
and now idea idea 80 on possible solutions.
And you're using design tools in real time.
You said whether you're in person with, I
guess, people on tablets or laptops right working
together on this. Yep. So we can kinda
see what's evolving or that easily works remotely.
And you said Mer is 1 of the
tools you'd like to use And for listeners
that I don't know you might want to
share us more... That... That's 1 that I
do use. I to give it as kinda
just a general whiteboard that you can put
all kinds of templates on. And Fig more
for my understanding I have actually used a
bunch more of a user interface
design type tool. How do you use those?
Yeah. So there's Fig then there's Fig jam.
So... And now they have 2 separate license
models for it. So Fig is really where
your design and prototyping are going on, your
design system, and then fig jam is a
sense just like Mir, When I used vision
for years, which would mh. Obviously, they're have
gone. So... But, ultimately, I'm and I'll be
honest, like, I I love Fig jim like,
a little more than mir and mural, but
I use all of them. But they're part
of like, the fig jam, like, fig jam.
Allows you to continue investing. I think because
I'm in it every day anyways for work.
I'm constantly. It's like outlook at this point.
Right? You're constantly using it every day and
you're used to it, you, everything about it.
So but either way I mean, it could
be any tool, and, in fact, I mean,
I have... If for those that aren't wanting
to use collaborative tools, this process can still
be on in the old school way. But
I think that is a inherent value of
being in the age that we're in the
technology age. Right, of being able have these
advanced technologies to help us. So... Right. Like
my old school is a whiteboard. Like I
get a lot of value of a out
of a whiteboard if we're meeting together. But
then you have to translate
anything that's on the whiteboard. Right into some
kind of artifact that's easier for the team
that's an extra step. But if you can
just do it as part of the process,
and have an easy takeaway for everyone to,
you know, point to ensure that works really
well.
Okay. That's great. So that's kinda what happens
in a design right here. Right? The 2
hour version. Clear understanding the customer, clear understanding
the problem, and then idea together on on
potential solutions for that. Right? What do you
see takes place after design Sprint. Yeah. And
you touched on this a little bit earlier
of, that's 1 of the biggest challenges right,
of any design sprint type is that hand
off afterwards.
And, I, a hundred percent accrued that in
when we talk about,
the failure rate that can happen whether you're
running a 5 day or 2 hour, that's
something to kind of
keep in mind as well.
So I think that for the most part,
that when you have a process, like a
2 hour design sprint,
the intention is that you're able to do
a hand and work on it immediately. So
because we're running so many a year at
T pay. When we run a 2 hour
design sprint, it goes right into a user
story and on the backlog for our team.
Like, it it has worked in that quickly.
And that is something that happens with a
lot of organizations as well. So when you
already have really well run teams,
we have over 20 engineering teams across the
globe, and
it's a really,
well run product and technology shop. So when
you have that fluidity,
across your teams, you can bring those in
immediately, and that's the huge... The biggest value.
Right?
But when you have don't have that support.
Maybe you don't have those teams. You don't
have the resources.
Maybe you are a smaller
organization.
And
that's where the hand becomes a little more
tricky. So who owns the hand? Who is
going to be the 1 that's setting up
meetings with the the customer to validate the
prototype.
That's really the trick piece is who owns
the hand of every item and who's responsible
for those actions.
And
oftentimes, so if you don't... If you aren't
running
Ux internally. It's surprising a lot of organizations
don't have Ux shops today. And before the
Covid 19 pandemic, Nelson Norman had come out
the report that said, they expected the, user
experience
and research industry to really
explode by 50 x from a role standpoint.
And I'd love to see the adjusted numbers
with the Covid pandemic, but I I do
not think that's gonna be the case anymore,
especially because that was before chat Gp had
come out. And right now, I think what
everyone's trying to do in product user experience
design is figure out how can Ai
compliment?
How could it used in your role but
not solve your role. Right? I mean, I
think a lot of organizations are looking at
it that way of... Yes, You could tell
Chat to create a user persona for you,
but you still have to go validate it.
But doesn't cite any resources. You don't really
know where it came up with the data.
And generally, it's pretty accurate, but it's not
your data. You didn't you didn't write it.
So that's something that I think we have
to kind of keep in mind of what's
the impact of
automation and how can that help the hand
off too? I I had a question asked
me when I was running a design sprint
last week of,
why do I need to do this process?
I can just ask chat Gp
to solve the problem for me? And they're...
They're were kinda saying it cheek. And I
was like, okay. Let's throw it in there.
Let's see what it says. And... But we
asked chat.
I know they had a... I'd use adoption
problem. So we ran a 2 hour design
sprint on how to increase user adoption for
a subset of their users that were not
interacting on mobile device
And I won't call out which generation this
was, but we could probably narrow down. Who
doesn't like using mobile devices pretty easily.
And ultimately, ask Chat And chat came up
with a bunch of items. And so we
ran the 2 hour design and we compared
our
solution options to what Chat Gp had. And
It would have been really interesting if they
were, like, exactly the same. But here's the
reality is chat Gp doesn't know your product.
They don't know your users. Right. You have
to kind of use what you get with
a grain of salt with that. So... Yeah.
Yeah. We're certainly not at the point where
chat Gp is creating better patterns for us
than we we can
gain from our own research and insights of
of customers. So maybe someday, but then I
don't know what we'll all do. So... Exactly.
I'm was just curious about the cadence of
this, if you're doing 50 through our design
for a year, do you plan on 1
a week and are you looking for significant
problems like the, you know, you the
user access on on this particular classes feature
is really low. So are you looking... Do
you just keep these basically in the calendar
and then be looking for a significant problem
each week that makes sense to bring to
it as Is sprint. Yeah. That's a really
great question. So so I
sit over.
We we have around... Let's see. We have
around 30 to 40 in terms of, like,
a team of, like, product reps and design.
So
lot of these design brands. Like, I... I'm
probably at this point running, like, maybe 4
7 design sprints a year and the rest
of it's being run by the rest of
the team. And that's 1 of the beauties
of when the 5 day design sprint, when
the book came out, a lot of organizations
hired third parties to come in and run
those. And with this process with the 2
hour process, that is meant for anyone at
the org to run it as the moderator.
So you don't need a third party. In
fact, I recommend a subject matter expert run
a 2 hour design sprint. But I found
a lot of failure points bringing in third
parties that know nothing about your industry, your
clients to come in and make a recommendation
for me on my business problems. That never
made sense to me. So that's really the
intent is to bring in a subject matter
expert. To run this process for you and
with that, all of my product managers,
designers, Ux researchers, and in fact,
Now folks and marketing and operations are trained
on this us and they are able to
go implement it whenever they want. And every
now and then they'll just, like, tell me,
like, hey. I ran this and here's our
results? Like, what do I do next? You
know, you asked on the action part. Right?
And that really is the number 1 thing
of,
okay. How do I take the solution we
have and actually go run with it and
execute it. When you're not in product and
technology because I think this process is morph
outside of the world product and technology a
bit, and that's something... That's a consideration. Right?
Those steps are gonna be a little different,
but you're not gonna have someone that gonna
go an engineer to go work on the
solution you have. You need to go solve
it who's gonna work on that solution for
you. Right.
Yep. Okay. Very good. Yeah. So it sounds
like this is been spread out to the
organization, People been empowered. They can do their
own to hour design sprints, which is probably
great for you to see. Right? I'll, this
would be put do snow organization. But they're
are colleague design sprints as they need to
as they Yeah run. It's ad hoc. Hey.
Ad hoc. It's not a plan to set
weekly because 2 hours that's easy to do.
Yeah. But, also I mean, you have to
think the stakeholder mix. Right? So every 2
hour design Sprint has its own unique stakeholder
mix. And so. There wouldn't really be way
inherent way to do that. And I also
think you would kinda have a little bit
of design Sprint fatigue. I mean, I know
back when I would run, like, a multi
day design sprint, like, most people would take,
like, pee... Even like a 3 day 1.
The last 3 day designs for I ran
before the pandemic, Like, everyone took Pto, like,
the last 2 days because they were just
done the brains were referring. Is a lot.
Yeah.
Excellent.
Very good. And you mentioned at the very
beginning of of this the connection to
and design thinking. And I remember for anyone
that wants to go find this on Youtube
if you look up
Shopping cart. When when I first saw this
video of them designing a a new shopping
cart in a week for a grocery store.
That that was the challenge that were given
by a news program. Thought, wow. The the...
This is how innovation happens. Right? This is
how you understand your customer and the different
stakeholders in that customer group. And how you
go through the work together to, dive into
the problem and then the idea idea about
possible solutions. So I think that illustrates it
well. And you have condensed this for solving
complex problems in a 2 hours and love
that you brought this to us.
We do, like innovation quotes and I asked
you to bring 1 for us as well.
What is that? And what does it mean
to you? Yeah. So when I think about
innovation, there's a really great quote by Albert
Einstein that... Really, like... When I think about,
like, the foundation of
this book and you know, why I have
kind of started on this process and press
forward. I know we both
are kind of in the academic realm. Right?
We, like, love
having an academic realm. So there was actually
a quote by Albert Einstein says we cannot
solve our problems with the same thinking we
we used when we created them.
And so if you think about that, we
cannot solve our problems with with the same
thing we use when we created them. So
it's kinda 1 of those things you have
to think about and it kinda blows your
mind for a second. But ultimately,
really what how that has influenced me in
in my career before even, going after a
couple masters. I was in English and journalism
double major. So I'm I'm really big on
reading and understanding history and
bringing that into it. So for me, Greece
I think that there are always new ways
of thinking. And even the 5 day process
made of design thinking. You know, the 2
hour processes made off innovating from those
we constantly need to be
reinventing ways that we've been thinking. And there
is no right or wrong answer, but the
reality, he is. I mean, look at the
amount of automation. We were just talking about
chat Gp.
You know, it could take you going from,
like, inter... Let's just say a company does
use chat gp T for personas, and you
go from interviewing 5 to 10 people,
really kinda honing on that persona to just
asking chat Gp in a couple seconds,
So tell me, why would it make... How
would it make sense to go spend 5
days solving a problem when you can do
it in less time. And in fact, I've
had people say, I'm just gonna throw in
chat
Skip the whole thing altogether. I mean no
1 has time that, you know, that that
they did, I guess, is how we're all
thinking about it. Right? Generational, the shift of
automation in has really changed and they're expecting
things instantly. Instant gratification at their fingertips. So
that's something to really keep in mind, and
that's always instant fired me to keep thinking
above and beyond. And even before
artificial intelligence was cool, I have worked on
machine learning and natural language processing tools and
automation for years before it came out. So
I mean, I think, there's so much more
work that we can be doing, and we
could use that to help us get along
the way, but we need to be solving
problems more quickly and thinking differently.
Absolutely. Having a clear understanding of the problem.
And front thinking that got us that there's
1 way of thinking that got us into
the problem. We we need you thinking help
us get out of that problem. So there's
always more to learn for sure. Front how
can people find out about your book? Clearly,
Amazon's source, but you might have a better
place of point us to as well as
the training work you do and anything else
that you'd like to share with us? How
Yeah. So they could go to the website,
2 hour design sprints dot com, or obviously,
you mentioned the book solving problems in 2
hours is...
On Amazon. I also... Like, I'm a network
or personality, so I always feel free to
follow me on linkedin
with content, and I also have, number of,
templates out on the fig jam community if
you search for teresa king.
Fantastic. Thank you so much for sharing the
information and really delighted to be able to
hear about these 2 hours Sprints, and I
think they probably you're you're... What you share
with this inspired many listeners to check out.
Hey, What can I get done in in
2 hours and how could we formulate that
and standardize? That. So good resources in your
book to make that cleared to all of
us. So appreciate you being with us today.
Yeah. Thank you so much for having me.
And listeners, I appreciate you being here as
well. I do fund this podcast by the
training that I do for product managers and
leaders. There's 3 versions of that 1 that's
just to help
managers get better grounded. That's my rapid product
mastery experience. Another 1 is to help product
leaders really becomes innovation leaders. And then finally
for senior exotic executives to understand what's different
about leading innovation compared to leading the organization
and their functions. To find those resources at
product mastery now dot com executives and let
me know if there's any questions about that
I can help you with. As always, everyone,
keep innovating. Thank you for listening to product
mastery now. Where product leaders and managers gain
product mastery through practical knowledge,
influence and confidence
by listening you are becoming a product master,
creating products customers love. Find additional resources at
product mastery now dot com.
Keep innovating.