►
From YouTube: Runner PM/UX Meeting - 2020-02-03
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
Yeah-
I
just
added
here
sorry
about
that.
That
means
I
mean
okay,
cool
yeah,
first
one.
I
just
wanted
to
give
you
an
update
on
my
availability
and
on
my
entering
position
as
product
design
manager.
So
I
learned
this
week
that
we
are
still
not
hiring
someone
this
month.
So
there
was
a
timeline.
A
We
were
expecting
to
have
a
new
product
design
manager
by
february,
so
I'm,
but
I'm
going
to
continue
until
well,
hopefully
end
of
this
month
or
through
march,
as
we
are
looking
for
the
design
manager
to
backfill
the
position.
That's
going
to
be
open
once
mike
long
joins
the
cicd
team
as
a
product
site
manager.
So
I'll
just
update
on
that
and
then
I'm
still
split.
So
not
a
hundred
percent
focus
on
testing
runner.
B
A
Yeah
and
then
I
open
here
and
align
this
I'm
looking
at
the
workflow
design,
verify
testing
runner,
so
maybe
I'll
share
my
screen
just
so.
You
know
where
I'm
looking
at.
A
Oops
here,
so
I
think
this
is
the
one.
Yes,
we
still
have
this
one
that
is
in
my
pipeline,
and
I
didn't
look
at
the
last
update.
A
I
was
supposed
to
do
this
last
week
and
then
I
was
out,
but
I
thought
that
there
was
a
discussion
here
from
technical
writers
on
what
the
the
copy
should
look
like,
and
I
don't
think
right
now.
It
changes
a
lot
in
the
scope.
B
A
Align
with
you,
if
I
can
wrap
this
one
up
and
then.
B
B
If
you
had
a
chance
to
circle
back
with
pedro,
I
know
he's
out
for
a
week,
so.
A
A
Yeah,
in
any
case,
I
don't
think
pedro
is
out,
but
he
has
a
limited
availability
at
this
point
I
think
he's
working
50
or
something
like
that.
B
No
pedro
the
developer
who's
working
on
the
back-end
changes.
B
Sorry
because
yeah
we
had
that
conversation
about
just
just
double
checking
now
that
we
kind
of
know
what
the
ui
is
going
to
look
like
for
the
top
for
the
switch
right
just
syncing
back
up
now
in
terms
of
all
the
latest
changes
that
have
happened
in
the
back
end
with
pedro
the
future
fry
the
logic
just
to
make
sure
that
we're
kind
of
all
aligned
before
we
even
you
know,
move
forward
actually
implementing
it.
A
A
All
right,
I'm
gonna,
even
add
his
profile
here:
okay,
cool
I'll-
do
that
on
friday,
I'm
looking
at
the
testing
runner.
So
I
have
this
one
and
also
another
issue
from
testing
in
my
backlog.
So
I'll
talk
to
the
backend
pedro
awesome
yeah.
Do
you
want
to
look
into
the
other
items
to
see
if
the
what
we
can
move
above
the
cut
line
from
my
epic
list.
B
A
A
A
No
so
I'll
start
working
once
it
goes
above
the
cut
line.
That's
why
I'm
asking
us
to
have
this
conversation
so
that
we
can
review
it
because,
as
you
can
see,
I
it
takes
like
like
what
one
two
weeks
for
me
to
actively
work
on
these
issues
so
yeah,
it's
a
bit
unrealistic
to
have
like
like
now.
I
have
five
four
or
five
items,
because
I'm
not
going
to
move
forward
with
them.
That's
why
I
say.
A
B
Oh
so,
basically
you're
so
moving
above
the
cut
line
basically
means
that
the
product
manager
is
saying
hey.
This
thing
is
important.
This
thing
should
be
prioritized
to
work
on
okay,
cool.
So
initially
what
I
was
doing,
I
saw
the
cut
line.
I
was
just
like.
Okay,
let
me
just
put
everything
below
the
cup
line,
because
I
was
thinking
the
cut
line
was
like
you're
signaling.
This
is
kind
of
like
my
capacity
for
3.9
and
other
things
you're
going
to
have
to
wait
to
get
into
the
queue,
but,
okay,
that
makes
perfect
sense.
Yeah.
A
Okay-
and
that's
also
another
thing
I
discussed
with
the
with
james-
is
that
these
items-
don't
they
don't
need
to
be
assigned
to
a
specific
milestone.
So,
for
example,
if
we
had
here
something
that
is
need
to
start
looking
to
research-
and
we
have
a
research
item
that
I
need
to-
I
don't
know,
help
you
out
with
the
draft
for
the
questions
or
anything.
It
goes
here.
So
now
everything
is
assigned
39,
but
you
can
just
add
something
or
we
can
be
working
on
something
that
still
needs
to
be
scheduled.
B
B
Okay,
but
since
we're
talking
about
the
the
priorities
before
we
jump
ahead
to
the
agenda
topic
on
on
vitico,
maybe
let's
talk
about
the
item
in
my
bullet
point,
which
is
like
the
enterprise
management
stuff,
because
I
think
it
aligns
better
with
our
discussion
around
the
prioritization
list
in
terms
of
the
cut
line.
So
let
me
share
my
screen
really
fast
and
kind
of
catch
you
up
in
terms
of
some
of
the
things
I've
been
doing.
B
B
Right
so
I'm
just
going
to
kind
of
do
a
quick,
five
minute
or
less
than
five
minute
kind
of
overview,
to
kind
of
give
you
sort
of
a
synchronous
kind
of
update
in
terms
of
like
all
of
this
continents
in
here
and
hopefully
kind
of
show
how
that
flows
into
some
of
the
initial
design
tasks
we've
talked
about
so
as
every
for
everyone's
looking
in
the
video
who
knows
who
hasn't
been
caught
up
in
the
conversations
this
particular
epic,
specifically
around
the
revamp
of
the
management
ui
for
the
runner
and
it's
under
this
broad
category
of
theme
of
enterprise
management,
and
it
ties
into
this
broader
theme
of
enterprise
management,
security
and
ux
right.
B
So
it's
the
initial
placeholder
holder,
epic
4k,
how
we're
going
to
re-work
the
the
ui,
the
gitlab
ui
to
manage,
runs
better,
especially
for
the
for
administrators.
So
what
I've
done
since
we
lashed
at
it
is
cleaning
the
problem
statement
a
little
bit
made
some
more
refinements
to
the
problem
statement.
B
B
This
section
here
is
just
kind
of
sort
of
a
reference
architecture
section
it's
just
basically
describing
for
folks
that
may
not
be
very
familiar
with
the
terms
enterprise
or
scale
just
an
example
of
what
we
mean
when
we
talk
about
enterprise
and
scan
and
then
there's
a
few
examples
of
customers
existing
that
live,
customers
and
kind
of
the
scale
of
their
environment,
so
so
folks
kind
of
trying
to
get
up
to
speed
in
terms
of
what
we're
talking
about.
B
This
is
kind
of
what
that
section
is,
and
then
so
I
know
what
I've
done
since
the
last
time
we've
met,
I
went
ahead
and
created
this
sort
of
like
jobs
to
be
done
back
to
the
requirements
table,
and
hopefully
this
is
again
a
work
in
progress
for
hopefully
a
way
to
simplify
the
aggregation
of
all
of
the
various
requirements
right
either
from
customer
conversations
and
on
calls,
or
you
know,
feedback
and
actual
issues
or
what
have
you.
B
So
this
is
kind
of
just
for
folks
from
kept
trying
to
get
their
heads
around
this.
This
is
like
hey
start
here,
strike
side
reading
through
this
from
a
jobs
to
be
done.
Point
of
view,
so
there's
a
column
for
jobs
to
be
done
and
we're
appropriate.
I
actually
have
a
requirements
column
as
well,
so
I'm
hayanna.
B
So
what
I
did
was
remember
the
last
time
I
spoke
to
you,
I
said:
hey,
let's
pause
and
run
a
registration,
so
it
can
work
right,
and
so
after
looking
at
other-
and
I
said
because
I
wasn't
quite
sure
we
wanted
to
do
that
tactically
versus
having
to
think
about
how
it
fits
within
the
broader.
You
know
strategic
plan
of
reworking
the
the
admin
ui.
So
after
going
through
it,
I
was
like
okay.
You
know
this.
This
is
a
very
important
job
to
be
done.
It's
probably
the
first
one
which
is
response
to
security
incident.
B
You
need
to
find
a
registration
token,
so
I
started
thinking
about
how
this
fits
into
everything
as
a
freedom.
So
I
want
to
just
kind
of
call
it
like
put
this
as
a
first
job
to
be
done.
So
this
is
the
job
to
be
done
table
this
diagram
here
was
just
a
rough
diagram
in
terms
of
us
thinking
about
how
we
implement
this
and
then
a
feature
stable.
It's
going
to
scroll
all
past
all
this
stuff,
so
hayan
in
terms
of
the
iteration
plan.
B
So
here's
what
I'm
proposing
right
now
in
terms
of
the
iteration
plan
and
once
you
kind
of
like
wrap
your
head
around
this,
you
can
certainly
suggest
a
different
approach,
but
this
is
kind
of
what
I
was
thinking
initially
so
through
the
duration
plan.
Knowing
that
we,
the
the
very
one
of
the
sort
of
immediate
action
sort
of
immediate
requirements
that
we
have
to
solve
for
is
how
can
I
quickly
find
a
registration
token
feature?
B
B
So
what
I
could
added
here
was
a
high
level
low
fidelity
markup,
just
at
least
type
of
conversation
right
and
hyena
by
the
way.
You're
very,
are
you
very
familiar
with
what
the
current
enterprise?
What
the
current
view
looks
like
in
the
admin
screen.
A
All
right,
yes,
I
know
how
how
it
looks
like
I.
B
Think
so,
except
for
anybody
else
hopefully,
so
this
is
just
a
suggestion
right
and
they
end
up
being.
We
need
to
and
the
idea
being
this
kind
of
strategic
vision
is.
We
need
to
think
about
how
to
represent
all
of
this
information
in
the
most
elegant
way
possible,
because
we
have
a
lot
of
features
to
add
in
the
future.
B
So
the
first
proposal
is:
let's
rework
to
start
that
table
and
so
how
you
know
what
it
was
just
a
rough
order
markup
and
if
you
notice,
I
added
the
registration
token
column
here
in
the
mock-up,
which
is
the
mvc
for
this
change.
The
other
thing
I
in
this
markup,
which
we'll
get
to
later
on
is
association,
and
this
is
potentially
not
an
mvc
feature
right,
but
it's
a
feature
we
lower
down.
All
this
in
terms
of
you
know
evolving.
That
journey
of
I
can,
I
find
my
runner.
B
Can
I
understand
who
owns
the
run
and
association
so
anyway,
just
as
we're
working
through
some
of
these
things,
you
know.
Maybe
I
went
a
little
bit
too
far
ahead
by
including
association
in
this
markup,
but
I
just
wanted
to
at
least
start
that
conversation
and
thought
process
and
then
the
other
thought
process
I
wanted
to
start
thinking
about
which
I
haven't
particularly
in
in
in
the
document.
Is
this
like
this
columns
concept?
B
Let
me
step
back
like
this
admin.
This
admin
view
right
now,
except
every
column
in
here,
except
for
association
right.
This
is
going
to
be
available
for
any
tier
of
gitlab
right,
so
any
tariff
gets
that
will
open
up
this
new
ad
open.
The
current
admin
view
that's
what
they
get
today.
They
open
up
the
new
reworked
admin
view.
That's
what
they're
going
to
get
any
tf
get
that,
however,
when
we
start
adding
new
features
like
hey
making,
it
very
super
easy
to
see
the
group
association.
B
We
need
to
make
a
decision,
and
right
now,
I'm
leaning
towards
that
kind
of
additional
column
is
not
going
to
be
available
and
I
think
you're
freaked
here
in
your
lower
in
tears,
it's
probably
going
to
be
maybe
premium,
maybe
all
the
way
up
to
ultimate
right
now.
Obviously,
we
need
leadership
to
come
in
and
give
us
guidance
on
that
right
and
if,
if
that's
the
path
we
want
to
go
to
which
it's
like
I'm
thinking
right
now,
that's
potentially
the
path
we
want
to
go
to
do.
B
We
have
an
ability
and
get
that
to
turn
on
and
off
columns
based
on,
like
you
know,
the
tier,
the
user
is
in
right
or
other
customers,
and
so
that's
kind
of
what
I
call
them
concept
here
anyway.
So
I'm
closing
this
off
really
fast.
So
as
I
so
I
propose
the
new
design
and
then
this
ties
in
back
to
to
this
issue
on
your
board.
B
B
Stakes
is
this
table,
but
thinking
about
hey,
if
I
drop
this
new
table
view
in
there
later
on,
we
know
that
we
have
to
add
the
details,
which
is
the
second
iteration
here
right
and
is
it
the
right
approach
to
add
details
like
in
this
low
fidelity
markup,
which
kind
of
for
the
most
part
just
copies?
What
we're
doing
today
but
gives
it
a
different
kind
of
spin
and
polish?
B
Do
we
want
to
continue
with
this
kind
of
approach
where
you
know
you
start
with
the
summary
table,
then
you
click
on
the
runner
and
you
go
into
the
detail
table.
Do
we
want
to
go
with
that
paradigm,
or
do
we
want
to
go
with
a
different
paradigm,
knowing
that,
once
you
see
the
detail
of
the
run
in
the
future,
and
especially
the
customers
and
ultimate
you're,
then
going
to
start
probably
exposing
other
features
or
capabilities,
whether
it's
other
columns,
whether
it's
integrated,
metrics
right?
B
So,
even
though
we
might
design
the
mvc
like
this,
we
have
to
think
about.
Is
that
the
right
approach
when
designing
one?
Let
me
pause
this.
I
just
patted
those
two
for
now
and
what
I've
been
doing
is,
if
you
look
at
the
iteration
time
table
actually
learning
my
pause.
B
It's
basically,
you
can
just
walk
through
each
row
like
create
a
new
embassy
design
for
the
the
the
table,
create
new
msu
design
for
the
detail
right
there
is
this
one
with
recent
job
service
called
then
validating
the
design
with
customers
and
implementing
the
design.
So
I'm
adding
all
those
tasks
in
in
this
sort
of
a
kind
of
like
you
know,
priority
order
in
this
column,
and
then
the
other
task
I
have
to
add,
is
things
like
creating
mvc
design
for
integrating
metrics
or
creating
embassy
design.
B
So
anyway,
let
me
pause
there
and
and
stop
talking
and
give
you
a
chance
to
ask
a
bunch
of
questions.
A
I'm
not
used
to
having
this
in
a
new
microphone
I'll
go
plot.
The
bottom
are
these
jobs
to
be
done
that
you
added
here
also
reflected
on
the
on
the
handbook
or
just
like
documented
somewhere
else,
or
is
it,
as
you
said,
you
on
the
fly,
you're
adding
them
to
to
the
issue
to
the
epic
description,
so
these.
B
Jobs,
the
button
down
aren't
in
the
handbook
right
these
jobs
to
be
done
are
were
created
because,
right
now
the
customers
are
not
expressing
the
requirements
and
jobs
to
be
done
right.
If
you
look
at
all
of
the
the
customer
conversations,
we've
had
or
customer
comments
in
in
the
issues,
the
customers
have
very
specific
requirements
right,
which
is,
let's,
let's
look
at
the
run
registration
token
one
for
a
second.
The
requirement
is
provide
the
requirement
as
written
right
now
in
the
app
with
issue
that
the
customer
opened
was.
I
need
to
find.
B
I
need
to
be
able
to
search
as
an
admin
in
the
gitlab
instance.
I
need
to
be
able
to
quickly
search
and
find
a
registration
token
right.
That's
the
requirement
the
customer
is
very
explicitly
asked
for,
but
since
we're
using
the
jobs
to
be
done,
parliament
here
in
gitlab,
I
thought
it
was
impo
important
to
kind
of
step
back
and
create
a
jobs
to
be
done
frame
so
that
again
giving
us
the
latitude,
which
is
the
whole
purpose
of
jobs,
to
be
done
to
think
differently
about
the
solution.
B
To
answer
your
question:
no,
it's
not
something!
That's
documented
in
the
handbook:
it's
it's
going
to
attempt
to
represent
those
requirements
and
jobs
to
be
done
for
you
as
we're
going
through
these
designs.
We
can
uplift
ourselves
and
kind
of
think
about
if
we're
doing
the
right
thing
in
terms
of
you
know,
solution,
design,
approach
and
so
on.
A
Yeah,
I
understand
yeah,
I
think
here
this
is
also
for
us
something
for
us
to
look
into
later
later
on.
We
actually
created
our
drx
research
folks
created
some
instruction
of
valentine
jobs
to
be
done,
and
I
just
wanted
to
know
if
this
the
statements
that
you
added
to
the
issue
description
are
documented
in
the
runner
javascript
handbook
page.
So
I
think
the
answer
is
know
that
they
live
in
the
epic
description
right.
B
B
A
Yeah,
most
age
groups
have
their
jobs
to
be
done
page,
I'm
gonna
just
add
here.
Let
me
see
release.
A
So
anyways
we
can
definitely
discuss
this
later
on,
but
I
see
the
value
for
us
to
document
this
in
a
handbook
so
that
we
can
always
refer
to
what
is
the
grade
of
the
job
to
be
done?
Have
we
validated
yes
or
not?
What's
the
next
step,
for
you
know,
how
do
you
want
to
iterate,
for
example
like
what
you're
saying
with
the
views,
so
the
first
request
is
user,
just
want
to
see
which
token
belongs
to
each
group
and
then
we're
going
to
grow
this
to
the
the
larger
enterprise
administration?
A
So
how
do
we
break
that
path
into
pretty
much
what
you
already
did
with
that
table
in
the
epic,
the
building
blocks,
but
anyways,
that's
a
science
session,
and
I
love
that
you
already
put
the
prototypes
there.
So
thanks
for
the
proactiveness.
A
And
we
really
need
to
do
the
the
solution,
validation
side
on
that,
and
I
think,
just
by
you
know
this
introduction
and
the
explanation.
I
think
it
would
be
interesting
for
us
to,
of
course
think
about
the
low-hanging
fruits
and
do
like
what
you
already
mocked
up
with
with
the
table
and
some
the
content
that
we
can
do
with
the
nvc.
But
I
think
for
us
would
be
interesting
to
just
do
the
bigger
picture
prototypal.
This
is
the
vision.
A
B
That's
what
I
was
hoping
you
were
going
to
kind
of
land
on
in
terms
of
you
did
we
want
to
go
down
incremental
path,
and
you
know
right
in
terms
of
design
or
to
your
point,
just
kind
of
step
back
and
look
at
the
current
interactions
and
say
hey
if
we're
redesigning
all
of
these
things
with
all
these
jobs
to
be
undermined,
what
it
would
look
like
it's
a
great
point.
A
Yeah
because
I
think
especially
for
I'm,
not
super
familiar
with
the
admin
field,
and
so
that's
going
to
give
me
also
an
opportunity
to
learn
a
little
bit
more
about
the
design
patterns.
But
it's
going
to
spark
a
conversation
on.
I
can
already
predict
that
this
is
what
I'm
going
to
be
discussing
with
designers.
How
do
we
show
data
on
like
tabular
data
on
admin?
A
How
is
the
the
flow
for
going
from
the
overview
to
the
detail
view
if
we
go
to
that
path?
So
that's
gonna
require
alignment
with
other
designers
that
own
some
the
capabilities
at
the
admin
area.
So
just
so
you
know
that's
what
I'm
saying
we're
just
gonna
need
to
mock
this
up
and
put
in
front
of
people
not
just
the
customers.
B
B
Right,
I
completely
agree
with
that
and
that's
kind
of
why,
if
you
see
in
the
iteration
flow,
I
have
at
least
for
the
customer
piece
for
the
small
iterative
design
mock-ups
that
I've
put
in
there
right
now.
I've
clearly
called
out
once
you
have
actually
created
a
design.
We
want
to
at
least
have
the
formal
custom
solution,
validation
with
the
customers
right,
but
I
think
we
should
also
add
that
role
that
you're
talking
about,
because
creating
that
overall
option
design
a
and
then
b
having
that
overall
argument
design
be
validated
internally
as
well.
A
Julio
and
in
terms
of
timelines
without
me,
because
part
of
me
not
part
of
me,
I'm
probably
like
I
want
to
work
on
this,
because
this
is
not
a
fun
challenge.
So,
in
terms
of
timelines
for
this
I
see
that
I'm
kind
of
trying
to
look
at
the
jobs
and,
oh
that's,
a
very
long
issue,
description.
A
Okay,
so
sorry
in
terms
of
timeline
for
us
to
start
at
least
looking
at
the
the
low-hanging
fruits
right
or
the
minor
things
that
we
can
do
right
so.
B
If
you
know,
if
you
don't
mind,
let's
make
sure,
because
I
think
for
folks
that
haven't
seen
that
just
do
it
really
fast
in
terms
of
your
point
earlier
about
the
admin
view,
this
is
the
current
admin
view
right
folks,
when
you
come
in,
if
you're
an
instance
admin
right-
and
this
is
a
you
know-
one
of
the
main
persons
where
we're
retaliating
with
this
kind
of
enterprise
management
view
when
you
come
in
this
is
the
current
dashboard,
ignoring
that
for
a
second
which,
by
the
way
as
hyena
knows,
this
dashboard
should
be
part
of
that
broader
conversation
that
you
just
talked
about
right.
B
The
tactical
thing
we're
talking
about
today
is
when
I
click
the
run
this
view
as
an
admin.
It's
this
thing
right
hasn't
been
touched
in
a
while,
and
search
capabilities
are
limited.
I
can't
find
my
registration
token
and
so
on.
So
in
terms
of
like,
like
you
know
how
quickly
your
next
steps,
I
think,
if
a
I
don't
know
if
you
want
to
create
like
a
specific
design
task
for
the
broader
vision,
so
it's
clearly
called
in
the
design.
Epic
remember
we
should
do
that.
B
Have
that
what's
the
position
when
we
use
here
think
big
section
on
that
right,
that's
maybe
this
with
the
next
two
weeks
and
then
from
there
make
a
firm
decision.
Okay,
we've
had
to
think
big
on
the
broad
on
the
broader
topic
right,
so
we
know
what
the
broader
vision
end
goal
is,
and
so,
let's
now
finalize
the
more
tactical
design
for
the
admin
view.
B
You
know
two
weeks
thereafter,
so
that
gives
us,
let's
say
by
by
late
february,
we
have
a
solid
design
and
then
we
can
solution,
validator
design
with
customers,
bringing
the
front-end
engineers
and
start
like
putting
that
stick
of
the
sound
in
terms
of
when
we
could
potentially
release
the
iterate,
the
first
iteration
and
that's
kind
of
how
I'm
thinking
about
it.
In
terms
of
you
know
getting
it
scheduled
out.
A
A
B
We
should
they
think
we're
talking
about.
I
think
we
should
have
the
thing
big
session
on
the
the
end
version
before
13
10
and
right,
like
you
know,
you
know,
sometime
between
now
and
I
think
fit
the
map.
I
think
the
admin
view
right
should
be
done
by
1310,
so,
whatever
we
have
to
do
up
to
to
get
that,
you
know
like
the
thing
bigs
or
whatever
it
is.
We
want
to
do
other.
B
I
know
we
are
do
we
have
a?
Can
you
go
over
for
one
or
two
minutes
or
do
we
need
to
rap
and
by
the
way
you
made
a
great
point
about
the
bigger
vision
I
just
didn't
want
to
get
ahead
of
my
skis
and
like
trying
to
like
think
about
it,
because
I
think
that's
what
we
had
done
the
first
time
and
it
became
overwhelming.
So
that's
why
I
went
with
a
smaller
view.
This
time
around.
A
But
when
also
when
I
mean
when
I
mentioned
a
bigger
view,
I
think
it's
important
to
look
at
the
the
more
pressing
jobs
to
be
done
right
that
would
have
identified.
So
how
can
you
find
to
review
all
this
content
but,
for
example,
if
you
say
that
jobs
can
be
done,
one
two
four
are
pressing
for
the
nbc
plus.
Let's
say
for
the
you
know
the
rest
of
this
card
or
a
lot
and
then
then
that's
what
the
design
should
reflect
right.
A
We
can,
of
course,
just
do
the
thing
big
and
then
blend
the
the
happy
path
and
the
bigger
picture,
but
I
think
it's
interesting
if
we
keep
ourselves
grounded
on
what
are
the
jobs
that
our
customers,
our
users,
need
to
perform
that
are
going
to
be
reflected
on
the
embassy,
and
what
else
can
we
already
incrementally
try
to
solve
with
the
prototype?
A
B
Yeah
and
I'm
thinking
because
of
what
you
just
said,
it
might
make
sense
to
add
a
column
to
the
drops
we
done
table
here
to
say:
hey,
like
jtb-001,
is
probably
mvc,
because
right
now,
it's
not
necessarily
in
priority
order.
It
was
just
more
of
because
it
was
so
difficult
to
kind
of
like
collapse
all
of
these
requirements
into
something
that
was,
it
was
kind
of
consumable.
B
It's
like
you
know
the
first
one
is
probably
mvc
the
the
registration
token
reset,
which
is
drop
series
on
number
two
is
probably
it's
definitely
not
mvc,
because
that's
a
whole
new
thing
right
number
four
is
probably
like
iteration
mvc,
plus
one
mvc,
plus
two
right,
which
is
like
okay.
Can
you
associate
in
that?
In
whatever
view
it
is
that
we
come
up
with?
B
Can
you
associate
a
runner
with
the
group
or
show
the
association
sorry
we're
running
with
the
group
very
easily,
so
someone
doesn't
have
to
go
from
the
funneling
for
it,
but
yeah.
I
think
that's
a
great
one.
I'll
add
that
column
in
here
and
I'll
also
think
about
your
jobs
to
be
done
handbook
page
and
how
we
can
use
that.
A
Yeah,
so
I'm
going
to
share
my
screen
here,
because
I
think
that
would
be
a
good
exercise
for
us,
also
to
start
reviewing
and
validating
them,
using
the
frameworks
right
and
the
tools
that
the
design
department
and
research
research
group
have
developed
to
validate
everything
that
we
need
to
validate
so
for
reference.
This
is
the
testing
job
to
be
done
page
and
yeah.
A
This
is
pretty
much
what
we
should
be
aiming
at
just
translating
the
high
level
job
the
statements
so
that
we
can
link
them
to
the
maturity
of
this
features,
because
at
some
point
we're
going
to
have
to
validate.
If
I
know
runner
is
a
lotable
so
which
jobs
we
don't
really
want
to
validate
right,
which
statements
and
scenarios
do
we
want
to
put
in
front
of
our
users
and
then
we're
gonna
have
to
use
all
the
design
frameworks.
So
that's
are
gonna
translate
into
the
confidence
and
the
validation
issue.
A
So
soon
we're
gonna
have
a
page
like
this,
where
we
can
just
track
everything
the
same
way
as
everybody
else
does,
because
I
think
this
is
also
gonna
help
us
have
a
more
standardized
conversation
with
with
other
groups
and
also
help
laurie
to
stay
on
track
of
yeah.
What
are
they
doing?.
B
Okay,
I
see
no,
I
see
the
point.
I
think
what
I'm
getting
calm
up
is
definitely
I'll
can
edit
this
table
that
I
think,
there's
already
one
drafted
for
the
runner,
but
if
you
scroll
down
just
a
little
bit
on
this
one,
I
say
just
choose
one
of
those
jobs
to
be
done.
I
think
the
one
thing
to
me
that
we
need
to
be
flexible,
honest,
for
example,
like
for
the
rental
registration
reset,
the
reset
registration,
token
sort
of
like
requirement
or
pain
point
right.
B
Do
we
have
to
do
we
have
to
have
knowing
that
we
already
have
a
long
issue
from
an
in
the
internal
customer
on
project
that
the
technical
account
managers
are
managing
where
the
customer
is
saying
here
is
the
pain,
here's?
What
I
need
to
get
that
to
solve,
knowing
that
we
already
have
that
for
that
particular
feature,
is
it
just
okay
to
say
that
this
has
been
validated
here?
Is
the
link
to
the
customer
telling
us
what
the
problem
is
right?
B
A
Yeah,
so
that's
the
difference
right
so
you're
talking
about
validating
the
maturity.
That's
next
step.
You
already
know
that
it's
a
problem.
You
already
know
that
I
don't
know.
10
customers
talked
about
the
same
thing.
You
have
a
level
a
certain
level
of
confidence
on
the
problem
and
the
job
that
we
have
to
solve
for
these
customers.
We're
going
to
build
this
we're
going
to
shift
the
theme,
then
we're
gonna
have
to
evaluate
the
maturity
of
that
feature
at
some
point
for
the
functionality.
A
That's
why
these
things
are
all
linked
here,
because
those
are
different
frameworks
that
we
use
to
so
the
the
there's
a
job
to
be
done.
There's
the
ux
core
card,
there's
the
maturity
score
card
in
a
way
they
all
revolve
around
the
the
customer
problems
that
you
already
know
that
exists,
but
my
point
here
that
it
is
important
also
for
us
to
document
in
a
centralized
place,
because
the
the
epic
description
is
very
long,
and
I
think
this
is
also
going
to
be
a
good
exercise
for
us
to
just
have
an
overview
here
like
okay.
A
A
Yeah
yeah,
so
other
groups,
you
can
actually,
if
you
just
search
here
and
on
the
handbook,
you
can
see
how
other
groups
they
do.
I'm
not
sure
if
monitor
has
them,
let's
see
yeah,
you
see,
they
don't
have
it,
but
they
at
least
know
what
some
things
that
they
should
be
looking
at,
but
anyways.
A
We
can
open
a
merge
request
later
on
and
we
just
throw
them
there.
We
continue,
of
course,
using
the
epic,
but
just
so
that
we
have
one
single
source
of
truth,
and
we
know
that
with
the
issue
descriptions,
it
can
be
a
bit
a
bit
tough
to
to
follow
the
conversation
yeah.
I
see
what
you're
saying.
I
wonder.
B
Yeah,
I
see
the
value
of
having
you
in
the
handbook,
I
think
we'll
definitely
iterate
fast
and
putting
it
in
a
handbook
and
just
for
now
I'll
just
leave
at
least
with
this
epic.
I
will
leave
it
in
this
epic
for
now,
until
we
to
the
point
we're
all
comfortable
that
we
understand
and
how
it
all
fits
together.
Okay,.
A
Sounds
good
and
also,
I
think
it's
a
good
motion.
It's
a
good
exercise
for
me
as
I
go
and
I
start
reading
it.
I
can
try
to
create
a
handbook
page,
and
then
you
know
just
so
that
when
the
information
is
digested,
there
is
a
draft
of
how
this
page
would
look
like
you
don't
have
to
move
by.
B
The
way
as
you
review
this
feel
free
to
refine
my
wording,
because
I
was
really
trying
to
take
the
customer
pain
and
requirements
and
flip
it
into
this
jobs
to
be
done
frame.
So
if
something
is
kind
of
like
oh,
this
could
probably
be
available
differently,
free
free
to
suggest
something
differently
as
well,
but.
A
B
The
admin
yeah.
B
A
But
anyways
for
me,
I'm
gonna
put
my
tasks
so,
but
that's
my
next
big
item
for
runner
and
as
I
work
on
my
priorities
for
next
week,
I'll
try
to
block
a
full
day
next
week
to
look
into
this,
so
that
I
can
digest
this
information.
A
And
before
the
end
of
this
week
I
have
of
next
week.
I
have
at
least
a
draft
or
something
that
I
can
give
an
update.
B
A
Okay,
so
because
we
have
the
runner
talk
with
the
tech
importance,
questions
right.
Well,
that's
the
thing,
I'm
not
sure.
If
I'm
for
the
next
one,
I'm
not
I'm,
not
confident
that
I'm
gonna
be,
you
know
well
equipped
to
to
have
that
conversation.
A
Yeah,
so
if
you,
if
you
want
to
have
this
question
before
that
with
the
team-
even
if
I'm
not
there,
of
course
by
all
means-
please
do
that
so
so.
B
I
know
I
know
you're
super,
so
what
I'll
do
is
take
your
time
to
digest
and
what
have
you
in
the
meantime,
I
will
take
the
heavy
lifting
of
by
getting
the
the
mr
going
to
put
the
stuff
in
the
jobs
to
be
done.
Handbook
page,
you
don't
have
to
worry
about
at
least
getting
the
first
like,
mr
on
that,
and
I
will
also
this
week
I
have
siteback.
B
I
actually
had
cycles
planned
on
friday
to
come
back
to
the
enterprise
management,
epic
and
work
on
other
iterations,
so
it's
already
in
my
calendar,
so
I'll
try
to
see
if
I
can
come
up
with
some
ideas
for
the
thing
big
right
like
you
know
some
what
this
concept
might
look
like
in
the
future
and
so
at
least
you're
not
starting
from
scratch.
Like.
Oh,
my
gosh,
there's
nothing
here
to
work
with.
A
Rob
it
sounds
good
and
if
you
do
that,
please
ping
me
on
if
you're
working
on
gitlab,
of
course,
if
you
have
a
document
assigned
to
me
thanking
me,
so
I
can
at
least
see
where,
where
the
conversation
is
going.
What's
in
your
head,
that's
pretty
much,
I
think
that's
important,
but
for
me
it's
really
like
about
getting
all
this
context
that
so
far
we
do
talk
about
it,
but
it's
yeah
it.
A
We
know
that
it's
on
the
surface,
and
especially
if
you
want
to
simplify
this,
that
that's
the
problem.
If
you
want
to
simplify
it's
something
so
complex
like
this,
we
need
to
understand
the
bigger
problem
behind
it.
That's
why
I
think
it's
so
important
for
me
to
get
familiar
with
this
statement
and
what
are
all
the
problems
with
specific
little
problems
that
you
want
to
solve
with
this
proposal
that
are
already
documented
yeah.
B
And
that's
all
sorry,
the
last
time
I
say
was
when
you
have.
I
know
you
called
when
I
shared
with
you,
but
if
you
have
time
to
look
at
the
video
with
disney
from
over
the
holidays,
it's
a
it's
45
minutes,
but
it
really
gives
you
a
good
tangible
sense
of
one
example
of
what's
happening
to
real
with
customers,
because
it.
A
B
An
enterprise
admin
person
and
it
has
other
sres
that
are
managing
the
groups
and
the
challenges
that
at
least
one
person
has
versus
the
other
sort
of
persona
has,
with
this
whole
thing
about
how
you
manage
you
know
the
runners
in
the
way
we
currently
have
them
represented
in
the
gitlab
ui,
because
it's
not
it's
not
just
the
admin
view.
It's
the
admin
view.
But
then
it's
the
group
view
and
all
that.
B
B
A
And
while
you're
doing
that,
I
think
it
would
be
nice
for
us
because
we
have
this
one-hour
ones
on
monday
next
monday,.
B
A
A
B
A
When
you
find
it
feel
free
to
share,
share
with
me
and
I'll
I'll,
have
a
look
and
leave
a
group
next
week.
In
the
meantime,
I'm
gonna
try
to
wrap
up
the
yeah
there's.
B
B
B
A
B
Have
a
I
created
one
for
solution:
validation
of
this
whole
programming
solution;
evaluation
for
this
whole
space,
and
it
shall
be
added
to
our
agenda
too,
and
it's
linked
in
there
as
well.
Under
the
like
one
of
the.
B
B
A
B
A
Yeah,
so
I
discussed
this,
I'm
gonna
share
my
screen
here.
So
just
you
know
what
I'm
looking
at
I'll
discuss
this
with
with
james
okay.
B
A
Testing
we're
going
with
with
ui
polish
issues
so.
B
A
Can
improve
the
system
usability
score
and
are
you
familiar
you're
familiar
with
this
happening
with
decisions
yeah?
So
my
question
here
is
that
we
have
two
options
and
a
ui,
polish
and
system
speed
performance.
A
Yeah,
okay,
cool!
So
maybe
next
step
do
you
already
have
like
a
list
of
ui
polish
issues
or
anything
that
you
think
you
want
to
to
prioritize
this
this?
This?
Okay,
okay,.
B
A
And
also
yeah,
and
I
agree
that's
when
I
look
at
admin
view
it's
like
it's,
it's
your
policy.
It's.
B
A
That's
the
thing
and
that's
the
nuance,
then:
when
you
talk
about
the
ability
to
filter
or
to
find
information
easily
whatever,
that's
then
no
more
ui
polish
ui
polish
is
really
like.
This
button
is
blue,
but
it
should
be
green.
A
Yeah,
so
you
want
to
hear
so
there's
a
nuance
between
ux
dev,
for
example.
We
know
that
our
customers
need
to
filter
this
list,
but
for
now
the
list
is
static.
We
are
delivering
the
feature
functionality
with
something
missing:
there's
a
depth,
a
ux
that
but
polish
is
really
like.
We
were
supposed
to
deliver
the
front
end
to
meet
certain
design
criteria
and
it
didn't,
but
the
functionality
is
there.
B
A
But
then
I
think
a
good
exercise
will
be
to
just
look
at
the
current
list
of
the
ux,
above
that
polish,
whatever
ux
things
are
front
and
things
that
we
have
in
the
already
locked
or
existing
issues
and
just
try
to
connect
those,
hopefully
with
the
enterprise
management
or
with
the
admin
view,
I'm
certain
that
we
can
make
some
minor
improvements
and
findings
in
the
in
the
backlog.
A
Yeah,
so
let
me
go
quickly
here
to
the
issues
and.
B
You're,
looking
at
the
issues
that
are
linked
from
the
okr
right.
A
B
A
Yes,
yeah
that
we
can
potentially
link
to
this
ovr.
So
if
I
do
runner
and
category
runner
or
group
runner,
okay
group
right.
A
A
group,
but
then
why
do
we
have
a
category
a
runner?
Is
it
a
group
and
a
category?
A
It's
those
are
the
the
labels
that
we
have
now.
That's
what
I'm
doing
just
so.
You
know
I'm
doing
here
again.
Yeah.
B
A
It's
not
accessible,
so
yeah,
I'm
going
to
do
that
today,
because
I
did
this
for
testing
as
well.
So
it's
fresh
in
my
my
mind,
so
I'm
going
to
look
at
the
what
we
have
today
for
you.
I
apologize
management
and
then
because
I'm
familiar
with
this
terminology
with
the
nuance
between
polish
or
feature
whatever
I'll
try
to
come
up
with
the
list
for
you
and
not
sharing,
select
so
that
we
can
just
be
line
on
what
are
the
items
that
fit
this
this
year?
Okay,.
B
This
makes
sense,
I
do
remember
when
we
had
done
this
exercise
before
and
I
looked
at
that
list,
except
for
the
one
or
two
like
missing
features.
I
was
like
okay
yeah.
That
makes
sense,
and
I
wasn't
really
as
worried
about
it,
because
I
was
just
like
okay
tweet
here,
tweet
there,
but
okay,
now
now
I
am
with
you.
I'm
currently
caught
up.
A
Okay,
awesome
I'll
try
to
do
that
today.
If
I
don't.