►
From YouTube: Jobs To Be Done for GitLab Create:Source Code
Description
Members of GitLab's UX department review the initial work done to define the Jobs To Be Done (JTBD) for the Create:Source Code stage group.
Participants:
• Daniel Gruesso - Product Manager, Create:Source Code
• Katherine Okpara - UX Researcher, Create
• Lorie Whitaker - Staff UX Researcher, Release and Verify & Enablement
• Marcel van Remmerden - Product Design Manager, Create
• Pedro Moreira da Silva - Sr. Product Designer, Create:Source Code
A
A
And
then
some
of
the
groups
don't
have
necessarily
to
do
with
our
stage
group,
for
example,
rubies
and
applying
a
tag
release
to
prod
and
things
like
that.
But
those
are
things
that
are
related
and
are
all
in
this
continuum
of
the
DevOps
lifecycle
and
the
stages
that
people
use
in
good
lab
and
after
doing
this
grouping,
we
yeah
we
started
talking
about
next
steps
and
me
and
Katherine's
are
working
on
more
in
defining
what
could
be
the
situation's,
the
job
formers
and
then
the
maiden
jobs.
And
then
this
list,
which
I
was
writing
this.
A
A
Group,
but
usually
like
the
main
people
that
interacts
and
that's
been
most
of
the
time
there
are
the
authors
and
reviewers
but,
for
example,
a
team
manager
or
a
product
manager
like,
for
example,
the
product
manager
providing
requirements
to
the
team
if
they're
not
able
to
perform
this
job.
Well,
the
author
and
also
the
reviewer,
but
mostly
the
author,
won't
know
if
they're
doing
the
right
thing
and
then
the
reviewer
won't
have
the
necessary
context
to
know
if
they're
reviewing
it
really
the
right
thing.
A
Basically,
and
so
these
are
all
related,
but
I
don't
think
there
are
the
main,
like
the
juice,
the
core
of
what
we
do
in
source
code.
I'll
stop
there
I
have
other
questions
and
we
can
expand
further,
but
I'll
stop
there
for
any
comments
or
questions
from
everyone.
Not
only
you
worry,
but
I
mean
if
you
have
them
I.
B
Just
to
say
this
looks
great
and
I'm,
assuming
your
brainstorm
came
from
your
experiences
with
customers
and
past
research,
so
yeh,
because
that
gives
you
a
higher
level
of
confidence
going
into
this.
Some
of
the
people
tend
to
say:
don't
brainstorm,
but
I
know
who
did
this?
So
you
guys
are
you
think,
researched
to
brainstorm,
says
that's
perfect
and
the
main
reason
is
they
don't
want
people
to
start
to
get
away
from
grounding
it
in
the
research
I'm
not
worried
about
that
at
all.
C
A
B
A
A
A
Others
are
continuously
involving
like
hours,
I
get
that
and
I
also
thought
that,
even
if
someone
is
building
the
product,
they
don't
do
it
like
in
an
8-hour
shift.
You
know
it's
not
something
that
you
start
and
finish
and
you
feel
like.
Oh
I
perform
this
job,
so
I
thought
this
was
a
bit
too
broad
and
then
we
we
talked
about
this
one
contributing
changes
to
the
project
and
then
I
feel
like
so
in
in
terms
of
granularity.
A
A
A
B
I
want
to
show
you
so
yet
you're
totally
you
you're
totally
getting
there.
Let's
share
this
one,
and
so
I
can
actually
say
yes
sure.
Okay,
so
on
my
in
my
workshop,
we
have
not
gotten
to
the
point
where
we
are
in
complete
agreement.
Yet
that's
coming
on
Monday,
but
we
started
talking
about
this,
the
granularity
and
the
altitude
of
jobs
to
be
done
so
at
a
high
level.
You've
got
this.
This
slide,
where
you've
got
a
job
and
those
main
jobs
that
you
just
showed.
B
Those
are
jobs,
but
the
well
I
should
say
like
they
build
a
product.
That's
a
wonderful
job.
It's
really
high
level
it.
It
can
encapsulate
everything
you're
going
to
put
underneath
there
contribute
changes
to
the
products.
Dad
starts
to
be
a
little
bit
more
granular
that
actually
might
turn
into
a
user
story.
I
need
to
contribute
changes
to
the
product,
so
that
I
can,
because
this.
B
Sorry
and
so,
and
then
you
work
down
into
the
very
very
specific
tasks
which
you
say
to
the
point:
they
don't
do
this
in
eight
hours
in
one
day,
there's
there's
a
job
map
here.
There's
tasks
in
this
map
that
they
take
on
over
a
series
of
days
or
weeks
or
whatever.
It
is
the
time
scale
and
tasks
are
basically
just
the
things
that
they
need
to
do
in
order
to
complete
that
user
story,
which
is
included
in
that
main
job.
B
B
It's
kind
of
like
the
five
questions
that
five
wise
until
you
get
to
the
root
of
the
real
problem,
if
you're
trying
to
figure
out
what
the
aspiration
is
for
somebody,
you
have
it
here
in
your
mural,
but
if
you're
having,
if
you're
having
difficulty
figuring
out,
am
I
at
the
highest
level,
you
even
you
keep
asking
the.
Why
question
so
in
this
example,
somebody
wants
go
to
a
conference.
Why?
Why
do
they
want
to
go
now?
They
want
to
develop
professional
skills.
Why
they
want
to
advance
their
career?
B
Why
to
have
a
better
life
and
I
guess
you
could
go
even
higher
if
you
want
to
do.
Why
do
they
want
to
have
a
better
life,
but
you
could
stop
there?
It's
it's
broad.
The
same
thing
can
happen
when
you
start
to
ask
the
how
question,
because
now
you're
going
to
ask
it
and
you're
getting
more
granular
with
each
question
you're
asking
all
the
way
down
to
what
do
they
need
to
provide
in
order
for
their
boss
to
let
them
go
a
cost-benefit
estimation?
How
are
they
going
to
do
that?
B
That
tip
that
turns
into
your
micro
job
or
your
task
at
the
bottom
here
so
you're,
struggling
with
the
same
thing
that
I
have
talked
to
everybody
about
that
they're
struggling
with
is,
is
this
granularity
in
this
altitude
and
the
other
thing
I
wanted
to
show
before
we
get
back
to
your
mural?
Is
the
example
in
the
jobs
be
done
playbook
by
Jim
carbonic?
He
he
looks
at
jobs
on
four
different
levels
and
it's
his
book.
It's
got
jobs
in
the
tile,
that's
why
he
uses
jobs
for
each
one
beats
levels.
B
But
basically
your
aspiration
is
what
you
have
it's
perfect.
It's
an
ideal
change
of
states
very
high
level.
Then
you've
got
your
big
job
or
a
main
job
which
you're
calling
your
main
job,
and
then
you
have
a
little
job
and
for
him
that
corresponds
to
stages
in
a
job
so
for
his
book
he
also
is
having
you
map
out
the
job.
What
is
this
I
want
to
make
code
changes?
What
does
that
mean?
How
many
stages
are
in
that
that
job?
How
many
tasks
are
in
each
stage?
B
You
guys
haven't
gotten
there,
yet
it
might
help
you
to
do
that.
I,
don't
know
if
it
will
and
then
the
micro
jobs
are
the
same
things
as
tasks.
So
you
can
kind
of
map
that
back
here.
So
your
job
is
you've
got
your
aspiration
above
your
job.
You've
got
your
main
job
and
those
light.
Yellow
stickies
you've
got
your
user
stories,
which
are
very
similar
to
this
micro
job
idea,
which
is
your
you
map.
A
job
out.
B
You've
got
these
user
stories
that
are
in
that
job
job
map
and
then
you've
got
your
tasks,
so
I
just
wanted
to
show
that,
for
you
guys,
so
you
can
have
a
little
bit
of
understanding
about
where
were
where
we're
going
with
it
and
then
see
if
that
might
help
you
to
figure
out
how
to
frame
some
of
this
here
so
like
in
this
example,
build
the
so
you've
got
your
aspiration
perfectly
build
a
great
product.
Perfect
you've
got
your
main
job
build
the
product.
B
Yes,
that's
perfect
as
a
main
job,
and
now
what
you
need
to
do
is
you
need
to
break
the
line
between
that
level
of
granularity
and
the
other
levels,
the
other
two
levels
of
granularity,
which
is
basically
between
user
stories
and
tasks,
so
I,
would
say,
contribute
changes
to
the
project,
that's
probably
a
user
story,
because
it's
not
a
singular
task.
There
are
other
tasks
involved
in
that
user
story
to
achieve
that
action
of
contributing
changes
to
the
project.
B
If,
let's
see,
there's
related
job
in
the
middle
column,
integrate
changes
into
a
project
that
might
be
a
task
depending
on
how
me
I
don't
know
how
many
steps
are
involved.
If
it's
a
button
to
integrate
the
changes
or
something
like
that,
so
it
there's
a
there's
a
distinction
between,
as
we
all
know,
tasks
and
user
stories
tasks,
you
do
to
achieve
the
user
story.
You
do
the
user
story
to
achieve
the
job.
Those
kinds
of
layers
hit
me
my
question.
B
Yes,
so
asking
how
and
why
will
help
so
how
so
like
building
the
product?
How
am
I
going
to
build
the
product?
We're
gonna,
move
down,
we're
gonna,
get
more
granular
I'm
going
to
contribute
changes
to
the
project.
That's
great!
That's
getting
insight
user
story
kind
of
area
of
I
need
to
because
so
that
how
am
I
going
to
contribute
changes
to
the
project.
A
B
B
I
user
stories
is
when
you
start
to
say,
as
an
author
I
need
to
do
this,
so
that
I
can
because
of
this,
that's
when
it
becomes
much
more
persona
century,
because
the
idea
of
a
job
to
be
done
is
that
it
is
broad
it's
not
as
broad
as
an
aspiration,
but
it
is
broad.
It
is
meant
to
not
be
tied
to
a
specific
persona.
It
can
be,
but
it's
never
that
personas
never
mentioned
in
a
job
to
be
done.
Grandma.
C
Yeah
I
think
one
thing
here
and
I
think
that's
exactly
right.
What
the
author
I
guess!
You
could
say
that
multiple
personas
could
be
an
author
I,
just
see
it
as
a
bucket
for
understanding
these
different
parts
of
source
code
management,
but
yeah.
It
definitely
isn't
something
you
would
put
into
the
statement
or
it's.
B
A
D
Me
try
to
yeah.
Let
me
try
to
ask
for
another
angle,
because
we
are
using
this
as
input,
then
also
for
the
category
maturity,
scope,
process
right
and
I'm
feeling.
We
are
now
looking
at
main
job
as
very
Olive
gate
lab.
But
in
this
discussion
it's
more
create
and
if
we
take
build
a
great
product,
SD
job
to
be
done
to
be
investigated
by
the
category
maturity
scorecard
I,
don't
know
how
we
perform
that
in
a
15
minute
session.
Right.
B
Yes,
it's
at
a
point
myself,
I
actually
took
a
note
when
I
was
we
were
doing
the
workshop
on
Wednesday,
then
I
need
to
go
in
there
and
I
need
to
specify
that
it's
not
that
you're
testing
retesting
it
in
some.
In
some
instances,
you're
testing
an
aspect
of
a
job
to
be
done,
but
what
you're
really
testing
or
user
stories
and
tasks?
D
D
Yeah,
in
that
case,
it
feels
to
me,
like
the
team,
has
done
a
great
job,
putting
all
the
granularities
already
into
this
into
the
structure,
and
it's
just
a
different
focus
for
where
do
we
as
create
focus
on
a
source
code
and
making
sure
we
don't
lose
the
part
above
it
out
of
sight,
but
not
taking
that
as
the
main
part
to
be
investigated
by
the
category.
Maturity
scorecard
right.
A
How
would
how
everyone
understands
when
they're
building
something
is
it
contributing
towards
this
right
or
not?
And
then
that
would
contribute
to
the
aspiration
I
mean
at
the
end
of
the
day,
the
aspiration
of
like
all
of
aspirations
were
probably
mapped
to
Maslow's
pyramid
right
either
someone
wants
to
survive,
even
though
someone
wants
to
be
happy
either.
Someone
wants
to
be
accomplished
like
that's
like.
If
we
go
all
the
way,
if
we
ask
all
of
the
Y's,
that's
where
we
will
probably
land
so
I
think
if
we
say
that
the
main
job
for
a
big.
A
Job
performance
is
to
build
the
product
like
every
time.
Someone
creates
a
Petri
proposal,
they're
gonna
say
yes,
this
aligns
with
your
job
to
be
done
of
building
the
product
and
there's
nothing.
We
can
say
about
it
because
it's
so
broad
that
anyone
can
fit
have
anything
that
we
do
fits
and
build
the
products
right.
B
And
again,
we
wait
and
that's
all
you
have
to
meet
with
everybody
for
another
hour
in
Monday,
because
we
didn't
see
the
other
part
of
that
is
in
and
I
don't
like
this
as
a
as
a
person,
I,
don't
think
as
it's.
It's
that
whole
phrase.
It
depends
so
now
that
we
talked
about
all
that
it
still
depends
like
you
can
look
at
all
this
and
go
I
need
I.
My
group
needs
more
granularity
and
our
job
to
be
done.
B
We're
gonna
go
down
the
level
for
our
job
to
be
done
for
create
or
a
for
secure
whatever.
It
is
that's
that
group
and
you
can
right
now
we
have
to
decide
in
internally
as
gangs
gitlab,
especially
as
the
UX
department
and
product,
how
we
want
to
handle
bad
granularity.
Is
that
going
to
be
a
job
to
be
done
to
get
stuck
down,
or
is
that
going
to
be
turned
into
a
user
scenario?
I,
don't
know
to
me,
there's
no
wrong
answer
there,
which
is
why
it
makes
me
angry.
B
A
B
Very
very
used
to
using
personas
as
a
software
developer.
I
need
to.
You
have
to
take
the
persona
out
of
the
job
to
be
done,
because
it's
not
meant
to
be
that
that
specific
to
a
type
of
personal,
attentive
role,
it
is
meant
to
be
a
little
bit
broader
than
that.
This
specificity
comes
in
with
the
user
scenarios,
or
these
are
stories
so.
B
B
They
want
you
to
keep
the
job
before
their
minds.
You're,
not
trying
to
make
somebody
do
a
job
that
doesn't
need
to
be
doing
that
job,
but
it's
not
that
you're,
mentioning
them
and
thinking
of
them,
specifically
in
that
job,
you're
you're
getting
more
granular
than
where
you
go
down
and
applying
those
personas
at
the
user
story
level
in
the
task
level.
Yeah.
A
A
I,
just
I
just
feel
that
we
should
have
the
like.
The
same
level
of
granularity
should
be
applied
across
all
of
the
stages
of
good
lab,
so
that
we
have
a
common
language
to
communicate
and
agree
on
what
what
are
the
boundaries
and
how
people
cross
stages
and
also
to
properly
evaluate
to
carry
very
maturity
or
elsewhere.
Be
we're
going
to
be
evaluating
differently
and
yeah
and
I
feel.
A
Yeah,
just
I
just
think
that's
if
the
job
is
to
brought
it
there,
there
won't
be
any
anchors.
People
won't
use
a
job
because
I
mean
even
if
you
look
at
the
stage
or
the
stage
names
like
create
plan.
Everyone
agrees
that
this
feature
isn't
plan.
Everyone
agrees
that
this
feature
isn't
create,
and
this
need
is
solved
by
that
stage
in
that
stage,
because
it's
so
broad,
it's
already
in
the
names.
So
if
we're
going
that
broad
I
don't
know
if
it
will
help
us
basically
well.
B
In
painter,
to
be
honest,
I
don't
know
if
we
are,
because
that's
where
that
group,
the
working
group
has
now
gotten
into
a
consensus,
yet
I
suspect
we
will
get
four
you're
going
on
Monday
that
it
they
need.
We
need
to
have
our
jobs.
Be
done,
are
going
to
start
more
granular
than
what
the
other
people
Ulric
in
call
back
from
prescribe,
because
we
need
them
to
start
more
granular
for
our
purposes,
because
we're
using
them
for
more
than
one
day
I,
don't
want
to
say
we
have
to
do
it
that
way.
B
I
need
everybody
to
come
to
a
consensus
with
me
on
that.
So
then
we
can
say.
Okay,
this
is
useful.
We
can
use
it
for
the
calculating
show
you
scorecards.
We
can
use
it
across
stages.
We
can
use
this
and
apply
and
look
at
across
everybody
to
see
how
that
one
more
granular
job
performs
I
suspect.
That's
where
we'll
get
will
land
on
like
a
medium
level,
granularity
for
just
be
done
and
then
use
like
build
the
product
as
our
aspiration.
Okay,.
A
B
B
Monday
because
we
we've
got
another
hour
and
so
that
that's
kind
of
where
we
talked
about
for
about
25
minutes
on
Wednesday
and
we
we
got
halfway
through
I,
think
the
discussion
and
hopefully
people
will
go
and
think
about
its
more
come
back
to
me
on
Monday
and
we'll
talk
about
it.
That
was
the
biggest
sticking
point
that
we
had
and
I
think.
If
we
can
crack
it,
it
will
answer
a
lot
of
the
other
questions
they
had
about.
How
do
I
play
this
product?
How
about
apply
this
to
building
features?