►
From YouTube: Conversion team sync 2022-02-09
Description
Bi-weekly Conversion team sync - mid-milestone checkpoint
A
B
D
B
C
B
E
B
A
C
Same
we'll
try
and
make
sure
those
are
kept
up
to
date
and
we
minimize
the
pain
there,
but
every
now
and
then
I
don't
know
if
it's
logging
out
or
zoom
pushes
new
updates
meetings
will
just
like
break
or
disappear
so
continue.
Now
that
we
have
a
bigger
group
here,
I
had
added
some
topics
to
our
agenda
this
morning,
the
main
one
just
being
the
member
limits
for
the
free
sas
name
spaces
that
we'll
be
working
on
primarily
this
quarter.
C
I
wanted
to
make
sure
everyone
had
access
to
kind
of
the
full
comprehensive
set
of
assets
that
we're
using
for
that
strategy,
starting
with
the
overall
kind
of
free
user
efficiency
direction
that
sam
and
kenny
johnson
who's.
The
he's
head
of
the
ops
team,
correct,
sam
yep
and
he's
like
vp
level,
help
put
together.
That
gives
you
a
really
good
understanding
of
the
overall
kind
of
like
impetus
for
this
effort.
C
C
For
this
effort,
the
things
that
will
probably
be
most
useful
for
this
team
is
the
growth
conversion
implementing
sas
user
limits,
epic,
that
is
where
sam
and
I
have
been
organizing
all
of
our
work
with
regards
to
both
ux
and
engineering
related
to
the
free
user
limit,
mvc
and
also
capturing
kind
of
follow-on
work
that
we
will
like
to
do
once.
We've
implemented
those.
C
Happy
to
like
walk
through
those
epics,
if
that's
helpful
for
folks,
I
also
added
some
context
around
just
some
product
analytics
data
that
we
gathered
last
week
to
better
understand
as
we
go
forth
and
implement
this
five
user
limit
on
free
name
spaces.
What's
the
actual
kind
of
broad
impact
to
our
user
body
and
the
amount
of
name
spaces
that
we
have
currently
in
our
base.
C
We
shared
this
data
at
the
growth
weekly
yesterday,
so
some
of
you
may
have
seen
it
already,
but
figured
it
was
worth
sharing
again
just
so.
You
have
kind
of
an
understanding
of
the
actual
kind
of
total
impact
that
we
expect
to
see
and
as
we're
kind
of
working
through
the
exact
issues,
kind
of
how
that
relates.
A
Thanks
girl,
though,
I
think
I'll
add
it
to
what
gayle
already
mentioned.
I
think
just
taking
a
step
back
on
on
why
this
is
important
to
the
business,
the
free
product,
we're
continuing
to
see
more
and
more
people
sign
up
and
use
the
free
product,
which
is
great,
but
we
are
on
pace
for
it
to
cost
us
roughly
30
million
dollars
this
coming
year,
which
I
I
don't
know
the
exact
number
off
the
top
of
my
head.
A
But
I
think
it's
like
a
quarter
of
the
marketing
budget
to
support
just
the
free
users.
So
the
business
was
really
kind
of
or
the
executive
team
was
really
pushing
like.
How
do
we
get
that
cost
down
and
increase
the
rate
at
which
people
move
from
free
to
paid?
And
there
are
two
kind
of
core
reasons
why
it
cost
us
that
much
one
was
this:
the
amount
of
storage
that
we
gave,
people
which
technically
was
10
gigabytes
per
project
and
you
could
have
unlimited
projects.
A
So
there's
other
teams
that
are
working
on
implementing
a
namespace
level
storage
limit
and
ensuring
that
people
can
properly
manage
their
storage
and
purchase
additional
storage,
and
there
will
also
be
some
sort
of
data
transfer
cap
associated
with
that
as
well.
So
another
team
is
gonna
work
on
that
that
will
reduce
a
lot
of
the
costs,
but
even
after
doing
that
analysis,
it
was
very
clear
that
the
free
product
is
simply
too
valuable.
A
A
The
one
thing
I'll
also
add
here,
doug's
already
done
a
great
job
of
digging
in
here.
There's
some
existing
feature,
work
done
by
the
fulfillment
team
that
specific
customers
have
asked
for
to
add
a
user
cap
as
a
paying
customer.
So
they
don't
go
over
their
number
of
seats
that
they're
paying.
For
so
let's
say
they
bought
100
seats.
They
can
set
their
cap
to
100
so
that
they
know
there
won't
be
any
overages
during
the
year.
A
A
D
A
A
How
they
can
create
a
group
and
move
an
existing
project
into
that
group,
which
has
its
own
kind
of
just
like
technical
concerns
with
it?
So
well,
it's
not
the
easiest
thing
for
users
to
do,
but
it
will
be
important
for
them,
especially
once
this
limit
is
imposed
and
doug
just
a
call
out
here,
as
we
worked
through
this
in
the
last
week.
A
I
I
realized,
we're
probably
I'm
going
to
create
a
spike
issue
for
us
as
a
team
just
to
investigate
how
the
using
the
user
cap
feature
for
the
five
member
limit.
How
that
will
work
for
projects
that
technically
aren't
in
a
group
because,
like
I
guess
the
personal
namespace
might
technically
be
a
group,
so
it
would
still
work.
I
I
I
don't
know.
F
F
F
There's
two
things
right:
remediating
the
records,
the
people,
the
the
one
remediating
the
data,
the
the
projects
that
are
over
the
limit
right
now
and
then
enforcing
it,
going
forward
right
two
different,
two
things.
I
don't
see
an
issue
with
that,
because
the
project,
when
you
go
as
far
as
most
mostly
in
a
project
it
doesn't
care
who
the
parent
is
it
just
in
that
sense
they
operate
the
same
way
as
far
as
like
inviting
members
goes,
and
things
like
that.
Okay,.
A
Okay,
I
I
know
there
will
be
other
issues
like
they
can't
upgrade
or
start
trial,
or
so
I
think
regardless.
We
want
them
to
ideally
move
their
project
into
a
group
if
possible,
but
it's
good
to
hear
that
at
least
the
the
limit
should
work,
because
we
don't
that
would
be
a
decent
sized
back
door
that
we
wouldn't
want
to
kind
of
ideally
leave
open.
F
D
C
Camille
asked
now
that
we
have
internal
rationale.
How
does
this
work
for?
The
public
will
be
some
campaign
that
educates
users
about
upcoming
changes
and
prepares
them
for
this,
so
we
are
working
with
the
pmm
team
to
get
this
user
limit
announcement
incorporated
into
a
larger
blog
post
around
the
upcoming
storage
limits.
D
E
C
C
We
are
kind
of
going
back
and
forth
with
her
right
now
about
the
strategy
for
informing
users
more
directly,
there's
a
blog
post,
blog
post
that
will
be
sent
out,
but
not
everyone
is
going
to
read
that
there
will
be
emails
at
some
point,
but
timing
seems
to
be
kind
of
of
the
question
and
debate
right
now.
Is
that
how
you
interpret
it?
Sam.
A
Yeah
and
and
the
clearance
we've
gotten
thus
far,
is
that
we
are
okay
to
develop
in
public,
especially
for
our
back
kind
of
back
end
work,
and
if
somebody
finds
it
in
somehow,
you
know
we're
comfortable
with
that
risk,
but
kind
of
more
obvious
front.
End
work
of
like,
like
emily's,
already
started
doing
some
great
work
on
like
what
banner
messages
could
look
like
or
what
the
updates
in
the
members
modal
would
look
like.
I
think
we
should
reserve
that
kind
of
front.
D
F
Well,
I
don't.
I
don't
understand
that
part
of
front
end
versus
the
back
end.
The
words
will
be
the
same
and
I'll
be
behind
a
feature
flag
that
won't
be
turned
on.
So
what
would
be
the
the
difference?
Is
your
thought
that
someone
will
be
able
to
parse
the
front
end
code
easier
than
they
would
the
back
end
code.
F
F
We're
we're
fine
there,
because
that's
usually
where
the
screenshots
are.
You
know
what
I
mean.
They
won't
actually
be
in
the
code,
but
my
fear
was
like
in
general,
was
when
a
branch
when
the
code
gets
in,
like
people
could
see
it
and
they
could
see
your
branch,
but
they
won't
have
access
to
the
merge
requests,
though,
if
we
keep
them
confidential.
A
C
We'll
also
keep
you
up
to
date
around
the
broader
like
as
the
messaging
campaign
and
plan
comes
together.
We
are
definitely
pushing
for
the
sooner
notification.
The
better
it's
sam-
and
I
kind
of
think
about
this,
like
how
you
would
treat
deprecation
messaging
like
it's
fair
to.
Let
users
know
as
soon
as
possible
that
a
change
is
coming
and
give
them
as
much
lead
time
and
direction
so
that
no
one
is
caught
off
guard
and
no
one
is
put
in
situations
that
are
unduly
painful
when
the
change
actually
goes
in
to
place.
C
A
B
A
C
A
A
And
just
for
reference,
you
know
that
email
will
not
be
something
that
our
team
has
to
manage.
We
can
we'll
work
with
the
product
analytics
team
to
get
a
export
of
the
email
addresses
and
partner
with
somebody
in
marketing
to
just
send
the
email
out
of
the
marketing
system,
so
that
won't
just
for
reference.
It's
not
gonna.
We
don't
have
to
worry
about
doing
something,
weird
with
mailgun
and
all
that
we'll
just
use
the
marketing
team
system.
F
So,
on
that
note
sam,
I
had
a
question
about
an
earlier
data
analytics
issue
that
that
it
was
on,
but
I
know
that
was
the
right
place
to
ask
it.
So
I
didn't.
But
how
are
we
calculating?
How
let's
put
this
way?
Are
we
calculating
the
number
of
users
in
these
namespaces
the
same
way
we
are
in
the
code?
F
A
F
C
D
C
B
Right
so
I
I
just
wanted
to
to
know
if
we
are
doing
some
check-ins
about.
You
know
milestone
progress
on
those
calls
or
we
do
them
offline,
or
I
think
that
was
one
thing
and
another
was
gathering
some
feedback
on
planning
issue
which
we
started
talking
about
in
the
previous
planning,
and
we
could
try
some
improvements
in
in
the
current
upcoming
14.9
planning
issue,
which
I
already
created,
but
we
can
do
some
small
improvements.
B
C
C
And
then,
as
far
as
just
check-ins,
from
my
perspective,
we
kind
of
the
individual
kind
of
drives
how
they
want
to
manage
their
check-ins.
I
know
dallas
is
pretty
consistent
about
adding
kind
of
a
weekly
async
update.
There's
a
template
for
that
in
the
handbook
that
can
be
used,
not
a
requirement
we'll
probably
be
touching,
based
on
14-8
issues
that
are
still
in
development
over
the
next
few
days,
just
to
get
a
sense
of
where
they're
at
and
if
we
should
expect
them
to
carry
into
14.92
as
pm's.