►
From YouTube: UX Showcase Package Validate JTBD
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
I
am
really
excited
to
share
with
everyone.
Today,
one
of
the
initiatives
we've
been
working
on
on
the
package
stage.
We
have
lots
of
great
stuff
going
on
we've
got
container
registry
UI
is
getting
some
updates.
We
have
a
whole
new
feature
set
being
built
for
the
dependency
proxy,
but
I
wanted
to
take
a
moment
and
take
a
step
back
and
discuss
jobs
to
be
done
and
I
know.
A
lot
of
us
designers
here
at
Ghaleb
have
heard
calls
to
be
done.
We
deal
with
them
a
lot.
They
really
are
the
structure
and
infrastructure.
A
We
need
to
measure
the
success
of
our
different
stages.
I'm
really
excited
because
Sam
and
I
the
product
manager
on
package
has
gone
through
the
process
of
validating
our
jobs,
to
be
done
with
our
users
and
a
few
different
designers
and
other
colleagues
as
well
have
come
to
us
asking
how
we
went
about
this.
So
I
thought
this
was
a
perfect
Avenue
for
us
to
kind
of
have
that
conversation
for
backgrounds,
package
stage.
We
deal
with
packages
and
the
container
registry
and
a
few
other
things.
What
we
do
is
we
store,
bundled
up.
A
A
The
goal
of
this
initiative,
we
had
a
business
goal
when
we
tried
to
validate
the
jobs
to
be
done,
which
was
to
really
understand
at
a
high
level
the
primary
areas
of
focus
regarding
package
and
images,
registries
to
prioritize
and
deliver
competitive
features
to
our
customers
and
from
a
user
goal.
I
get
to
be
selfish
in
this
presentation,
where
I
am
the
primary
user
of
this
work
that
we're
doing
as
well
as
Tim
and
the
rest
of
the
team,
and
it's
always
nice
to
be
selfish,
because
it's
exactly
what
I
wanted.
A
How
we
made
our
jobs
to
be
done,
the
question
that
everyone
seems
to
be
having
right
now.
The
first
iteration
was
just
a
brain
dump
and
there
is
no
hiding
it.
Tim
and
I
the
product
manager
had
done
a
few
different
rounds
of
research,
including
a
survey
two
rounds
of
interviews
and
just
kind
of
regular
customer
chats
and
as
the
scorecard
process
started
getting
evolved
and
put
in
front
of
us.
We
wanted
to
take
a
moment
to
just
write
down
everything
we
could
think
of.
That
could
be
a
job
to
be
done.
A
A
The
users
need
to
pay
attention
to
and
then
subsequently
had
job
stories
underneath
it
which
were
closer
to
a
task
so
a
thing,
a
user
needed
to
complete,
but
not
necessarily
the
reason
they
would
buy
package
to
different
scales.
We
were
trying
to
work
with,
as
I
mentioned,
we
brought
the
full
package
engineering
team
in
we
asked
them.
Did
we
miss
anything,
and
we
just
wanted
them
to
add
anything
that
they
thought
was
missing
directly.
We
also
gave
them
an
opportunity
to
add
comments
and
ask
questions.
We
have
some
great
discussions
happen
from
there.
A
Lastly,
part
of
the
reason
we
use
the
jobs
to
be
done
in
the
job
task
list
to
help
us
prioritize
and
understand
what
is
important
for
our
users.
So
we
asked
the
engineers
who
are
also
users
of
the
package
registry
to
just
pick
the
three
most
important
ones
and
vote
for
them
similar
to
a
red
dot,
but
with
Google
Docs
a
little
different,
so
we
were
able
to
walk
away
with
little
more
structured
jobs.
We
done
with
engineers
insight
businesses
an
engineer's
tool
as
well
as
some
level
of
prioritization.
A
A
We
weren't
D
prioritizing
something
important
or
prioritizing
something
they
didn't
matter.
Things
like
that.
The
way
we
went
about
this
is
we
partnered
with
Laurie
and
Emily.
Both
of
them
have
done
incredible
jobs,
helping
us
be
successful
and
we
asked
our
users
through
a
survey
to
do
a
couple
of
different
activities.
One
was
to
stack
rank
the
list
of
jobs
to
be
done.
There
were
six
for
the
package
team
in
order
of
importance
or
relevance
to
their
day-to-day
work.
A
We
asked
them,
then,
to
evaluate
the
each
individual
job
to
be
done,
trying
to
use
a
little
bit
more
common
language
of
the
maturity
ratings.
So
this
is
something
that
hasn't
been
implemented.
This
is
something
that
you
know
barely
works.
This
is
something
that
is
a
viable
solution
for
us.
This
is
great.
As
Lobel
we
tried
to
offer
up
more
human
language
for
that
and
then
for
each
job
to
be
done.
A
There
were
subsequent
tasks
and
we
asked
them
to
rate
how
important
each
task
was
to
them
in
terms
of
their
ability
to
work
in
their
job.
This
is
how
that's
directly
impacting
them
very
last
question.
We
asked
this
we've.
Given
you
a
job
to
be
done
and
every
task
we
could
think
of
that
relates
to
this
job.
To
be
done.
Did
we
miss
anything?
A
We
took
this
survey
and
we
rolled
it
out
to
two
different
groups.
The
first
group
was
an
internal
group.
These
individuals
had
the
full
survey,
so
they
went
through
every
job
to
be
done
and
all
of
the
tests,
which
was
a
mighty
effort
and
I,
really
appreciate
everything
they
did
and
we
partnered
with
anyone
who
works
with
package
in
any
capacity.
Specifically,
we
reached
out
to
support
and
the
sales
team.
A
Those
are
the
two
groups
that
hear
from
our
users,
often
about
areas
that
are
important
where
they're
looking
for
where
they
need
extra
help
and
support.
So
it
was
really
great
to
get
that
insight.
We
had
a
second
rollout
of
this
survey
and
this
was
the
more
public
version
or
an
external
version.
This
one
was
almost
the
same,
except
instead
of
asking
them
to
go
through
all
six
jobs
to
be
done.
We
asked
them
to
go
through
two
jobs
to
be
done,
that
they
ranked
is
most
important.
A
The
reason
we
went
about
this
as
anyone
who's
done,
a
survey
might
know
the
longer
they
get
the
more
incomplete
your
survey
results
become
and
getting
those
complete
surveys.
All
the
way
done,
takes
a
lot
of
work
and
effort.
Dropping
this
down
so
only
having
to
do
two
of
them
made
it
easier
to
get
more
results
and
the
results
we
get
were
going
to
be
the
jobs
and
job
stories
that
were
more
important
to
them,
so
that
data
is
more
valuable
anyway.
A
The
results,
sixty-eight
people
in
total,
participated
in
both
the
surveys,
54
of
them
or
external.
The
remainder
were
our
internal
users.
We
were
able
to
generate
eight
unique
user
research
insights
based
on
the
things
that
we
found,
including
the
staff
ranked
orders
of
the
jobs
to
be
done,
so
we
now
have
a
validated
idea
of
the
most
important
job
versus
the
next
most
important
than
you
know.
Lastly,
the
least
important:
we
really
understand
how
our
users
feel
about
that.
A
We
got
feedback
on
the
individual
tasks
in
terms
of
how
important
they
are
or
on
important
important.
And
lastly,
we
kind
of
got
an
overall
view
of
how
package
is
doing
from
their
perspective.
We
were
able
to
get.
They
thought
it
was
around
viable
the
results,
the
question
weren't
really
solid,
so
a
lot
of
the
percentages
were
close
together.
A
This
is
a
bit
of
an
average,
but
it's
nice
that
we,
we
recently
changed
that,
and
so
we
do
have
some
validation
that
that
users
are
feeling
we
definitely
need
to
go
through
the
full
maturity
process,
but
it's
nice
to
get
a
little
piece
of
data.
The
biggest
thing
that
we
walked
away
with
in
terms
of
actionable
things
is
we're
confident
in
our
priorities,
our
strategy
and
how
we're
measuring
success
and
maturity
for
the
packaged
stage.
We
have
insight
into
what
is
most
important.
What
needs
to
be
evaluated
from
the
UX
perspective?
A
What
should
weigh
more
heavily
what
priorities
are
going
to
come
from
where,
as
we
all
work
in
strategy
and
we
partner
with
our
PMS
having
this
perspective,
is
really
really
powerful
for
Tim
and
I
was
a
really
great
experience,
because
the
results
of
the
survey
really
lined
up
with
what
we
had
heard
from
our
users
and
how
we
were
acting.
So
we
also
got
validation
that
the
work
that
we
were
prioritizing
was
what
was
most
important.
A
We
also
learned
some
additional
insights,
which
we
didn't
know
which
happens
at
every
researching,
is
kind
of
the
exciting
part.
One
of
them
is
that
we
walked
in
with
the
assumption
that
users
different
types
of
users
had
different
priorities.
An
engineer
cared
about
being
able
to
push
and
pull
a
package,
whereas
a
DevOps
manager
may
be
more
interested
in
managing
registries
on
a
higher
level.
After
we
got
the
results
back,
there
wasn't
any
difference
between
the
user
segments.
They
were
all
actually
the
same.
A
So
even
if
you
were
a
DevOps
manager
and
theoretically
not
pushing
as
many
packages,
they
still
ranked
the
ability
to
push
a
package
as
the
most
important
thing.
As
an
example,
so
that
was
pretty
cool,
then
we
don't
have
to
think
about
all
the
different
user
segments
as
hard
as
some
other
areas
of
the
product
that
there's
big
difference.
A
Our
next
steps,
we
are
going
to
add
a
dedicated
page
to
the
handbook.
That's
the
package
jobs
to
be
done
I.
This
is
a
real-time
event
which
is
really
exciting,
because
yesterday,
when
I
put
this
together,
it
was
it
to
do
and
then
last
night
Tim
did
it.
So
it
is
now
in
progress.
Getting
live
updates
as
we
go.
The
idea
is
that
I'd
like
to
show
the
six
primary
jobs
to
be
done
in
order
of
importance
and
then
under
each
job
to
be
done.
A
Show
those
job
stories
show
the
maturity
or
score
that
we
have.
The
confidence
we
have
of
a
net
score
was
a
based
on
research.
Was
it
based
on
our
evaluation,
etc
and,
as
the
scorecard
start
coming
out
a
link
directly
to
the
scorecard
that
tells
us
what
the
score
is
for
the
job
for
the
job
to
be
done,
which
is
a
long
sentence
but
very,
very
powerful
along
those
same
lines.
A
The
next
step
for
us
in
these
jobs
to
be
done
is
to
internally
review
all
the
jobs
and
see
how
we're
doing,
based
on
the
order
of
priority
and
help
us
kind
of
focus
on
areas
that
we
could
improve
and
to
start
the
UX
scorecard
process
with
what
we
now
know
is
the
most
important
job
to
be
done
and
that
jobs
to
be
the
most
important
job.
So
that
really
helped
us
understand
what
our
next
goals
needs
to
be.
A
Thank
you.
Everyone
I
know
that
was
a
little
quick,
but
I
hope
that
helps
a
lot
of
people
have
again.
It
comes
to
me
with
a
question
around
this
special
thanks
to
Tim,
of
course,
and
Laurie,
and
really
really
big
props
to
Emily.
We
were
doing
this
survey
right
when
the
world
kind
of
turned
upside
down
and
Emily
went
above
and
beyond,
making
sure
she
was
reminding
people
to
fill
it
out,
asking
people
to
try
again
all
kinds
of
stuff,
so
the
success
of
this
was
really
because
of
her
feel
free
to
reach
out.