►
From YouTube: Plan stage weekly - 2020-01-29
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
A
B
Yeah,
so
we
have
aligned
to
each
group
as
UX
designers.
Holly
is
going
to
be
working
or
focusing
on
a
project
management
I'll
be
focusing
on
portfolio
management
and
Nick
will
be
focusing
on
certified,
so
that
doesn't
mean
we're
not
going
to
help
each
other
out
or
that
you
can't
ask
any
of
us
questions,
but
that's
gonna,
be
our
main
domain
focus
group
within
this
age.
That's
about
it.
C
I'm
next
yet
so
we
have
a
stable
counterpart
from
the
app
sack
team.
That's
coastal,
Maxim,
I
didn't
know.
We
had
a
stable
counterpart
in
the
apps
like
team,
it's
not
on
our
team
th,
but
that's
the
quirk
of
the
get
lab
team,
diamo
file
and
I.
Think
like
I
haven't
spoken
to
Ethan.
The
best
policy
going
forward
is
if
we
have
abscess
concerns
with
any
of
our
issues
that
we
sort
of
tag,
cost
them,
but
also
CC
the
rest
of
the
app
SEC
team.
C
To
date,
what
we've
been
doing
is
just
tagging
the
OPSEC
team.
That's
fine!
They
need
visibility
over
it
anyway,
and
but
it
also
means
like
I'll,
try
and
bring
kostol
in
when
we're
doing
our
back-end,
kickoffs
and
stuff
so
that
he
can
have
a
look
through
the
deliverables
in
each
milestone
and
kind
of
see
for
himself,
which
ones
might
have
implications
for
application
security.
So
it's
a
bit
of
both
like
it's
about
reactive
and
proactive,
so
he's
gonna
join
us
in
our
kickoffs,
but
also
like
we
can
bring
them
in
on
any
issues
and
yeah.
C
All
right,
I
will
one
of
the
things
that
I
think
I
realized.
I
went
on
site
last
week
with
customer,
and
it
became
pretty
apparent
that,
like
given
our
size
and
how
many
different
personas
we're
serving
with
him
plan,
it
would
be
really
valuable
if
we
had
a
more
formalized
product
partnership
program,
sort
of
like
cab,
but
just
for
plan
and
more
hands-on
and
interactive.
Where
we
would.
C
If
you
get
more
than
six,
it's
hard
to
keep
up
and
pay
close
enough
attention
to
each
relationship
and
posture
each
relationship.
But
this
is
something
I'm
proposing
I'm,
also
working
with
product
marketing
sales
and
anyone
else
in
the
organization.
We
need
to
get
blessing
to
do
this,
but
the
goal
would
be
like
weekly
touch
points
if
we
can
get
those
with
each
of
these
six
customers
and
they
would
help
provide
feedback
on
what
we're
building
validations.
C
All
the
solutions
were
proposing,
as
well
as
like
using
things
earlier
than
maybe
generally
available
and
helping
us
prioritize
our
roadmap,
so
we're
delivering
the
most
value
to
their
businesses.
If
that
makes
sense,
so
I
think
this
should
go
through
there's
a
good
feedback
initially,
but
yeah
I
just
wanted
to
make
everybody
aware
and
I
think
there's
a
agenda
point
further
down.
That
will
talk
about
the
minute,
but
just
like
getting
engineering
more
involved
in
customer
interviews
and
customer
discovery,
activities
I
think
there's
a
lot
of
power
and
doing
that
too.
D
Thank
You
Sean
next
one
is
mine.
Now
it
is
about
our
roadmap
draft,
your
vision,
so
we
have.
This
issue
share
dual
45.8.
We
discussed
it
a
while
ago
and
planned
in
Collard
leaf
where
we
had
a
bunch
of
things
happening
on
board
map
as
user
schools
in
either
ways.
So
we
solved
the
first
part
of
buffered
rendering,
which
was
the
performance
problem.
If
there
are
too
many
epics
to
show
on
a
group
level
roadmap,
then
if
we
render
all
of
them
at
once
then
page
lower,
it
shall
become
slower,
so
we
solved
it.
D
But
then
there
are
additionally
UX
that
is
going
on
on
the
page.
Well,
if
user
schools
horizontally
in
the
timeline,
then
we
would
make
additional
requests
to
fit
to
fetch
epics,
which
are
from
a
different
time
frame,
and
we
would
insert
those
epics
within
the
roadmap
list,
based
on
the
sort
order
that
user
is
selected
and
the
start
and
end
date,
values
that
we
have
for
the
fix
that
we
received
from
the
and,
as
I
said
like
they
are
inserted
into
the
list.
D
So
we
are
performing
on-the-fly
sorting
based
on
how
we
receive
the
epics
from
back
end.
So
if
user
has
like
ascending
order
sorting
down
on
the
start
date
of
Attucks,
then
if
user
starts
coding
forward
in
the
timeline,
then
we
would
fetch
epics
and
we
would
insert
them
in
appropriate
places
within
the
list
now.
D
So
that
already
is
somewhat
confusing
in
a
way,
because
epics
show
up
in
different
places,
based
on
how
much
user
schools
or
the
back
into
the
future
or
past,
and
now
this
issue
focuses
on
the
graph,
QL
page
addition,
which
is
another
part
of
performance
problem
that
we
are
trying
to
solve
so
right
now
we
already
use
graph
QL,
forget
lab
or
group
on
roadmap
on
github.com
and
there.
Although
we
are
using
graph
QL,
we
are
not
leveraging
graph
QL
pagination
abilities.
D
Instead,
we
have
basically
increased
the
limit
of
number
of
epochs
that
we
receive
on
first
call
to
1000
epics.
So
right
now,
although
we
have
only
700
epics
as
long
as
they
are
under
thousand,
we
would
return
them
all
of
them
at
once
on
first
call,
but
obviously,
as
number
of
epochs
grow
for
a
specific
group,
this
becomes
a
problem
and
we
need
to
fetch
additional
epics,
as
user
continues
to
scroll
in.
So
we
would
basically
gap
that
limit
200
epics
once
graph
QL
is
updated
to
use
that.
D
But
once
we
do
that
capping
of
hundred
items,
what
happens
is
when
user
schools
in
horizontally
things
start
to
basically
combine
like
you
have
a
buffer
rendering
on
the
page,
then
you
also
have
resort
of
schooling,
where
we
need
to
account
for
dates,
and
then
there
is
a
graph
QL
pagination,
where
we
need
to
keep
track
of
the
cursor
based
on
what
API
came
back
with
for
the
page
info.
So
when
all
of
them
are
combined
us
becomes
tricky
to
implement,
because
things
may
show
up
in
random
places
instead
of
where
they
should
be.
D
So,
do
we
have
any
decision
on?
How
do
we
want
to
handle
sorting
as
long
as
there's
a
horizontal
scoring
going
on
I
also
have
linked
in
the
third
point
here,
I
will
link
to
a
comment
that
I
made
on
one
of
the
existing
issues
around
graphed,
your
own
production
a
while
ago,
where
I
shared
multiple
approaches
that
I
could
think
of
to
solve
this,
both
from
the
front
end
and
back
in
perspective
and
Philippe
knows
the
background
of
this
I.
D
So
he
knows
what
we
are
trying
to
deal
with
here
and
a
while
ago,
I
also
was
on
a
call
with
Alexis,
where
I
shared
my
pain
of
having
horizontal
scrolling
on
the
time
line
and
I
was
basically
sharing
my
thoughts
like
if
we
could
get
rid
of
it
by
using
some
additional
UX
on
the
page,
instead
of
allowing
user
to
school
and
Leslie,
because
the
moment
you
introduce
endless
scrolling
with
so
many
parameters
into
the
picture,
it
becomes
difficult
to
handle
and
so
yeah.
That
was
basically
the
idea
like.
D
If
we
want
to
simplify
the
implementation
of
front-end
by
combining
both
buffered
rendering
and
graphical,
then
we
need
to
get
rid
of
horizontal
scrolling
in
some
way
or
the
other
I'm,
not
sure
from
the
customers
perspective
like
how
much
they
rely
on
horizontal
scoring
and,
at
the
same
time,
I
looked
at
periscope
data.
I
shared
it
on
a
plan
channel
like
how
many
users
are
actually
visiting
group
level.
Road
map
versus
the
road
map
tab
on
individual
epics,
because,
most
so
back
when
the
Victor
was
widget
app.
D
When
we
implemented
the
road
map
app
within
the
epic
page
like
if
you
open
any
epic
it,
and
if
it
has
multiple
child
epics,
then
we
would
have
Gordon
F
within
the
page
itself
that
it
would
show
roadmap
timeline
just
for
those
tile
epics.
Instead
of
all
the
epics
from
the
group
and
the
periscope
data
that
I
checked,
the
group
level
roadmap
was
not
something
which
was
very
popular
among
users.
People
were
visiting
epic
page
instead
of
going
to
roadmap
page
I
assumed
there
were
two
reasons
of
people,
not
using
roadmap
page.
D
One
would
be
that
it
is
not
very
useful
because
we
are
showing
lot
of
data
on
the
page,
while
people
are
interested
in
seeing
the
data
just
for
one
epic
or
it
could
be
a
performance
problem
like
people
found
the
page
to
be
really
slow
on
first
root.
So
we
solved
the
second
point,
like
loading
page
loading
of
the
pages.
D
But
if
aux
itself
is
something
which
is
a
user
or
not
visiting
the
hoop
level
roadmap,
then
chances
are
that
you
are
not
doing
something
about
it
with
the
page,
and
my
guess
is
that
horizontal
timeline
scrolling
might
be
it
because
the
moment
you
scroll
the
timeline
horizontally
a
bit.
You
see
lot
of
things
popping
up
on
the
list
as
long
as
they
are
there
to
the
timeline
and
the
sorting
order,
and
it's
so
just
putting
a
lot
of
thoughts
out
there
around
the
UX
around
the
timeline
scoring.
And
what
is
our
take
on
it?
D
B
B
Data
I
think
those
are
things
we
need
to
explore
and
like
talk
to
users
about
I,
haven't
really
looked
at
this
from
a
wets
perspective
yet
and
explored
it
in
that
way.
So
maybe
we
can
get
that
prioritize.
I
know
we
had
talked
about
in
the
past
the
idea
of
maybe
brushing
and
zooming
the
road
map,
so
instead
of
using
horizontal
scrolling
just
allowing
the
user
to
basically
zoom
in
and
out
of
it
manually,
so
I
think
there's
a
few
things
we
could
explore
there.
E
I
can
add
some
color
on
that
too.
So
we
also
have
to
remember
that
right
now,
road
maps
or
lock
to
ultimate
just
like
epics,
are
so
the
pool
of
users
that
we're
talking
about
is
a
lot
lower
than
say
issues.
So
we
need
to
keep
that
in
room
and
kind
of
just
in
context.
The
other
side
of
that
is
from
my
conversations
with
users
around
portfolio
management.
Is
we
just
don't
have
any
functionality
on
the
roadmap,
which
is
one
of
the
reasons
we
are
pushing
to
add.
E
You
know
adding
progress,
information
in
the
epoch
bars
and
allowing
you
to
pop
open
an
epic
ANSI.
It's
tough
ethics
like
that's
the
base
functionality.
That
needs
to
be
there
for
a
roadmap
to
be
something
valuable.
So
that's
what
we
know
from
a
assumptions
standpoint
I
would
assume
that
roadmap
tab
on
epics
I.
Don't
personally
think
it's
super
valuable
I
think
the
reason
we
see
more
views
there
is
cuz
people
go.
What
is
that
then?
E
Click
it
I
honestly,
like
I've,
seen
a
couple
people
who
new
to
the
tool
just
clicking
around
and
like
it's
I
did
it.
What
is
this
show?
But
then
it
suffers
from
the
same
problem.
There
really
isn't
that
much
there,
and
so,
like
Alexis,
said
I.
Think
as
we
we
add
a
little
more
a
couple
more
bells
and
whistles
to
the
road
map
view
and
allow
us
to
actually
drive
some
additional
usage
to
it.
We
can
start
learning
more
and
perform
better
with
it.
Now,
with
the
horizontal
scrolling,
I
mean
I
I.
E
Don't
have
a
good
argument
for
why
we
need
endless
scrolling
on
the
roadmap.
I
think
we
should
cap
it
as
some
sort
of
timeline.
I,
don't
know,
but
I
think
that
I
think
we'd
need
a
little
I'd
need
a
little
more
understanding
of
what
what's.
What's
the
smallest
weekend
or
the
largest
painting
like
timeline
we
can
put
in
there
that
gets
rid
of
some
of
these
issues
play.
Is
it
a
year?
I,
don't
know
if
that
matters
is
it.
E
D
First
equation
of
the
roadmap
that
we
built
when
Pedro
was
leading
the
UX
of
the
roadmap,
we
decided
on
having
a
fixed
timeline,
which
was
like
three
months
into
the
past
and
six
months
into
the
future,
and
this
was
back
when
we
didn't
have
the
different
views
available
on
the
corner.
Like
we
only
supported
months
view,
we
didn't
have
weeks
of
what
is
view,
so
we
decided
on
having
only
a
couple
of
months
back
into
the
future
for
the
road
map.
By
default.
D
There
was
movie
that
user
can
provide
any
timeline
like
start
and
end
dates.
We
would
always
take
today
as
our
base,
and
then
we
would
go
back
from
today
by
a
couple
of
months
and
go
into
the
future
by
couple
of
months
when
we
introduced
waters
view
and
the
weeks
view
we
did
the
same,
but
instead
of
months,
we
would
have
a
fixed
count
like
how
many
weeks
or
how
many
quarters
into
the
past.
D
So
that
was
the
idea
where
we
decided
to
have
at
the
school
I
was
against
against
that
idea,
magnin
because
of
the
implementation
perspective,
because
I
knew
that
if
the
moment
you
work
with
the
scroll
bar
and
start
updating
a
lot
of
things
on
UI,
especially
for
a
complex
application
as
roadmap,
a
lot
of
things
are
rendered
on
the
page.
It
is
not
something
like
Twitter
timeline
or
a
FIFO.
Well,
you
would
have
enters
cards.
We
compute
the
timeline
bar
based
on
dates.
D
We
update
the
indicator
on
the
page
based
on
how
user
schools
there
are
a
lot
of
things
going
on
the
moment.
You
start
scrolling.
The
roadmap
page
so
I
wanted
to
keep
the
implementation
as
simple
as
possible,
but
now
that
we
have
a
fresh
view
about
having
that
endless
scrolling
for
a
while
and
now
we
know
that
whether
it
is
actually
useful
or
not,
we
can
revisit
that
problem
about
working
with
dates
and
the
range
and
which
is
I
have
also
left.
Another
question
like
do.
D
We
have
any
access
to
JIRA
instance,
where
we
can
have
a
look
at
the
roadmap
approach
from
them
because
they
recently
updated
the
roadmap
you
to
improve
progress,
parts
and
drilling
down
the
epics,
to
show
child
ethics
and
from
the
screenshots
that
I
saw
on
Atlassian
support
pages.
It
had
a
neat
way
of
working
with
dates.
It
didn't
have
any
scroll
bars
or
at
least
horizontal,
where
user
can
scroll
endlessly
across
the
timeline
so
yeah.
D
E
B
Yeah
I
think
a
lot
of
products
have
a
calendar
that
you
set
and
you
can
configure
it
different
ways
than
any
congressional
to
do
it
and
I
don't
know.
Did
me
answer
your
question
crucial.
Do
we
have
an
account
that
we
can
play
with
or
I
mean
to
your
point?
What
I
do
fish
all
is
just
not
know
if
I
should
say
this,
but
I
see
throwing
emails
and
do
demos
of
products
so.
A
Anyone
else
have
anything:
I
just
had
a
process
question
like
how
do
we
wanna?
What
do
we
put
our
next
steps
for
this
issue?
Alexis?
Do
you
kind
of
want
to
take
it
on
and
see,
if
do
maybe
another
round
of
competitor
analysis
and
see
if
we
can
get
any
customer
interviews
before
we
decide
how
to
build
it?
Jericho.
B
E
Yep
sounds
good:
oh
I'll
put
a
vase
up.
I
gotta,
just
go
back
over
all
my
competitor
notes
in
this
area
and
then
I'll
come
up
with
three
different
options
and
we
can
start
playing
around
with
which
ones
we
like
more
and
then
we
can
surface
that
and
I'll
probably
just
link
it
back
to
this
issue
that
cou
shawls
brought
up
today.
Yeah.
D
D
We
can
leave
the
milestone,
as
it
is
at
least
for
the
discussion
of
the
time
frame,
like
anything
that
we
do
to
make
the
issue
progress
forward
would
be
nice,
so
we
don't
have
to
produce
the
issue
or
move
it
to
backlog
and
not
discuss
it
anymore.
Instead,
we
can
have
that
milestone,
be
it
while
not
eight,
but
instead
put
our
thoughts
on
how
we
want
to
work
with
the
timeline
and
then
once
we
have
anything
better
mind
for
12.8,
then
maybe,
if
I
don't
be,
have
something
as
a
front-end
implementation.
That
makes
sense
things.
C
C
A
Yeah
and
I
think
it's
a
great
idea
to
just
to
see
how,
from
an
engineer's
from
an
engineering
standpoint,
see
customers
actually
I
mean
it's
kind
of
similar
to
like
user
testing,
but
actually
seeing
how
customers
use
the
products
that
they're
build.
It
gets
them
a
little
bit
closer
to
the
actual
actual
customer
customer
value,
I
think
from
process
standpoint
from
an
overhead
standpoint.
The
easiest
way
would
be
just
to
let
myself
and
John
be
aware
of
the
interviews,
and
then
we
can.
A
C
Let
me
know
in
that
in
the
thread
to
that
message
or
John
again
who
wants
to
participate
or
if
anybody
wants
to
just
volunteer
I
guess
like
speak
up
there,
so
everybody
can
do
that,
but
yeah
I
don't
want
to
interrupt
Flo
and
I.
Don't
want
to
have
this,
be
something
that
is
like
a
distraction,
but
I
do
believe
it
will
add
value,
and
if
we
realize
it's
not
adding
value
after
you
know
a
month
or
two,
we
can
change
things
up,
but
I
think
of
being
great
to
try
for
a
while
cool
agreed.
C
The
other
last
time
I
had
is
something
you
know.
I've
been
looking
at
our
progress.
We
talked
a
lot
about
like
how
are
we
going
to
slow
or
we
working
on
the
right
things
and
I
realized
that
we
don't
really
have
a
plan
stage
cross,
functional
team
objectives
and
key
results.
They
kind
of
are
siloed
two
functional
areas,
and
this
is
like
not
it's
not
the
most
efficient
way
to
drive
business
value.
C
If
that's
okay
to
track
is
our
primary
measure
of
like
success
instead
of
the
functional
loans
and
the
one
of
them
is
just
is
really
like
a
lovable
experience
and
I
think
there's
a
couple
things
to
that.
One
would
be
you
know:
quality
issues
like
how
can
we
decrease
the
effects
increased
performance
have
more
consistent
consistency
in
the
user,
experience
and
I
think
like
by
default.
My
natural
inclination
is
always
to
like
optimize
for
performance
and
quality
and
then
always
go
pajamas
first.
So
those
aren't
like
a
result
like
I
guess
going.
C
Pajamas
first
isn't
a
result,
because
I
would
hope
that
we
would
do
that
anyways.
But
if
we
need
to
make
all
we
can
but
I
didn't
know
like
we
I
just
wanted
some
feedback
to
see.
If
anybody
had
any
ideas
for
good
quality
targets
or
things
that
would
help
us
have
or
deliver
a
more
lovable
planning
experience
to
think
about.
So
the
floor
is
open
for
anybody
who
has
input
about
the
whole
idea
across
Metro.
Here's
the
hole
or
the
specific
proposed
objective
of
lovable
planning
experience
so.
F
I
posted
the
link
of
an
issue
and
RMR
that
Matt
created
in
terms
of
increasing
the
collaboration
between
different
counterparts,
and
so
the
links
are
there
for
you
to
take
a
look.
One
of
the
ideas
is
that
we,
as
software
engineers
in
past,
should
be
more
involved
in
in
the
planning
process
and
starting
working,
more
collaboratively
with
other
engineers
and
new
actors
and
product
managers
from
the
start.
F
This
is
something
that
it's
been
difficult
to
follow
with
the
with
the
like:
having
lots
of
back-end
and
front-end
engineers
for
just
one
test,
automation,
engineer
in
the
theme
which
is
going
to
change
I
think
next
month,
Tommy's
coming
from
create
to
the
plan
team
as
well,
but
still
it's
true
for
for
many,
but
I
just
wanted
to
to
put
that
in
the
table
so
that
it's
transparent
for
everyone.
I
love.
G
This
idea
we
did
this
planning
process
at
version
1
when
I
worked
there.
The
challenge
that
I
see
is
that
we
don't
always
know,
at
least
it
seems
to
me
what
engineer
might
be
working
on
something
during
the
planning
phase,
but
I
think
there's
huge
benefit
in
having
that
engineer
input
early
on,
because
the
engineers
know
what's
possible
technically
in
a
way
that
maybe
not
everyone
else
does
so
I
would
love
to
see
more
of
that
in
the
UX
and
planning
phase,
if
possible,
but
I,
don't
know
how
that
changes.
A
A
A
Is
that
we
should
work
through
that,
and
inspired
has
some
interesting
in
a
section
on
like
process
around
that
and
having
like
the
first
phase,
be
UX
designer
someone
from
engineering
and
product
and
product
be
I,
forget
what
they
call
it
in
and
inspired.
I
always
call
it
like
the
tripod
of
departments
or
of
the.
A
There
you
go
the
three-legged
stool,
but
you
know
working
together
in
a
whole
earlier
phase
and
then
and
then
working
on
the
build
phase
separately.
But
I,
don't
remember,
gate
probably
knows
better,
since
you
read
it
more
recently,
but
so
there's
that
and
Gabe
you
can
address
that.
But
I
also
wanted
to
ask
to
you
Gabe
on
the
okrs,
so
I
think
it's
a
great
idea
to
have.
Okay.
Ours.
Are
you
looking
for
feedback
like?
A
C
Evangelizing
it
early
before
I
put
it
on
paper
so
that
everybody
understands
that
what
they
look
at
when
they
see
it
and
there's
two
there's
kind
of
two
main
objectives
that
I'm
floating
in
my
head.
One
would
be
the
lovable
experience.
The
other
would
be
more
around
business
value
like
creating
a
suite
of
playing
tools
that
you
know.
Large
companies
can
use
right
now
they
can't
use
gate
lab
and
so
that
that
one
of
the
key
results
around
that
would
be
the
six
you
know
partner.
C
If
there
are
more
that
you
think
we
should
have,
we
can
look
at
that,
but
just
to
keep
it
simple
and
then
from
there
I
would
look
to
everyone
on
the
team
to
help
refine
the
key
results.
The
quantitative
key
results
you
know
like:
can
we
reduce
our
defect?
Count
our
open,
D
key
fit
count
from
its
it
500
something
right
now.
You
know
increment
ly
down
to
zero.
Eventually,
like
can
we
increase
the
performance
of
the
application
and
the
page
render
time
from
whatever
it
is
now
like
something
lower.
C
Can
we
like
whatever
the
key
results,
are
that
we
want
to
measure
in
track
against
to
help
achieve
that
objective?
I,
guess
that's
where
I
would
see
feedback
and
input
from
the
team,
because,
like
they're,
usually
it's
the
team
who
gets
to
define
those
and
I'm
part
of
the
team,
so
I
want
to
help
with
that,
but
it
also
like
engineers
and
UX
folks.
A
lot
of
insights
so
I
want
their
input
and
feedback
to
hope.
C
C
A
C
Think
it's
a
product
department,
I,
don't
know
I,
guess
that's
where
I'm
saying
it's
a
business!
It's
business
results
right
and
I
think
there
are
the
way
that
our
okay,
ours,
as
a
company
are
broken
down,
is
is
by
department
and
because,
like
engineering
is
a
different
department,
the
product
UX
lives
within
engineering.
There's
a
chance
for
those
to
be
kind
of
more
like
tightly
coupled,
but
product
is
separate
and
I
feel
a
dissonance
between
you
know.
C
My
okay
are
at
last
quarter
was
delivered
to
opportunity
canvases
and
record
a
demo
of
my
stage
right,
like
that's
helpful
stuff,
but
it's
not
type
of
business
results.
I.
Think
the
same
thing
with
like
increasing
the
merge
request.
Throughput,
that's
a
it's
a
productivity
metric,
but
it's
not
business
result
and
I
would
like
to
figure
out
how
to
have
it
bubble
up
all
the
way
to
the
company
level
somewhere
and
I'm.
C
Gonna
keep
pushing
on
it,
because
that's
the
way
that
you're
supposed
to
use
the
okay
ours,
but
for
this
first,
like
pilot
I,
think
like
we
have
to
demonstrate
that
it's
it
works
well
and
hopefully
by
demonstrating
that
it
works.
Well,
it
will
naturally
organically
spread
upstream
and
horizontally
the
other
stages
about
mixes.
A
E
Yeah
I
think
I
think
when
we
talk
about
it
bubbling
up
to
like
overall
company
metrics.
Like
you
know,
the
number,
the
name
of
the
game
is
iacv,
that
incremental
annual
contract
value
right.
So
if
we
can,
you
know
I
that
leans
right
into
what
Gabe
was
describing
his
business
value
like
if
we
can
show
if
we
can
actually
identify,
what's
missing
for
people
to
get
to
actually
start
leveraging
plan
and
get
value
from
it
so
that
they
can
in
turn
get
more
value
from
the
entire
get
web
platform
like.
E
We
can
start
tying
these
improvements
and
these
expansions
to
iacv
and
I
mean-
and
that's
I,
think
that's
the
quickest
route
I
see
at
this
at
the
moment,
but
there's
plenty
of
other
opportunities
tried
to
tackle
business
and
metrics
as
we
get
there
now
NPS.
If
we
really
want
to
start
chasing
down
level
right,
but
that's
a
good
place
to
start
at
yeah.
C
A
E
Think
we
went
through
that
issue
and
built
out
that
table
with
the
whips
that
we
recommended.
Do
we
want
to
revisit
that
one
more
time
to
guarantee
alignment
on
what
they
should
be
before
we
I
guess
I'm,
just
looking
for
a
time
right
like
we
need
it,
we
need
a
dog
food
as
soon
as
we
can
so
we
can
get
that
help
and
improve
it.
C
I'm
gonna
schedule
a
meeting
based
on
the
issue
board
call
I
had
with
the
aims
and
designers
on
Monday
for
the
project
management
group,
I'm
scheduling
a
follow
on
with
Donald
and
John
to
walk
through
and
sanitize
the
project
management
board
and
like
kick
everything
that
isn't
absolutely
critical
out
of
the
like
prioritization
and
planning
and
I.
Think
is
part
of
doing
that.
We
can
talk
about
what
the
whip
limits
would
be,
making
sure
look,
it's
looking
up
at
that
issue
and
then
applying
them.
So
you're
happy
to
hop
on
that.