►
From YouTube: Think BIG 12-18-19
Description
In which we talk about JTBD, maturity plans and cognitive biases
A
B
A
Alright,
so
one
of
the
things
that's
top
of
mine
and
Dan
and
I've
been
talking
a
little
bit
about
lately
is
our
maturity
level.
So
we
have
a
few
maturity
targets
that
are
coming
up
in
January.
So
we
have
the
package
registry
and
the
dependency
peroxy
and
helm
charts
are
all
supposed
to
package
registry
is
supposed
to
move
from
minimal
to
viable
dependency.
Proxy
is
supposed
to
move,
to
minimal
or
to
viable,
and
then
helm.
Charts
is
supposed
to
just
move
them
to
minimal
from
planned,
and
we
can
make
our
way.
A
A
We
I
can
make
an
argument
that
you
could
push
a
helm
chart
to
the
container
registry
now
and
it
works
and
there's
just
some
missing
data,
and
maybe
we
could
say
that's
minimal,
so
it's
possible,
but
the
bigger
reason
that
I
bring
that
up
is
because,
in
the
past
the
way
that
good
lab
is
done.
The
maturity
targets,
including
these
is
just
like
a
product
manager,
says:
okay,
this
is
the
maturity
target
and
we're
gonna
write
these
down
in
our
direction.
Page
and
that's
gonna,
be
our
goals.
A
Yesterday
during
the
weekly
product
meeting,
they
said
that
this
is
we're
going
to
move
away
from
this
and
we
want
to
go
towards
the
UX
scorecard,
driven
maturity
plans
and
those
UX
scorecards
are
driven
by
the
jobs
to
be
done.
So
I
wanted
to
make
sure
that
we
didn't
get
just
that
process
just
slapped
on
to
us
and
that
we
all
had
a
time
to
talk
about
the
jobs
to
be
done
and
review
them
and
talk
about
what's
important
and
what
does
a
good
grade
mean
and
a
specific
job
to
be
done
or
drop
story.
A
So
I
just
wanted
to
bring
that
up
as
just
as
to
create
some
transparency
into
the
process.
I'm
thinking
what
we
could
do
is
have
one
issue,
that's
our
the
core
issue
and
then
each
thread
of
that
issue
could
be
one
of
the
jobs
to
be
done
and
we
could
put
in
there
like
thumbs
up
thumbs
down
whether
we
think
it's
important
and
then
maybe
we
could
have
some
other
rating
to
say
if
this
helps
us
reach
a
given
maturity
target
or
something
like
that.
A
I'll
say
in
my
old
physical
office
days,
or
you
know,
we're
doing
project
management
we
would
probably
just
like
draw,
have
a
line
on
a
whiteboard
and
then
put
all
of
our
issues
that
are
above
the
line.
I
reflect
a
certain
maturity
or
something
like
that,
or
have
some
sort
of
like
a
two-by-two
chart
where
you
would
sort
of
have
like
what
phase
maturity
it
helps
and
how
good
the
feature
needs
to
be.
We
could
do
something
like
that
in
neural.
A
C
A
A
Probably
before
most
of
us
were
here,
Dan
was
probably
here.
Maybe
Steve
was
here,
and
so
a
lot
of
those
things
got
put
into
prioritized
without
ever
being
triaged
without
ever
being
spoken
about
and
I
really
wanted
to
make
sure
that
didn't
happen
this
time
and
that
we're
all
aware
of
that
there's
some
process-
that's
gonna,
get
you
know
shared
with
us
from
from
up
above
so
I
just
wanted
to
make
sure
we
were.
We
were
working
towards
the
same
shared
goals
as
all
Dan
are
you're.
Gonna,
say
something
I
see
you
sorry
furrowing.
D
Yeah
I
guess
I.
For
me,
what
I'm
curious
about
is
is
like
where
it
is
right
now,
so
I
can
go
to
look
at
it
and
get
a
broader
overview.
Do
you
have
I
mean
I
clicked
on
the
link
that
you
put
in
here
already
I?
Do
you
want
to
maybe
just
sort
of
scan
through
these
really
quickly
to
give
people
a
sense
of
what
it
is?
We're
and
the
package
stays
jobs
to
be
done?
I.
A
This
book
done
by
a
bunch
of
PhD,
or
you
know,
MBA
type,
folks
that
came
up
with
the
jobs
theory
and
the
idea
behind
that
is
finding
the
motivation
for
why
people
hired
you
to
do
a
certain
thing
and
the
classic
example
they
give
is
a
McDonald's
milkshakes
is
like
the
first
example
they
give.
So
they
were
realizing
that
they
were
trying
really
hard
to
sell
more
milkshakes
to
people,
and
they
didn't
realize
why
people
were
buying
milkshakes.
A
So
in
the
morning
they
found
out
when
they
got
to
asking
people
why
that
people
would
buy
a
milkshake
on
their
way
to
work
because
it
was
cold
and
it
was
filling
and
it
would
last
time
their
whole
trip
commute
to
work
and
then
in
the
afternoon
people
would
buy
milkshakes.
They
would
come
in
with
their
kids
and
they
would
say.
Oh
I
can't
say
no
I've
been
saying
no
to
my
kids
all
day.
A
A
They
made
the
milkshake
itself
thicker,
so
it
would
last
longer
and
then,
in
the
afternoon
they
made
as
small
cups
as
possible
and
and
much
much
thinner
recipe,
and
in
doing
this
they
were
meeting
the
customers
where
they
needed
to
be
in
terms
of
their
why
they
were
buying
the
product.
So,
and
you
could
say
the
same
thing
like
why
in
the
end,
why
does
someone
buy
Lamborghini
right
like?
Is
it
because
they
need
to
get
from
spot
a
to
spot
B?
A
Tesla
would
probably
be
a
better
example.
The
doors
are
awesome,
unlimber
use
and
so
for,
when
it
comes
to
get
lab,
we
you
know,
we
started
Ian
and
I
started
this
exercise
of.
Why
do
people
buy
gitlab
and
then
specifically,
why
are
people
hiring
the
package
group
or
package
stage
to
fit
their
needs
and
initially
we
started
it.
So
we
started
out
with
one
job
to
be
done,
which
was
the
one
I
heard
most
often
from
customers.
A
I
want
to
replace
my
existing
universal
package,
man
or
manager
vendor
they
don't
want
to
have
get
lab,
and
so
no
type
or
kit
lab
and
J
frog,
for
example,
and
they
want
to
solidify
on
one
platform
and
only
pay
for
one
contract
and
not
worry
about
different
implementations.
So
that
was
like
an
example
of
a
reason
that
we've
heard
that
our
prospects
and
customers
thought
gitlab
and
specifically
the
package
day.
So
we
tried
thinking
through
things
at
that
high
level
of
job
to
be
done.
A
Why
are
people
hiring
us
and
then
for
each
one
of
those?
What
are
the
one
of
the
user
stories
that
are
required
to
satisfy
that
job
to
be
done?
So,
for
instance,
if
you
go
back
to
the
sono
type
example
or
J,
for
example,
we
could
say
well.
We
need
to
have
a
certain
coverage
of
package
manager
formats.
We
need
to
have
certain
capabilities.
We
need
to
have
the
ability
to
help
customers
transition
from
one
service
to
ours.
A
We
need,
they
probably
need
to
know
whether
or
not
they
could
do
that
and
things
like
that,
and
so
that
got
translated
into
user
stories
or
job
stories.
They're.
Basically,
the
same
thing:
the
difference
between
a
user
story
and
a
job
story
is
a
job
story,
has
a
little
bit
more
context.
It
has
you
would
just
a
user
stories.
I
is
Tim
when
I'm
drinking
coffee
want
it
to
be
hot
and
a
job
story
would
be
actually.
I
was
a
job
story.
A
You
add
the
context,
I
would
more
be
a
user
story
would
be
I
as
a
user
want
my
coffee
in
the
morning,
so
I
can
pop
and
then
a
job
story
would
be
more
specific.
I
would
be
like
I
as
Tim
when
I
am
doing
something
want
something.
So
I
could
do
this,
so
it
just
adds
a
little
bit
more
context
and
that's
why
he
and
I
use
those
a
bit
that
a
help
on
background
yeah.
A
This
this
list
in
the
issue
that
I
linked
to
includes
what
are
these
high
level
jobs
to
be
done,
and
people
have
been
going
in
and
voting
them
and
on
them
in
the
Google
Doc
that
needs
to
make
its
way
to
this
issue,
but
the
high
level.
What
I'm
thinking
is
when
my
organization
decides
to
move
forward,
you
need
to
prepare
and
migrate
the
organization's
packages
and
images
to
get
labs
package
and
container
registry.
A
So
this
is
all
about
being
able
to
easily
migrate
from
one
service
to
the
next,
and
then
we
have
a
bunch
of
job
stories
for
the
system
administrator
and
for
developer,
and
then
the
next
one
is
we
need
it
too.
They
need
it
to
work
reliably,
so
the
users
and
developers
have
a
consistent,
stable
experience.
That
seems
pretty
obvious,
but
that's
a
big
reason
that
people
want
to
use
get
lab
is
the
high
availability
and
performance.
A
Making
sure
that
they
work
that
the
registries
are
working
optimally,
and
so
they
could
but
not
worry
about
high
costs.
So
this
could
be
as
an
engineering
manager.
They
need
to
know
how
much
storage
is
being
used.
They
need
to
have
storage
management
features,
they
need
to
know,
be
able
to
monitor
the
system
and
things
like
that.
A
Can't
I
think
it's
public,
but
yeah.
That's
that's
the
idea,
and
so
what
we
want
to
do
and
then
then
the
thing
that's
gonna
happen.
Next
one
we
want
I
want
to
like
keep
the
voting
process
going
and
make
sure
that's
clear,
but
then
ian
is
going
to
take
each
one
of
those
prioritized
job
stories
that
we
or
jobs
to
be
done
and
he'll
create
one
of
those
UX
scorecard.
E
A
Through
what
step
has
to
be
record
done
free
to
accomplish
it,
and
then
he
gives
us
a
grade,
and
the
idea
is
that
we
won.
We
should
see
those
grades
improve
over
time.
Those
are
important
to
us
and
to
that
we
would
be
able
to
give
the
idea
that
they're
talking
about
now
is
using
those
scores
to
rate
our
maturity.
So
that's
why
it'll
be
important
for
us
to
say
which
jobs
to
be
done
in
job
stories
are
important,
so
that
we're
measured
and
that's
like
where
we
can
have
the
most
input.
A
D
A
I
think
I'm
not
decided
yet
on
what
the
framework
is.
I
think
I'll
choose
one
then
and
just
go
with
it
I'll
test
it
myself,
but
what
I
really
want
to
know
is
that
one.
We
think
this
is
important
or
not
important,
so
I
get
that
everybody
on
the
team
and
then
is
this
in
what
does
this
contribute
to
the
next
maturity
level?
And,
if
so,
maybe
like
less
important
but
like
what
grade?
Would
we
have
to
get
in
order
to
give
ourselves
to
reach
the
next
maturity
level?
A
So
if
there's
a
job
story
that
it,
that
is,
you
need
to
be
able
to
migrate
your
packages
to
the
package
registry.
At
what
point
do
we
say
we're
a
lovable
product,
for
instance:
does
that
have
to
be
an
A?
Is
it
or
is
a
B,
suffice
and
so
I
think,
having
some
way
of
grading
on
both
importance
and
also
like?
What's
the
threshold
for
the
maturity
level
and
now
that'll
be
the
trick
of
meat
of
the
process?
C
A
That's
that
that
would
definitely
be
awesome
if
we
could
do
that,
but
if
that's
yeah,
that
would
be,
that
would
be
great
just
having
a
conversation
about
each
of
them,
especially
the
ones
that,
if
we
all
say
it's
not
important
like
there's
some
that
are
down
there,
that
you
know
they're
little
they're
nice
to
haves
for
short,
because
we're
trying
to
be
cover
everything.
We
don't
have
to
have
that
level
of
depth
of
conversation,
but
one
that
has
like
10
up
votes.
And
you
know
everybody's
saying
this
is
the
key
to
having
a
mature
product.
A
All
right
so
I
think
next
steps
then
will
be
I
will
work
on
just
creating
some
I.
Really
we
already
have
them
all.
So
I
just
need
to
make
it.
So
it's
like
a
visual
way
that
we
could
all
vote
and
comment,
and
everything
and
and
I
want
it
to
be
in
good
lab.
So
I'll
work
on
that
over
the
rest
of
the
week
and
I'll
share
something
now
as
soon
as
I
have
it.
D
D
A
A
B
Ohs,
it
might
be
a
little
like
you
know,
off
of
what
you
were
specifically
saying,
but
when
it
comes
to
the
like
the
idea
of
voting
and
up
voting
because,
like
like
I,
think
I
mentioned
in
the
previous
issue,
that,
like
I'm
gonna,
be
extremely
biased
towards
like
the
developer
role
like,
for
example,
if
we
look
at
the
jobs
to
be
done
of
like
migrating
packages,
that's
not
something
I'm
going
to
ever
do
and
necessarily,
and
so,
while
I
understand
the
importance
of
it.
I
might
be
biased
against
me.
B
No
saying
that
that's
less
important
than
having
certain
package
features
available
within
the
UI.
So
when
it
comes
to
the
voting,
is
the
idea
to
vote
within
the
predefined
like
bold
job,
to
be
done,
but
what's
most
important
and
least
important
in
our
minds,
or
is
it
you
know
overall,
because
I
feel
like?
If
we
do
overall,
then
we
risk,
like
you
know,
being
biased
against
certain
jobs
just
because
of
our
roles
compared
to
roles
at
other
companies.
Yeah.
A
If
we
see
something
that
looks
off,
we
could
say:
okay,
we
should
think
about
this
one
too,
but
also
that's
why
we
push
it
through
the
validation
track,
because,
if
we're
all
saying
it's
important
and
we're
all
users
of
the
product
and
then
we
we
take
it
through
the
validation
track
and
we
see
like
every
system
administrator
goes.
Oh
I
can't
do
anything
until
you
have
this
done.
So
don't
even
bother
on
that
stuff.
A
That
would
give
us
a
little
bit
different
insight
into
the
problem,
validation
and
so
I'm
long
I'm,
okay,
with
things
like
that
bleeding
in
because
they
should
be,
they
should
be
weeded
out
during
the
interview
process
and
the
validation
process,
but
do
your
best
to
try
and
be
hippie
neutral
as
possible.
Yeah.
B
And
I
guess,
when
I
say
biased,
it's
more
of
a
like
lack
of
experience
in
certain
areas
like,
for
example,
I
have
never
worked
at
a
large
enterprise
company
that
has
hundreds
of
internal
packages.
So
I,
don't
really
like
know
how
that
works.
So
I
might
not
have
as
much
insight
into
those
types
of
features
and
end
of
the
importance
there.
I
think
that
would
be
more.
My
concern,
like
I,
like
certain
things,
I.
A
Does
make
me
think
that
they're
one
ones
we
kind
of
call
out
the
job
stories
by
my
role
but
I,
think
visualizing
them
by
role
could
be
really
useful
to
like
being
able
to
see
like
even
the
story
that
our
developer
stories
like
it's
not
just
like
so
cut-and-dry
that
this
would
be
a
developer.
This
would
be
assistant,
administrator,
I.
A
Think
a
lot
of
things
exist
on
a
spectrum,
so
it's
like
the
migration,
probably
wouldn't
fall
in
a
developer
until
it
did
because
there's
probably
some
things
you
would
have
to
do
and
if
you
got
really
frustrated
and
it's
gonna,
you
know,
what's
the
result
of
that
so
I
think
having
visualizing
once
we
have
at
some
visualization
of
like
maybe
it's
by
role
and
by
customer
type
would
be
really
valuable,
like
a
being
able
to
say
yes,
yes,
I
agree
with
that.
I
think.
E
A
Think
it's
true,
so
I
think
that
visualizing
this
in
the
end,
in
my
mind,
by
at
least
by
customer
or
by
user
type
and
by
customer
type,
is
a
really
like
an
interesting
way
of
looking
at
it,
because
the
needs
of
a
small
start-up
with
five
engineers
is
gonna,
be
very
different
than
the
needs
of
a
company
with
5,000
engineers.
So
in
the
end,
like
visualizing,
that
and
I
think
he
even
has
that
in
mind.
Already
we've
talked
about
that,
but
I
think
the
first
step
is
just
to
like
pass
through.
B
C
A
Think
what
we
should
do
is
because
this
is
leading
into
the
validation
track,
not
the
build
track.
We
should
be
open
to
asking
the
research
questions,
because
we
might
find
that
there's
a
different
way
to
implement
it.
Then
then,
the
most
challenging
way
like
let's
say
that
you
know
one
of
the
user
story
x.
We
think
we
all
think
this
is
really
valuable,
but
we
also
think
it's
incredibly
complex.
A
We
could
still
validate
that
it's
a
problem
talking
to
users
or
customers,
but
not
actually
implement
it
or
we
to
figure
out
a
way
like
a
path
to
implement
it,
but
it's
always
worth
calling
out
I.
Think
if
we're,
if
you're
commenting
on
a
specific
one-
and
you
say
this
looks
like
it's
gonna-
be
really
challenging
or
next
to
impossible,
it's
worth
calling
out,
and
maybe
we
didn't,
we
know
not
to
even
prioritize
it.
If
you
said
it's
just
there's
no
way
that
this
will
ever
happen.
I.
A
Am
I
want
to
went
to
this
product
conference
a
few
weeks
ago
and
they
were
talking
about
different
biases,
that
product
managers
face
and
one
of
my
favorite
examples
they
gave
was
during
world
war
two.
They
were
studying
a
lot
of
the
planes
that
were
coming
back,
I
like
to
figure
out
where
to
put
more
armor
on
the
additional
planes
because
they
and
they
would
look
at
the
bullet
holes
and
say,
okay.
A
So
they
were,
they
were
heading
armored
took
places
that
these
were
the
planes
that
were
surviving
versus,
like
looking
at
the
planes
that
had
all
crashed
and
where
all
the
bullets
were
centered
in
the
cockpit
and
so
like
that's
a
survivor,
bias
I
think
that's
called
for
example,
so
the
kit
lab
version
of
that
is,
if
we're
only
talking
to
customers
that
love
us.
It's
a
problem
right.
If
we're
not.
If
we're
not
thinking
about
the
customers
that
also
fired
us
survivorship.
Thank
you,
yeah
and
so
I.
A
B
D
A
Well,
I
think,
that's
all
that's
on
the
agenda,
so
maybe
we
can
give
people
back
20
minutes
of
their
day,
and
this
is
really
helpful
for
me
to
talk
out
to
by
the
way
today,
because
now
I
think
I
have
a
better
picture
of
how
to
format
this
and
what
some
of
your
concerns
and
how
you
want
to
participate
in
this.
So
thank
you
for
reviewing
this
today.
It
was
great
all
right,
I'm,
gonna,
stop
recording!
Thank
you.