►
From YouTube: JTBD Alignment Workshop - part 1
Description
Members of our Product Management Team, Product Design Team and UX Research Team met to align on what JTBD means for GitLab:
- Common definitions
- Which grammar structure to use
- How to choose the right level of granularity for JTBD
A
So
I'm
going
to
start
with
why
we're
here
I'm
going
to
go
over
all
the
things
that
we
have
lined
really
well
on
based
on
your
feedback.
So
thank
you
so
much
for
filling
out
the
mural.
That
really
really
helps
me
a
lot,
and
then
we
have
a
couple
of
areas
that
we
need
to
discuss
and
so
the
slides
here
or
just
going
to
be
used
as
templates
and
a
place
for
me
I'll
type.
A
B
A
A
All
right
thanks,
alright,
so
we're
here,
we've
got
some
challenges.
We've
got
at
least
four
different
places
that
I
found
that
mentioned
jobs
to
be
done.
That
doesn't
even
include
my
merger
process
and
process
that
covers
a
lot
of
what
we're
gonna
talk
about
today
and
as
well
as
the
stage
group
jobs
to
be
done,
format.
The
format
and
the
usage
of
them
is
varying,
at
least
with
the
five
places
I
found
here,
not
that
much,
but
it's
a
little
bit
different,
a
little
bit
different
flavors
between
each
of
the
different
groups.
A
So
we're
really
just
trying
to
align
expectations
and
usage
definitions,
all
that
jazz.
So
these
are
the
questions
that
really
stood
out
to
me
from
our
earlier
meeting
that
we
had
when
we
kind
of
brainstorm
some
some
concerns
we're
gonna
get
to
almost
every
one
of
these
today.
So
it
was
just
good.
Some
of
these
we
actually
came
together
on
without
having
to
discuss,
but
people
want
answers
to
those
and
you'll
see
some
names.
A
A
It's
it's
a
framework
for
understanding,
user,
behavior
you're
using
it
to
innovate,
product
strategy,
and
it
also
includes
that
task
that
somebody
or
a
group
of
people
want
to
accomplish
as
part
of
their
day-to-day
function
and
at
any
point
you
guys
just
take
yourself
off
the
mute
and
be
like.
No,
that's
fine
with
me.
I.
Don't
need
to
wait
to
the
end
for
questions
or
concerns.
I'm.
C
C
A
A
The
next
piece
was
the
principles
like
what
are
the
core
jobs
to
be
a
job
to
be
doubted,
principles,
and
these
were
these
are
great
I'm,
so
glad
to
read
these
people
buy
products
to
get
a
job
done
right,
they're,
not
buying
it,
for
any
other
reason,
their
persona
and
solution,
agnostic,
which
means
they're
not
directed
to
any
one
persona
any
one
time.
You
know
not
wrapped
around
the
get
lab
solution.
It's
goal
that
they
need
to
accomplish
solution
aside.
A
You
have
to
have
a
foundational
understanding
of
what
jobs
people
need
help
in
getting
done,
but
what
are
they
trying
to
do?
You
have
to
know
that
out.
First
and
jobs
are
consistent,
even
if
the
technology
changes,
which
is
why
you're
trying
to
get
away
from
the
solution
and
they're,
not
a
user
story.
So
this
was
great
questions.
Concerns
disagreements.
D
D
A
Perfect,
yes,
keep
me
honest
five
hours,
sleep
does
not
do
me
good
alright.
So
where
are
we
getting
these
jobs
to
be
done
from
and
overwhelmingly,
you
guys
agree
it's
coming
from
research,
either
through
in
observation
or
interviewing
people
who
could
be
impacted
or
is
using
the
product
understanding
their
underlying
motivations,
for
what
they're
doing
in
trying
to
expose
unmet
needs
that
they
may
not
even
be
aware
of
we're.
Also
looking
at
market
assumptions
and
competitive
landscape
as
well
to
understand
what
those
jobs
to
be
done
might
be.
B
A
It
should
be
what
it
should
be.
Do
yeah
yeah
this
whole
hour
today
is
to
come
out
with
what
should
be
happening
here,
and
so
we
understand
that
it's
not,
which
is
why
we
here.
So
that's
good
catch
Jackie
all
right.
So
then
the
next
thing
was
about
needs.
So
there
was
one
with
questions
on
the
mural
around.
A
How
needs
are
factoring
into
jobs
to
be
done
and
we
Hawaiians
are
not
pretty
well
as
well,
because
jobs
to
be
done
help
define
the
scope,
you
keep,
the
user
needs
at
the
forefront
and
it
allows
for
the.
How
might
we
discussions
to
happen
in
order
to
innovate
and
then
talking
about
the
desired
outcome,
which
is
very
closely
really
listen,
needs
help
strategists,
think
outside
the
box,
again,
innovation,
and
then,
when
you
understand
the
job,
you
can
dig
into
the
needs
and
desired
outcomes.
A
So
if
you
start
with
the
needs
without
thinking
about
the
job,
you
might
miss
some
of
the
needs,
then
you
had
to
go
back
again
and
go
around
the
whole
circle.
Thank
you
then,
again
anything
here
that
Hetch
or
we
should
add
to
make
sure
that
gitlab
understands
how
jobs
to
be
done,
relates
to
needs
and
desired
outcome.
A
A
B
A
Misalignment
I
think
on
my
part,
we'll
talk
about
it,
but
the
others
they're,
not
that
just
we're
not
all
about
disparate,
but
we
just
have
those
different
flavors
bringing
to
the
tables.
I
just
want
to
have
an
agreement
almost
and
here
these
are
the
things
we're
going
to
talk
through
I've
got
slides
to
support
these.
So
you
don't
have
to
remember
any
of
this
there
on
the
slides
to
come.
So
the
first
one
is
the
structure
and
then,
after
we
talk
about
this,
we're
going
to
talk
about
levels
and
Valerie.
A
That's
where
your
task
job
tasks.
These
are
story.
Conversations
gonna
sit
for
the
most
part,
so
the
next
part
is
really
kind
of
just
how
job
to
be
done.
It's
like
structured
grammatically,
if
anything
else
so
you've
got
your
strategy.
People,
that's
the
over
dude
and
you've
got
the
jobs
to
be
done.
Playbook.
That's
the
call
box
dude
and
they
both
look
at
it
in
terms
of
like
a
verb,
a
noun,
a
conditional,
clarifier
callback
looks
at
it
as
a
circumstance
plus
a
job
stage
step.
A
A
Just
so
you
could
see
the
three
that
I
got
from
from
everybody,
so
they're
similar
so
like
you've
got
situation
or
circumstance,
you've
got
a
job,
the
noun
verb
and
and
then
how
they
need
to
do
it.
So
the
need
of
contextual
clarifiers.
So
we're
not
that
far
off
from
what
those
two
guys
are
proposing
in
their
practice.
We
just
need
to
figure
out
what
we're
gonna
do
here
at
gate
lab.
A
E
A
B
D
Probably
because
it
does
feel
very
familiar
to
a
user
story,
and
so
that's
just
what
I've
worked
with
and
it
fits
a
lot
of
what
I,
like
the
mental
model
of
what
I've
been
working
in.
Usually
whenever
I've
use
a
job
to
be
done.
There
is
an
entire
other
step
of
like
how
do
we
use
data
to
verify
or
validate
that
we've
done
a
good
job
accomplishing
the
job.
If
that
makes
sense,.
A
C
D
C
Two
remaining
stickies
that
I
just
finished
filling
out,
but
yeah
I
use
this
format
it.
It
can
be
confusing,
though,
because
it's
so
close
to
a
user
story,
so
I'll
give
it
that,
but
I
do
think
it's
easier
to
provide
a
simplified
format
like
this
to
anybody.
Who's
gonna.
Be
writing
a
job
to
be
done,
because
it's
literally
a
formula
that
you
just
plug
in.
A
Chucky's
from
a
product
management
standpoint,
it's
very
similar
to
the
stratagem
job
statement,
but
it's
still
different
you're
here
my
PM
rep
cuz
Keenan
had
to
be
he
got
pulled
into
a
Dell
conversation.
So
what
what
do
you
think
like
if
we
prescribe-
or
we
strongly
suggest
that
get
lab
a
dot?
This
way
to
formulate
job
statements?
I.
E
E
So
typically
I
would
organize
jobs
to
job
statements
by
persona
and
that
would
allow
you
to
just
group
the
different
actions
that
you're
expecting
a
specific
user
to
take
in,
in
light
of
the
goal
that
they're
trying
to
accomplish.
So
it
was
more
just
taking
that
persona
grouping
and
clarifying
that
circumstance
that
I'm
hoping
that
user
to
go
through
so
that
they
can
accomplish
with
the
desire
that
I
have
outlined
in
the
the
object
of
the
verb
and
the
noun
of
the
first
statement.
E
A
E
It's
actually,
it
would
be
a
task.
So
if
we
look
at
the
I
want
to
plan
a
deployment,
the
deployment
would
be
the
object
of
the
verb.
The
verb
is
plan,
so
the
circumstance
is
planning
a
deployment
when
I
want
to
plan
a
deployment.
I
want
to
see
my
deployment,
which
is
the
contextual
clarifier
from
the
micro
job,
so
I
can
deliver
value.
To
my
end,
users,
that's
back
to
the
verb,
gotcha,
okay.
E
A
When
you
he's
he's,
jumping
ahead,
cuz
we're
gonna
get
there,
but
like
mapping
out
a
job,
so
maybe
maybe
my
job
is
I
want
to
go
visit.
My
mom
for
Mother's
Day,
but
I
need
to
rent
a
car
in
order
to
do
that.
So
what
is
the
whole
process
of
that
job?
I
decide.
I
want
to
go
visit,
I,
look
up
car
rentals,
I,
rent
I,
make
a
reservation.
I
travel
I
do
go
trying
to
pick
up
the
car
what
the
car's
not
there.
What
happens
like
it's
all
of
those
stages
of
that
job?
A
B
But
I
have
this
strong
opinion
about
the
job
statement
format
and
that
it
encourages
these
very
long
wordy
statements
and
like
sometimes
they
seem
like
handbook
pages
with
jobs,
written
and
there's
tons
of
text
to
read,
and
it
becomes
very
repetitive
because
sometimes
the
circumstance
and
the
job
stage
and
step
is
the
same
from
many
micro
jobs.
You
know,
or
the
need
might
be
the
same
for
many
micro
jobs
and
circumstances
it
just
so
I'd
like
to
see
us
like
top
about
when
you
use.
C
B
Job
statement
like
I
think
they
work
really
well
and
it
you
need
it
to
stand
all
by
itself,
but
then
I
think
when
you
are
trying
to
like
help.
Somebody
understand
what
is
the
whole
picture
and
your
top
job
and
then
the
smaller
jobs,
to
use
a
job.
Now
where
your
statements
are
really
short
like
I,
the
one
that
we
have
for
growth
is
is
like
auto-renew.
My
accounts
pay
for
my
subscription,
like
really
quick
things
where
you
don't
necessarily
need
to
include
every
single
one
of
the
pieces
of
the
job
statement
again.
A
B
A
So
what
you're
speaking
to
we
will
get
to
and
you're
speaking
to
the
granularity
and
the
altitude
yeah,
you
are
yeah
cuz,
we're
talking
about
a
big
job.
I
want
to
renew
my
subscription
uh-huh,
that's
that's
the
big
job,
and
then
there
are
these
micro
jobs
or
more
granularity
that
you
can
get.
What
does
that
mean
to
a
nooner
subscription
and
I
need
to
make
sure
my
credit
cards
up
today?
I
need
to
write.
C
A
B
I
would
say
because
say
you
have
like
your
job
is
to
upgrade
or
something
depending
on
who
you
are
like
what
persona
you
are
depending
on
what
circumstances
you're
in
there
there
might
be
like
10
job
statements
around
that
different
circumstances,
what
different
needs,
but
yeah.
So
I
guess
it's
also
the
granularity
of
the
statement
and
like
where
now
the
statement
is
living
like?
Is
it
an
issue
or
it's
only
one
statement
and
you
need
all
of
that
information?
A
How
to
do
granularity?
Yes,
that
was
my
nine
o'clock
last
night.
Yes,
yes,
I
think
when
we
get
into
it,
I
think
you'll
see
that
it.
It's
very,
is
what
you're
you're
talking
about,
but
it's
just
a
different
lens
on,
because
the
problem
is
people
are
writing
novels
what
it
should
probably
be
a
little
bit
shorter
and
then
maybe
them
not
capturing
the
detail
when
they
need
to,
and
so
well
we'll
talk
about
that.
So.
C
But
I
think
there's
confusion
between
when
to
use
a
job
statement
and
when
to
use
a
user
story
and
how
user
stories
roll
up
into
a
job
statement.
I
mean
just
like
tasks,
so
I
do
think
it's
like
the
levels
of
the
layers
or
whatever
we're
calling
it,
but
I
think
that's
part
of
like
when
I
go
and
look
in
a
handbook
and
I
see
even
the
ones
that
are
written
for
secure
and
defend
I'm,
seeing
more
user
stories
that
are
written
in
the
format
of
a
job
statement.
Yes,
yes,.
A
I
agree,
yeah,
yeah
and
I.
Think
part
of
it
is.
We
haven't
agreed
on
the
grammatical
structure
of
what
the
job
to
be
done.
Statement
looks
like,
and
then
we
have
not
talked
about
how
that
is
different
from
how
we
use
user
stories
or
ten
tasks
as
well,
so
they're
all
conflating
it,
because
it's
looks
very
similar
grammatically
when
I
want
when
I
need
to
do
this.
I
want
to
do
this,
because
this
and
it's
very,
very
similar
so
I
think
that's
part
of
it
as
well
as
the
granularity
in
the
altitude
as
well.
A
So
it
sounds
like
so
far
at
this
moment
in
time.
We
don't
have
to
agree
completely
yet,
but
from
the
for
the
grammatical
structure.
It
sounds
like
this
this
second,
when
I
blank
I
want
two
points
like
hand.
Blank
is
being
lean
towards
more
because
it
makes
a
little
bit
more
sense.
It's
what
people
are
used
to
for
better
for
worse.
A
So
we'll
keep
that
in
mind
as
we
move
forward,
we
can
always
come
back
and
change
change
our
mind,
so
that
was
what
this
was
going
to
be
so
I
will
just
put
I'm
gonna
copy.
What
Jim
had
here
and
put
that
over
here,
because
it's
basically
where
we
just
decided
on,
we
can
come
back
and
change
it
if
we
need
to
now
the
fun
stuff
different
levels
based
on
what
I
had
in
the
mural
when
I
looked
at
it
yesterday,
we
all
kind
of
agreed
on
this
kind
of
roll-up
structure.
A
A
roll-down
structure
hang
on
how
you
want
to
look
at
it,
so
you
have
a
job.
It's
a
high
level
scenario
that
Spurs
a
customer
to
buy
or
hire
a
product,
and
then
from
that,
that's
where
your
user
stories
come
from.
That's
more
granular,
it's
a
workflow
or
a
scenario.
If
you
will
that
describes
a
series
of
tasks,
somebody
has
to
do
to
accomplish
the
outcome
and
then
under
that,
of
course
you
have
your
tasks
that
you're
actually
going
to
do.
A
This
is
the
action
that
you
need
to
take
in
order
to
go
to
the
next
step.
So
this
was
pretty
much
what
came
out
of
that
mural?
We
disagree.
Let's
talk,
but
this
is
how
I
interpreted
what
you
guys
gave
me.
That's
the
notes
and
I
just
kind
of
duplicated,
because
sometimes
you
can
have
more
than
one
user
story
and
tasks,
but
you
could
also
just
have
this
one
one
job.
One
story:
one
task
depend
on:
what's
going
on,
they.
E
I,
when
I
thought
about
this
in
answering
the
question
on
the
board,
I
started
to
think
about
when
I
create
an
epic.
Typically,
that's
a
workflow
that
I
have
described
in
the
form
of
a
job
to
be
done,
and
a
user
story
is
a
component
that
we
need
to
deliver
as
a
part
of
that
global
job.
So
that
would
be
the
specific
action
that
we're
expecting
a
user
to
take.
In
order
to
accomplish
that,
workflow
that
we're
describing
in
the
job
to
be
done.
I
see.
A
E
A
Do
I
start
Eddie
the
user
story
level
with
my
job
to
be
done,
which
is
why
you're
seeing
a
lot
of
those
paragraphs
written
or
Valerie,
you're,
seeing
and
I
saw
some
of
those
they
are
not
at
all
a
job
to
be
done.
They're
a
scenario
it's
weird
but
they're,
getting
it
completed
between
the
two.
So
Jackie
tell
me.
A
E
So
I
would
say
that
the
job
to
be
done
is
the
over
arching
justification
for
purchasing
our
solution,
so
I
want
to.
When
a
user
wants
to
plan
a
multi
project,
deployment
I
want
to
go
to
a
single
place
to
view
my
deployments
so
I
can
reduce
confusion
across
my
team's
well.
This
is
a
super
broad
over
arching
outcome
and
multi-level
steps.
I
would
break
that
down
into
you,
at
least
for
user
stories,
to
talk
about
building
a
dashboard
for
that
user
to
go
to
a
single
place.
E
So
the
job
to
be
done
is
the
entry
point
for
why
someone
would
consider
the
release
management
group
per
stage.
The
user
story
is
that
specific
steps
or
series
of
actions
they're
going
to
conduct
in
order
to
feed
into
that
specific
job
and
then
the
task
of
what
they're
actually
doing
on
that
dashboard?
Is
it
completely
it's
like
a
subset
right.
A
E
E
At
what
point
do
we
see
a
user
story
surface
and
at
what
point
do
we
deliver
a
task
for
a
user,
because
I
think
that's
where,
like
some
product
managers
may
only
use
tasks
as
issues
or
may
not
even
create
an
issue
to
deliver
a
task
for
a
user,
but
there
everything
is
kept
out.
A
user
story
would
be
interesting
to
see
that
that
part
yeah
I.
C
E
C
D
Really
agree
with
what
everyone's
been
saying
from
the
package
side,
because
we
handle
quite
a
few
different
categories.
The
job
tends
to
align
with
the
category,
so
the
pack
of
intra-industry
has
one
job
to
be
done
that
it
hopes
to
accomplish,
and
then
that
involves
a
few
different
user
stories
and
each
user
story
tends
to
have
the
many
individual
tasks
it
takes
to
actually
accomplish
that
goal.
Another
then,
beside
the
package
registry,
we
have
the
dependency
proxy,
which
has
its
own,
like
high-level
need
of.
D
A
B
E
E
Let
me
see
if
I
can
figure
out
words
to
articulate
why
I
viscerally
disagree
with
that,
so
I
would
say
don't
to
be
done.
Our
are
an
entry
point
for
any
user
buyer
agnostic
of
tool
to
evaluate
our
solution
and
a
user
story
focuses
and
that
flow
that
scenario
to
be
rendered
in
our
product
and
meet
that
expectation
of
the
market
like
the
job.
It
almost
informs
the
user
story
of
any
persona,
because
it's
its
justification
for
why
that
solution
exists.
You
have
to
have
a
job
in
order
to
have
a
user
story
so.
B
B
A
C
C
C
We
mentioned
that
earlier
and
the
thing
so
you
can
have
multiple
user
types
or
personas
or
whatever
you
want
to
call
them
doing
the
same
job,
but
the
differences
of
how
they
go
about
doing
those
those
completing
those
they're
completing
their
objective
is
through
the
other
stories,
so
their
motivation
might
actually
be
slightly
different,
I
think
at
a
higher
level.
It's
the
same.
C
But
when
you
get
down
to
like
a
soft
word
about
versus,
like
I,
don't
know
a
security
analyst,
they
actually
could
be
going
through
the
same
process,
but
one
jumps
off
as
into
a
different
part
of
the
DevOps
workflow
than
the
other,
but
there
are
still
completing
the
same
job
if
that
makes
sense
yeah.
So
it's
just
like
it's
nuanced
yeah.
A
C
Think
you're
right,
though
Jackie
that
it's
the
we
have
to
lock
in
on
the
vocabulary,
and
then
we
have
to
be
very
prescriptive,
which
is
like
anti
a
get
lab
culture
and
the
way
that
we
use
these
things
and
say
this
is
when
we
use
a
user
story,
and
this
is
when
we
use
a
job,
and
this
is
how
these
this
is.
The
relationship
between
these
two
things.
Yeah.
A
I
think
if
we
can
give
them
examples,
we
will
probably
not
have
to
be
so
prescriptive
it's.
This
is
what
this
looks
like.
This
is
what
this
looks
like.
This
is
how
you
use
these
things
and
it'll
come
a
little
bit
more
naturally
to
people,
because
right
now,
they're
just
trying
to
pick
something
and
put
the
thing
in
there
cuz
they're
told
to
so.
A
Let's
let
me
get
onto
a
couple
more
slides,
because
a
lot
of
what
we're
talking
about
is
is
on
here
and
I
want
to
get
your
thoughts
on
that
too,
because
so
altitude
we've
been
talking
about
altitude
yeah,
and
these
questions
that
we
just
were
talking
about
like
what's
the
best
size,
for
it
was
the
best
level.
How
do
you
map
them
to
cross
stage
stage
group
different
levels
of
abstraction?
These
are
all
dealing
with
granularity
and
altitude,
and
the
two
guys
take
look
at
this
differently.
A
So
I
wanted
to
explain
to
you
how
they
both
do
it's
two
stratagem.
This
is
where
it's
like
89
steps,
they've
got
their
core
functional
job
at
the
top
and
that's
the
job.
The
end
user
is
trying
to
get
done.
That's
a
one
single
statement,
job
using
that
grandma
that
I
showed
you
earlier
then.
After
a
long
set
of
a
lot
of
quantitative
and
qualitative
research,
you
could
come
up
with
50
to
a
hundred
and
fifty
desired
outcome
statements.
A
This
is
average
for
them
and
then
from
that
you
come
up
with
these
related
jobs,
emotional
jobs,
Assumption
change
jobs,
it's
very
interesting!
Yes,
so
that's
kind
of
how
he
handles
this.
This
idea
of
altitude
granularity
call
box
a
little
bit
different
he's
got
these
terms
that
he
calls
he
files
them
into
four
categories
aspirations.
A
Here's
an
example:
I
want
to
enjoy
the
freedom
of
mobility.
That's
an
aspiration.
He's
got
a
big
job,
which
is
what
we've
been
talking
about
that
short
sentence.
I
want
to
do
this
thing,
I
want
to
make
a
difference
in
my
life
between
this
thing
he's
got
things
that
he
calls
little
jobs,
which
might
be
a
smaller,
more
practical
job
that
corresponds
roughly
to
the
stages
in
a
big
job,
and
then
he's
got
a
micro
job
which
he
inflates
with
tasks.
So
he
kind
of
breaks
it
down
that
way.
A
Instead
of
having
to
start
with
120
outcome
statements
desired
outcome
statements,
he
just
kind
of
breaks
down
that
big
job
into
basically
this
structure,
just
using
a
couple
of
different
terms
to
denote
that,
so
that's
how
they're
approaching
it.
Those
are
the
two
big
differences
with
it
and
the
other
piece
that
call-box
brings
in
is
this
granularity
piece,
which
is
what
we've
been
talking
through
this
morning,
and
it
goes
it
uses
the
questions.
Why
and
how
to
move
your
focus
so
Valerie,
like
you,
you
mentioned
you
are
completely
correct.
A
We
are
very
micro
focused,
we
are
not.
We
are
very
focused
on
those
lower-level
jobs.
We
can
it's
very
hard
for
us
to
move,
especially
in
the
design
world,
to
move
higher
to
the
higher
level
jobs.
You
do
that
through
asking
why?
So,
if
you
want
to
get
to
the
higher
that
one
statement,
nice
little
aspirational
job
have
a
better
life.
You
ask
questions:
why
would
somebody
want
to
go
to
a
conference
whoever
this
job
performance?
Why
do
they
want
to
develop
professional
skills
this
conference?
A
So
then
they
want
to
do
that
to
advance
their
career.
Why
do
they
want
to
advance
their
career
to
have
a
better
life,
so
you're
asking
the
question
why
to
get
to
the
higher
level
broader
job?
If
you
need
to
get
more
specificity,
you
really
want
to
understand
what
are
the
tasks
and
world
would
or
the
workflows
involved?
You
ask
me
how
okay,
so
he
wants
to
go
to
a
conference
right
to
have
a
better
life.
How
is
he
going
to
attend
that
conference?
He
needs
to
convince
his
boss
to
let
him
go.
So.
A
How
is
he
going
to
convince
his
boss
to
let
him
go?
He
needs
to
provide
a
cost-benefit
estimation
of
the
event.
How
is
he
going
to
provide
that?
That's
your
micro
job
they're,
getting
down
to
the
level
of
more
specificity
by
diving
in
to
it
from
that
lens.
So,
and
this
is
where
I
pull
my
UX
research
card,
it
depends.
You
know
it
kind
of
depends
on
what
your
goal
is
for
that
job,
for
that
user
story
for
that
task,
but
how
you
get
there
is
using
call
box
framework
of
asking
the.
A
B
E
Main
it's
been
a
while
I'm
thinking
of
like
you
know,
IBM
in,
like
2018,
came
out
with
this
double
diamond
design.
Thinking
approach,
and
it
reminds
me
of
this
because
you
start
really
narrow
and
then
you
go
back
broad
and
then
you
go
really
narrow
and
then
back
broad
and
really
narrow,
and
it's
like
the
whole
lifecycle
of
how
you
should
be
thinking
about
the
problems
after
you
ship
a
feature.
E
So
how
do
you
change
the
context
of
somebody
working
once
you
deliver
an
incremental
value
at
and
sometimes
in
gitlab,
since
we
have
such
a
focus
on
iteration,
we
introduce
a
change
that
causes
the
job
to
be
done
to
shift
dramatically.
So
the
original
job
to
be
done
is
no
longer
relevant
because
we've
introduced
a
new
way
to
do
something,
and
this
happens
with
products
and
companies
that
are
market
disruptors.
I
am.
E
So
that's
where
this
kind
of
framework
was
useful,
because
when
you
start
introducing
these
changes,
you
can
sometimes
need
to
reevaluate
that
highest
level
job
and
then
drill
back
down
into.
They
use
your
story
or
the
task
you're
trying
to
accomplish
so
I
would
say
that,
with
the
progressive
delivery
side,
there
was
feature
flags
of
early
stage,
they're
constantly
having
to
bubble
back
up
higher
level
and
kind
of
be
aspirational,
because
they're
introducing
new
ways
that
they're
defining
how
customers
decide
to
continuously
deliver
their
their
offering
and
that
expectation
changes.
E
D
So
I
might
just
feel
a
little
confused.
Jackie
and
I'd
love
your
response
to
this
idea.
It
feels
like
when
we
look
at
the
user
stories
and
we
introduce
a
new
solution
and
we
have
to
change
the
user
story,
because
we've
done
something
really
innovative,
doesn't
the
hierarchical
job
above
it
stay
the
same.
D
So
if
we
introduce
a
way
that
you
can,
you
want
to
be
able
to
deploy
your
software
really
easily.
We
originally
had
user
stories
and
were
like
you
have
to
do
this
step
in
this
step
in
this
step
to
deploy
it.
But
now
we've
come
up
with
this
solution
that
just
Auto
deploys
everything
for
you.
The
job
story
stayed
the
same.
Right.
I
still
need
to
deploy
my
code,
but
the
user
story
is
completely
shifted
because
we
basically
did
away
with
all
the
steps
you
had
to
do
so.
E
Say
in
some
time,
I
think
initially,
it
depends.
I
have
two
use
cases
with
release
orchestration
right
now,
for
example,
where
it
says
I
when
I
want
to
see
the
status
of
my
deployments
and
production
I
want
to
be
able
to
use
my
existing
tool
sets
so
that
I
can
easily
transition
my
release
candidates
to
production.
E
A
user
struggling
to
create
from
that
job
to
be
done
is
how
do
I
then
create
a
plug-and-play,
a
toolset
that
allows
customers
to
view
their
environments
of
external
external
deployments
from
gitlab,
because
we
want
to
support
their
existing
tool
sets,
but
then
I
introduce
that
feature
in
the
market
that
now
I
ingest
external
deployments,
the
job
to
be
done,
then
kind
of
shifts
a
little
bit
because
we're
no
longer
after
we
revaluated
that
customer
base.
In
this
particular
instance,
they
now
are
starting
to
use,
get
lab
for
continuous
delivery.
E
So
then
their
experiences
become
less
about
supporting
external
deployments
and
shift
to
becoming
more
about
improving
the
gitlab
toolset
experience.
So
the
job
to
be
done
then
shifts
to
I
want
to
more
effectively
or
more
efficiently
deploy
code
to
my
production
environments
rather
than
the
existing
tool
set
performance,
or
maybe
it's
that
that
job
to
be
done
was
completed
and
executed
and
we
expired
it
and
the
job
to
be
done
then
shift
it,
which
I
guess
could
happen,
but
have
a
minute's.
Have
a
neighbor
conspired
a
job
to
eat.
Humble.
A
Yeah
I
don't
know
if
I
ever
had
either
because
they're
so
broad
they
actually,
unless
your
product
just
decides
we're
not
shipping
DVDs
anymore
as
Netflix,
so
we're
gonna
just
put
all
those
jobs
for
you
to
five
minutes.
Five,
usually
that
doesn't
like
your
business
model
has
to
change
dramatically
to
let
them.
B
A
You
yeah,
you
almost
have
to
go
all
the
way
to
the
aspirational
like
I.
Just
want
to
sit
back
and
push
a
button.
I
have
to
worry
about
anything,
gonna,
say
yeah,
it's
hard,
because
we
are
a
technology
company.
So
you
in
that
call
box
says
you
can
start
an
aspirational
level,
but
you're
never
going
to
make
a
product.
If
you
stay
there,
you
have
to
then
come
back
down
all
the
way
down
to
the
micro
job,
which
is
basically
tasks.
B
A
Exactly
I
think
that
is
the
problem
and
that's
the
problem
I
have
in
his
book.
It's
two
sets
of
vocabularies,
because
basically,
what
he
says
here
is
that
you
could
write
a
job
to
be
done
for
any
of
these,
but
it's
at
the
level
of
granularity
that
you
write
it
depending
on
what
you're
trying
to
accomplish
with
that
statement.
So
no
longer
does
it
have
to
be
have
a
better
life
at
every
level.
You
get
more
granular
with
the
job
to
be
done
structure
so
that
grammatical
structure.
A
A
A
A
C
A
C
Yeah
the
high
level
job,
so
that's
my
preference
is
that
let's
only
introduce
one
new
thing,
which
is
how
we're
gonna
write
a
job
to
be
done,
what
it's
for,
how
we
use
it
and
then
allow
them
to
continue
to
use
user
stories
and
tasks,
because
our
designers
are
really
good.
Are
writing
user
stories
and
tasks
and
I
don't
want
to
muddy
that
for
them.
So.
B
C
C
Because
if
we
remember
that
a
job
is
agnostic
to
a
persona,
well
user
stories
allow
us
to
actually
bring
in
the
persona
via
a
user
type
like
we
wouldn't
call.
We
wouldn't
say:
Sam
Sam
wants
to
do
the
Sam
as
our
security
analyst.
It
would
be
as
a
security
analyst
I
want
to
so
that
I
can
do
whatever
I
think.
It's
really
important
to
separate
that
format
from
the
job
so
that
we
can
get
to
the
altitude
that
we
want
and
I
think
that
the
altitude
forget
lab
is
within
there's.
C
Multiple
forms,
I
think
that
there's
one
that
should
occur
at
the
category
level,
like
the
stage
group
level
and
by
one
I
mean
that
there
will
be
more.
But
this
is
the
tier,
the
lowest
tier
of
the
job
would
be
at
the
category
or
stage
group
level,
and
there
should
be
stage
jobs
to
be
done,
and
then
there
should
be
cross
stage
where
we're
actually
looking
at
how
things
are
traversing
across
the
system.
C
So
for
security,
you
know
we're
we're
heavily
involved
in
what's
going
on
with
the
EM,
our
widget,
and
so
we
have
jobs
that
are
that
people
want
to
accomplish
that
span
across
basically
the
entire
experience
or
we.
We
do
target
user
stories
that
roll
up
into
these
jobs
for
software
developers
and
so
as
they're
looking
at
them
our
screen,
for
example.
They
need
to
do
these
certain
things.
B
C
B
C
Your
participants
for
that
evaluation
would
be
who
you
intend
that
who
you
think
that
job
is
done
or
completed
by
it's
just
like
a
usability
study.
You
can
actually
start
at
a
job
level,
but
when
you're
writing
your
script
you're
at
the
task
level,
then
that's.
Why
there's
a
really
close
relationship
between
task
and
user
story
and
job
yep.