►
From YouTube: UX Showcase: Discovering JTBD at GitLab
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
Hello,
so
I
recently
finished
some
jobs
to
be
done,
interviews
and
wanted
to
kind
of
take
the
time
to
reflect
back
on
the
Lessons
Learned,
but
also
the
big
picture,
discovering
job
to
be
done
at
gitlab
and
wanted
to
share
some
of
that
information.
So
I
want
to
start
first,
some
brief
background
into
the
research
I
just
recently
did
for
securing
govern.
A
We
use
the
jobs
to
be
done,
Playbook
by
Jim
callback
as
a
primary
source,
which
a
lot
of
people
have
read
here
we
asked
we
were
just
wondering
what
were
the
jobs
to
be
done
for
creating
security
policies
and
other
related
jobs,
as
well
as
any
aspirational
jobs,
and
the
interviews
were
with
12
people
that
took
place
from
January
to
February
of
this
year.
So
I'll
talk
a
little
bit
about
the
lessons
learned
from
that,
but
also
just
jobs
to
be
done
in
general.
A
So
to
do
that
first
I
want
to
talk
about
how
jobs
be
done
are
more
than
just
a
job
story.
A
Jobs
to
be
done
are
discovered
through
interviews
and
and
we
are
finding
that
jobs
to
be
done
are
the
building
blocks
for
gitlab.
Were
a
lot
of
things
within
gitlab
that
we've
been
using
so
just
to
start
talking
about
jobs,
to
be
done
being
more
than
just
a
job
story.
A
So,
first,
when
we're
working
on
everything,
we
obviously
started
with
job
stories
and
I
looked
at
the
parts
of
a
job
Story
how
to
break
them
down
and
I
was
finding
a
lot
of
usefulness
in
the
modularity
of
it
being
able
to
go
to
the
smaller
levels
like
with
microdrops
and
small
jobs,
as
well
as,
if
you
are
in
a
micro
job,
to
move
up
and
to
be
able
to
use
the
job
statements
kind
of
interchangeably
and
to
understand
like
the
higher
level
of
workflows.
A
But
they
didn't
provide
everything
they
weren't
completing
all
of
the
understanding,
and
to
do
that,
we
really
started
focusing
on
a
job
canvas
or
a
job
to
be
done.
Canvas
which
includes
more
than
just
the
job
story
and
the
need
statement
and
the
circumstances
and
the
job
statement.
So
the
job
to
be
done.
Canvas
includes
related
jobs,
emotional
jobs
and
social
jobs,
as
well
as
the
job
performer
and
in
more
detail
about
the
job
process.
A
We
really
saw
a
lot
of
information,
a
lot
of
usefulness
with
the
job
performer
understanding
who
a
job
performer
is
said,
the
different
types
of
job
performers
and
the
difference
between
that
and
a
user
Persona,
and
we
also
had
a
lot
of
value
in
understanding
the
process
using
the
job
to
be
on
canvas
getting
down
to
the
micro
jobs
and
then
getting
all
the
way
up
to.
It
doesn't
sit
here
but
aspirational
jobs
and
big
jobs
and
how
those
relate
to
each
other.
A
We
found
that,
seeing
all
of
these
things
out
once
really
kind
of
completed
the
picture.
More
than
just
a
single
job
story
could
and
the
the
thing
that
was
really
helpful,
like
I
said,
was
moving
up
and
down,
and
especially
during
discovering
the
interviews
and
actually
during
the
research,
the
ability
to
ask
why
to
move
up
to
towards
the
main
job
and
ask
how
to
move
towards
a
micro
job
was
really
helpful
and
kind
of
instrumental
in
the
actual
interviews.
A
So
to
talk
about
those
interviews,
I
want
to
talk
about
how
you
can
discover
jobs
to
be
done
through
interviews
and
that's
actually
not
too
hard.
We
found
the
process
relatively
easy
and
we
took
a
lot
of
the
lessons
that
we
had
and
applied
them
into
our
template
into
the
handbook.
So
one
of
the
first
things
that
we
started
with
was
just
to
scope
the
project,
and
that
was
actually
really
important
for
us
to
do
and
something
we
realized
that
we
kind
of
have
skipped.
In
the
past.
A
A
We
saw
this
basically
after
the
first
like
five
interviews,
that
the
only
way
we
could
appropriately
determine
the
scope
of
the
interviews
was
using
the
screener
and
essentially
making
sure
to
terminate
the
people
that
we
didn't
want
to
talk
to.
For
us,
it
happened
to
be
network
security
policies
happen
to
be
using
language
that
were
very
similar
to
our
security
policies
for
application
security
development.
A
So
in
our
screener
we
had
to
include
a
specific
text
for
people
who
knew
network
security
policies,
so
they
would
select
it
and
then
be
terminated
and
not
become
a
participant,
but
just
in
general
we
really.
We
realized
that
the
screen
error
was
different
than
most
other
screeners,
because
it's
very
generative
and
open-ended
in
nature.
A
So
we
kind
of
had
to
be
open-ended
in
nature
in
the
screener
as
well
and
use
the
results
that
they
give
and
actually
just
talk
about
them.
We
asked
what
were
their
top
one
to
two
jobs
and
to
write
a
sentence
about
it,
and
then
we
used
their
own
description
of
their
job
to
figure
out
if
they
were
in
scope
for
us
or
if
they
were
out
of
scope.
We
found
that
was
really
easy
and
helpful
to
actually
talk
to
the
people.
A
A
Basically,
I
knew
that
the
questions
I
was
asking
were
kind
of
important,
but
I
wasn't
confident
in
my
ability
to
understand
all
the
answers,
but
I
realized
I
was
actually
kind
of
a
core
part
of
the
entire
experience,
because
jobs
to
be
done
are
so
foundational
to
how
we
do
things
and
how
we
see
the
workflow.
If
we
don't
know
it,
then
we
really
have
no
idea
what
it
is.
A
We
don't
know
it
at
all
and
there's
very
little
that
we
can
use
to
help
us
understand
it
without
actually
talking
to
the
people
so
I
found
the
first
version
of
my
script
was
actually
very.
It
was
too
intensive.
It
had
too
much
back
and
forth
and
questioned
and
answers
and
I
realized
I
had
to
be
more
General
and
use
a
lot
more
active
listening.
A
So
I
kind
of
wanted
to
focus
on
that
specifically
because
it
was
very,
very
helpful
in
the
interviews
just
to
listen
more
than
talk
I
found.
That
was
the
easiest
way
to
collect
data,
as
well
as
to
get
the
things
that
I
wanted.
So
I
was
I
found
some
just
high
level
active
listening
techniques,
but
some
that
were
really
helpful
for
us
were
asking
probing
questions
and
requesting
clarification
as
well
as
paraphrasing,
basically
parroting
back
everything
that
they
told
me
in
a
different
way.
A
So
that
way,
the
conversation
went
from
like
an
interview
with
questions
and
answers
to
more
talking
with
someone
and
agreeing
on
an
understanding
of
something
that
they
knew
about
and
really
using
them
as
an
expert
and
just
asking
them
questions
along
their
way
and
getting
to
know
everything
and
I
felt
at
the
end.
If
the
participant
wasn't
completely
understanding
what
I
was
doing
in
the
interview,
then
it
wasn't
a
good
interview
and
I
wasn't
doing
it
right.
A
The
last
thing,
I
kind
of
learned
was
that
it
is
very
important
to
have
a
note
taker
and
if
you
don't
have
a
note
taker
go
even
slower,
I
found
it
is
possible
to
do
it.
Without
a
note
taker,
the
interviews
generally
take
one
to
two
months.
The
data
synthesis
can
take
a
little
bit
longer,
but
I
found
if
I
had
a
note
taker.
A
It
was
a
lot
easier
to
map
the
process
in
a
mural
and
then
show
it
to
the
participant
and
have
them
validate
it
and
ask
them
questions
about
it.
Ask
them
if
it
makes
sense
to
them
and
if
they
would
do
anything
differently
from
what
we
wrote
down
and
being
very
deliberate
about
the
language
in
each
step,
asking
them
if,
if
that
sounds
right
to
them,
and
if
it
makes
sense,
this
is
the
a
murals
job
to
be
on
canvas.
A
That's
finished,
just
as
an
example,
and
we
put
a
lot
of
time,
mainly
in
the
job
process.
We
focused
a
lot
in
what
steps
made
sense
together
in
looking
at
those
steps
and
then
the
job
performer
and
looking
at
the
commonalities,
so
common
job
performers
and
common
steps
for
those
job
and
job
performers
doing
that
was
a
really
easy
way
actually
to
get
to
the
inside
needed.
Instead
of
kind
of
blowing
everything
up
and
making
it
really
complicated.
A
We
kind
of
just
focused
on
the
few
things
that
seem
to
be
the
most
consistent,
most
important
and
then
building
everything
else
from
there
and
that
helped
a
lot
and
that
was
actually
really
really
useful.
So
we
found
that
the
more
we
talked
about
jobs
to
be
done,
the
more
we
understood
them
as
a
group
and
as
a
section,
the
more
we
use
them
as
well
and
the
more
we
realize
that
they're
used
in
other
things.
A
So
one
thing:
the
one
of
the
goals
of
the
job
to
be
on
canvas
and
jobs
to
be
done
is
to
do
more
outcome
driven
Innovation.
So
we
can
use
the
jobs
to
map
the
priority
and
importance
and
build
towards
them.
So
we
can
see
underserved
appropriately,
served
or
over
served
needs,
and
we
can
get
at
that
just
by
asking
two
questions
that
directly
came
from
like
the
job
to
be
done.
A
Playbook
and
we
just
asked
the
main
job
and
the
two
questions,
and
we
can
have
an
incremental
model
for
prioritizing
and
understanding
the
needs
quantitatively,
and
then
using
that
for
our
themes
and
our
roadmaps,
so
I'm
gonna
go
into
that.
Securing
government
has
been
using
themes
and
roadmaps
more
the
last
year
and
to
to
a
good
amount
of
success.
We
think
it's
been
pretty
helpful
to
just
kind
of
understand
things
as
a
whole
and
the
jobs
to
be
done.
We
found
are
really
really
tied
into
that.
A
Having
solid
jobs
to
be
done
that
were
validated
with
research
was
really
helpful,
because
one
question
we
kept
asking
is:
how
do
we
know
that
that
job
to
be
done
is
at
the
right
level?
How
do
we
know
that
it
is
both?
The
workflow
is
exhaustive.
It
does
everything
that
the
users
do,
and
it's
at
the
right
level
that
it
needs
to
be
at
because
our
previous
unvalidated
jobs,
a
lot
of
them,
were
either
too
wide
or
too
unfocused.
A
That
would
be
do
this
specific
step
and
it
was
kind
of
hard
to
relate
those
words
into
a
roadmap,
so
how
having
well-validated
jobs
definitely
help
for
that
and
then
using
them
in
the
themes,
as
well
as
the
roadmaps
it
made
it
because
we
all
use
other
things
in
the
themes
as
well
to
collect
the
information
and
having
the
validated
jobs
to
be
done,
made
it
more
consistent,
made
everything
more
consistent,
so
all
of
the
non-jobs
to
be
done.
Insights
also
aligned
with
our
jobs
to
be
done.
A
So
all
of
the
theme
as
a
whole
was
more
consistent.
One
of
the
other
things
that
we
saw
was
really
helpful
for
for
jobs
to
be
done
to
be
used,
for
is
the
category
maturity
scorecard.
A
Obviously,
we
ask
a
number
of
questions
for
the
category
maturity
scorecard
and
one
of
the
main
ones
Step
Zero
actually
for
the
the
process
is
to
understand
the
jobs
to
be
done
is
to
use
the
job
statement
for
the
survey,
the
questions
that
are
on
the
left,
and
that
is
how
we
grade
everything
so
having
the
appropriate
job
level
that
is
validated
was
really
really
helpful.
For
us,
and
was
super
important
and
from
the
research
side
of
things
kind
of
what
made
me
start
this
job
to
be
done.
A
Research
actually
was
doing
the
benchmarking.
The
Benchmark
takes
the
workflows
that
the
user
does
has
various
tasks
for
them
to
do,
and
then
grades
them
based
off
of
what
how
successful
they
were
and
the
conversation
of
shaping
what
those
tasks
were,
and
what
success
was
was
very,
very
much
revolved
around
jobs
to
be
done.
A
We
had
to
understand
their
big
job,
what
their
main
goal
was
and
what
their
individual
tasks
were
in
order
to
set
up
the
right
success
criteria
for
the
benchmarking,
and
if
you
don't
have
the
right
level
of
jobs
to
be
done
or
as
well
detailed
as
they
should
be,
then
it
could
be
a
lot
harder
to
map
the
correct
benchmarking
and
get
the
results
that
are
actually
useful
and
applicable
to
a
realistic
situation
so
just
to
go
over
everything
again,
we
found
that
job
story,
a
job
to
be
done
were
more
than
just
a
job
stories.
A
Having
all
of
the
job.
Canvas
was
really
helpful.
For
us,
jobs
to
be
done
are
discovered
through
interviews,
and
it's
not
too
much.
It
usually
takes
about
two
months
or
so
to
talk
to
everybody
and
get
all
of
the
Discover
jobs
to
be
done
and
that
you
can
use
them
for
a
lot
of
things.
Innovation
themes,
roadmaps,
scorecards
and
benchmarking.
A
This
research
was
also
so
helpful
for
us.
We
came
up
with
another
hand
what
random
other
things
that
came
out
of
it,
including
the
slide,
but
also
the
related
jobs,
to
be
done
more
research
for
another
group
to
validate
those
jobs
to
be
done.
A
We
also
had
multiple
handbook
updates,
I
mentioned
earlier,
the
difference
between
a
job
performer
and
a
user
persona,
but
the
more
we
have
conversations
around
it
and
the
more
we
use
jobs
to
be
done,
the
more
we
wanted
to
kind
of
understand
them
and
clarify
them,
and
all
that
was
pretty
helpful
and
then
the
clips
that
we
actually
got
from
it.
A
Some
of
the
interviews
were
so
helpful
by
themselves
that
they
were
worth
it
to
clip
the
insights
separately
from
the
rest
of
the
the
data
and
share
it
individually
with
people
in
the
slack
group.
So
they
can
see
an
example
of
a
user
workflow
or
usually
have
a
user
having
some
needs
that
weren't
really
explained
in
other
jobs
or
other
areas
of
the
handbook.
A
So
yeah,
that's
it.
If
anyone
has
any
questions,
oh
Camellia.
B
Yeah
I
have
the
first
question.
I
just
first
want
to
say
thank
you,
I,
really
like
the
job
to
be
down.
You
do
for
the
policy,
it's
really
helped
my
work
a
lot
and
the
small
thing
I
realized
like
for
the
emotional
relief
thing
we
documented
are
the
negative
emotion
so
I'm.
Just
having
a
question
like
curious
about.
Do
people
ever
talk
about
positive
emotion?
Do
we
think
it's
valuable
to
document
positive
emotion,
because
there
are
some?
A
That's
a
yeah,
that's
a
really
good
question.
I
think
it
I
can't
have
research
that
explicitly
knows
this,
but
from
my
experience,
people
don't
typically
bring
up
positive
things,
naturally,
quite
as
much
as
they
would
bring
up
negative
things.
The
script
that
we
kind
of
used
from
the
job
and
Playbook
also
did
happen
to
focus
on
like
things
that
they
didn't
like
anything
that
they
remember
that
they
would
have
changed
stuff
like
that.
It
tend
to
ask
those
questions
more,
but
I.
A
A
That's
actually
because
negative
emotions
are
more
prevalent
in
the
job
to
be
done
compared
to
positive
emotions,
I
think
in
general,
the
emotional
elements
are
of
the
Lesser
prioritized
things
just
because
if
we
want
to
understand
more
about
how
users
feel
about
a
certain
thing,
there
could
be
other
research
methods
that
get
that
data
in
a
more
clear
and
concise
way,
whereas
the
jobs
research.
It's
like
a
helpful
add-on
or
almost
like
a
cherry
on
top,
where
it's
like.
Oh
it
kind
of
rounds
out
the
rest
of
the
understanding
of
the
workflow
in
the
job.
A
A
B
I
think,
like
it's
really
interesting,
maybe
future
to
dive
into
that,
because
sometimes
because
we
design
something
so
logical
and
our
product
is
like
technical
driven
and
sometimes
we
forgot
users,
emotion
in
the
background
and
those
something
good
to
be
easier
to
step
into
users.
Shoes
if
there
are
other
methods
or
like
if
we
have
time
to
prioritize
those
research,
I'm
very
interested.
Let
me
know.
A
Yeah,
that's
a
that's
a
good
idea
to
be
honest.
I
actually
found
it
to
be
kind
of
hard
to
ask
the
question
in
general,
because
one
of
the
questions
like
random
motion
was
every
time
I
gave
it.
I
gave
it
to
somebody
in
the
interviews
they
all
kind
of
like
stumbled
over
the
question.
They
all
kind
of
like
didn't,
really
know
how
to
answer
it
initially
and
I
think
it's
kind
of
hard
for
those
people
to
context
switch
between
their
workflow
and
the
logic,
steps
and
then
their
emotions
involved.
A
C
To
speak,
yeah
thanks
Michael
great
great
work,
I
love
this
presentation
in
particular
I
liked
how
you
showed
the
relationship
between
job
to
be
done
and
the
different
activities
or
methods
that
we
use
in
our
design
process
and
I
was
looking
at
the
jobs
to
be
done
page
and
having
the
handbook,
and
we
only
mentioned
that
link
very
lightly
at
the
top.
So
I
wonder
if
there's
an
opportunity
here
to
expand
on
that,
to
show
how
jobs
be
done
are
at
the
core
of
those
activities.
I
know
that
you
know.
C
If
you
go
and
look
at
the
you
know,
ux
benchmark
or
some
other
activities
you
see
jobsvidan
mentioned
as
a
requisite
as
something
that
you
need
to
do,
but
I
I
really
liked
seeing
this
overview
that
connects
these
things.
So
I
I
wonder
if
it
would
be
nice
to
expand
on
that.
A
Yes,
I
think
it
would
I
think
you're
completely
right
I
even
earlier
today,
I
showed
this
to
Andy,
who
was
helpful
enough
in
providing
me
some
of
the
images
and
like
visuals
that
he
created
I
realized
looking
at
him.
C
Yeah
exactly
yeah,
because
when,
when
you
look
at
the
specific
methods,
it's
there
and
you're
like
oh
okay,
I
need
jobs
to
be
done,
but
the
jobs
to
be
done
themselves.
If
you
notice
how
how
many
activities
it
supports
in
our
Innovation
and
design
practice,
I
think
that
strengthens
their
importance.
A
lot
yeah.
A
Absolutely
I
agree:
do
you
want
to
voice
your
comment.
D
Yeah
there's
some
like
something
strange
that
I've
been
experiencing
so
jobs
to
be
done
is
definitely
something
very
helpful
and,
like
Pedro
said
it's
kind
of
at
the
center
of
everything
that
we
do
here.
So
it's,
of
course
something
very
important
and
every
time
I
visit,
I
won't
say
every
time
because
I
visit
like
pretty
often
but
every
six
months
when
I
look
at
the
documented
jobs
to
be
done.
D
For
my
Stage
Group,
it
feels
like
it's
a
little
off
and
requires
some
correction
and
that's
when
I
go
back
to
like
I
revisit
the
insights
that
I
receive
from
any
recent
research
that
I
conducted
and
if
not
I,
even
have
performed
like
very
foundational
research
just
to
kind
of
redo.
My
the
documented
jobs
to
be
done
but
I
mean.
D
Is
there
any
guidance
on
how
to
make
sure
or
how
to
determine
the
right
elevation
for
the
documented
jobs
to
be
done,
because
I
mean
this
process
of
revisiting
every
time
it's
helpful,
but
maybe
there's
something
that
would
ensure
that
the
first
time
we
do
it.
It's
like
done
at
the
right
level.
A
Yeah
I
found
that
was
a
a
common
thing
in
our
group.
I
actually
have
a
research
with
a
group
to
just
re-level
their
jobs,
not
even
ReDiscover,
just
to
re-level
it
at
the
fact.
So
it
is
definitely
common
I.
Don't
think
there
are
handbook
pages
that
speak
to
this,
so
I
think
that's
a
need
that
we
should
probably
work
on,
but
something
that
helped
me
from
the
job
speed
done.
Playbook
was
that
a
job
to
be
done
should
exist
without
in
a
UI
or
a
particular
product.
A
The
biggest
thing
is
it
should
be
product
agnostic,
and
it
should,
if
you
really
that
the
UI
thing
and
for
us
I
obviously
thought
of
it
in
terms
of
RCI
like
a
job
speed
done
should
be
able
to
be
completed
without
any
reference
to
a
specific
feature
on
gitlab,
and
it
should
be
one
of
the
other
things
I
think
I
think
I
said
was.
It
should
be
able
to
be
done
in
50
years
or
theoretically
done
in
50
years.
I
didn't
put
that
in
here
and
I.
A
C
A
And
the
micro
jobs
are
the
things
that
are
changing
more
regularly
I
found,
so
a
big
job
should
be
something
like
gather
resources
doing
you
know,
writing
a
job,
doing
something
general
and
then
the
micro
step
is
actually
how
they
did
it
in
this
specific
product
or
how
they
did
it
in
this
specific
situation.
But
a
lot
of
that
just
came
from
conversations
too,
with
Andy,
as
well
as
other
people
in
this
Stage
Group.
Just
asking
does
this
make
sense?
Does
it
compare
to
the
other
jobs
at
the
right
level?
A
I,
don't
know
if
that
helps
I'm
sure
we
can.
If
you
have
any
more
questions,
that's
a
big
thing,
so
I'm
sure
we
could
dive
into
it
deeper
in
some
other
place
or
another
issue.