►
From YouTube: Progressive Delivery UX/PM meeting 2020-05-19
Description
Meeting to improve alignment between Product Management and UX for progressive Delivery
A
All
right
welcome
to
uxp
I'm
meeting
for
release,
so
I
put
together
a
list
of
items
I
want
to
go
through.
Most
of
them
should
be
pretty
quick.
A
That's
some
basic,
mostly
targeting
questions
at
ored,
but
I
also
have
a
question
for
you
laurie
in
there,
and
everybody
is
welcome
to
put
in
their
feedback
as
this
is
what
this
meeting
is
for.
Of
course,
I
was
seeing
some
issues
being
upgraded
towards
epics
and
I
just
wanted
to
know
what
the
workflow
or
idea
is
behind
when
we
are
promoting
issues
to
epics,
because
there
are
some
downsides
in
terms
of
visibility,
at
least
for
me
personally,
and
just
wanted
to
discuss
a
little
bit.
B
So
normally
I
promote
issues
when
they
become
too
large
to
be
contained
in
one
issue
and
they
start
having
children
and
that's
when,
when
I
start
opening
epics,
because
if
from
the
conversation
this
one
issue
turns
into
four
or
five
issues,
that's
the
way
that
I
do
it.
B
It
means
that
I
mean
the
good
thing
about
gitlab
is
that
we
have
a
lot
of
community
contributions,
especially
on
issues
and
feedback,
and
sometimes
they
just
spawn
out
to
like
different
use
cases
and
the
way
that
I
see
epics.
Maybe
this
is
wrong,
but
the
way
that
I
see
it
is
it's
like
a
container
for
issues
that
make
sense
to
group
together,
there's
also
epics
that
are
bigger
than
that
and
the
whole
epics.
But
when
I
promote
an
issue,
it's
usually
because
there's
a
lot
of
work
to
be
done
there
and
it's.
A
Gotcha,
that
seems
very
logical
to
me
and,
as
like
sounds
like
a
sound
plan.
The
point
where
I'm
less
favorable
towards
ethics
is
that
there's
no
way
to
visualize
them
on
issue
boards
and
there's
no
way
to
assign
someone
to
them,
making
it
a
very
like
a
weird
experience
as
towards
who's
going
to
be
pushing
this.
You
know
like
we
have
discussions
on
epics
similar
as
issues,
but
they
have
all
these
downsides
on
epics.
A
So
my
suggestion
was
instead
of
promoting
issues
which
removes
them
from
the
issue
board
and
without
a
trace,
apart
from
them
being
closed
to
always
create
a
new
epic
and
then
include
the
issue
into
that
epic,
as
like
the
the
origin
towards
that
epic.
B
So
hey,
I
completely
agree
with
the
fact
that
there's
epic
is
not
the
best
solution,
because
maybe
we
need
to
talk
about
with
plan
about
that.
But
the
problem
with
associating
an
issue
that
has
become
an
epic
to
the
issue
is
that
it's
never
going
to
be
worked
on
because
it's
just
too
large.
B
C
Wonder
yeah
like
I
wonder
if
we
could
just
make
an
issue
and
promote
that
issue
to
an
epic
and
then
keep
the
keep
the
original
stuff
so
like
in
the
research
repo
we
just
are
not
in
the
repo.
Sometimes
I
make
an
epic
for
research
effort,
so
I'm
actually
creating
an
issue,
a
new
issue
and
promoting
it
to
an
epic
and
then
linking
all
the
other
stuff
to
it.
So
I
don't
know
if
that.
B
I
don't
know
anything
because
I
just
want
a
process
that
works,
but
me
too,
but
the
the
thing
that
the
thing
that
bothers
me
about
associating
the
issue
is
that
we
already
got
to
the
conclusion
that
the
issue
is
too
large
to
handle.
So
we
know
we
need
to
split
it
up.
Yeah,
that's
true,
why
not
promote
that
and
then
you
know
have
all
the
original
conversations
from
which
we
open
up
all
the
new
issues
because
it
spawns.
You
know
it's
like
rabbit
holes.
A
B
A
A
Okay,
so
if
I,
if
I
see
it
correctly,
if
an
issue
gets
promoted
to
an
epic,
it
is
no
longer
you
know
intended
for
any
milestone
until
like
some
sub
issue
gets
created
and
new
discussion
is
started
on
that.
B
Be
scheduled
so
a
really
good
example
of
one
that
I
did.
This
milestone
was
allow
four
pipelines
to
run
in
parent
projects.
So
this
is
like
a
two
or
three
year
old
issue.
Like
200
people
responded
on
it,
I'm
exaggerating,
of
course,
but
but
it's
like
a
lot
of
conversations,
have
been
there.
B
They're
all
there's
a
lot
of
also
disappointment
in
the
community
that
these
kids
are
getting
pushed
out
and
the
reason
that
it's
happening
is
because
every
time
someone
starts
a
new
thread
about
a
new
use
case
that
we
didn't
think
about.
So
what
I
decided
to
do
is:
okay,
we
figured
out
three
main
use
cases.
Each
one
of
them
is
going
to
be
its
own
issue.
Maybe
we'll
also
open
additional
issues
for
it
and
then
we'll
just
start
scheduling
them,
because
it
was
just
too
large
to
handle.
B
I
don't
think
anyone
coming
in
demetri
you're
a
great
example
because
you're
new
to
the
team
there's
no
way
you
can
understand,
what's
going
on
there
with
two
years
of
discussion
and
understanding,
so
this
just
makes
it
easier
to
scope
out
issues
and
continue
on
separate
threads.
In
my
mind,
yeah
I'm.
D
Excited
I
like
that
as
well.
This
is
how
it
makes
sense
like
the
epic
is
a
huge
like
a
big
initiative,
place
placeholder,
and
then
we
have
a
smaller
items
to
describe
the
smaller
works
that
executable.
So
as
soon
as
we
promote
that
issue
to
an
epic
and
assign
a
little
ones
to
be
assigned
to
the
milestones
and
drives
that
make
sense.
B
Yeah
and
that's
that's,
how
I've
been
doing
it?
Sometimes
I
don't
open
like
I'm
human.
So
sometimes
I
don't
open
everything
I
should
at
once,
but
that's
why
I
have
the
epic.
So
it
reminds
me
like
here
open
up
another
iteration,
but
but
we
definitely
know
what
the
first
and
second
issues
are.
So
there's
at
least
a
clear
understanding
of
where
this
is
going.
A
Yeah,
let's
see.
A
So,
let's
I
think
I
think
we're
pretty
clear
in
that
point.
Let's
skip
on
to
the
next
ux
availability,
I'm
wondering
about
a
little
bit.
I
seem
to
miss
out
a
little
bit
on
some
of
the
issues
and
one
of
the
pain
points
I'm
experiencing
is
that
there's
too
much
to
keep
track
of?
There's
too
much
like
hey.
Would
you
please
look
at
this
issue?
Please
look
at
this
issue.
Oh
by
the
way
do
this
you
know
like-
and
I
want
to
do
that
all
like
that
is.
A
That
is
the
way
that
I
would
like
to
be,
but
I
can
I'm
only
one
person,
so
I
was
wondering
what
your
first
thoughts
are
as
towards
how
you
would
like
to
scope,
ux
weight
per
milestone,
so
that
I
am
not
overloaded
and
can
be
of
best
service
to
you.
B
So
I
have
two
suggestions:
one
of
them
I
suck
I
talked
to
nadia
this
morning,
so
one
of
them
is.
We
already
have
a
needs
weight
issue
where
we
have
the
backing
years,
and
this
milestone.
We
added
the
front-end
engineers
and
we
can
have
even
a
new
addition
for
the
next
milestone
to
add
ux,
so
that
you
can
be
weighing
issues
and
seeing,
if
it's
too
large
and
to
be
scoped
down,
which
is
always
at
least
one
milestone
ahead.
B
So
I
think
that's
a
really
good
idea.
Another
good
place
to
do
that
is
on
the
planning
issue
itself,
we're
trying
to
figure
out
the
capacity
our
capacity
as
a
team,
and
we
have
what
we
did.
What
we
added
like
average,
mrs
per
engineer
for
the
last
three
milestones,
which
has
give
been
give
and
take,
give
or
take
five.
Mrs
per
milestone,
we
could
do
that
for
you
as
well.
I
mean
figure
out
how
many
issues
you
can
handle
and
just
make
sure
that
that's
the
capacity
at
max
that
we're
scheduling
again.
A
D
I
would
say
you
that
you
should
answer
that
question
and
you
should
answer
that
question
by
calculating,
for
example,
we
take
13.0
as
a
as
a
I
understand
that
that
was
your
first
milestone
within
the
progressive
delivery,
but
we
should
take
that
as
a
starting
point
and
you
should
analyze
the
work
that
you've
done
and
say:
hey.
Okay,
because
I
was
new.
Maybe
it's
plus
two
points
or
I
don't
know
how
we're
gonna
even
calculate
that
we
had
a
similar
discussion
about.
How
do
we
exactly
wanna
estimate
the
capacity
of
ux?
D
Is
it?
Is
it
story?
Points
is
it
ours?
Is
it
is
it
I
don't
know,
t-shirt
sizes?
I
think
what
hayana
is
using
and
jackie.
It's
a
story
point.
So
in
probably
that's
a
good
place
to
start,
and
I
would
suggest
we
go
back,
we'll
look
at
13.0,
we
say
approximately.
The
meter
you
spend
like
I
don't
know.
A
Ux
waiting
is
something
that
I
also
really
would
like
to
to
dive
into,
but
go
ahead.
Laurie.
C
Oh,
I
was
just
gonna
echo
nadia's
sentiments,
everybody
has
their
own
velocity,
everybody
has
their
own
capacity
and
the
more
that
you
try
to
weight
things
and
see
how
much
you
got
done,
the
better
you
can
see
and
think
about
your
future
capacity
and
your
future
velocity.
C
So
the
the
only
caveat
it
will
say
is
that
whatever
measurement
you
use,
we
should
all
agree
on,
but
you're
like
the
final
sayer
in
it.
So
how
I've
done
it
in
the
past
is
I've
done
it
much
more
formally
where
we
kind
of
go
through
each
of
the
issues.
You
you
tell
me
what
you're
planning
on
doing
with
it
we'll
do
planning
poker,
that's
what
they
call
it
like
you.
You
show
a
card
and
you
pick
a
number
fibonacci
sequence
number
and
we
all
have
to
agree
on
the
number.
C
If
we
don't
all
agree,
we
have
to
continue
talking
about
the
activity
at
hand
until
we
understand.
Oh,
that's
a
five
for
you,
okay
or
that's
an
eight
doing
that
over
time
like
taking
a
couple
months
to
do
that
continuously
will
help
everybody's
understanding
of
what
the
velocity
is
and
what
a
five
is
and
what
eight
is
what
a
three
is,
but
I
don't
we
don't
do
that
here
so
so
I
say
like
take
your
best
guess
at
it.
Explain
to
us
like
hey.
I
put
this
out
of
five
because
of
this.
C
A
Yeah
yeah
like
or
do
you
feel
confident
in
knowing
which
issues
are
going
to
be
needed.
B
We
have
a
car,
we
have
everything
planned
ahead,
so
I
don't
know
per
se
how
much
work
that
is,
but
you
can
definitely
see
what
what
I
have
planned.
I
do
this
every
quarter,
so
I
plan
the
next
three
milestones
where
I
can't
tell
you
exactly
what
will
reach
each
milestone,
but
they
should
all
be
in
the
quarter
specifically
for
this
quarter.
I
do
have
like
estimations
of
what's
going
to
be
13
1.
B
What's
going
to
be
13
2.,
the
only
thing
that
I
can't
tell
you
an
event
is
some
of
the
issues
have
some
kind
of
ux
on
it
and
need
to
be?
Are
okay
and
fine
and
some
need
to
be
redone,
so
I
don't
know
how
to
estimate
how
much
effort
that
is
on
your
side,
but
I
can
tell
you
what
needs
some
kind
of
ux
attention.
A
Yeah
so
like
the
thing
I'm
trying
to
prevent
is
like
say
you
know,
we
have
the
meat's
weight
issue.
You
ask
me
for
waiting
on
issues
that
I'll
be
working
on
in
1302,
so
they
will
be
implemented
in,
for
example,
13.3
right
that
there
will
not
be.
You
know,
additional
issues
suddenly
scheduled
that
I
would
have
not
been
able
to
wait
and
then
suddenly
have
it
to
have
to
attend
to.
B
Well,
that
will
always
happen,
but
those
are
not
the
planned
issues.
The
plan
issues
we
know
away
in
advance,
like
all
the
p1
issues
of
the
team.
I
know
them
well
in
advance.
I'm
gonna
put
a
little
small
print
on
that
because
we
did
have
one
issue.
This
milestone,
where
we
knew
we
were
doing
research
on
how
to
implement
load
balancers,
and
we
knew
that
was
going
to
create
new
issues
that
we
didn't
know
in
advance.
B
A
Yeah,
because
there
was
also
the
the
aws
issue
right
on.
B
It
was,
it
was
in
the
queue
and
a
quarter
quarter
of
those
and
the
way.
A
All
right
because
it
was
prior
to
that
it
was
a
p3
issue.
So
I
think
that
brings
more
the
question
as
to
what
is
the
single
source
of
truth
that
I
should
uphold
the
highest.
Is
it
label
assignments
and
milestone
assignments,
or
is
it
the
quarterly
and
planning
issues?
I'm.
D
If
I
could
add
two
cents,
I
would
say
to
be
searching
for
truth
in
talking,
often
to
each
other.
I
feel
like
aligning
on
those
because,
like
we're
all
kind
of
like
in
agile,
it's
all
a
bitsy
floating.
Sometimes
I
agree
with
the
read
that
things
will
arrive,
that
we
are,
we
haven't
been
prepared
for
planned
and
that's
kind
of
like
okay,
for
me,
important
is
that
we
are
always
communicating
and
saying:
okay,
hey
like
that.
D
A
B
I
don't
know
I
have
meeting
days
all
day.
I've
been
in
meetings
today
since
10
with
nadia,
and
I
have
them
going
until
six.
I
don't
even
know
when
I'm
I
I
picked
up
my
kids.
I
had
like
a
10-minute
break.
I
was
like
get
yourself
out
of
school,
stop
talking
to
the
teachers.
I
can
only
get
you
now
and
I
don't
even
know
when
I'm
going
to
take
my
other
one
from
daycare.
I'm
going
to
show
you
like
how
bad
it
is.
D
By
the
way,
looking
at
your
calendar,
I
see
that
you
also
have
an
overlap
with
this
meeting
like
in
10
minutes.
You
also
have
to
be
in
the
ops
pm
session
so
or
we
have
to-
oh
god,
sorry
for
saying
that
or
we
have
to
move
this
a
bit
earlier,
maybe
15
minutes
earlier
or
one
hour
earlier.
I
don't
know
because
we
have
a
conflict
like
at
10
minutes.
I
have
to
drop.
It
seems
like
great
as
well.
Of
course,
it.
B
Might
be
two
weeks,
though,
the
apps
the
apps
toggles
between
europe
friendly
and
pacific,
so
it's
only
once
every
two
weeks.
Oh
that's
true,
yeah,.
A
Are
we
all
right
with
me
moving
this
a
little
bit
earlier.
C
A
A
Cool
thanks
and
we're
going
to
rush
her
to
next
just
wanted
to
ask
is
suggesting
you
exactly
why
polish
issues
in
this
way
and
left
a
little
comment.
There's
this
url
a
help
with
planning
issues.
A
I
feel
I
might
come
in
too
late,
or
is
this
necessary
for
certain.2
we're
trying
to
push
for
ux
depth
being
reduced
as
a
department-wide
effort?
So
I
was
wondering
you
know:
is
this
a
helpful
at
all?
What
is
your
preferred
way
of
working
with
this.
B
B
Your
you
added
your
issues
like
last
week
for
13-1,
which
is
a
little
bit
late,
so
anything
that
you
suggested
I
may
have
added
for
13
too,
but
132.
I
just
opened
today
so
everything's
open
and
that's
a
great
time
to
add
a
suggestion
as
well.
He
asked
me
if
we
could
do
something
urgently
and
I
was
like:
does
it
urgently
mean
13-2
and
he's
like
yeah?
That's
fine,
so
I
prefer
planning
to
be
done.
B
We
we
already
had
a
kickoff
yesterday,
the
the
company-wide,
so
I
really
need
basically
the
the
planning
to
be
done
by
the
tent,
so
anything
that
you
can
do
before
is
great,
and
then
we
can
have
a
real
conversation
about
it.
I
don't
want
you
to
think
that
I'm
just
not
looking
into
things.
I
try
to
give
everything
an
attention.
A
Yeah,
that's
why
I'm
asking
like
hey.
I
don't
want
to
be
doing
work
that
is
not
useful
yeah.
I
see
that
nadia
put
in
a
question.
Can
we
align
on
picking
one
item
every
milestone,
we're
doing
this
with
most
of
the
other
pms.
D
Sure
it's
kind
of
you
know
like
we
are.
We
kind
of
like
agree
on
that,
and
of
course
I
understand
that.
Sometimes
there
is
like
okay,
guys
like
we
have
to
do
this,
for
example,
and
otherwise
we're
gonna
die,
but
most
of
the
time
we
try
to
make
sure
that
we
like
include
one
of
those
things
and
I
think
that's
a
nice
way
to
meet
in
the
middle.
I.
D
That
this
milestone
is
a
bit
too
late
or
it,
but
thanks
dimitri
for
pushing
this
forward
in
the
beginning,
and
I
hope
we
could
continue
this
in
going
forward.
Yeah.
A
Thanks
for
that,
let
me
see
there's
this
issue,
which
one
is
it
it's:
a
ability
to
associate
feature
flag
with
contextual
merge
quests.
So
there
was
a
pain
point
that
came
up
during
the
ux
weekly,
as
in
that
feature,
flags
might
be
intrusive
for
our
review
at
workflow.
I
don't
know
for
sure
if
this
issue
fixes
that,
but
there
might
be
extra
incentive
for
us
in
that
case,
to
push
this
issue
forward.
I
was
wondering
what
you
thought.
B
I
don't
understand
the
reason
this
specific
issue
has
nothing
to
do
with
review
apps,
it's
just
showing
related
feature
flag
underneath
like
where
you
have
related
issues,
so
I
don't
understand
why
this
would
be
intrusive.
Maybe
it's
a
larger
topic
that
we
can
talk
about
in
the
weekly
feature
flags,
because
I
don't
really
understand
it.
A
Yeah,
so
it
was
mostly
like
if
a
feature
flag
is
enabled,
but
it
it
like-
or
at
least
it's
active,
but
it
is
disabled.
Then,
if
the
review
app
is
spun
up,
then
the
new
feature
will
not
be
visible
within
the
review
app
and
we
might
be
able
to
you
know
to
do
better
there.
Potentially,
what
do
you
think.
B
So
we
started
with
this
conversation
with
epics
and
I
guess
we'll
go
back
to
epics.
I
have
an
epic
that
talks
about
the
content,
the
connection
between
future
flights
and
review
apps,
it's
a
very
powerful
feature
and
something
that
I
talked
to
one
of
the
analysts
about
that.
That's
like
one
of
the
biggest
advantages
that
gitlab
would
have
for
feature
flags
is
that
you
could
basically
see
any
kind
of
behavior
in
a
review
app,
given
that
you
said
something.
So
I
think
this
is
a
really
huge
topic
for
this.
A
Do
you
want
us
to
to
lock
this
that
this
has
been
discussed
on
the
ux
weekly
agenda?
As
for
internal
customers?
For
this
feature,.
A
So,
do
you
want
us
to
make
a
record
somewhere
on
an
issue
or
epic
that
we
as
git
lab
as
internal
users,
are
requesting
for
this
to
be
pushed
forward?.
B
B
A
No,
so
I
would
say,
forget
the
issue
I
thought
like.
I
did
a
quick
pick
off
issues.
I
saw
that
issue.
I
thought.
Maybe
this
has
a
connection
to
it.
I
changed
my
agenda
point
originally.
My
agenda
point
would
explain:
hey
is
this
issue?
Might
that
potentially
have
any
correlation
with
this
problem?
It
clearly
does
not.
So,
let's
throw
that
out
of
the
window.
Don't
think
about
that
that
issue
anymore,
it
was
mostly
about
like
hey.
A
Can
we
improve
our
review
app
feature,
functional
feature,
flag
functionality
and
in
that
way,
help
not
only
our
customers,
but
also
ourselves,
as
this
is
a
pain
point
shared
across
the
ux
department,.
B
A
D
Okay,
I'm
afraid
I
have
to
drop
in
order
to
make
the
next
meeting
yeah
move
the
future
sessions
already.
B
A
B
Lori
just
one
question,
so
I
have
been
I've
done
like
three
interviews
so
far
with
respondents
for
the
post
deployment
monitoring,
oh
good
and
two
of
them
were
like
not
great.
Oh,
I
don't
know
what
to
do
with
that
or,
if
like
how
to
fill
out
the
there's.
There's
this
section
after
you
interview
or
you
say,
uh-huh
this
year,
but
I
don't
know
if
they
shouldn't
get
paid,
because
I.
C
C
Yeah,
so
what
go
ahead
and
like
feel
free
to
fill
that,
I
think
the
feedback
just
goes
to
the
system.
I
don't
think
it
goes
to
them,
but
you
can
always
just
say
like
they
didn't
their
profiles
didn't
match
what
I
who
I
needed
to
talk
to.
That's
usually
what
I
say
and
then
in
the
issue
I
would
ping
either
emily
or
rupert,
whoever
helped
you
set
it
up
and
tell
them
like.
I
need
help.
I
need
replacements
for
these
two.
B
And
like
so
here's
another
question,
one
of
them,
her
name
was
melissa.
She
like
came
up
in
the
respondent
like
she
basically
only
fit
gender,
but
she
didn't
match
the
role
or
the
something
else
for
the
industry.
So
I'm
wondering
why
they
come.
That
comes
up
anyway.
C
B
A
Hey
thanks
for
staying
a
bit
longer,
okay,
I
just
had
some
questions
on.
Let
let's
first
discuss
this
one,
and
then
we
do
ux
research.
This
one
rings
thoughts
there,
but
I
registered
for
dovetail
okay,
which
looks
very
nice
yeah.
A
C
It
is
more
than
that,
so
we
just
met
about
this
on
thursday,
as
a
research
team.
B
C
Dovetail
will
be
the
thing
we
use
moving
forward
to
record
our
sessions,
take
notes
in
for
the
session,
so
no
more
spreadsheets,
and
it
also
the
platform,
also
helps
you
to
identify
themes
in
insights.
C
So
it
doesn't
quite
write
them
for
you,
but
what
it
will
do
is
go
through
the
different
sets
of
notes
for
a
particular
project,
and
you
can
tag
things,
so
it
kind
of
relies
on
tags
and
it'll
say:
hey
look.
This
is
kind
of
the
same
feedback
you
got
about
this
one
tag.
C
Is
that
useful
to
you-
and
you
can
say
yes-
and
you
can
say,
make
this
an
insight
so
which
I
think
just
really
tags
it
as
an
insight
and
so
to
that
point,
we're
going
to
be
using
that
now
to
store
our
insights
for
research
with
a
hopeful,
a
hopeful
thought
to
being
able
to
use
their
api
in
the
future
to
pull
that
also
back
into
our
insights
repo.
C
She
told
me
this
morning
over
slack
that
she'll
publish
that
page,
I
think
today
and
then
on
thursday
or
by
thursday.
Everybody
else
should
have
access
to
dovetail.
So
I
I
knew
you
were
looking
for
something
like
this.
So
that's
why
I
begged
you
early
to
get
early
access
to
it,
so
you
could
play
around
with
it
and
look
at
it
but
yeah.
So
that's
that's
the
deal.
A
Thanks
for
that
so
going
forward,
it
is
like
it's
it's
fully,
okay,
to
use
that
as
the
the
tool
going
forward.
There's
no
need
to
like
replicate
that
data
in
the
existing
ux
research
inside
your
posture,
et
cetera,.
A
B
A
Yeah,
like
I'm,
I
I'm
one.
I've
been
wanting
to
move
a
b
testing
forward.
There's
some
last
task
I
need
to
attend
to
and
then
we
can
start
recruiting
and
then
it
should
be
pretty
fast
to
to
continue
from
there.
How
are
you,
what
are
your
thoughts
on
taking
on
one
research
project
per
milestone?
Generally
speaking,.
C
C
It
kind
of
ended
up
being,
maybe
one
every
other
one,
because
just
for
the
sheer
workload
you
have
to
do
your
job,
you
have
to
prep
for
the
research
you
have
to
do
the
research
you
have
to
wrap
up
the
research
and
then
you
have
to
also
keep
doing
your
design
job
too.
So
I
would
say
you
could
probably
get
be.
I
would
be
confident
that
you
could
get
one
done
every
other
milestone
and
then
maybe
orie
can
do
the
other
one.
The
other
milestones.
C
A
C
A
All
right,
thank
you
thanks.
I
was
wondering
because
it's
always
there's
always
been
one
which
has
been
bugging
me
less,
like
hey
the
minimum.
I
can
see
like
for
me
if
I
really
push
it
it's
like
five
weeks
and
that's
just
a
bit
longer
and
it's
always
gonna
delay,
and
it's
like
how
are
people
doing
this
within
one
one
milestone?
I
really
don't
get
that.
C
They
aren't
unless
it's
a
researcher,
because
that's
our
full-time
job
so
they're
they
can't
they
just
can't.
So
don't
don't
push
it
too
hard.
You
know
I'd.
Rather,
you
spend
the
bulk
of
your
time
doing
your
the
job
that
you
have
talent
for
which
is
the
design
job
then
trying
to
shove
the
research
in
there.
So
I'd.
Rather
you
take
more
time
for
the
research
and
then
focus
on
your
design.
Job
gotcha.
A
Thanks
for
that,
then,
for
this
we're
pretty
much
done,
I'm
I'll
be
pushing
this
forward
by
the
way.
The
last
question
is
we
have
the
maturity
scorecard
yeah.
So
the
thing
is
a
b
testing
is
going
to
leak
into
13.1
maturity.
Scorecard
is
originally
planned
for
13.1
after
13.00
for
a
b
testing,
as
we
just
discussed
it,
it's
kind
of
hard
to
put
both
things
into
one.
C
A
C
No,
as
far
as
I
know,
you're
not-
and
I
I
don't
know,
product
has
their
own
timeline,
but
we
we
don't
on
our
side
like
it's,
it's
something
that
is
supposed
to
be
agreed
upon
between
ux
and
product
that
hey
it's
time
to
do
this.
Let's
try
to
get
this
done
in
this
time
frame,
but
that's
set
between
you
and
or
eat,
so
it
shouldn't
be
dictated
by
anything
else
outside.
Unless
product
decides,
I
mean
you
know
whatever
they're
doing
on
their
side,
but.
A
All
right,
thanks
for
that
and
last
question
is
I
didn't
like.
I
saw
your
reply
in
like
I've
like
cleaned
up
the
agenda
a
little
bit.
I
just
you
know,
deleted
a
lot
of
the
discussion
because
it
was
just
convoluting
the
agenda
to
know
and,
and
you
know,
chorus
ai.
I
think
this
is
like
a
wealth
of
information
we're
not
using
yet.
A
I
was
wondering
how
you
know
how
trustworthy
it
is.
Is
it
being
used
by
anyone
like
what
are
your
general
thoughts
on?
Let's
see,
you
already
posted
like
a
comment.
C
Yeah,
I
think
some
of
the
researchers
I
think
I
want
to
say
jeff-
might
have
been
going
into
chorus
and
looking
for
stuff
for
growth.
I
know
some
of
the
pms
go
in
there
and
look
for
stuff,
but
I
don't
know
if
anybody
is
doing
it
on
the
regular.
C
So
I
but
I
love
your
idea
of
suggesting
in
the
template.
Not
only
did
you
check
the
repo,
but
did
you
check
chorus
and
then
like
other
sources
of
past
research
or
past
customer
notes
or
whatever
we
want
to
call
it,
because
I
agree,
I
think
it's
there's
a
lot
of
stuff
in
there
it
just
I
don't
know
if
everybody
even
knows
it
exists,.
A
Yeah
there's
my
that's
my
thinking
as
well,
so
how
about
this
I'll
I'll?
Add
it
in
the
merge,
quest
or
I'll,
create
a
merch
quest
to
edit
english
template
and
then
we'll
see
if
it,
you
know,
becomes
more
well-known
from
there.
I
I
still
need
to
like
I'm
registered.
I
can
go
into
it,
but
it's
a
large
tool
there's
a
lot
of
things
to
to
explore.
So
it's
also
something
like
you
know.
I
want
to
dive
into
this,
but
they're
just
more
pressing
things
than
that.
C
A
Trades
all
right
thanks
for
that,
any
more
points
from
you
to
me
personally.
C
Just
let
me
know
how
I
can
help.
I
know
with
the
time
zone
differences
it's
hard,
but
ori
always
has
so
much
that
she
wants
to
get
done.
She's
very
optimistic,
so
let
me
know
how
I
can
help
with
any
anything,
either
corralling
or
being
the
go-between
between.
I
don't
I
don't
know
whatever
you
need,
I'm
here
to
help
you
thanks.
A
For
that
yeah
we'll,
let
you
know
as
soon
as
I
I
mostly
send
you
a
dm
when
I
yeah
it's
just.