►
From YouTube: UX Showcase - JTDB Meta Analysis
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
A
You
might
be
wondering
what
the
heck
is
a
jobs
to
be
done,
meta-analysis,
and
why
are
we
doing
it?
Essentially,
you
know
jobs
to
be
done
has
been
part
of
our
practice
for
a
while
now,
but
there's
never
really
been
a
systematic
review
or
an
attempt
to
simplicize
these
job
stories
into
a
cohesive
whole.
A
Essentially,
we're
missing
out
on
the
fact
that
jobs
to
be
done
can
get
very
powerful
framework.
It
can
help.
Drive
Innovation
show
us
where
our
weak
spots
are,
but
only
if
it's
done
properly.
So
what
I've
done
is
kind
of
taken
all
of
our
job
stories
that
are
in
our
yaml
file
and
try
to
break
them
apart,
organize
them
analyze
them
squish
them
every
which
way
to
sort
of
figure
out.
If
there
might
be
some
kind
of
collective
interesting
synthesis
that
we
can
do,
but
before
I
go
any
further.
A
I
want
to
make
a
distinction
fairly
clear
jobs
to
be
done
is
a
framework,
and
a
job
story
is
a
sentence
that
belongs
into
that
framework
and
a
job
story
has
you
know
three
parts,
a
job,
a
circumstance
and
a
need,
and
the
job
story
itself
is
what
is
in
our
yaml
file,
not
jobs
to
be
done,
jobs
to
be
done,
encompasses
an
entire
methodology
or
actually
variance
on
a
methodology.
So
when
I
talk
about
the
statements
that
we're
used
to
seeing
with
jobs
to
be
done,
I
would
refer
to
them
as
job
stories.
A
So
this
is
our
list
of
job
stories.
It's
a
giant
yaml
file
and
it's
not
super
useful
and
kind
of
intimidating.
So
this
is
where
I
started,
and
you
know,
there's
not
a
whole
lot.
I
can
do
with
this,
so
I'm
going
to
kind
of
walk
you
through
what
my
process
was
in
getting
this
to
a
form
where
I
felt
like
we
could
derive
some
value
from
it.
So
here
we
go
First
Step,
get
it
out
of
the
yaml
file
and
into
a
spreadsheet.
A
This
is
still
really
not
great.
As
you
can
see,
we
have
things
up
here,
like
slug
short
jtbd
grade.
Some
things
have
grades.
Some
confidence
like
what
is
a
confidence
heuristic
need.
What
is
confidence
low
mean?
What
are
you
know?
Some
things
have
a
source,
it's
a
mess
right,
but
you
know
after
some
work
we
kind
of
and
massage
the
data
a
little
bit.
A
We
can
at
least
identify
which
stage
and
group
and
product
category
certain
jobs
are
from
and
start
theming
them
out
a
little
bit,
and
basically,
what
this
allows
us
to
do
is
start
counting
stuff
right.
So
I,
presented
or
I
released
a
report
at
the
end
of
last
quarter.
That
sort
of
goes
over
this,
so
I'm
going
to
move
relatively
quickly
through
these
slides.
But
essentially
you
know
we
looked
at
the
distribution.
So
what
we
have
you
know
different
stages,
have
different
amounts
of
job
stories.
A
A
I,
don't
you
know
we
had
a
lot.
We
had
a
lot
to
deal
with,
but
we
also
looked
at
what
wasn't
there
right.
So
what
were
we
missing
if
you
look
at
if
you
count
up
all
of
the
product
categories,
the
groups
and
the
stages,
there's
a
111
divisions
within
gitlab
that
show
up
on
that
wonderful
handbook,
page
and
only
38
of
them
had
a
one
job
story
or
more,
which
would
imply
that
we
don't
have
job
stories.
A
Sorry,
oh
yeah,
which
would
imply
that
62
of
the
product
is
without
job
stories,
which
would
be
bad.
You
know
so.
Job
stories
lived
at
different
levels,
so
their
stage
there's
groups
or
category
ones,
but
you
know
if
you
believe
that
you
know
each
of
these
stages
should
have
some
kind
of
addressable
user
need
and
that
should
be
represented
in
the
jobs
to
be
done
framework,
then
for
only
30
38
of
the
way
towards
validating
that
right
and
I'm
going
to
go
over
some
of
this.
A
73
so
there's
just
like
a
real
variance
here
right,
so
we're
all
treating
this
differently,
so
basically,
okay,
I
counted
some
stuff.
A
Now
what
well
I
ended
the
last
report,
with
sort
of
the
next
steps
of
looking
at
themes
and
overlaps,
applying
some
Parables
throughout
the
process
to
sort
of
engage
in
consistency
and
look
at
our
organization
and
process
of
how
we
do
jobs
to
be
done
so
I'm
going
to
start
with
a
little
bit
of
what's
happened
since
the
end
of
that
last
report.
A
So
as
far
as
addressing
organization
and
process,
every
group
within
create
has
started
the
process
of
drafting
a
job
performer
canvas
which
is
part
of
how
we
want
to
address
jobs,
cbdums
from
a
more
job,
performer-centric
point
of
view.
So
you
know
we
put
up
our
best
guesses
in
this
canvas
and
then
we
go
talk
to
people.
We
actually
conduct
interviews
and
validate
the
job
map,
the
aspirational
goals,
the
social
goals,
and
we
come
out
with
something
you
know
that
we
feel
confident
about
that's
validated
in
a
real
way.
A
This
also
will
continue
once
we
have
like
a
validated
job
map.
We
get
to
send
out
a
survey
based
on
the
tasks
that
we've
identified
as
part
of
the
job
performer
experience,
and
we
get
to
ask
them
their
importance
and
satisfaction
levels
for
each
of
these
jobs
and
what
that
does
is
allows
us
to
calculate
an
opportunity
score
along
our
job
map.
So,
for
instance,
you
know
if,
let's
say
assigning
a
Reviewer
is
very
important
and
I
find
that
process
extremely
unsatisfying.
A
A
This
is
from
the
code.
Reviewer
canvas
that
and
Andy
put
together.
So
thank
you
to
them,
but
how
will
we
do
that
right?
We
have
tasks
on
one
hand
and
we
have
job
stories
on
the
other.
A
Well,
we
need
to
compare
apples
to
apples,
so
what
I
did
is
take
all
the
job
stories
and
basically
pulled
out
the
derived
task
for
each
of
these
right
like
what
is
the
task
that
each
of
these
things
is
addressing,
and
once
we
have
that
puts
them
all
into
a
mural
and
I
started,
grouping
them
kind
of
stripping
away
their
origin
right,
I,
don't
care
what
group
or
stage
they're
associated
with
anymore
I
care
about
the
task
and
how
it's
related
to
the
larger
goal.
A
Right
then,
I
started
like
drawing
connections
at
this
point.
I
was
sort
of
unclear
as
to
what
exactly.
A
But
suffice
to
say
you
know
it
it's
just
sort
of
like
looked
at
things
that
were
part
of
a
workflow
or
building
blocks
that
needed
to
sort
of
act
as
a
prerequisite
or
or
come
before
or
after
something,
but
how
to
show
what's
missing
right,
as
I
mentioned
earlier,
a
lot
of
our
product
isn't
represented
by
job
stories,
so
I
had
no
tasks
to
pull
in
this
sort
of
graphic
in
the
middle
shows
you
you
know,
what's
there
and
what's
not
there,
so
there's
a
lot
more
red
than
green,
and
so
you
know
what
I
ended
up
on
and
I'm
not
saying
this
is
a
perfect
solution
by
any
means
it's
just
sort
of
pulling
in
the
product
areas
grouped
by
stage
that
were
not
represented
and
putting
them
together
with
the
job
stories
that
we
did
have
and
put
them
all
into
like
a
giant
graphic
like
this,
and
you
can,
you
know,
caveat
I'm
no
longer
a
designer.
A
This
is
not
great
right,
but
it's
something
and
basically
take
a
look
like
here's.
Our
job
map
from
the
code
reviewer
canvas
right.
It
all
kind
of
ties
together
in
some
way,
but
you
know
like
this
okay,
so
we
have
a
map
of
tasks
and
product
areas
and
they're,
grouped
by
theme
and
they're
connected
by
dependencies
in
their
workflows.
A
But
like
is
it
perfectly
designed?
Does
it
have
all
the
relevant
connections,
all
the
right
groupings
and
everything
you
could
possibly
want?
No
way,
of
course
not.
But
it's
a
start-
and
you
know
you
might
look
at
this
and
be
like
wow.
That's
cool,
but
I
have
no
idea
what
to
do
with
this
right.
This
is
like
a
spaghetti
mess,
so
one
idea
is,
you
could
make
a
route
through
this
right
think
of
a
process
like
a
benchmarking
workflow
and
see
if
it
can
be
mapped.
A
You
know
where
we
have
if
we
zoom
in
a
little
bit
here,
you
know
solid
purple
is
like
existing
job
stories.
A
dashed
line
could
be
connecting
things
that
don't
have
a
job
Story
Each
sticky
is
a
task,
that's
derived
from
our
jobs
to
be
done.
Yaml
file
and
the
colors
of
the
stickies
represent
larger
areas
of
work
or
themes,
and
you
have
those
themes
and
you
have
the
gaps
that
are
represented,
and
yet
that
looks
really
twisty
and
turning
in
like
how
could
we
actually
make
use
of
that?
A
Well,
what
I
did
is
I
kind
of
straightened
it
out
and
pulled
it
apart
and
I
ended
up
with
something
kind
of
like
this,
which
is
a
little
bit
like
I,
don't
know
kind
of
like
a
root
map
in
a
Subway
or
something,
and
if
we
zoom
in
here
a
little
bit,
what
I've
done
is
taken
the
journey
steps
and
actually
given
them
a
label
like
what's
actually
going
on
here
kind
of
in
a
general
term,
and
what
we
can
also
do
is
take
a
guess
at
my
who,
the
job
performer
might
be
because
we're
trying
to
as
part
of
jobs
to
be
done,
move
towards
a
more
job.
D
A
Trace
the
job
story
back
to
where
it
came
from
so
which
stage
or
group
did
this
originate
from
in
the
yaml
file,
and
what
we
can
do
is
kind
of
look
at
okay.
A
You
know
we
took
this
plausible
path
through
feature
development
which
themes
did
that
touch
on
and
which
job
performers
had
to
take
part
for
this
to
happen.
So
you
have
everything
from
you
know:
business
planning,
CI,
CD,
business,
metrics
for
themes
and
product
planners
code,
authors,
safety,
testers.
You
know
all
these
people
need
to
work
together
to
get
this
larger
job
done.
A
You
can
also
take
a
look
at
how
the
stage
groups
are
represented
on
this
path
right,
so
for
each
of
these
for
this
path
anyway,
it
touched
on
eight
different
stages,
is
66
existing
job
stories
and
touched
on
15
product
areas
that
don't
have
a
job
story
yet
so
it's
clear
that,
like
we
have
some
work
to
do
in
order
to
fill
out
this
story
right
so
for
areas
without
the
job
stories.
A
What
this
map
does
is
it
allows
us
to
like
say:
okay,
you
know
this
is
a
place
in
this
story
that
we
need
to
focus
on.
You
know
clearly
write.
The
initial
code
has
more
steps
to
it
right
than
one,
but
that's
all
that's
represented
now.
A
So
we
need
to
dig
into
this
more
and
figure
out
what
the
job
performer
is
doing
here
and,
as
a
note,
the
IDE
job
performer
interviews
are
currently
being
conducted,
so
this
will
be
completed
soon
and
for
things
like
adjacent
steps,
where
you
have
a
lot
of
different
job,
performers
or
different
stages,
stage
groups
working
next
to
each
other
or
different
themes
that
are
kind
of
adjacent
right.
You
can
kind
of
zero
in
now
and
think
about.
A
So
you
know
I,
don't
know
if
deploy
and
plan
work
together,
a
lot
right
now
when
it
comes
to
like
documenting
product
changes
or
or
Insurance
releases,
or
maybe
that's
not
something
you
need
to
work
on,
but
it
kind
of
fit
here,
but
we
can,
you
know,
examine
those
things
and
see
and
as
we
move
more
towards
a
job
performer
kind
of
centric
point
of
view,
the
pl
the
places
are
groups
internally
that
are
interested
in
what
a
release
officer
does,
can
look
at
these
places
and
see
like
okay,
a
release
officer
and
the
code
author
are
kind
of
both
kind
of
here.
A
Also
the
parts
of
the
workflow
that
have
been
validated
right
so
in
this
case
our
our
code
reviewer
they
can
easily
slot
into
the
map.
So,
as
we
continue
to
validate
this,
we
get
a
clearer
and
clearer
picture
right.
So
this
is
like
obviously,
a
lot
of
steps,
but
we
know
that
they're
they're
pretty
good,
because
we've
talked
to
people
and
we've
done
some
synthesis
to
get
to
this
point
Okay.
So
we've
we've
got
a
few
things
what's
next.
This
is
obviously
still
a
work
in
progress.
A
I'm
going
to
be
cleaning
up
these
visualizations
and
trying
to
get
them
into
some
kind
of
format
that
can
be
reused
and
altered
and
serves
some
kind
of
of
utility,
as
we
move
forward,
I'll
also
be
creating
a
step-by-step
guide
in
the
handbook,
with
examples
and
templates
of
how
to
run
through
this
new
jobs
to
be
done
process
and
then,
of
course,
I
will
have
a
report
detailing
this
journey.
A
Well,
we've
learned
and
where
we
go
from
here
with
the
big
hint
of
organizational
change,
is
hard
and
kind
of
like
just
to
give
you
a
preview
of
what's
the
end
goal
here.
Right
I
want
us
to
be
aligned
on
terminology
right.
I
want
us
to
speak
the
same
language.
When
we're
talking
about
jobs
to
be
done.
A
We
should
all
know
the
difference
between
a
job
story
and
jobs
to
be
done.
We
should
we
should
all
be
speaking
the
same
language
so
that,
when
we're
talking
about
these
things,
you
know
we're
not
misconstruing
what
we're
saying
I
want
us
to
be
aligned
on
process.
This
is
a
lofty
goal,
but
you
know
I'm
going
to
propose
something
out
there.
It's
up
to
you
know
teams
to
sort
of
take
it
on
I'm,
going
to
try
to
hold
up
the
work
that
we're
doing
and
create.
E
Foreign
I've
got
the
first
couple
of
questions,
so
one
I
like
to
always
ask
just
what's
been
the
biggest
surprise.
You've
come
across
so
far,
you've
done
a
ton
of
work.
Heads
down
work,
it's
daunting,
you're
brave,
for
diving
into
this.
So
there's
probably
lots
of
surprises,
but
what's
the
biggest
one.
A
Wow
that
I
should
have
expected
that
question.
I
I
think
some
of
the
initial
work
of
just
pull.
You
know
pulling
these
things
apart
and
just
how
variant
they
were
a
yaml
file.
Has
this
like
kind
of
veneer
of
structure
right
where
it
feels
like?
Oh,
this
is
all
nicely
organized.
A
A
Yeah,
my
hope
is
that
other
teams
can
look
at
this
and
see
that
we're
getting
tangible
benefit
from
adapting
this
process
right.
We
get
a
validated
idea
of
who
our
job
performers
are
in
each
stage
and
what
the
opportunity
score
is
for
different
parts
of
our
map
and
I'm
going
to
try
to
make
it
as
easy
as
possible
for
them
to
do
that
to
self-serve
on
that
and
I
hope
that
you
know
at
some
lovely
point
in
the
future.
This
map
that
I've
created
is
completely
full
and
validated.
A
D
Thanks
for
the
presentation,
Ben,
one
of
the
things
that
you
spoke
to
in
your
deck
was
that
the
yaml
file
wasn't
really
the
best
like
single
source
of
Truth.
As
you
were
kind
of
uncovering
things.
D
A
That
is
a
great
question.
Will
I've
been
thinking
about
that?
A
lot
across
the
the
research
that
I've
been
doing?
A
I
agree
that
the
list
like
a
single
source
of
Truth
in
a
list
form
is,
is
valuable
for
for
things
like
okay
I
just
want
to
see
what
job
stories
there
are
out
there
I'm,
hoping,
though,
that
we
move
more
towards
using.
You
know
something
like
this
map,
where
you're
not
just
looking
at
stories
in
isolation.
A
You
shouldn't
just
be
concerned
with.
You
know
the
little
area
that
you're
looking
at.
We
want
to
kind
of
broaden
and
Foster
a
more
holistic
understanding,
so
something
that
like
allows
you
to
see
kind
of
more
in
the
peripheries
of
of
what
you're,
focusing
on
and
kind
of
seeing
that
okay,
you
know,
I'm
really
looking
for
for
job
stories
that
relate
to
code
review,
but
I
know
that
oh
I
can
see
like
this
butts
up
against.
A
You
know
safety,
testing
or
vulnerability
management
or
whatever
it
is,
and
so
you
know
I
want
to
be
aware
of
that,
and
possibly
talk
to
those
teams
as
I'm
doing
my
design
or
my
research
or
whatever.
C
Hey
Ben
yeah
mine
is
just
that
it.
It
seems
like
if
you
step
all
the
way
back,
we're
going
to
be
able
to
get
a
map
of
kind
of
the
down
to
be
done
stories.
Across,
The,
Meta
workflow
with
our
products,
and
so
I
just
wanted
to
confirm
that.
That's
something
you
think
we
might
be
able
to
take
away
from
this
research
yeah,
okay
and.
A
C
Go
ahead,
if
so,
because
you're
nodding,
if
so,
I,
would
even
like
lead
with
that
as
the
organizational
change
framing
right.
It's
like
well,
we
don't
have
now.
Is
this
holistic
map
of
the
user,
Journey
users
Journey
with
our
product
and
in
the
end
after
we
can
land
this
stuff,
we'll
be
able
to
look
more
cross-functionally.
A
F
I
have
the
next
one,
so
we
the
existing
jobs,
that
you
were
referencing
I'm
wondering
how
do
we
reconcile
that
with
this
new
performer-based
process?
Is
this?
Can
they
be
trusted
and
should
this
something
where
we
should
expect
them
to
redo
it
using
this
new
process?
What
are
your
thoughts.
A
Again
very
good
question:
my
research
has
led
me
to
conclude
that
there's
a
wide
variance
in
the
rigor
that
was
used
to
derive
these
job
stories.
A
I
could
spend
like
another
six
months,
diving
into
the
rabbit
hole
of
each
specific
job
story
and
how
well
researched
it
was,
but
I,
don't
think
that's
a
good
use
of
time.
I
think
I
would
rather
put
something
out
there.
That
shows
hey.
If
you
do
it
this
new
way,
you
can
get
these
benefits.
I!
A
F
Yeah
I
like
that
you're
implying
they
should
do
it,
but
you're
not
saying
they
have
to
do
it,
but
they
should
do
it.
I.
F
All
right,
I
got
the
next
one
too.
Would
you
say
that
your
metro
map
is
a
living
document
and
this
kind
of
I
think
feeds
into
what
Erica
was
saying
to
some
degree,
there's
a
living
document
that
we
should
continue
to
update
and
you
know,
contribute
to
so
it
becomes
sort
of
the
single
source
of
Truth.
A
Yeah
100
That's
My
Hope
I'm,
hoping
that
somebody
with
better
figma
skills
than
me
can
figure
out
a
good
way
to
sort
of
add
to
this,
so
that
as
teams
go
through
this
process,
it
becomes
more
complete
and
more
validated
and
yeah
serves.
A
That
single
source
of
Truth
for
for.
B
F
B
Just
wanted
to
make
this
point
that
it's
I
think
it
would
be
very
beneficial
to
have
something
of
this
sort
to
refer
to
at
the
discovery
stage,
so
that
we
can
at
least
frame
better
questions
to
ask
to
our
users,
because
we
learned
it
a
very
hard
way
in
secrets
that
we
need
to
collaborate
with
the
authanath
and
just
looking
at
this
map.
It
gives
so
much
of
clarity
that
if
this
was
handy
like
come
back,
we
could
have
like
understood
that
at
a
much
earlier
stage.
A
Yeah
yeah
awesome
I
mean
I
love
to
hear
that
because
I
feel
like
there's
so
many
there's
so
much
overlap
and
potential
collaboration
with
Synergy
between
the
work
that
we
all
do
and
we're
pretty
good
at
working
together.
But
sometimes
we
don't
even
know
that
we
should
work
together
right.
So
hopefully
this
can
illuminate
some
of
that.
G
All
right,
I,
don't
see
any
more
questions,
so
thanks
a
lot
Ben
and
Emily
for
taking
the
time
to
present
they're
fantastic
and
if
we
look
forward
to
and
I
definitely
look
forward
to
seeing
the
the
full
version
of
the
jobs
to
be
done.
Map
would
be
great
to
dive
into.
G
All
right
we
can
and
a
little
early
today,
everyone
can
have
some
time
back
thanks
a
lot
for
attending
and
for
the
great
conversation
see
everyone.