►
From YouTube: Discussion on JTBD Mapping - Erika/Veethika
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
All
right
so
today,
erica
and
I
are
going
through
the
process
of
mapping
jobs
and
I
am
taking
the
reference
of
the
old
mapping
that
I
had
done
about
one
and
a
half
years
ago,
which
might
not
be
perfect,
but
this
is
what
we
are
going
to
base
our
discussion
on.
So
how
I
started
with
this
mapping.
Is
I'm
not
sharing
my
screen
and
I
totally
should.
A
Visible
enough,
okay,
great
so
I
started
off
with
the
kind
of
making
a
note
of
the
core
functional
jobs
that
users
come
to
perform
when
we
are
talking
about
all
things
verified.
So
at
this
stage
I
was
not
even
like
focusing
a
lot
on
just
pipeline
execution
or
just
continuous
integration.
A
I
was
thinking
of
everything
that
users
would
want
to
do
with
the
features
that
we
kind
of
group
under
verify
and
from
there
I
consolidated
the
core
jobs
into
this
one
particular
statement
and
this
statement
says
to
standardize
and
automate
tests
builds
and
deploy
process
across
organization
to
allow
easy
contribution,
while
keeping
the
main
branch
cream,
which
is
main
branch
healthy,
and
I
like
kept
this
as
a
reference
for
the
core
job
that
we
are
going
to
be
referring
to.
A
The
next
part
was
thinking
of
who
would
be
executing
the
jobs.
So
there,
the
circles
in
the
innermost
circle
are
the
core
executors.
So
for
core
executors,
I
thought
of
personas
that
we
very
frequently
refer
to
like
the
devops
engineers
or
software
engineers
or
developer,
and
a
little
outside
that
circle
on
its
periphery.
I
was
imagining
personnel
such
as
system
administrator
compliance
manager,
release
manager,
development
team
lead
because
in
the
process
that
release
managers
follow
and
compliance
managers
follow
they
the
processes.
A
The
idea
is
anybody
can
because
taking
the
reference
of
a
company
like
gitlab,
where
we
work,
everybody
runs
five
minutes,
everybody
merges
their
changes,
so
everybody
kind
of
interacts
with
that
in
their
day-to-day
job,
and
I
kind
of
skipped
this
part,
because
I
was
not
able
to
get
a
very
good
hang
of
like
what's
the
value
that
this
is
adding
and
I'm
not
saying
that
that
was
really
great
step
on
my
part,
but
just
stating
that
it
wasn't
like
yeah
coming
to
the
job
map
part.
A
So
we
have
these
stages
which
come
predefined
and
I
try
to
segregate
all
the
primary,
not
primary,
all
the
jobs
that
were
kind
of
that
that
were
documented
here
earlier
into
these
buckets
into
these
different
stages.
A
Let's
say,
and
I
started
off
like
if
we
talk
about
defining
and
we
talk
about
pipelines,
then
what
are
the
jobs
which
are
relevant
at
that
stage
and,
of
course,
what's
relevant
is
defining
a
new
pipeline,
but
to
put
it
in
a
more
functional
way,
without
focusing
a
lot
on
the
tool
and
the
exact
mechanism
that
we
are
providing
today.
So
I
I
wrote
that
defining
standard
standards,
tests
and
commands
for
organizations
to
test
fill
and
deploy.
A
This
was
written,
keeping
in
mind
that
users
have
to
author
the
pipeline
before
they
can
even
before
they
can
do
anything
else
with.
It
then
comes
the
part
of
locating
so
make
a
aware
of
available
test
suite
or
explain
the
process
for
using
the
existing
pipeline
and
so
on.
So
what
I
saw
was
since
we
had
made
this
division
in
the
responsibilities
of
the
two
stage:
groups,
fibonacci
and
pipe
and
execution-
and
we
mentioned
that
everything
that
relates
to
defining
the
pipeline
or
editing
the
pipeline.
A
It's
under
the
purview
of
pipeline
authoring
and
while
the
pipeline
is
running,
that's
when
it
is
like
it
comes
under
the
categories
under
pipeline
execution.
So
it
starts
with
like:
where
would
we
make
the
like
this
option
available
to
users
to
avail
the
automated
tests
and
processes?
A
That's
where
we
are
talking
about
the
discovery
of
all
the
features
which
are
related
to
workline
execution
or
continuous
integration?
Next,
first,
just
confirming
like
enable
using
environment
specific
process.
So
this
particular
stage
we
are
only
talking
about,
like
maybe
confirming
the
action
and
next
was
when
pipeline
has
already
started
to
execute.
A
So
when
the
I'm
using
the
term
pipeline
here,
which
is
not
ideal-
and
I
just
want
to
make
a
note
that
we
are
still
talking
about
those
automated
tests,
but
since
it's
just
like
I'm
going
through
the
process,
so
I'm
just
using
terms
which
are
not
very
well
thought
of
yeah
and
you.
So
when
we
come
to
the
execute
stage.
This
is
exactly
what
piping
execution
categories
take
care
of
like
when
your
pipeline
is
running
when
the
runner
is
picking
up
jobs
executing
those.
What
is
the
job?
A
What
is
the
real
job
that
we
are
referring
to
here?
What
is
is,
was
it?
What?
What
is
it
that
users
have
come
to
do
on
gitlab
that
we
are
making
happen
through
these
through
the
setup
feature,
and
the
next
was
monitoring
yeah.
C
So
this
is
perfect,
but
where
do
the
devs
come
in
like,
and
so
so
is
this
execute
like
between
the
handoff
between
stage
four
and
stage
five?
Is
that
how
we
distinguish
authoring
from
from
execution.
A
Other
team
leads,
and
it
kind
of
I
mean
it's
not
something
very
hard
and
fast,
because
it
totally
depends
on
the
composition
of
the
teams
like
if
it's
a
very
short
team,
then
maybe
there's
one
developer
who's
responsible
for
the
pipeline
as
well.
Apart
from
the
day-to-day
job
of
writing
the
software,
but
in
like
big
enterprise
teams,
there
would
be
a
dedicated
devops
engineer
or
there
might
even
be
an
sre
who's
going
to
take
complete
responsibilities
of
all
things
that
relates
to
defining
or
writing
the
pipeline
or
editing
the
pipeline.
A
So
what
the
handoff
really
happens
is,
I
would
say,
not
even
locate
prepare,
because
when
developers
are
merging
their
changes,
they
are
looking
for
initiating
these
automated
tests
and
once
they
initiate
that
and
confirm.
This
is
actually
the
part
where
their
role
kicks
in
okay,.
C
A
A
Yeah-
and
the
next
part
is
of
course
monitor
because
when,
when
the
jobs
are
being
executed
at
that
time,
there
would
be
some
degree
of
anxiety
among
the
developers
like
I
initiated
this,
I
have
other
things
to
look
at.
How
is
this
progressing?
Would
I
have
to
come
back
and
dedicate
more
time
to
this,
so
they
want
some
sort
of
peace
of
mind
and
that's
where
the
monitoring
part
comes
in.
A
They
want
to
easily
be
able
to
examine
and
monitor
the
running
pipeline
and
observe,
if,
like
the
safety
measures,
are
in
place,
for
example,
they
want
to
be
assured
that
the
variables
that
they're
passing
through
the
jobs
they're
not
getting
leaked
anywhere,
there's
no
security
threat,
that's
underway
and
in
case
something
goes
here
and
there
like
not
as
expected.
A
C
A
Yeah
so
stage
four,
if
I
talk
to
you
in
terms
of
like
the
exact
action
that
you
are
performing
on
the
product,
so
when
you.
A
When
you
click
on
like
creating
the
merge
request
when,
when
the
creation
of
mr
is
initiated
at
the
same
time,
the
pipeline
also
gets
started
so
that's
fun
and
then
another
option
to
do
this
is
when
you
go
to
your
pipeline
page
pipeline
index
page
and
you
click
on
the
blue
button,
which
is
on
the
top
right
corner
that
says,
run
pipeline.
A
A
I
know
that
jobs
have
to
be
personal
agnostic,
but
talking
in
terms
of
like
who's
doing
the
who,
the
main
executor
here
is
yeah
developers
are
expecting
different
things
when
they
are
talking
about
monitoring
the
pipelines
and
the
devops
engineers
or
someone
sitting
like
at
the
very
top
at
the
director
level.
They
are
expecting
something
very
different
from
monitoring.
They
want
to
see
like
in
terms
of
usage,
households.
C
Or
like
they're
so
they're
doing
that
in
coordination.
So
one
thing
we
could
do
is
frame
that
stage
in
terms
of
like
I
work
with
my
team
to
align
with
our
security
standards.
A
Yes,
yeah.
That's
a
really
great
point,
that's
something
that
I
definitely
missed
like
noting
here
that,
even
though,
like
the
executor,
especially
in
the
context
of
the.
C
A
State,
it's
it's,
it
might
be
the
developer,
but
the
job
that
the
job,
the
the
user,
who
the
job
should
target,
might
be
someone
totally
different.
The
compliance
manager
or
the
release
manager
or
whoever
who
is.
A
So
one
thing
that
I
saw
in
the
video
today
in
a
one
of
the
videos
that
I
was
watching
is
so
there
the
person
talked
about
that,
let's
say
you're
working
for
a
b2b
company
and
you
have
a
buyer,
but
the
buyer
is
not
your
user.
A
The
buyer
is
like,
of
course,
purchasing
from
you,
but
you
should
never
like
build
the
persona,
build
the
jobs
to
be
done
targeting
the
buyer,
because
it
has
to
be
about
the
user
what
the
user
is
trying
to
accomplish.
So,
even
though
we
are
not
talking
about
the
buyer
here,
but
in
terms
of
who,
the
jobs
to
be
done
should
target,
like
the
end
user
of
that,
I
think
in
this
case
it's
different
set
of
people.
A
State
sex,
yes,
so,
like
I
had
mentioned
that
from
state
sex,
different
kind
of
personals
would
have
different
expectations
here.
C
A
A
Okay
yeah,
but
should
it
matter
like
who's
the
most
hands-on?
Should
it
matter
like
whose
concern
is
this
a
particular
stage
attending
to
well.
C
I
I
think
that's
why
the
jobs
to
be
done.
At
least
this
is
the
paint
this
is
the
like
handbook
page
with
jackie's
video
that
like
I
can
understand
it
so
because
the
job
can
be
anybody
that
does
it,
but
eventually
the
persona
when
it
becomes
a
jobs
to
be
done.
The
persona
steps
in
because
it
says
in
this
handbook
page
says
job
deploy
and
build
and
deploy
software
and
then
job
performer
is
an
element
of
jobs
to
be
done,
and
that
brings
in
the
persona
which
is
part
of
the
circumstance.
A
Yeah,
I
think,
thinking
in
the
constraint
only
thinking
in
the
constraint
of
the
executor
personas
that
we
shortlisted
at
the
beginning.
I
think
that's
the
wrong
approach,
that
kind
of
limits
in
some
way
like
how
we
are
defining
the
jobs
to
be
done,
and
it
might
not
be,
though,
because
a
developer
would
never
be
too
concerned
about
the
compliance
standards
or
the
security
standards.
It
would
always
be
somebody
else,
but
if
I
only
think
of
like
what
the
developer
is
trying
to
achieve
here,
I
might
get
things
wrong.
C
C
A
Yeah
yeah
and
then
I
did
this
small
exercise
of
privatization.
At
this
point
I
couldn't
tell
like
what
the
colors
denote,
because
I
was
smart
enough
not
to
make
an
index
for
that,
but
yeah.
We
we
had
a
synchronous
session
b
and
the
pm,
and
we
talked
about
like
which
are
the
most
important
and
most
important
personas,
but
least
satisfied.
So
we
mark
them
as
opportunities
for
our
self
like
this
is
the
area
where
we
should
be
thinking
of
making
improvements
in
our
future
plans
for
categories.
C
C
C
A
That's
where
the
elevation
and
the
granularity
that
mapping
comes
into
picture,
so
we
can
like,
if
we
map
map
it
as
a
reverse
triangle,
then
what
you're
saying
that
can
totally
be
the
core
jobs
to
be
done,
which
is
at
the
highest
level
and
then,
when
we
try
to
like
break
it
further,
it
would
be
it
would
cover
the
flow.
C
C
A
A
note
from
the
one
job
workflow,
the
one
that
you
mentioned
about
the
one
that
you
had
framed
yeah
yeah.
That
can
be
so
in.
In
my
case,
I
had
something
for
the
core
job
in
like
for
the
new
mapping.
What
you
mentioned
could
be
our
core
job.
C
I
think
so
yeah
the
top
of
the
triangle
one
or
the
funnel,
and
then
I
think,
because
what
our
main
research
goal
can
be,
or
where
I
mean
research
question
can
be
would
be
to
figure
out.
Where
did
I
write
it?
I
wrote
it.
C
C
We
could
even
like
have.
We
could
even
have
these
stages
here
and
then
say
like
walk
us
through
your
process
with
these
stages
like,
ideally,
they
would
show
us
in
the
tool,
but
they
are
sometimes
not
what
they
don't
want
to
do
that.
So
we
could
just
put
this
in
a
deck
and
then
have
them
talk
through.
C
A
Sounds
good
yeah.
It
could
be
critical,
though
yeah,
because
my
current
plan
was
kind
of
to
create
the
initial
mapping
by
myself
and
then
go
to
validation,
but
this
is
so
much
better
because
we
won't
have
to
like
take
a
u-turn
at
any
part
of
the
process.
A
C
C
The
stages
involved
in
pipelines
to
see
where
our
users.
B
C
Do
you
think
they'll
recognize
these
parts,
or
it
doesn't
matter?
We
can
even
just
say
we
can
even
just
say
this
is
how
we're
defining
this
isn't
in
define.
Locate,
prepare
confirm.
Is
that
coming
from
us
in
any
way,
or
that's.
A
Not
coming
from
us,
that's
actually
coming
from
the
jobs
dividend
template
so
if
you
think
like
changing
this
to
and
even
combining
a
few
stages
would
help,
which
I
think
would
help.
For
example,
I
don't
see
like
very
clear
differentiation
between
prepare
and
confirm
here,
it's
kind
of
so
maybe.
C
A
C
B
C
Like
what
I
end
up
doing,
I
I'll
show
you
one
of
these
sessions,
but
what
I
end
up
doing
is
like
just
like
making
shapes
with
them
and
like
having
them
talk
about
it
like.
So
what
we're
doing
right
now
with
the
the
secrets
life
cycle
is
just
to
be
like
tell
me
about
a
secret.
What's
the
beginning,
what's
the
middle
what's
the
end,
and
then
they
kind
of
articulate
it
there,
but
in
that
one
we're
like
who
what
where
when,
but
I
think
in
this
one
we
would
just
be
like.
C
A
So
keeping
it
open-ended
but
kind
of
nudging
them
to
define
the
stages
themselves.
C
What
is
it,
what
do
we?
How
do
we
say
it?
How
do
you
from
your
perspective,
what
are
the
stages
of
a
pipeline
of
pipeline
execution
of
pipeline.
C
C
C
Idea,
I
think
we
want
to
step
back,
tell
us
how
your
team,
especially
if
you
have
the
bandwidth,
tell
us
how
your
teams
are
breaking
up
the
process
of
verifying
your
code.
C
Yeah
because
they're
in
this
flow
too
right,
yeah,
yeah,
okay
at
some
point
we'll
need
to
put
where
is,
can
we
do
it
now
really
quickly?
It
will
help
my
brain,
which
stages
is
gina,
doing.
A
Pipeline
insights
and
runner,
but
in
this
I
like
these
stages-
oh
okay,
all
right,
I
thought
stage
groups,
that's
what
was
going
on
in
my
mind,
so
here
we
go.
Maybe
we.
A
Execute
execute
is
where
both
the
stage
groups
that
gina
is
working
with
would
very
well
fit
and
sorry
the
pipeline
insights
can
be
more
about
monitor.
I
guess
stage.
Six
yes
and
runner
is,
of
course
execute
because
when
the
jobs
are
being
executed,
that's
when
the
role
of
runner
kicks
in
okay.