►
From YouTube: Why Release Management uses Jobs to Be Done
A
Hi,
my
name
is
jackie:
I'm
a
senior
product
manager
over
release
management
here
at
get
lab,
and
I
wanted
to
take
a
couple
of
minutes
to
talk
a
little
bit
about
jobs
to
be
done
and
how
it
helps
me
as
a
product
manager
prioritize
and
look
at
the
maturity
of
my
product
line.
So
I'm
going
to
go
ahead
and
share
my
screen
and
introduce
the
jobs
to
be
done
and
what
they
are
for
release
management,
so
jobs
to
be
done
help
you
understand
what
your
users
are
hoping
to
accomplish
inside
your
platform.
A
They
also
allow
you
to
look
at
something
generically
without
thinking
about
how
a
particular
product
or
solution
addresses
that
need.
This
allows
you
to
holistically
consider
the
user's
experience,
desires,
wants
and
drive
a
solution
to
their
problem
that
will
encourage
their
adoption
and
usage
of
your
product.
A
Some
of
the
challenges
that
release
management
is
focusing
on
right
now
is
about
addressing
all
different
types
of
release:
managers
in
gitlab,
which
includes
technical,
build
managers,
non-technical
release,
managers
that
are
responsible
for
coordinating
across
multiple
teams
of
varying
technical
experiences
that
may
or
may
not
be
using
git
lab
as
a
single
source
of
truth
for
the
deployment
of
their
product
and
also
understanding
the
project
managers.
That
would
be
coordinating
different
aspects
of
a
release
within
that
umbrella
of
release
management.
A
We
also
need
to
target
non-cloud
native
deployments
and
allowing
users
to
effectively
track
and
execute
deployments
and
releases
without
being
a
kubernetes
first
organization,
so
the
job
to
be
done
that
I'll
focus
on
here
is
about
creating
a
release
and
updating
it.
So
the
job
to
be
done
is
when
I'm
ready
to
deploy
a
change.
I
want
to
deploy
to
protection
state
for
customer
consumption,
so
I
can
get
adoption
of
the
product
released.
That
is
the
generic
statement
that
users
are
trying
to
accomplish
when
they
use
release
functionality
inside
of
gitlab.
A
We
look
at
a
job
statement.
This
is
the
specific
task
or
outcome
that
a
user
is
looking
to
do,
and
I
have
the
first
one
here
when
tracking
important
deliverables
in
my
project.
I
want
to
easily
create
and
manage
all
related
information
for
a
software
release,
so
I
can
provide
package
software
notes
and
files
for
people
to
use
this
job
to
be
done
has
nothing
to
do
with
gitlab.
A
By
focusing
on
this
job
to
be
done,
we
were
then
able
to
define
what
would
make
the
releases
page
viable.
What
are
all
the
different
pieces
that
would
allow
a
user
to
effectively
coordinate
an
orchestrated
deployment
to
create
that
software
bundle,
as
well
as
release,
notes
and
files
related
to
that
bundle.
A
So
we
were
able
to
very
quickly
identify
and
knock
out.
Some
quick
wins
like
allowing
guest
access,
adding
notifications,
adding
a
button
to
edit
a
release
in
the
ui
adding
asset
links.
We
also
were
able
to
identify
that
users
really
want
to
be
able
to
support
file
uploading
to
releases.
So
this
is
the
last
component
of
the
release,
page
completion
being
able
to
upload
a
release
asset
to
an
actual
release,
object
so
that
people
can
effectively
download
and
distribute
that
deployment.
A
That
last
piece
will
allow
users
to
effectively
adopt
release
management,
and
then
they
can
begin
to
leverage
the
other
benefits
of
our
stage,
including
issue
progress,
summaries.
The
release,
progress
view
could
then
link
back
to
a
run
book
and
having
the
release
page,
be
the
single
source
of
truth
for
your
release.
Object
this
issue
right
here,
of
making
it
possible
to
edit
a
release
using
the
ui
was
what
introduced
a
release
page
to
to
users,
and
this
was
a
really.
A
This
is
what
we
basically
graded
as
a
part
of
that
f
effort
and
now
we're
layering
a
bunch
of
new
functionality
in
the
releases
page,
and
when
we
look
at
the
existing
releases
offering
today,
you
have
the
option
to
create
a
release
from
this
button.
You
can
add
different
links
to
the
release
post,
you're
able
to
edit
and
add
asset
types,
which
is
a
really
great
benefit
for
for
users
who
are
looking
to
connect
and
integrate
their
end-to-end
plan
with
delivery
inside
of
gitlab.