►
From YouTube: UX Showcase - Why did we revise the JTBDs in Pipeline Execution team and how we did it?
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,
hello,
everyone
and
today
I
am
going
to
talk
about
why
we
recently
Revisited
and
revised
the
jobs
to
be
done
in
pipeline
execution
and
the
process
that
we,
the
approach
that
we
took
to
do
it
so
I
mean
it's
not
an
ideal
practice
to
keep
on
changing
the
jobs
to
be
done.
That
is
there
for
the
stage
groups,
because
jobs
are
supposed
to
be
timeless,
I
mean
they
are
Timeless.
A
If
the
job
that
we
we
keep
the
job
at
the
center
of
everything
that
we
do
in
a
Stage
Group.
So
in
case
we
are
like
changing
them.
Often
it's
not
a
good
practice,
because
that
also
means
that
the
focus
of
the
Stage
Group
is
kind
of
I
mean
it's
not
stable.
So
keeping
all
of
those
concerns
in
mind
like
what
made
us
take
that
decision
to
go
and
revise
the
jobs
to
be
done
is
what
I'll
be
talking
about
today.
A
So
let's
get
started
all
right.
So
when
I
started
two
years
back
as
a
product
designer
in
and
get
lab,
the
state
group
that
I
was
working
with
was
continuous
integration
and
there
were
a
bunch
of
categories
within
that,
namely
artifacts
rules,
variables,
moisture
and
secrets.
Now,
in
this
span
of
two
years,
A
lot
has
happened.
The
state
group,
as
is,
doesn't
exist.
It
was
broken
down
into
pipeline
execution
and
Pipeline
authoring,
and
not
just
that.
A
There
are
many
categories
that
were
taken
out
and
many
that
were
added
to
the
Stage
Group
pipen
execution.
You
can
show
like
what
the
status
quo
is
like.
So
today
we
have
these
three
categories:
continuous
integration,
that
is
integration,
scaling
and
mood
strains
now.
Continuous
integration
scaling
is
something
that
has
been
very
newly
added
like
some
few
quarters
back,
and
that
was
done
because
we
realized
that
there
was
the
number
of
bills
that
we
were
processing.
It
was
kind
of
increasing
exponentially.
A
So
what
is
it
that
we
need
to
do
on
the
back
inside
to
be
more
prepared
for
the
challenges
that
had
to
come
now?
This
is
just
to
kind
of
give
an
idea
about
like
how
much
has
changed
and
how
much
has
evolved
in
this
time
span
and
that
has
not
just
affected
the
number
of
categories
within
verify
piping
execution,
but
also
the
vision,
the
mission
and
the
plan
that
we
laid
out
the
maturity
plan
that
we
laid
out
so
keeping
all
of
those
things
in
mind.
A
We
thought
that
yeah
so
adopt
to
be
done
is
composed
of
job
performer.
That's
full,
then
job
the
process
and
then
the
need-
and
in
this
one
I
felt
that
I
had
a
different
understanding
of
the
process
and
the
need.
Now
the
jobs
might
not
change,
but
the
person
who
has
been
documenting
and
kind
of
driving
or
arriving
at
the
jobs
to
be
done.
A
The
understanding
changes,
and
that
also
calls
for
re-looking
at
what
was
done
before
what
was
documented
before
and
that's
why
we
thought
of
taking
forward
this
exercise
of
like
redoing.
This
whole
process
of
understanding
like
what
are
the
core
jobs
that
pipeline
execution
as
a
Stage
Group,
should
be
looking
at
now.
What
do
we
use?
A
Jdbs
for
them,
just
like
any
other
state
group
and
the
and
what
we
have
documented
here
in
the
handbook,
we
use
it
to
define
the
scope
of
our
work
like
the
field
of
vision
like
what
is
it
that
we'd
be
looking
at
then
for
identifying
competitors
now.
This
has
been
really
helpful
in
this
specific
thing.
A
For
me,
at
least
because
when
you
have
the
jobs
to
be
done
right,
you
understand
competitors
better,
because,
usually
how
we
look
for
competitors
is,
we
try
to
see
like
which
of
the
other
products
like
are
providing
a
very
similar
solution
than
like
that
we
are,
but
that's
not
necessarily
that
we
should
be
looking
at.
We
should
be
looking
at
that.
If
this
is
the
job
that
our
product
is
helping
to
get
done,
then
how
are
the
other
products
doing
it?
A
Are
they
doing
in
the
same
way
or
that
or
in
any
different
ways?
So
we
often
completely
ignore
the
indirect
competitors,
if
we
don't
have
the
jtvd
right,
so
to
make
sure
that
we
are
like
thinking
about
the
indirect
competitors
correctly.
It's
also
important
to
like
look
at
your
jtvd.
If
that's
in
place-
and
it
helps
in
definitely
assessing
the
maturity
of
the
categories-
help
decide
at
what
level
do
we
want
to
innovate
here?
A
If
we
keep
it
very
like
if
we
go
too
granular
and
focus
on
a
feature
and
avoid
it
like
very
specific
to
a
feature
that
means
we
are,
we
kind
of
have
decided
that
we
are
not
going
to
be
moving
a
level
up
and
looking
at
things
from
a
more
broader
perspective,
so
always
making
sure
that
they
are
well
elevated
and
then
that
we
kind
of
leave
enough
room
for
innovating.
When
it
comes
to
the
solution,
then
we
also
had
our
maturity
plan
in
place.
A
A
All
right,
then
yeah
then
comes
to
part
like
how
did
we
do
it?
How
did
we
make
it
happen?
So
this
time
some
learnings
that
I
had
from
before
was
that
I
mean
we
had
some
knowledge
about
what
users
are
coming
to
the
Stage
Group.
The
features
related
to
this
stage
group
to
perform
and
key
like
taking
all
of
those
existing
knowledge.
A
So
taking
that
as
the
main
job
we
arrived
at
a
hypothesis,
and
we
kind
of
then
used
that
hypothesis
to
come
up
with
a
whole
set
of
questions
that
and
you
could
go
and
like
look
at
all
the
questions
here
in
the
docile
project,
I'm
not
going
to
open
that
because
that
might
reveal
the
identities
for
some
interviewees.
So
that's
we
did
that
as
the
basis
of
arriving
at
this
whole
list
of
questions,
but
then,
when
it
came
to
actually
executing
all
of
those,
we
took
a
very
different
approach.
A
A
So
it
wasn't
just
me
like
asking
questions
and
taking
notes
all
by
myself
and
then
cutting
kind
of
putting
my
own
interpretation
in
in
the
research
analysis,
but
rather
doing
it
together
with
the
interviewee,
so
Erica
suggested
that
we
use
these
bars
to
kind
of
like
ask
questions
such
such
as
like,
in
which
industry
do
you
see
your
work
fitting
in
and
then
just
place
the
bar?
So
a
lot
of
visual
indicators
there
and
the
questions
were
also
laid
out
very
clearly
and
in
a
very
different
way.
A
But
there
was
one
part
of
the
whole
exercise
that
I
thought
was
the
most
helpful
and
which
is
this
section
where
we
followed
the
same
process
as
what's
mentioned
in
our
handbook
section.
That
says
how
to
create
a
job
map
like
we
do
have
to
think
of
different
stages,
and
the
purpose
of
selecting
these
different
stages
is
to
make
sure
that
we
are
covering
the
before,
during
and
after
of
the
whole
like
of
the
sequence
of
jobs,
so
that
there's
no
context,
that's
missing.
A
So
keeping
that
in
mind
I
mean
this
is
not
something
that
we
came
up
with
in
the
first
goal.
We
ran
a
couple
pilots
and
then
refined
this,
of
course,
but
we
gave
them
like
a
blank
screen
with
just
these
headers
and
sort
of
like
a
more
abstract
sort
of
explanation
for
each
of
the
stage
so
that
they
could
interpret
it
in
a
more
broader
way
and
not
like
get
too
specific.
The
discussion
shouldn't
get
too
specific.
A
Because
that
means
when,
when
we're
interviewing
non-kitlab
users,
we
are,
and
we
are
also
finding
opportunities.
That
means
those
are
the
areas
where
even
our
competitors
are
not
currently
I,
wouldn't
say,
not
innovating,
but
at
least
they
don't
have
something
so
solid
out
there,
yet
so
identifying
those
opportunities.
Through
these
interview
sessions
that
we
did
The
Next
Step
was,
of
course,
going
to
dovetail
documenting
everything.
A
There
then,
going
to
mural
kind
of
doing
an
exercise
to
analyze
like
put
everything
together,
then
see
like
how
this
can
be
translated
or
how
this
can
be
just
still
into
a
single
job
and
then
converting
them
into
statement
and
then,
finally,
of
course,
creating
a
merge
request
to
get
things
merged.
Now
what
I
have
out?
There
might
not
be
very
perfect
at
this
moment,
but
I
think
using
this
process.
We
made
sure
that
what
we
are
like
the
kind
of
information
that
we
are
putting
out
there
is
more
solid.
A
So
there
was
this
statement
that
I
came
across
somewhere
in
the
handbook.
That
said,
it
is
crucial
to
ensure
that
the
job
statements
are
grounded
in
experience
and
not
Theory,
and
we
must
have
a
high
level
of
confidence
in
our
job
statements
before
we
can
put
them
into
use.
So
this
was
what
kind
of
pushed
me
into
taking
a
different
approach.
This
particular
time
and
yeah
I
would
love
to
hear
some
feedback,
but
also
I
have
some
opening
questions.
Still
so
I
mentioned
about
those
stage.
A
Groups
I
mean
the
categories
that
we
have
in
Python
execution
group
today.
So
there's
this
one
category
that
we
call
as
non
non-marketable
category
because
it
kind
of
is
preparing
our
product
to
tackle
problems
that
would
come
with
like
processing
a
very
high
number
of
bills
or
when
what
happens
when
we
have
like
a
huge
number
of
pipelines
running.
So
what
would
they
experience
from
the
back
end?
Would
things
lag?
Would
things
be
delayed
or
would
failures
happen
like
how
to
avoid
all
of
those
situations?
A
Now
a
user
doesn't
think
about
all
of
those,
because
they
think
that
as
a
product,
it's
kind
of
given
that
their
the
team
would
be
working
on
the
stability
availability
and
all
of
those
important
Parts.
But
since
this
is
a
category-
and
we
do
have
to
think
about
the
maturity,
it
gets
kind
of
challenging
like
how
do
we
document
the
jdbd
for
that
kind
of
relates
to
these
categories?
So,
for
now
we
have
what
we
have
put
out.