►
From YouTube: Growth Expansion sync 2020-01-22
Description
Highlights:
- One new idea to enhance our empty states and drive deeper feature adoption
- Deep conversation about workflow labels to improve team throughput
- OKR alignment discussion
Link to notes: https://docs.google.com/document/d/1j2vFR5zZixgrrozrvPtuaoFxcrUejLcVqt3Mfviyq3A/edit#heading=h.a1gd7ugmgt4y
A
A
B
A
B
A
A
A
Know
what
I
was
going
to
recommend
that
we
that
we
we
set
up
a
bi-weekly
call
today
and
and
we
get
this
thing
established
so
that
way
we
have
a
touch
point,
instead
of
just
using
them
monthly
that
we
had
set
up
for
ideation,
where
we
could
invite
other
people
I
figured.
This
would
be
a
good
place
for
us
just
until
we
get
to
a
point
where
we
have
enough
work
in
the
backlog
and
we're
just
kind
of
you
know,
moving
along
yeah
quickly,
I
think
it'd
be
really
really
old.
A
So
it's
yeah-
and
I
am
recording
this
just
for
the
rest
of
the
expansion
team
and
I'll
post
it
to
the
growth
channel.
So
that
way
everybody
can
see
what
we're
what
we're
up
to,
but
we
can
kind
of
go
right
through
it
here.
I've
got
a
couple
of
items
down
here.
One
is
a
new
idea:
let's
do
it
to
embed
content
from
me
from
the
demos
pages
in
the
product,
MV
states
to
improve
feature
adoption.
A
C
A
They
are
it's
pretty.
Some
of
them
are
pretty
long.
A
handful
of
them
are
outdated,
but
I
feel
like
there's
some
kind,
there's
probably
some
good
ones
in
there,
and
if
we
do
our
due
diligence,
we
can
identify
essentially
the
next
right,
like
the
next
best
thing,
that
a
user
should
educate
themself
about
for
a
for
either
an
upgrade
or
just
driving
deeper
feature.
Adoption
I
think
it
would
be
really
helpful.
Yeah.
B
A
B
C
C
A
I'll
write
up
an
issue
or
well,
we
can
get
to
work
on
it.
Okay,
you
and
I
can
figure
out
what
it'll
look
like
and
well
we'll
get
it
moving.
Yeah
cool,
so
number
number
two:
what
we're
currently
working
on
so
I?
What
I
did
was
I
just
linked
in
here
the
the
work
flow
dashboard.
So
that
way
we
would
have
a
more
holistic
view
of
all
of
the
items
that
that
we've
got
in
pipeline,
and
this
does
both.
It
shows
the
actual
workload
validation
all
the
way
through
the
build
track.
A
So
you've
got
the
validation
track
and
the
build
track.
All
in
one
view
here-
and
this
is
just
what
I
wanted
to
I
just
wanted
to
surface
it.
So
that
way,
we
all
I
know
we're
all
in
here
every
day,
working
on
some
of
these
things,
but
I
just
wanted
to
make
it
very
apparent
that
we've
got
these
phone
lines.
B
I
put
that
as
a
topic
at
the
bottom,
but
maybe
maybe
we
should
talk
about
it
now
since
you're
talking
about
it
so
I
a
see,
there's
a
new
board
that
still
created
and
that
one's
not
going
by
milestones
and
I
was
trying
to
find
the
links
to
the
milestone
ones
that
we
were
going
and
so
I
don't
know
which
ones.
So.
B
B
A
So
when
I
went
and
I
just
did
a
bunch
of
research
on
this
and
I
spoke
with
a
bunch
of
other
people,
and
it
also
sounds
like
they're
gonna
make
the
make
that
page
a
little
bit
more
clear
and
easier
for
people
to
understand
with
with
a
nice
graphic,
but
the
the
handoff
point
really
is
when
so
I
go
through
the
validation
track.
You
know,
I
identify
a
problem,
create
a
hypothesis.
Maybe
it's
an
experiment.
A
We
write
an
issue
if
it
needs
design,
I
work
with
Mackay
to
to
get
those
designs
created
and
then
what
we
do
is
we
sit
down
and
we
validate
the
issue.
We
scope
out
the
designs
and
then
it
moves
on
to
essentially
engineering
and
but
before
it
moves
on
to
engineering.
If
it's
a
big
enough
issue,
we
sit
down
and
we
do
a
essentially
a
planning
breakdown
which
would
involve
UX
engineering
NPM,
all
together.
Looking
at
the
issue
as
a
group
and
from
that
what
happens
is
essentially
the
breakdown
or
the
writing
of
additional
issues.
A
So
if
there
wasn't
enough
context
for
engineering
to
pick
them
up
or
if
additional
designs
were
needed,
that's
when
we
would
identify
that
once
that's
done
it
moves
to
ready
for
scheduling
and
ready
for
scheduling
is
really
the
notification
to
our
engineering
manager
for
them
to
say.
Okay,
now,
I
can
go
to
schedule
of
this.
One
of
the
core
things
I
feel
like
we
may
have
missed
when
we
were
at
fastboot
and
in
Vancouver
was
product
is
responsible
for
the
lot
and
engineering
is
responsible
for
the
land.
A
So
so
it's
gonna,
be
our
engineer.
Managers
job
to
really
kind
of
schedule
out
those
milestones,
I
can
figure
out
or
estimate
or
say,
hey
I
need
to
have
this
done
by
you
know
twelve
eight
or
twelve,
nine
ten,
but
really
it's
it's
dependent
upon.
You
know
the
engineering
schedule
so
I
can
I
can
only
take
it
up
to
a
certain
point
and
when
I
spoke
with
Phil
last
night,
he
basically
said
you
know
once
it
gets
to
to
scheduling.
You
know
it
comes
over
to
us
and
you
know
just
you
know.
A
That's
when
our
en
is
going
to
then
say:
okay,
this
is
ready
for
development
and
what
that
means
is
he
would
have
gone
through
or
the
engineering
manager
would
have
gone
through
and
said.
Okay.
This
can
be
scheduled
on
this
day
for
this
milestone.
It
has
this
weight.
You
know
all
that
kind
of
stuff.
So.
A
Workflow
scheduling,
that's
when
it
moves
from
from
validation
to
end,
but
then
I
guess
really
the
one
that
you
would
want
to
be.
Looking
for
in
your
on
your
chair
as
an
engineer
would
be
ready
for
development
because
it's
gonna,
it's
gonna,
be
in
that
kind
of
scheduling,
queue
until
Phil
says
yep.
It's
scheduled.
A
B
B
A
B
A
Let's,
let's,
let's
take
that
as
it
to
do,
and
we
can
Circle
up
with
Phil
and
have
him
chime
in
and
and
see
where,
where
he
wants
us
to
go.
Focus
specifically
for
engineering
I
would
imagine
that
it's
the
Billboard
but
I
could
be
wrong
and
when
I
think
about
milestones
milestones
for
for
product
for
our
traditional
product
group
of
really
really
important,
because
we're
trying
to
deliver
product
features
and
on
us
on
a
very
scheduled
and
specific
cadence.
A
Maybe
we're
trying
to
ship
something
new
for
a
product
bra
for
customer
who
requested
something
and
growth.
It's
a
it's
a
little
bit
different.
My
gut
tells
me-
and
we
should
probably
figure
this
out
with
Gila
and
the
rest
of
the
gang
is
that
you
know
our
milestones,
aren't
necessarily
dependent
upon
a
mile.
I
should
say
our
deliverables
aren't
necessarily
dependent
upon
of
milestone.
So
I
would
say
that
the
milestone
is
just
a
way
right
now
for
us
to
track
deliverables
by
my
house
tone.
Our
okay.
B
B
C
Was
going
to
ask
about
this?
Actually
so
I
yeah
I,
changed
I
think
for
issues
while
right,
the
ones
for
Korea
nudge
designs,
more
DMR
suggests
the
pipeline
stuff.
I
changed
them
today
from
design
to
ready
for
development,
but
if
I'm
understanding
this
correctly,
based
on
what
we
just
said,
I
think
I
should
have
changed
them
to
workflow
scheduling,
I.
B
Your
issues
are
underneath
you
I
des
UX
which
to
me
says
that
they
should
kind
of
be
closed.
Then,
at
that
point,
because
okay,
I'm,
not
sure
I,
see
working
on
your
issue,
I
mean
I.
Should
you
lose
your
issue
in
our
engineering
issue,
dunno?
What
to
do
I
guess
or
have
that
content?
Somehow
in
our
engineering
issue,
yeah
I'm,
not
sure
how
that
works.
A
They
are
related,
and
that's
that's
how
I
would
probably
do
it
is.
You
know
close
these
so
that
way,
you
know
we
know
that
matteo
you're
done
on
these.
These
were
closed
and
then
for
this,
in
this
instance,
we'll
just
update
the
engineering
issues,
but
I
think
if
we
were
to
step
back,
maybe
this
is
a
good
example
of
you
know
that
planning
breakdown
conversation
that
needs
to
happen
when
I
created
two
child
epics,
underneath
the
EMR
for
the
pipeline
issue,
I
and
one
was
for
design
and
one
was
for
engineering.
A
Maybe
we
don't
need
to
do
that
right.
Maybe
it
could
have
just
been.
These
are
the
issues
that
we're
gonna
need
designs
for
and
then
once
they're
done,
they
just
work
through
the
workflow
board.
That's
just
habit!
That's
old
habit
from
coming
from
me,
so
my
past
line
is
I
used
to
create
many
epics
for
design.
Many
epics
for
it.
They'd
have
many
epics
for
engineering,
I.
Think.
B
A
B
C
Quantifying
the
issues
I'm
not
required
to
because
we're
not
we're
not
our
performance
is
not
judged
based
on
the
number
of
issues
we
close
as
I
think
and
what
we
have
been
doing
so
far
or
what
I
did
with
the
managing
when
I
wasn't
manage
and
what
I've
seen
other
teams
do
as
well
is
just
used
the
same
issue
and
move
AIDS
through.
You
know
the
design,
the
validation
stage
of
design
stage,
then
once
it's
ready
in
this
case,
that's
why
I
also
did
this
I
changed
it
to
ready
for
development,
because
that
would
be.
C
You
know
the
progression
that
we
used
so
far,
so
that
you
have
that
issue
for
the
solution,
for
the
issue
is
already
in
that
issue.
Right
everything
is
described.
All
designs
are
attached
to
it,
so
you
don't
need
to
move
all
that
content
to
another
issue
right.
We
should
have
like
a
single
source
of
truth,
which
is
that
issue
and
just
move
through
all
these
stages.
So
that's
how
I
was
used
to
doing
stuff
until
now,
but
yeah
I
don't
mind.
A
I
think
sticking
with
how
the
rest
of
the
organization
is
is
operating
is
the
right
approach?
Okay,
so
how
about
for
this
one
I?
Just
we
can
just
update
I'll
update
the
these
issues
and
I'll
get
rid
of
the
ones
that
I
that
are
associated
with
these
from
an
engineering
perspective
and
I'll,
just
close
those
out
and
put
a
comment
in.
Why
I'm
and
then
moving
forward,
we'll
just
make
sure
that
we
address
these
during
the
planning
breakdown
on
stage
yeah
yeah.
C
That
make
sense
and
gives
with
the
assignees
change
throughout
the
process
right
so
initially
the
product
manager
in
the
designer
is
usually
assigned
when
the
validation
is
done
and
we
I
guess.
We
then
move
it
to
scheduling.
That's
when
the
engineering
manager,
I,
assume,
should
be
assigned
right.
Yep
and
engineering
manager
assigns
a
software
developer
right.
That's.
A
C
B
A
B
C
C
B
Yes,
the
next
one,
so
what
I'm
I'm
currently
working
on
is
that
I,
since
I
have
not
seen
any
that
are
actually
ready
for
engineering
development.
Besides
a
few
customer
application,
bugs
I
have
been
focusing
on
the
version
app
still
so
we're
linking
the
cusps
trying
to
figure
out
how
to
link
the
version
application
to
the
customer
application
in
the
UI,
and
we
determined
that
their
account
ID,
which
I
can
capture
from.
B
When
we
push
the
usage
ping.
It's
a
sales
force
which
back-ended
into
fixing
the
background
workers
to
pushes
that
we're
pushing
a
sales
force
that
we
can
get.
The
Thor
account
ID
record
on
the
person
application
side
and
then
find
a
way
to
hit
that
page
that
we
want
to
underneath
the
cuffs
the
admin
customers
area,
which
is
allowing
the
sales
team
to
then
go
in
and
personate
the
customer
and
deal
and
work
with
a
customer
to
modify
things
for
them.
B
B
A
A
C
Idea
suggesting
a
pipeline
on
request
without
a
pipeline
yeah,
yes,
I,
wrapped
wrapped
up
the
designs
they're,
not
that
different
from
the
initial
mock-ups,
which
I
guess
it's
a
good
thing
in
a
way,
we'll
see
how
successful
it
is
in
the
end,
but
I
still
want
to
do
so.
I
spoke
to
this
to
Jack
about
this
today
as
well.
The
popover
that
you
initially
show
right.
It's
quite
an
aggressive
way
of
you-
know
nudging
people
towards
doing
something
so
I
still
want.
C
The
next
issue
that
I'm
working
on
is
a
bit
more
attention
focused
actually,
but
it
should
get
a
quick
one,
but,
based
on
my
past
experience
with
working
with
retention,
things
that
look
small
actually
turn
out
to
be
quite
big.
I
hope
this
isn't
the
case
here
again
and
I'm
planning
to
start
working
on
the
next
six
corporate
next
week,
which
is
part
by
CIA
minutes.
So
we
should
get
a
lot
of
work
possible
work
out
of
that
as
well.
Right.
A
A
A
Item
three
is
what
we
want
to
work
on
next,
let's
just
skip
over
that
one,
as
midday
and
I
continue
to
build
out
the
backlog
and
then
I
I
feel
like
a
good
opportunity
really
just
to
do
a
quick
okay,
our
status
check,
one
of
the
questions
I
had
for
the
team
here
was,
you
know:
do
you
have
okay
ours
for
your
section,
similar
to
the
product
orc?
So,
for
instance,
a
product
expansion
is
responsible
for
one
deliverable
per
week.
A
For
the
month
per
week,
sorry,
so
that
gives
us
12
for
the
actual
quarter,
and
then
we
also
have
to
make
material
update
enhancements
to
to
the
workflows
that
were
responsible
for
I'm
gonna,
be
tracking
those
here
and
and
in
talking
about
them,
I'd
love.
Further,
you
all
to
do
the
same.
I
think
it's
really
important
that
we
all
understand
where
the
overlaps
are
for
our
groups
to
be
successful
as
a
team.
A
So
if
you,
if
you
don't
mind
just
adding
them
to
the
stock,
when
you
get
a
chance,
I'd
really
appreciate
it.
If
it's,
you
know
10m
ours
a
month
Doug
that
engineering
is
responsible
for
that.
Be
it'd,
be
nice
to
know
that
or
if
you
have
to
make
material
improvements
to
X
or
address
seven
bugs
or
whatever.
Those
are
I
think
that's
helpful,
and
then
you
know
for
UX
I'm,
not
sure
what
yours
are
my
table,
but
it'd
be.