►
From YouTube: Expansion Sync 2020-08-19
Description
Weekly meeting with the expansion team
A
All
right,
so
we
got
the
expansion
sink
going
on
today
looks
like
we've
got
jeff
and
mate,
and
I
figured
we'd
just
kick
it
off.
I
think
I
have
the
I've
got
the
first
four
actually
and
really.
What
I
wanted
to
do
is
just
use
the
time
to
kind
of
connect
and
talk
a
little
bit
more
about
some
of
the
things
that
I've
recognized
and
going
on.
I
think
most
of
us
are
on
the
same
page
with
them,
but
just
in
the
event
one
of
us
missed
something.
A
I
think
it's
important
to
chat
about.
The
first
one
is
that
there
was
a
recent
mr
made
today
to
the
handbook
where,
from
a
pm
perspective,
we
have
basically
a
table
that
shows
us
how
to
rank
and
prioritize
issues,
and
it's
it's
just
a
guideline
right,
but
from
a
growth
point
of
view,
we're
we're
pretty
heavily
focused
on
driving,
iacv
and
and
usage,
and
what's
interesting
is
that
you
know
recently
this.
This
handbook
update
actually
puts
ux
and
usability
over
iacv
drivers.
A
We're
talking
about
it
a
little
bit
more.
I
know
a
new
is
really
driving
it.
It
was
brought
up
yesterday
or
two
days
ago
in
the
product
weekly
meeting.
So
if
you
haven't
watched
that
recording
you
might
want
to
take
a
look
at
it,
and
I
also
think
there's
going
to
be
some
follow-up
in
relation
to
it
doesn't
necessarily
mean
that
we're
going
to
de-prioritize
things
that
have
an
impact
on
on
iacv
and
only
focus
on
things
that
drive
usability.
A
B
A
Yeah,
I
think
it
can
be
looked
at
a
couple
of
different
ways.
For
instance,
there
was
a
a
board
slide
that
scott
had
shared
with
us,
and
it
showed
that
you
know.
Basically,
70
percent
of
the
resources
were
focusing
on
features
that
drove
iacv
and
30
of
the
work
that
was
being
done
by
the
product
team
was
focused
on
other
things,
so
it
can
be
used
all
the
way
at
the
board.
A
Level
can
also
be
used
at
the
section
level,
and
then
I
think
it
can
also
be
used
at
the
project
and
issue
level
as
well
me
specifically,
I'm
I'm
gonna
use
it
to
make
sure
that
we
get
a
nice
a
nice
balance
of
of
kind
of
both.
It's
important,
I
think
for
us
to
be
able
to
put
points
on
the
board
from
from
a
usability
perspective
and
then
also
couple
it
with
iacv
and
show
show
that
we
can
actually
drive
some
incremental
revenue
as
well.
A
B
It
does
and
to
answer
the
question
you
sort
of
raised
around
like
what
do?
What
do
we
feel
like?
I
I
do
think
ux
certainly
will
you
know
lead
to
improvements
in
in
usage
and
in
iotv,
but
it's
going
to
be
lagging
right.
You
know
it's
not
like
when
you're
doing
an
iacv
revenue
focused
experiment
where
you
can
draw
a
very
clean
straight
line
between
like
we
changed
this
and
we
earned
this
much
more
money,
and
we
know
that,
with
with
a
great
deal
of
certainty,
it's
going
to
be.
B
We
made
this
ux
change,
which
resulted
in
this
usage
change,
which
resulted
in
this
revenue
increase.
You
know
potentially
three
to
six
months
or
whatever
down
the
line.
It's
and
we
may
not
be
able
to
know
that,
because
we
may
not
be
looking
at
it
or
instrumenting
in
such
a
way
to
be
able
to.
You
know
know
that
cleanly
that
we
can,
you
know,
make
a
direct
attribution
of
this
change
resulted
in
this
change
in
revenue,
which
is
okay.
B
A
I
I
agree
with
all
that
yeah
we're,
I
think,
we're
pretty
well
aware
of,
like
the
the
challenges
around
being
able
to
map
product
usage
to
revenue,
it's
a
tricky
one.
I
think
we
do
an
okay
job
with
it.
For
instance,
like
the
invite
members
experiment
that
we
ran
like
we
knew
that
there
were
x
number
of
people
who
clicked
on
that
link
and
did
something
with
it.
A
So
we
can
basically
come
up
with
a
model
that
says
like
we
can
assume
that
x
number
of
iacv
was
attributed
to
it
because
they
they
added
this
many
users
right,
but
it
isn't
like
exact.
It's
not
a
it's,
not
like
accounting,
metrics,
it's
or
or
like
an
accounting
practice.
It's
more
of
a
you
know,
business
intuition.
That.
B
We
can
learn
I'd,
love
us
to
get
more
comfortable
with
the
idea
of
pre-post-testing,
especially
for
things
that
maybe
aren't
of
primary
importance
or
don't
necessarily
need
to
be
a
true
ab
experiment,
because
it's
just
so
much
less
effort
and
it
it
can
be
just
sort
of
calculated
so
much
more
easily.
You
don't
have
to
put
people
into
conditions.
You
know
time
the
time
period.
Pre-Post
change
is
your
condition,
and
so
you
don't
need
an
experimentation
framework.
You
don't
need
all
this
stuff.
You
just
say.
C
C
As
I
wrote
do
we
know
what
the
main
reason
for
doing
this
is
because
so
far
specifically
the
growth
teams
were
mainly
driven
by
is
iacb
right
and
now
this.
For
us,
this
is
quite
a
big
change.
I'm
not
sure
how
it
is
for
other
teams,
but
I
know
for
for
us
today
and
at
the
same
time
it
shouldn't
be
that
much
between
do
we
want
to
generate
revenue
or
do
we
want
to
prioritize
ux,
because
we
know
that
a
better
ux
on
the
long
term
generates
revenue
right.
C
A
The
just
some
some
additional
context
too,
in
skipping
a
little
bit
ahead,
but
scott,
so
this
driving
product
usage.
So
if
you
skip
down
to
number
three
scott
created
a
very
well
written
issue
about
shifting
the
focus
to
driving
product
usage,
and
if
you
read
through
that
issue
mate,
I
think
you'll
you'll
get
the
some
additional
context
and
you'll
be
able
to
kind
of
tie
the
two
together
at
least
that's
how
I'm
taking
it
like.
A
This
announcement
was
made
about
shifting
the
focus
to
driving
product
usage
instead
of
going
so
broad
and
just
working
on
multiple
features
and
having
a
having
breath
over
depth.
Now
we're
trying
to
get
more
usage
of
you
know
the
more
utilized
features
and
functionalities
of
our
tools,
and
I
think
that's
really
where
the
genesis
comes
from
and
then
in
addition
to
that,
it's
more
of
like
okay!
A
You
know
scott
explicitly
called
out
on
the
call
that
the
pms
still
have
you
know
autonomy
and
control
over
the
work
that
their
teams
are
doing
so
that
way
they
can
meet
their
goals.
That
being
said,
you
know
it's
it's
one
of
those
things,
that's
kind
of
being
recognized
at
the
top
like
hey.
If
we,
if
we
keep
building
these
features,
that
don't
get
much
use
and
we
spend
a
lot
of
time
and
resources
on
them,
but
nobody
uses
them
or
nobody
adopts
them.
A
Then,
what's
the
point
kind
of
like
the
existence
of
of
growth
right,
like
we're,
gonna
run
a
bunch
of
experiments
and
find
out
whether
or
not
people
use
a
certain
thing
or
find
out
if
we
can
get
them
to
use
a
different
part
of
the
product.
Good
example
is
the
mr
with
no
pipelines
thing
like
if
we
can
get
more
people
to
use
more
of
the
product
and
reach
that
aha
moment,
then
the
better
off
we'll
be,
and
we
won't
have
to
necessarily
spend
resources
in
areas
that
are
just.
A
You
know
not
getting
a
lot
of
attention
and
then
I
think
there
is.
There
was
some
really
good
debate
to
mate
like
if
you,
if
you
watch
the
the
recording
of
the
product
weekly,
there
was
some
some
healthy
debate
in
there
about
like,
for
instance,
if
you
take
security
out
of
context
in
this,
and
you
just
look
at
like
the
overall
utilization
of
git
lab
as
a
whole.
A
The
usage
of
security
is
going
to
be
like
tiny
in
comparison
to
something
like
ci
or
sem,
and
the
reason
being
is
that
just
there
are
just
not
a
lot
of
people
who
pay.
There
are
a
lot
of
users
that
or
customers
that
pay
for
ultimate
and
they
they
use
the
product.
But
there's
only
like
in
in
the
grand
scheme
of
thing
it's
like
tiny
compared
to
our
user
base,
so
it's
kind
of
like
you
got
to
put
it
in
the
right
context
too.
C
A
Out
there
spend
a
little
bit
of
time
with
it.
It's
I
think
it's
a
healthy
change
and
I
think
it's
a
really
good
debate
and
and
discussion
for
for
the
team
to
have
as
a
whole,
and
I
also
know
that
some
people
might
have
been
caught
a
little
bit
off
guard
because
they
might
feel
like.
Oh
no,
like
is
my
part
of
the
product
not
getting
enough
usage,
and
what
does
that
mean?
A
So
people
are
probably
being
a
little
protective
or
they
could
be
even
a
little
worried,
but
I
don't
think
that's
the
purpose
of
it.
I
think
the
purpose
of
it
is
like
if
we
built
these
awesome
tools
like
let's
get
people
to
use
them
now
and
let's
just
focus
on
making
them
easy
to
find
easy
to
navigate
to
right
and
easier
to
adopt,
and
that
will
hopefully
lift
revenue
for
the
entire
organization.
A
A
The
long
story
short
is
that
the
the
charts,
the
handbook
and
the
actual
financial
plan
that's
written.
They
don't
match
so
we
need
to.
We
need
to
make
the
match
and
and
really
it's
a
I
just
wanted
to
bring
it
up,
because
it
is
it's
a
little
it's
a
little
scattered.
So
I
I
raised
this
tequila
gila
craig
and
I
are
gonna-
just
have
a
conversation
about
what
the
next
steps
should
be.
A
I
think
the
proposal
really
is
to
just
make
them
all
match
or
if
they
don't
match,
and
we
need
to
have
an
internal
target,
that's
more
aggressive
than
what
we
have
in
the
plan
for
the
company.
Then
you
know
phil
had
a
great
suggestion.
Why
don't?
We
just
use
two
target
lines
inside
the
chart,
so
that
way
we
can
see
like
the
internal
target
that
we're
tracking
towards
and
then
the
actual
plan
target
that
we're
tracking
towards
so
then
we
can
kind
of
communicate.
A
You
know
we're
not
the
the
ship
isn't
sinking
and
this
was
planned
and
it
was
accounted
for
and
here's
what
we've
been
recognizing
rather
hey
than
target's
170.
Why
is
it
trending
down
below
170
for
the
past
three
months?
How
can
we
fix
that?
I
think
those
are
good,
healthy
questions
to
ask
and
we
should
still
track
them
down,
but
at
the
same
time,
a
lot
of
this
stuff
is
kind
of
planned
and
already
has
already
been
kind
of
thought
through.
A
A
Number
three
is
just
make
sure
you
spend
time
on
this
one
actually
jeff.
I
think
you
were
in
the
product
weekly,
I'm
just
putting
it
there
as
a
as
an
fyi
mate.
I
highly
recommend
it
yeah.
I
know
you
already
said
that
you're
going
to
check
it
out,
but
it's
it's
good
information
and
then
the
last
was
I
I
put
this
one
on
here.
Number
four
was
to
just
just
to
review
the
navigation
priority
mural.
A
We
did
this
as
a
team
last
week
with
jackie,
if
doug
and
jackie
fraser
were
jackie
fraser's
on
she's
on
pto
right
now,
so
she's
not
here,
but
I
was
just
gonna-
bring
this
to
the
team's
attention.
So
that
way
everybody
could
look
at
it
together,
but
me
you
and
jeff,
or
the
three
of
us
have
already
kind
of
spent
a
lot
of
time
on
this
one.
So
we
probably
don't
need
to
do
any
additional
work
here.
A
A
B
Cool,
I
just
added
one
thing,
because
we
got
a
little
time
left
and
I
realized
tim.
I
haven't
actually
brought
this
up
with
you
yet,
and
this
is
something
I
kind
of
spoke
about
a
little
bit
in
growth
weekly
yesterday,
but
in
our
design
meeting
with
jackie
and
mate
and
myself
and
some
of
the
other
growth
designers.
B
We
were
talking
about
how
to
approach
this
idea
of
doing
research
towards
a
new
dashboard
or
a
new
home
page
and
how
we
might
do
that,
and
we
were
thinking
like
at
a
high
level.
We
understand
the
problem.
The
problem
is
we're
not
showing
relevant
or
personalized
information
to
people
at
a
detail
level.
I
don't
think
we
understand
the
problem
and
we
certainly
don't
have
a
well-defined
solution
right
now,
and
so
we
started
thinking
about
well.
How
can
we
sort
of
get
to
the
next
level
of
detail?
B
This
is
going
to
be
a
little
challenging
because
it's
going
to
be
so
specific
to
the
individual
and
the
approach
we
kind
of
settled
on
and
I
apologize.
I
need
to
create
an
issue
describing
this,
and
I
will
once
ux
showcase
is
over
in
a
little
over
an
hour.
Is,
is
kind
of
doing
what
would
be
called
like
a
rapid
iterative
testing
process,
and
so
it's
kind
of
were
you
in
the
airbnb
lunch
and
learn
with
the
woman
from
airbnb.
A
B
It's
actually
pretty
good,
I
I
mean
some
of
it
you
can
skip
some
of
it
is
like
pretty
basic,
like
you
know,
make
sure
you,
you
know
well
have
well-defined
metrics,
but
some
of
one
thing
she
said
that
I
thought
was
really
really
smart
was
she
was
talking
about
doing
landing,
page
experimentation,
testing
and
how
they
did
it.
For
this
one
thing
and
her
approach
was
really
interesting.
B
She
basically
said
we
sort
of
cut
the
page
into
components
and
we
defined
like
three
major
components
for
the
page
and
sort
of
sub
teams,
went
off
and
did
a
bunch
of
rapid
experimentation
on
just
those
components,
and
they
had
very
near-term
success
metrics.
So
it
wasn't
like
an
actual
booking
of
a
night.
It
was
like
people
get
it
like
completing
that
flow
of
that
single
component,
like
basically
clicking
a
button
and
they
sort
of
reached
like
the
local
maximums
for
those
components.
B
A
I
think
we
could
probably
just
look
at
a
page
and
say
what
are
what
are
five
things
that
we
could
do
different
on
this
page
that
might
drive
better
usage
or
drive
people
to
an
area
the
product
that
is
new
or
exciting
that
they
haven't
seen
before
yeah
and
phil
phil
brought
this
up
to
me.
He
he
almost
said
the
exact
same
thing
that
you
did
verbatim
so
like.
I
have
to
go.
Watch
this
this
airbnb
thing
mate.
Have
you
have
you
watched
it.
B
Two
weeks
ago,
I
think
yeah,
it
was
good.
I
I
mean
again
some
of
it
is
pretty
straightforward
stuff,
so,
like
don't
feel
like,
you
need
to
watch
every
single
second
of
it
like
skip
ahead.
If
it
seems
like
stuff,
you
already
know,
but
that
when
she
described
that
that
I
thought
that
was
really
smart
because
she
was
like
look
like
this
is
a
huge
landing
page.
There's
a
lot
going
on
like
it's.
A
What
do
you
think
it
would
take
for
us
to
to
get
this
done
from
an
engineering
perspective
and
then
even
smaller
ones?
That
just
take?
You
know
just
a
little
bit
of
mate's
time
right
like
not
like
crazy
things,
but
like
link
placement
for
the
invite
members
experiment
like
we
could
put
links
all
over
the
place,
we
could
change
the
coloration
of
them.
We
could
change
the
copy.