►
From YouTube: JTBD Alignment Workshop Part 2
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
And
Mike
had
a
a
suggestion
that
we
upload
it
to
unfiltered
I.
Think
so
you,
whatever
the
YouTube
channel,
is
but
I
didn't
want
to
do
that
until
I
asked
you
guys
if
you
were
okay
with
that.
So
just
let
me
know
your
not
let
me
do
I
mean
Nick
is
here
because
he
expressed
some
interest
and
had
some
experience
as
well
with
jobs
to
be
done
at
other
places.
So
I
thought
why
not
another
mind,
especially
if
we
might
lose
Jackie
for
today
thought
it
might
be
good
to
have
you
guys?
A
Have
him
join
us?
So
that's.
Why
he's
here
thanks
Nick
all
right.
So
if
you
will
remember
where
we
left
off
last
time
was
a
very,
very,
very
important
discussion
on
granularity
and
altitude
of
jobs
to
be
done,
and
since
we
talked
so
many
moons
ago,
I
have
been
talking
with
a
couple
of
designers
about
this
very
question.
A
It
has
come
up
for
them
they're
trying
to
create
trying
to
do
jobs
to
be
done
with
rpms
and
they're,
starting
to
ask
themselves
questions
about
the
jobs
that
they
have
written
and
the
questions
really
boil
down
to
is
this
at
the
right
level.
Is
this
too
much
of
a
user
story
level?
Is
this
too
high,
so
I've
had
a
lot
of
conversations
with
them
around
the
idea
that
it
kind
of
depends
because
you
need
to
have
it
at
a
level
that
you
can
use.
A
So
if
you
are
wanting
to
start
at
that
higher
level
and
then
write
user
stories
from
it,
you
need
to
have
it
at
a
high
enough
level
to
be
able
to
do
that.
If
you
want
to
just
kind
of
get
a
aspirational
view,
that's
even
a
higher
level,
and
if
you
can't
write
user
stories
from
something
you
might
need
to
take
it
down.
So
you
can
start
writing
user
stories.
So
last
meeting
we
talked
about
this
structure.
This
overall
concept
of
you've
got
a
job.
A
You've
got
user
stories
that
are
written
based
on
what
that
job
says,
and
then
you
have
tasks
that
come
from
each
of
the
user
stories,
which
are
the
same
thing
as
issues
that
the
tasks
are
in
our
world.
So
just
as
a
reminder,
that's
we
all
agreed
on
that
structure.
So,
let's,
let's
talk
again
about
the
hierarchy
of
jobs
and
the
granularity
and
the
altitude
and
how
how
we
want
to
approach
that
as
a
group,
because
they
didn't
think
that's
going
to
be
the
most
important
thing
that
we
get
out
of
this.
B
B
Okay,
this
is
the
growth
job
map,
but
I'll
just
show
you
kind
of
how
its
structured
so
there's
a
like
a
main
job
which
is
really
high-level,
find
by
the
best
solution
to
build
and
deploy
software
and
our
job
performers.
Actually,
this
is
wrong
because
it's
missing
the
buyer
persona
and
I
keep
forgetting
to
put
it
in
there.
We
have
a
buyer
persona
and
then
we
also
have
people
who
are
doing
jobs
who
also
buy
them,
and
we
have
different
situations
that
are
really
important.
B
So
the
situation's
are
things
like
people
who
need
security
and
control.
They
want
to
run
their
own
instance
and
so
they're
the
self-managed
people,
people
who
want
just
to
try
or
really
ease
of
administration.
They
don't
want
to
mess
with
installing
those
are
the
dot-com
people,
the
stuff
people
we
have
first-time
shoppers.
First-Time
shoppers
are
kind
of
like
they're,
maybe
not
as
familiar
with
the
develop
solutions
that
are
out
there.
So
they're
really
they're
learning
a
lot,
and
then
we
have
other
shoppers
who
are
they're
familiar
with
DevOps
they're
familiar
with
github
with
it.
B
They
have
a
lot
of
familiarity
already.
We
have
a
lot
of
shoppers
like
that,
and
so
that's
another
situation.
We
have
needs
and
desired
outcomes
which
are
pretty
common-sense
things
like
performance
ease,
ease.
We
use
things
like
that
and
then
we
have
kind
of
like
a
path
that
people
may
take.
Of
course,
the
path
is
different:
every
person,
but
at
a
high
level
you're
going
to
discover
what
solutions
are
available.
B
We
have
these
kind
of
things,
these
categories
I,
don't
know
what
to
call
them,
but
it's,
like
you
know,
try
paid
features
of
get
lab
to
see
the
value
and
under
that
you
have
all
these
tasks.
You
do
like
sign
up
for
a
trial
of
gold
install
get
lab
if
you're
doing
self-managed
and
they're
broken
down
more
granularly
here
and
now.
What
we
do
is
when
we're
doing
like
a
scorecard.
For
instance,
we
might
be
like
okay,
we're
gonna.
B
C
B
Helps
you,
you
can
go
back
and
reference
it,
and
then
you
can
get
to
your
more
details.
Otherwise,
if
you
don't
have
it,
you
tend
to
want
to
so
I.
Don't
know
my
throat
hurts
today.
You
tend
to
want
to
really
dig
into
all
of
the
details.
Yeah
all
the
time,
and
sometimes
you
end
up
getting
kind
of
like
lost
in
the
weeds.
Yes,.
A
B
We're
not
napping
all
gitlab,
but
over
in
the
like,
learn
how
to
use
get
loud
part.
That's
where
the
things
start
to
spread
out,
because
I
couldn't
use
any
part
of
get
loud
to
learn
how
to
use
get
up.
Didn't
really,
of
course,
I
mean
I
could
put
everything
in
there,
but
like
getting
training
documentation.
A
Into
it
that
user
story
becomes
the
job
to
be
done,
because
you're
going
to
go
deeper
into
the
set.
What
what
are
here
listed
as
tasks,
though
in
the
blue
cards
might
also
be
coming
user
story
when
you
get
deeper
into
it,
and
that's
what
I've
been
trying
to
capture
this.
This
whole
idea
of
this
is
wonderful
Jackie.
Thank
you
by
the
way
just
showing
this.
This
is.
B
Grade,
therefore,
a
scorecard,
you
would
open
up
the
issue
for
the
scorecard
and
you
would
probably
not
for
all
of
them
yet
because
we
haven't
always
just
are
using
this.
You
would
have
the
stories
written
out
more
in
a
more
lengthy
way,
as
the
statements
that
apply
to
upgrading
you're
right,
okay,
good
job
to
keep
in
mind
is
never
like.
I
want
to
upgrade
my
subscription
because
nobody
wakes
up
wanting
to
do
that.
It's
just
what
I
keep
using
the
thing
they
have
to
do
it.
It's
like
you
have
to
do
it.
A
If
you
want
to
keep
using
it
yeah,
so
upgrading
your
subscription
turns
into
a
user
story,
and
then
you
have
tasks
under
that
user
story
to
get
you
to
get
that
upgrade
finished,
but
the
reason
you're
upgrading
is
because
you
want
to
continue
to
use
the
right
plan
for
your
needs
that
that
now
becomes
a
job
for
that.
That
effort
right.
So
it's
it's
like
you
move
it
up.
A
That's
what
I
meant
like
you
like
how
level
everything
up
a
little
bit
so
then
you
can
dive
deeper
into
it
and
it's
that's
what
I'm
I'm
I
think
we
need
to
capture
in
in
some
of
the
documentation
for
the
jobs
to
be
done.
It's
not
just
writing
one
job
to
be
done.
You
you
and
you're
done
it's.
You
might
need
to
go
up
or
down
in
how
you're
viewing
things
in
order
to
get
the
thing
done,
that
you're
trying
to
get
done
for
your
design
and
your
product
partners,
yeah
Ian,
Valerie
thoughts.
D
What
we
did
on
the
package
team
so,
where
you
have
the
UI
scorecards,
we
also
have
we
called
them
job
stories,
because
the
terminology
wasn't
defined
yet,
but
that's
kind
of
the
same
idea
of
you
don't
wake
up
in
the
morning,
because
you
want
to
upgrade
your
subscription
for
package.
You
don't
want
to
wake
up
in
the
morning
and
be
able
to
deploy
specifically
through
CI.
You
want
it
to
be
able
to
be.
You
know
the
higher-level
idea,
I
think
yeah.
It
really
does
line
up
well,
which
I'm
excited
to
see.
D
B
Gonna
have
like
it
doesn't
have
to
take
a
long
time
to
make
this
thing.
It
didn't
take
very
long
and
it
doesn't
have
to
be
really
perfect
and
right,
like
we're
doing
journey
research
now
and
growth.
This
will
probably
change
chairman
and
it's
fine,
so
I
I
think
you
know
it's
important
to
not
to
get
hung
up
just
to
throw
the
cards
up
there
for
what
you
think
it's
like,
and
you
can
always
make
it
better
later.
E
I'm
trying
to
think
through
of
like
how
we
would
provide
instruction
and
I
think
this
is
what
Lori
was
getting
to
like.
How
do
we
even
help
people
determine
what
altitude
or
or
I
think
it
was
altitude,
the
terminology
freezing?
How
would
we
help
them
determine
at
what
altitude
they
need
to
be
working
within,
so
I'd
be
curious,
Jackie?
E
B
B
Was
because
I
felt
like
our
scorecard
stories,
whatever
you
want
to
call
them
statement
we're
too
granular
and
they
were
too
much
like
tasks
and
they
ended
me
and
I
found
myself
often
asking
the
designers
like
that
question
of.
Is
this
the
thing
the
person
wants
to
do?
Yeah?
Really?
What
do
they
want
to
accomplish?
A
A
Why,
if
you,
if
you
don't,
if
you
can't
jump
to
the
Hal
right
away,
it
might
be
too
high
level
go
down
a
level
write
it
better
at
a
lower
level
and
then
see
if
you
can
get
into
the
user
stories
and
tasks.
It's
a
it's
a
nada,
I
I,
don't
think
like
it's
a
set
of
directions.
We
can
write
for
people
to
read,
I,
think
it's
gonna
probably
be
some
training
that
we're
gonna
have
to
send
somebody
through,
but
I.
A
F
So
I
have
a
problem
that
I
was
working
through
with
high
on
and
my
designer
one
of
them
was.
We
had
a
bunch
of
issues
related
to
environments
in
our
backlog
and
we
didn't
really
know
what
users
were
trying
to
do
with
environments.
So
we
had
a
bunch
of
different
tasks
and
we
had
to
bubble
it
back
up
on
to
like.
What's
the
higher-level
decision,
we
want
people
to
be
doing
with
with
get
lab
in
environments,
so
our
altitude
was
reversed.
F
We
had
a
big
problem,
a
bunch
of
tasks
that
didn't
make
any
sense,
and
we
had
to
like
back
it
up
to
see
what
the
umbrella
was.
So
I
think
that
kind
of
adds
another
problem
to.
How
do
we
coach
people
on
granularity
whenever
it's
bi-directional,
you
can
be
so
you
can
have
something
after
a
task
oriented
and
then
you
need
to
understand.
What's
the
general
flow
you
want
somebody
to
go
through,
which
is
your
user
story
and
then
what's
the
actual
purpose,
you're
trying
to
accomplish
at
the
end
I?
F
Do
you
think
in
my
past
life
I
was
able
to
help
coach
people
through
that
by
encouraging
them
to
start
with
something
like
a
metric
to
accomplish
a
goal?
You
know
like
a
goal
post
that
here's
your
quantifiable
metric
and
then
breaking
that
metric
down,
and
you
know
how
users
are
actually
going
to
contribute
to
that
metric.
B
Also,
this
I'm
not
sure
at
Lake
Taylor
I
may
have
around
the
idea
of
starting
with
a
metric,
because
the
metrics
are
measuring
things
that
we
want
people
to
do
to
show
that
they're
engaged
with
our
product
but
they're,
not
necessarily
the
things
that
are
jobs
that
people
want
to
accomplish.
Sometimes
they
are
but
sometimes
they're
indicators
of
that
oh
I,.
F
Yeah
I've
got
to
give
you
one.
So
in
my
past,
where
this
was
where
we
use
this
it
was.
We
want
people
to
use
their
platform
to
publish
to
attend
a
social
media
site,
so
we
were
tracking
that
global
network
of
here's,
an
action
that
we
want
people
to
perform,
and
how
does
this
particular
task
or
job
contribute
back
to
that
metric,
and
then
that
would
be
the
action
that
we
would
detail
in
our
job
to
be
done.
B
But
I
guess
I'm
starting
at
that,
because
the
job
should
be
agnostic
to
your
product
anyway,
and
if
you're
tracking,
like
people
who
are
sharing
something
on
social
media
on
our
platform,
then
it's
still
defined
by
the
by
the
platform
rather
than
like.
Well,
why
are
people
sharing
in
social
media
because
they
want
to
have
our
friends
or
they
want
to
improve
the
visibility
of
their
business?
Or
you
know
whatever
their
goal
is,
which
is
what
I
would
consider
that
the.
C
That's
the
approach
that
we
would
typically
take
as
well
we'd,
say,
what's
happening,
six
to
twelve
months
out
what
what?
What
are
the
goals
that
we
want
to
achieve
from
a
business
perspective,
and
how
is
that,
coupled
with
with
the
user
outcomes
that
we're
trying
to
achieve
as
well,
and
that
that
sort
of
tie
gives
you
a
good
hypothesis
of
what
could
the
jobs
be,
that
we
want,
and
that
outlines
a
map
very
similar
to
to
what
Jackie
put
there?
C
That
is
full
of
hypothesis
of
what
jobs
to
be
done
are
and
the
subject
tasks
and
users
and
stuff,
and
that's
what
we'd
call
like
an
opportunity,
map
and
we'd
use
that
map
to
say
which
areas
do
we
need
to
validate
the
the
particular
job
to
be
done?
Which
ones
are
we
uncertain
about?
Where
do
we
think
we
can
invest
our
efforts
now
and
and
sort
of
do
stuff
around
the
product?
C
F
Also
like
that,
you
said,
category
was
constraining.
I
do
think
that's
an
artificial
constraint
and
I
do
see
a
lot
of
product
managers
shying
away
from
solving
high-impact
jobs
to
be
done
because
it's
across
stage
initiative
and
it's
something
that's
really
challenging
for
us
to
embrace
that
get
lab,
because
we
have
40
product
managers
and
the
job
to
be
done.
The
task
the
user
wants
to
complete
will
lead
into
all
these
other
areas.
I.
B
C
About
that
may
be
quite
difficult
to
start
out
with
by
creating
the
taxonomy
just
like
from
from
the
start,
so
maybe
it's
something
we
could
get
to
eventually,
once
we
have
a
collection
of
well
validated
jobs,
I
would
say,
starting
out
with
different
pockets
based
on
categories
may
be
an
interesting
way
to
do
it,
and
then,
once
you
have
a
solid
mass
of
jobs,
then
you
can
start
reflecting
and
thinking.
Is
there
a
different
sort
of
taxonomy
in
structure
that
comes
out
of
this.
C
E
A
A
What
I
have
experienced
with
working
with
the
UX
team
as
a
whole,
I'm
not
going
to
call
out
any
individuals
but
as
a
whole,
they
tend
to
lean
towards
the
prescriptive.
Give
me
a
template.
I
will
fill
it
out.
Give
me
some
steps.
I
will
follow
them.
If
I
have
problems,
I
will
come.
Ask
you,
but
I
just
want
some
steps
to
to
follow
this
Lanes
its
leans
towards
a
little
bit
of
alchemy.
It's
not
quite
a
ABCDE.
F
Here
with
frameworks
and
with
teaching
people
frameworks,
sometimes
exit
criteria
are
more
important
to
satisfy
then
like
following
a
particular
process.
So
if
we
think
about
what
is
the
end
state
of
a
job
map
and
then
giving
people
that
end
state
as
the
target
or
the
goal
post,
then
they'll
start
to
flow
through
the
job
back
or
process
organically.
In
order
to
accomplish
that
goal
post.
F
So,
for
example,
if
it
is
I
as
a
UX
designer
want
to
accomplish
a
a
hierarchical
view
of
how
a
job
to
be
done
is
inherited
by
user
stories
and
it's
accomplished
or
rendered
by
tasks.
First,
this
big
user,
and
this
would
be
a
natural
way
for
them
to
decompose
that
job
to
be
done
into
user
stories
into
tasks.
What
do
you
think
yeah
I.
C
Would
say,
and
then
a
may
not
to
be
go
and
and
document
something
asynchronously
to
start
out
with
yeah
I.
Would
what
I've,
what
I've
found
with
some
of
the
more
complex
and
abstract
like
ideas
and
ways
of
approaching
design
in
general,
within
a
context
where
you're
not
sat
down
next
to
other
designers
in
the
studio?
And
it's
it's
it's
harder
to
get
the
sort
of
tacit
stuff
going
is
go
with
like
Geoffrey
Moore's
crossing
the
chasm
model.
C
If
you're
familiar
with,
like
that
diffusion
of
innovation
curve,
and
basically
the
summary
of
the
book
is,
if
you're
going
to
if
you're
gonna
try
and
drive
adoption
of
the
particular
innovation
in
general,
you
just
need
to
focus
your
efforts,
not
in
the
mass-market,
but
you
need
to
focus
your
efforts
on
the
early
adopters
that
people
are
actually
showing
interest
in
using
this
and
testing.
The
idea
is
out
with
those
that
user
group
and
then
using
the
insights
that
you
have
from
testing
users
to
generate
whatever
material
comes
afterwards.
C
E
Yeah,
just
knowing
so
I
would
agree
in
any
place
other
than
get
love,
but
I
think
love
is
unique
and
it
has
its
pros
and
cons.
We
can
just
be
honest
about
that
right.
So
to
me,
I
actually
see
what
jackie
has
proposed
as
a
template
and
mural
or
in
figma
or
wherever.
We
want
to
put
this
where
it
has
these
boxes,
where
you
populate
them
and
I
do
agree
with
the
previous
discussion
of
people
are
gonna.
E
Look
at
this
in
different
ways
and
they're
gonna
fill
it
in
differently
and
I
think
that
part's
okay,
but
we
need
to
give
them
a
structure
where
they
can
kind
of
like
grab
cards
and
Phillip
put
in
filmin
and
group
them
together
and
I.
Think
that
this
layout,
that
Jackie
Bower
has
proposed
is
really
helpful
and
people
are
gonna,
look
at
it
from
top
up
top
up
and
bottom
down
right.
So
we
talked
a
little
bit
about
that
too.
Some
people
are
gonna
start
with
the
growth
job
higher-level
cross
stage.
E
Other
people
are
gonna
say
well.
These
are
the
tasks
that
I
think
that
users
are
going
to
do
and
they're
gonna
fill
it
in
in
different
ways,
but
the
structure
that
we
provide
them
is
the
templates
and
then
the
rest
of
it
can
be
somewhat
organic,
so
just
like
give
them
the
freedom
but
give
them
the
boxes
to
be
free
within
yeah.
C
E
A
And
that's
what
I
was
just
gonna
say
is
like
I
think
that
that
slide,
that
I
had
that
I
showed
you
guys
last
time
with
the
how
and
the
why
questions
that
seems
to
have
resonated
cuz
I,
just
pull
it
up
and
I'm,
showing
everybody
who
comes
to
me
with
questions
like
what
do
you
think
about
this,
and
it
seems
to
have
resonated
a
lot
with
them
because
they
can
understand.
Oh
am
I
at
the
right
level
to
do
my
work.
How
do
I
get
to
the
right
level?
A
Ask
why
or
ask
how
so
maybe
that
paired
with
a
starter
template
here
with
a
little
bit
of?
Why
would
you
use
either
one
of
these
to
get
them
started
because
I
hear
what
you're
saying
Nick
the
problem
that
we
have
is
that
the
cart
has
always
already
going
and
there
we
don't
know
if
we
have
the
right
horse.
A
That's
pulling
the
cart
like
we've
already
got
to
do
these
category
maturity
scorecards,
we
have
said
you're
going
to
use
jobs
to
be
done
to
help
you
pick
out
the
tasks
that
you're
going
to
be
doing
with
them.
So
that's
been
the
impetus
for
all
of
this
jobs.
We've
done
work
that
I've
been
a
part
of
with
other
people.
So
it's
kind
of
hard
to
just
have
a
separate
group
that
is
very
passionate
about
it
and
to
hammer
out
the
process,
so
I
think
we're
gonna
have
to
do
the
best.
A
We
can
and
then
come
back
and
iterate
if
we
need
to
depend
on
how
they
consume
what
we
give
them
back.
I
hate
that
as
a
Virgo,
I
hate
back
so
like
I,
just
wanted
to
be
able
to
give
you
guys
some
steps
and
some
foolproof
methods,
so
you
can
feel
confident
in
what
you're
doing
but
yeah
sorry.
Thank
you
guys.
C
How
about
how
about
we
run
a
little
test
where
we
put
like
a
poll
out
on
on
on
slack
and
say
who
wants
to
be
part
of
this
new
jobs
to
be
done?
Working
group
or
whatever?
It
is
just
to
gauge
interest
of
who's.
Actually,
like
oh
I,
want
to
start.
I
want
to
start
doing
something
with
jobs
to
be
done,
and
those
are
the
people
who
will
help
to
provide
feedback
and
shape
that
template
sort
of
structures
that
we
want
to
generate
for
the
masses.
Maybe
it
may
it
like.
B
E
Wanted
to
be
on
it
or
yeah,
everybody
is
using
a
job
job
to
be
done
in
some
form.
It
may
not
be
perfect.
That's
okay,
because
we're
attempting
to
use
it
so
I
think
that
as
a
company
we're
sold
on
the
idea
of
using
it,
we
have
enough
adoption.
It's
just
now.
It's
kind,
of
course
correcting
on
this
is
how
we
actually
use
it
here
at
get
lab.
And
yes,
it's
slightly
different
than
how
you
know
certain
books
outline
it.
It's
gonna
be
a
different,
slightly
different,
take
on
it
and
I
think
that's!
E
What
we're
really
trying
to
achieve
here
is
is
what
is
the
get
lab
way
of
jobs
to
be
done,
and
and
how
do
we
convey
that
and
get
people
to
use
it
in
practice?
In
a
consistent
way?
And
my
my
concern
about
like
having
a
little
bit
too
much
of
a
free-for-all
is
we're
gonna
come
up
with
a
hundred
different
takes
of?
How
do
you
use
it,
and
people
are
gonna?
E
F
Know
what
it's
interesting,
you
say
that
I,
like
that
you
have
this,
had
the
intent
to
want
to
build
like
a
really
good,
get
lab
version
for
jobs
to
be
done.
I
think
that
you're,
absolutely
right.
We
are
kind
of
in
this
place
where
we're
telling
people
use
jobs
we
done
and
people
are
using
them.
I
would
question
our
tolerance
for
people
deviating
from
the
model
and
how
do
we?
How
do
we
feel
about
that
deviation
and,
if
that's
something
that
we
want
to
support
like?
Is
it
here
it's
to
a
model?
F
What
we
really
want,
or
is
it
that
we
give
people
the
objective
of
a
job
to
be
done
and
then
take
note
of
how
they're
using
them
so
that
we
can
feed
back
into
this?
That
stop
to
be
done?
Use
case
a
model
I'm
really
hesitant
from
a
product
management
standpoint
of
having
a
prescriptive
job
to
be
done
model
because
I
think
that
you're
the
way
your
interview
Styles
the
way
you
learn
how
you
process
information,
how
your
team
works
together,
could
all
influence
the
way
that
you
approach
drops.
F
We
done
and
the
way
you
decide
to
decompose
them
and
having
something
too
prescriptive.
Or
something
to
this
is
what
you
must
follow
could
really
inhibit
the
innovation
and
the
creativity
that
we
want
to
inject
back
into
a
jobs
to
be
done.
Framework
so
I'm
a
little
anxious
to
hear
that
we
want
to
have
this
gold
standard
and
I
could
see
the
utility
and
having
it,
but
I
can
also
see
the
consequences
of
having
it
that
people
feel
boxed
in
yeah.
A
There
are
people
who
have
no
clue
what
they're
doing
and
they
have
not
read
a
book
picked
up
what
they
haven't
done.
Anything
they
decide.
Oh
it's
it's!
This
grammar
I'll
just
write
anything
with
his
grandma
I'll,
be
fine!
Then
they
stride
to
do
stuff
with
it.
That's
when
they
come
to
me
and
that's
when
I
have
to
have
a
conversation
with
them
around.
This
is
not
a
job
to
be
done.
This
is
something
entirely
different.
A
Let's
talk
about
what
that
really
is
so
we're
trying
to
educate
on
that
level,
but
to
your
point,
Jackie
I
don't
want
to
constrain
innovation.
I
don't
want
to
constrain
out-of-the-box
thinking,
but
I
need
to
get
them
to
the
point
where
they're
ready
to
break
the
rules.
They
have
to
know
what
the
rules
are.
First
and
some
people
just
don't
know
what
they
are
yet.
So
we
have
to
strike
that
good
balance
between
giving
them
some
scaffolding
to
educate
them
on
what
it
is
and
feel
comfortable
with
it.
A
So
then
they
can
get
to
the
point
where
they
can
have
those
interviews
how
they
want
to
gather
the
information
in
the
best
way
possible.
But
I
still
have
people
who
are
fighting
me
about
not
interviewing
the
job
doers.
They
don't
want
to
interview
them
like,
but
you
don't
even
know
if
your
jobs
are
correct,
we'll
just
send
a
survey.
That's
not
how
this
works.
You
don't
send
a
survey
to
validate
your
jobs.
You
have
to
do
interviews
with
people
or
look
at
the
research
that
has
already
been
done
and
pull
those
jobs
from
that.
E
That
those
baddest
decision
tree
yeah
so
because
there's
a
there's,
a
confidence,
thing,
confidence
and
like
what
do
we
know
living?
How
confident
are
we
and
what
we
think
that
we
know
because
I
can
I
can
make
I
can
justify
some
use
cases
where
we
would
not
go
in
and
validate
jobs
to
be
done
because
we
have
market
research.
We
have
research
that
we
have
already
done.
We've
already
spoken
to
your
target
audience.
E
You
know
we're
90%
good
on
these
jobs
we
might
have
one
or
two
they're
still
questionable
and
I
think
we
don't
have
to
address
immediately,
but
in
time
we
will
and
I
also
think
that
there's
other
ways
of
verifying
jobs
it
could
be
more
organic.
It
doesn't
have
to
be
this
formulated
process
of
okay,
I'm
working
on
a
job
to
be
done.
Therefore,
I
must
go
through
these
hundred
steps
in
order
to
validate
it.
I
think
that's
where
I'm
at
right
now
is
is
I
agree.
E
Jackie
I,
don't
want
to
I,
mean
the
whole
concept
of
jobs
to
allow
for
innovation,
and
so
for
us
to
come
up
with
a
really
prescriptive
step,
and
that's
why
I
mean
by
get
lab
needs
its
own
version
of
jobs,
because
we
don't
want
to
be
super
prescriptive
about
it.
We
don't
want
to
have
you
know
a
thousand
page
book
or
they
have
to
read
through
in
order
to
understand
how
we
apply
it
here.
E
I
actually
think
that
it's
like
a
two
pager,
the
gitlab
way
of
doing
things
as
a
two
page
version
of
jobs
to
be
done,
and
we
just
have
to
get
to
that
point
like
how
do
we
distill
it?
How
do
we
make
it
to
where
there's
just
enough
to
Louise
point
enough
structure
where
they
know
how
it
to
just
get
going
and
then
we're
gonna
get
feedback
from
people
who
do
it?
I
think
this
was
part
of
Nick's
points
you
of
like.
We
just
need
to
get
people
to
try
it
out
and
then
offer
feedback.
E
A
E
Would
what's
my
concern
is
like
I,
don't
want
to
roll
out
this
big,
hey,
we're
gonna,
do
this
big
job
to
be
done
things,
and
then
it
becomes
immediately
overwhelming
people
lose
interest
in
it.
We
hear
from
PM's
like
you're,
adding
an
additional
step
to
our
workflow
right.
We
need
to
figure
out.
Where
does
this
already
fit
into
our
process
and
how.
E
F
Was
such
a
hard
thing
for
me
to
like
go
through
and
and
adopt
because
I'm,
like
man,
I've
already
interviewed
50
people,
that's
a
product
manager
who
is
very
much
like
experiencial
with
customers
like
I
like
to
watch
them?
Do
things
I
like
to
interview
people
on
have
hypothesis
that
get
validated
really
quickly
or
no
I'm
in
complete
agreement,
like
you,
I
would
say
if
we
find
like
our
pilot
group,
what's
our
timeline
to
roll
out
whatever
framework
we're
looking
at
like
what
what's
their.
A
Goal
here,
I
would
already
argue:
we've
already
got
our
pilot
group
they're
doing
it
now,
like
I,
can't
tell
you
a
day.
Does
not
go
by
that
somebody
doesn't
ping
me
on
slack
to
say:
hey,
can
you
talk
about
jobs
to
be
done?
I
need
help
they're
already
doing
it.
So
what
I'm
trying
to
do
is
chase
them
with
my
two
pager
going.
Wait.
Do
it
this
way?
Maybe
this
will
help
you
so
I
can
I
mean
I
can
tell
you
again
it's
like
altitude
and
granularity.
A
They
don't
understand
how
to
apply
that
the
job
map
I
think,
will
very
much
help
them
because
they're
getting
lost
very
quickly
in
an
overwhelming
list
of
40
jobs
to
be
done.
Where
do
I
start?
What
do
I
do?
What
does
this
look
like?
How
does
this
even
apply
to
my
category
and
even
just
the
grammar
that
we
talked
about
last
time?
That's
not
set
either
like
that
does
actually
need
to
be
set.
A
A
That
will
also
help
them
as
they
go
through
this
and
stop
coming
to
me
for
all
the
I
mean
like
I,
don't
mind
them
that
they
come
to
me,
but
it
tells
me
that
they
still
need
help
then
they're
doing
it
now,
so
I
would
argue
we
have
our
our
experiment
is
going.
It
has
been
going
for
a
couple
weeks
now
and
it's.
This
is
why
you
guys
are
here
again
like
I
asked
Christie
is
like
I
need
to
I
need
help,
I
need.
A
We
need
to
come
together
as
a
group,
a
Crossgate
lab
and
figure
out
what
we
can
agree
on
and
then
ship
that
and
say
this
is
what
we've
agreed
on
that.
This
is
our
flavor
of
jobs
to
be
done
here.
I
get
lab,
please
use
some
of
these
guidelines,
and
then
we
need
to
figure
out
how
else
we
can
support
people
as
they're
doing
it's
already
doing
it.
Okay,.
C
Just
before
we
do
that,
just
a
quick
observation,
I
think
I
think.
Therefore
there
are
two
personas
or
categories
of
people
use
it
in
jobs
to
be
done,
then,
and
get
let
broadly.
There
are
the
learners
people
who
want
to
learn
jobs
to
be
done
and
they're
the
people
who
want
to
activate
jobs
to
be
done
or
basically
Excel
with
them.
So
the
the
tracks
of
training
and
the
ways
that
you
approach,
those
people
will
be
different.
F
E
I
think
one
more
hands-on,
where
design
managers
in
particular
will
need
to
be
far
more
invested
and
making
sure,
like
the
the
foundational
elements
are
understood,
and
some
designers
won't
need
as
much
attention
and
not
right.
Some
people
pick
on
Ian
yen's
not
going
to
me
and
his
manager
to
sit
with
him
and
go
through
this.
That's
like
our
life's
easier
and
so
he's
in
part
of
this
discussion.
He'll
help
us
formulate
how
we're
going
to
move
forward,
and
then
he
can
also
help
spread.
B
E
A
D
One
of
the
cool
things
I
would
call
out
was
seeing
the
board
that
Jackie
put
together
and
then
seeing
the
scorecard
grade.
It
just
immediately
clicked
it
like
that's
the
scale
of
that
item,
and
then
the
group
of
all
the
UX
scorecards
is
the
next
level
up.
So
one
piece
of
advice,
I
might
offer
from
what
I've
heard
from
everyone
else
talking
about
jobs
to
be
done.
Is
the
deliverable
attached
to
them?
So
you
don't
want
something
so
granular
that
a
UX
scorecard
is
way
overboard.
D
That
means
you
went
too
far
down
and
that's
resonated
with
some
of
the
designers
I've
talked
to
where
it's
just
like.
Would
you
do
a
UX
scorecard
to
be
able
to
click
a
button
like
you
could,
but
that's
not
really
valuable,
and
that
has
resonated
when
other
people
have
been
talking
about
it.
So
in
that
two-pager
being
able
to
say
here's,
you
know
the
map
in
total
and
that
this
one
piece
is
going
to
be
a
UX
scorecard,
and
then
these
five
things
end
up
being
a
maturity
scorecard
er.
D
However,
it
breaks
out
might
help
them
understand
if
they
know
what
the
outcome
is.
If
it's
too
abstract
all
the
time,
it
is
really
hard
to
nail
it
down,
because
every
group
every
category
every
stage
is
going
to
be
a
little
different
just
inherently,
and
so
it's
hard
to
grasp
those
kinds
of
groupings.
E
I
really
like
that,
you
called
that
out
Yin
because
it's
so
important
for
people
to
understand
that
they're
not
doing
these
one-off
things
that
everything
is
connected
to
like
we're,
not
asking
them
to
do
this
job
map
and
it
not
be
applicable
to
everything
that
they're
actually
doing
within
their
work.
So
I
think
that's
just
really
important
to
highlight
that
we're
not
adding
something
to
your
plate,
we're
we're,
providing
an
alternative
way
to
view
it
and
and
get
a
perspective
into
you're
gonna
work
on
this.
A
B
It's
a
really
good
question:
I've
shared
it
with
the
PM's.
The
PM's
are
like
fine,
but
that's
because
I
think
we
already
have
a
really
strong
alignment
and
so
I
think,
probably
that's
not
it'll
work
for
every
team,
so
we
can
think
through
like
how
we
suggest
people
go
about
doing
this
I.
Don't
think
everyone
should
just
do
it
the
way
that
the
way
that
I,
that
way
that
we
did.
A
In
growth,
so
yeah
dad,
you
know
that's
a
good
point.
Yeah
I
think
there
be
a
lot
of
groups
who
could
benefit
from
doing
it
synchronously
with
their
p.m.
if
possible
and
work
through
it.
That
way,
I,
like
my
vision,
was,
would
be
to
have
your
design
measure.
Your
designer,
your
researcher
and
your
p.m.
A
all
there
together,
working
on
at
least
starting
working
on
that
together
in
in
a
room,
and
then
maybe
finishing
asynchronously,
but
having
those
discussions
because
I
know
for
some
of
the
PM's
I
know
it's
going
to
be
hard
for
to
have
these
conversations,
because
he
just
don't
think
like
this,
and
some
of
them
is
gonna,
be
super
easy,
like
Jackie
I
would
feel
like
yeah.
She
just
comes
up
with
this,
and
her
dreams
and
it'll
be
fine,
because
Jackie
said
so
good
at
it,
but
yeah
I
think
it's
definitely
collaborative
effort.
So.
C
E
That's
very
it's
at
least
historically
so
far.
You
know
the
three
months
that
we've
been
doing
them
they've
been
a
very
feature
specific.
So
we
have
this
idea
that
a
our
customer
base
wants
list
feature
and
then
we
fill
in
an
opportunity.
Canvas
based
off
of
that
feature
to
me,
it
seems
like
this
could
either
come
before
an
opportunity
canvas
or
during
an
opportunity
canvas.
Oh,
my
I'm,
sorry
I
heard
two
people
at
once.
I
didn't
hear
anything
Jaggi.
D
Simmons
Tim
and
I
at
least
I,
don't
want
to
speak
for
him,
but
from
our
from
what
we've
done,
we've
had
a
similar
experience
where
the
opportunity
canvas
is
usually
tied
to
a
job
and
if
we
go
through
the
opportunity,
canvas
process
and
discover
a
job
is
missing
entirely
like
there
was
a
goal
we
didn't
see
before
that.
There's
a
new
job
to
be
done.
We
need
to
add,
or
the
converse
where
we
assumed
there
was
a
need
and
we
started
working
towards
the
solution,
and
then
we
found
out
that
wasn't
actually
a
problem.
D
B
I
had
had
a
question
that
I
think
I
was
just
wondering
so
I'll
just
say
this
so
to
me
is
like
the
job
map
is
just
something
you
do
it
anytime,
you
like.
Oh,
we
don't
have
it,
we
need
one,
let's
make
it
and
then,
after
that
you
have
it
and
you
refine
it
and
you
look
at
it
at
different
times
like
when
you're
doing
an
opportunity
canvass,
you
look
at
it
either
to
identify
okay.
Where
are
we
focusing
or.
C
B
You
know:
where
do
we
have
opportunity?
Where
do
we
want
to?
Where
do
we
want
to
like
fill
in
gaps
and
then,
when
you're
doing
a
scorecard,
you
look
at
it
and
you
use
it.
So
it's
just
a
thing
you
do
and
you
can
do
it
at
any
time
because
you
don't
have
it
and
then
once
you've
done
it
once
then
it's
just
like
you
know,
you're
using
it.
It's
a
living
thing
in
I.
F
F
So
I
have
this
tab
job
to
be
done.
Rm,
release
manager
and
I
cross
them
off
once
we
deliver
that
job
to
be
done,
and
then
I
have
this
other
tab
called
user
stories
environments,
and
this
is
like
a
specific
users
like
decomposition
of
the
user
story
and
just
several
jobs
to
be
done
and
if
you
scroll,
like
all
the
way
over
I,
have
like
a
huge
linking
of
issues
and
epics
and
tasks
to
those.
So
that's
how
that's
how
I've
done
it?
It
lives
and
I
add
to
it
constantly
yeah.
B
F
It's
actually
breakdown
at
something
on
the
on
the
second
tab
that
I
just
moved.
It
looks
like
so
journeys
to
job
to
be
done:
release
manager,
user
story,
environments
which
links
back
to
a
release,
orchestration
job
to
be
done,
six,
which
is
from
the
job
to
be
done.
Release
manager,
yeah,
so
I
have
like
a
slug
column
s
that
then
gets
its
own
tab
for
a
decomposition,
because
this
can
get
really
big.
You
can.
C
B
F
A
F
Have
a
handbook
page
so
yeah
I'm
created
a
handbook
page
and
now
those
people
have
published
that
handle
page
so
creating
a
table.
It's
typically
how
people
are
managing
it
and
I
would
say
the
other
way
that
people
are
managing.
It
aren't
issues
so
to
this
sprawl
of
FX
and
issues
that
people
are
creating
and
that's
more
products
like
yeah
when
I'm,
when
I'm
coaching
people
on
how
to
get
a
job
to
be
done.
I'm
like
ooh.
F
B
It's
just
gonna
and
quickly
answer
your
question
Larry,
so
girls
is
different
because
we
do
experiment
so
the
way
it
sort
of
works
is
the
PM's
are
focused
on
very
specific
KPIs
they're
running
small
and
big
experiments
to
impact
those
KPIs,
and
then
the
designers
are
constantly
reminding
the
PM's
about
the
job
in
order
to
help
them
design
like
once
they
get
to
the
design
of
those
experiments
to
make
design
decisions.
So
the
PM's
in
growth.
They
don't
necessarily
use
jobs
to
be
done
because
they
are
very
much
key
catalyst.
Joshua.
F
Olivia
said
that
Jackie,
because
I
used
to
work
in
an
organization
where
I
had
growth,
pm's
reporting
and
through
me
and
traditional
PMT
reporting
through
me.
So
that's
where
I've
had
to
create
this
artifact
of
attributing
things
to
a
global
KPI,
so
that
we
were
able
to
use
the
same
process
across
both
both
groups.
Yeah.
E
Yeah
honestly
I'm
feeling
a
little
nervous,
because
I
mean
we
have
seen
really
great
things
today
and
we've
had
a
really
good
discussion
but
I'm
coming
from
a
from
a
really
practical
standpoint
of
lish,
I,
really
I've
seen
things
not
be
successful
when
we
don't
specifically
say
this,
is
the
moment
of
time
that
you
do
this
and
I
think
that
over
time
that
can
change,
but
just
to
get
the
adoption
going,
we
have
to
explicitly,
unfortunately
explicitly
say
this
is
when
you
do
this
and
then
over
time.
Oh,
my.
B
E
What
you're
getting
lonely,
not
the
ladder,
I
think
it's
the
like.
How
do
we
even
get
adoption
of
this
so
I'll
pick
on
product
management
for
a
second
sorry,
Jackie,
yeah
yeah.
C
E
Here
actually
you're
the
exception
to
the
rule.
So
it's
not
really
about
you.
So
in
the
area
that
I
work
it
is
or
some
some
of
our
categories,
some
of
our
stage
groups,
it's
I've,
never
seen
an
opportunity
campus,
so
we're
out
of
the
level
where
it's
really
a
consistent
across
the
board,
and
so
we
explicitly
need
to
say
this
is
the
moment
that
you
do
this.
So
if
it's
during
the
opportunity
canvas.
This
is
why
I
keep
bringing
opportunity
cameras
up
like
if
product
management
is
responsible
for
doing
an
opportunity
canvas.
F
Actually,
I
really
do
dream
about
and
I
do
think
about.
I
put
everything
to
context
of
them
of
a
task
and
the
KPI
and
North
Star
metric
like
how
do
I
drive
revenue
from
what
this
customer
is
trying
to
do
in
our
platforms.
I
think
that
is
the
way
my
brain
thinks
with
everything
that
I
have
to
do
with
release
management.
So
I
would
say
opportunity.
F
Canvasses
are
probably
not
the
best
way
to
do
it,
because
not
everyone
has
it
adopted,
but
I
do
think
if
we
can
tie
it
to
the
product
development
lifecycle,
yeah
I
get
labs
like
solution,
validation,
it's
where
you
select
your
job
to
be
done
and
that's
where
you
iterate
and
decompose
it
and
to
specific
issues.
I
think
that
that's
like
a
a
way
that
we
can
update
the
handbook
and
say
this
is
where
product
managers
need
to
interface
with,
with.
E
I'm,
ok
with
starting
with
that
I
think.
That's
our
first
iteration
to
me.
It's
still
so
late
in
the
process.
I
would
much
rather
have
like
how
do
we
get
to
the
altitude
that
jackie
was
talking
about
if
we
ready
at
solution
validation-
and
this
is
where
designers
really
struggle,
because
if
we're
a
solution
validation,
then
that
means
we're
in
the
product
we're
thinking
about
how
things
are
going
into
the
product.
E
We're
not
really
thinking
about
the
job,
we're
thinking
about
the
task
and
that's
why
we're
getting
these
jobs
that
are
written
at
either
a
user
story
or
task
level,
and
so
but
I'm,
ok
with
starting
there.
As
long
as
we
can
also
coach
and
train
on
the
altitude,
because
it's
it's
so
different
and
I
think
that
the
biggest
gap
that
we
have
isn't
necessarily
during
the
solution,
validation
phase-
is
it's
actually
the?
How
do
I
see
across
my.
F
E
A
Yeah
I
I
see
it
as
to
two
things:
we
need
to
back
back
it
up
back
everything
up,
because
we
are
so
granular
all
the
time
with
our
solutions
and
even
the
problem
validation
can
be
very
granular
with
what
is
it
getting
brought
to
my
desk
at
least
we
need
to
back
it
up
and
take
a
bigger
view,
like
Jackie's
team
has
done
with
growth
like
let's,
let's
back
up
and
look
longitudinally
what's
happening
here.
That
is
where
we
can
encourage
them
to
create
these
job
maps
specifically
using
them.
A
I
think
you
get
into
this
problem.
Validation,
oh
I,
think
there's
a
problem
with
this
step
in
this
function,
I'm
not
sure
what
it
is.
Let's
go
find
out.
Well,
let's
go
back
to
the
job
map,
where's
that
why
what
is
involved
in
that
problem
area?
What
can
we
possibly
go
and
dive
deeper
into?
And
so
you,
like
you,
go
back
to
that
job
map
and
use
it
at
different
areas,
solution,
validation!
Where
is
that
line
on
this
job
map?
What
else
is
around
it?
A
What
else
am
I,
not
thinking
about
cross
stage,
lis
cross
stage
lis
cross
stage
wise,
like
that?
I
need
to
take
into
a
consideration
as
well
with
this
solution,
as
well
as
that
problem,
validation,
I
think
it
can
serve
as
like
the
dare
I
say
a
road
map,
but
like
like
a
place
to
get
your
bearings
in
your
context
for
what
your
task
your
perceive
task
is
at
hand
that
we
don't
have
right
now.
I
think,
that's
why
we're
so
granular
and
so
many
things
that
we're
doing
I.
E
Yeah,
so
that
that
plays
into
that
flexibility
model
of
like
we're,
providing
them
a
framework
and
then
they'll
have
to
determine
when,
because
I
can
tell
you
in
the
area
that
I
work,
we
can't
even
get
to
milestones
ahead.
So
two
months
I
know,
and
and
so
we
need
to
start
really
small.
But
if
there
are
pockets
of
the
company
that
are
thinking,
you
know
three
milestones
and
beyond
then,
yes,
by
all
means,
use
the
framework
and
to
that
and
then
be
the
exemplar
that
everyone
else
can
follow.
E
E
A
Endorse
should
we
because
I
don't
always
say,
base
time.
So
that's
why
we're
here?
So
thank
you
so
much
for
everybody
for
joining
today.
I
really
appreciate
it.
I
think
what
I'm
gonna
do
is
I'm
gonna,
think
about
all
this
and
go
into
my
mr
and
update
some
stuff
and
then
I'm
gonna
ping.
All
of
you
on
that,
mr
and
so
you
can
go
back
and
look
at
things
and
if
I
do
things
wrong
in
the
end
Mar.
A
Just
let
me
know
alright
I
do
in
learning
about
merger
crests
on
all
different
fronts
for
another
project,
but
I
would
love
to
get
your
thoughts
on
that
because
that's
where
all
of
this
has
started,
at
least
for
the
UX
organization,
but
there
is
stuff
that
we
need
to
spill
over
into
the
product
management
organization
as
well.
So
keep
that
in
mind
as
well,
but
thank
you
so
much
for
this.
This
has
been
wonderful,
I'm,
so
glad
and
so
happy
where
we
we've
landed
after
two
sessions.
Thank
you.
Thank
you.
Thank
you.