►
From YouTube: Product Group Conversation (Public Stream) 2022-03-08
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
Station
for
tuesday
march,
the
8th
this
is
product
gets
to
host
this
week,
so
super
excited
and
we'll
jump
right
into
questions
gila.
It
looks
like
you
have
the
first
one,
oh
not
here,
voiced
by
david
david.
B
A
Synergy
is
my
favorite
word,
so
I
think
personally,
I'm
the
most
excited
to
learn
more
about
pricing,
that's
sort
of
my
weakest
or
area
of
leased
experience
in
my
my
career-
and
you
know,
I've
been
a
part
of
some
big
pricing
related
changes
such
as
eoa
in
the
last
year,
and
so
I'm
excited
to
sort
of
learn
how
it
works
beyond
sort
of
the
execution
and
implementation
of
those
changes.
A
But
but,
broadly
speaking,
what
I'm
most
excited
about
is
synergies
is
a
great
word
but
like
yes,
connecting
the
dots
between
sort
of
our
pricing
and
go
to
market
strategy
to
what
our
growth
teams
do
in
helping
convert,
free
users
to
paid
users
and
onboard
our
customers,
and
then
the
actual
commerce
and
transaction
pieces
of
fulfillment,
keith
and
hila,
and
I,
prior
to
this
change
and
prior
to
product
monetization
being
a
thing.
We're
collaborating
a
lot
already,
and
so
now.
A
This
creates
an
opportunity
where
we
can
align
our
strategy
and
vision
and
direction
for
that
entire
sort
of
group
of
sections
and
sort
of
achieve
work
to
achieve
some
of
the
really
ambitious
goals
we
have.
You
know
things
with
for
user
first
order,
e-commerce.
A
Those
will
all
be
even
more
possible
because
we're
collaborating
in
that
way.
Now.
B
I
do
again
as
hello
regarding
the
e-commerce
self-service
transaction
metric.
Do
you
envision
the
target
for
smb
self-service
transaction
share
percentage
to
be
100?
Reading
from
the
notes,
it
seems
that
this
metric
is
influenced
by
many
factors
such
as
product
flow
and
sales
processes.
Can
you
share
any
more
insights
on
the
metric.
A
Yeah,
it's
a
great
question.
Our
target
right
now
is
95,
but
I
do
think
I
guess
the
denominator
of
that
chart
is
all
transactions.
A
I
don't
know
if
we'd
ever
get
to
100
of
all
transactions
from
smb
flows
through
the
web
store,
but
I
do
think
that
every
smb
customer
ought
to
be
able
to
transact
self-service
right,
and
so
we
have
now
a
self-service
sales
team
who
you
imagine
shall
back
up
when
you,
when
you
see
a
lot
of
these
smb
transactions
today,
they
look
and
feel
a
lot
similar
to
like
a
mid
market
or
enterprise
transaction.
There's
a
quoting
process.
There's
a
sales
cycle
granted
that
sales
cycle
is
much
shorter
than
a
larger
enterprise
account.
A
Naturally,
but
sort
of
the
paperwork
process
looks
and
feels
very
similar,
ideally
what
we
get
and
what
the
the
our
self-service
sales
team
can
help
with
is
driving
efficiency.
So
maybe
the
customer
starts
by
talking
to
you
know
a
git
lab
team
member
that
conversation
might
happen
only
over
email.
Maybe
it
happens
over
a
chat
module
on
the
website
or
on
the
web
store,
maybe
they're
texting
who
knows,
but
then
the
customer
is
able
to
transact
or
sort
of
finish
their
transaction
through
like
a
digital
medium.
A
So
I
that's
sort
of
a
abstract
way
to
answer
the
question,
but
I'd
say
yes,
I
could
see
100
of
our
customers
being
able
to
transact
digitally
smb
customers
being
able
to
transact
digitally,
but
I
think
they'll
always
be
cases
where
that
one
of
those
customers
might
need
to
transact
complicated
order.
Maybe
there's
a
high
lam
account
or
something
like
that
that
transacts
traditionally
with
an
ae.
B
Follow
question
on
voicing
on
behalf
of
myself:
would
it
be
fair
to
say
that
there's
like
a
size
of
transaction
that
should
be
e-commerce
self-service
because
we'll
have
an
easy-to-use
intuitive
self-service
process?
B
The
reason
for
the
clarification
question
you
could
have
so
when
you,
when
I
hear
smb,
I
think
of
like
very
small
companies
when
I
hear
bid
market,
you
know
obviously
certain
size
and
going
up,
but
we
could
have
first
lands
of
enterprise
accounts
that
could
be
smaller
and
they
should
be
able
to
also
self-service
if
they
they
choose
to
do
that.
That
makes
sense.
A
Yes
makes
perfect
sense
and
that's
a
great
way
to
designate
it.
It's
not
necessarily
just
smbl,
though
that's
naturally
aligns
closely
yeah.
It
is
smaller,
first
orders
right
now.
The
simple
sort
of
designation
is
well.
Is
the
customer
willing
to
pay
with
a
credit
card
and
for
a
large
enough
order,
most
credit
cards
in
the
world?
A
Don't
allow
that
and
so
that's
sort
of
the
distinction
today,
but
in
the
future,
if
we
add
to
ach
transactions
or
something
like
that,
you
can
see
that
number
growing,
but
yeah,
that's
a
great
that's
a
great
designation
is,
is
order
size.
C
Yeah
hi
justin,
so
a
few
weeks
ago
I
did
a
mapping
between
features,
xiaomi
paid
features
so
premium
and
ultimate
and
service
service
ping,
metrics
key
paths
and
I'm
finding
that
50
of
the
paid
features
we
have
in
features
yaml.
Don't
are
not
instrumented,
basically
for
self-managed,
so
to
speak,
and
also
it's
a
bit
inconsistent.
So
there
are
sometimes
we
have
like
the
monthly
active
user
metrics.
Sometimes
we
have
objects
counts.
Sometimes
we
have
both.
Sometimes
we
don't
have
anything.
So
I'm
wondering
why
that
is.
C
Are
there
like
guidelines
missing,
maybe
or
incomplete,
on
when
to
implement
these
these
these
metrics?
And
how
and
the
second
question
would
be
if,
if
there's
any
plans
to
to
alleviate
that
issue,
maybe
align
metrics
between
sas,
which
are
much
more
comprehensive,
that
we
have
in
size
and
threat
and
the
self-managed
service
ping
metrics.
A
Yeah,
it's
a
great
question
and
if
amanda's
on
the
call
I
might
pass
some
of
this
to
her,
but
at
a
high
level
you're
not
wrong.
I
guess
I.
I
still
want
to
look
at
some
of
the
data
to
understand
like
what
is
causing
or
what
what
exactly
the
sort
of
the
variables
are,
but
in
general,
there's
still
a
lot
of
room
for
improvement
on,
especially
our
self-managed
service
ping.
A
Data
collection
for
those
unfamiliar
service
ping
is
a
a
set
of
aggregate
counts
that
sort
of
increment
on
a
customer's
instance
every
day
and
then
once
a
week
or
so
we
collect
a
payload
from
that
instance,
and
so
you
know
instant
x
might
increment.
Oh
each
time
an
issue
is
viewed
or
something
like
that.
It
increments
a
number
and
then
once
a
week
we
capture
that
number.
So
we
don't
know
the
like
click
stream
for
lack
of
a
better
word
for
that
data
set.
A
We
just
know
that
at
this
point
in
time,
on
march
the
8th
we
collected-
you
know
data
from
this
instance,
and
this
is
the
count.
Whereas
on
sas
we
have
de-identified
or
pseudo-anonymized
click
stream
data,
so
user
x
took
these
four
actions,
and
that
is
clickstream,
and
that
is
you
know
effectively.
A
You
know
real
time
and
so
to
answer
your
question
broadly
and
then
hand
it
to
amanda
who
has
better
and
more
specific
answers.
Yes,
there's
a
lot
of
room
for
improvement,
especially
on
the
self-managed
side.
A
We've
made
great
progress
over
the
last
six
or
12
months,
where
we
now
have
better
designations
between
like
operational
and
optional
data
service
things
a
lot
more
reliable
than
it
ever
was,
but
there's
still
a
long
roadmap
ahead
of
us
amanda.
D
D
Current
experience
in
instrumenting
at
get
lab
is
not
a
great
one,
and
so
what
I'm
focused
on
at
the
moment
is
actually
interviewing.
Sorry.
D
Chirping,
so
what
I'm
focused
on
at
the
moment
is
interviews
with
our
developers
and
our
pms
to
understand.
Why
is
it
so
hard?
Where
are
those
gaps
and
trying
to
influence
our
short-term
and
longer-term
roadmap,
but
by
the
end
of
this
year,
where
we
want
to
be
is
parity
for
sas
and
self-managed,
where
we're
we're
getting
the
same
types
of
metrics,
whether
they're
counters
or
their
events,
on
both
platforms?
D
So
a
couple
of
things
that
are
in
process
at
as
of
this
moment
is
we're
conducting
a
pilot
to
figure
out
how
to
use
snowplow
to
create
kind
of
counter-based
metrics
for
name
spaces
and
sas,
so
that
you
can
measure
the
number
of
epics
on
an
instance
versus
the
number
of
epics
on
a
namespace,
for
example,
we're
next
going
to
self-manage
and
implementing
snowplow
events
so
that
you
can
get
event
space
to
the
user
level
as
much
as
justin
mentioned
on
self-managed
as
well.
D
At
the
point
where
we
have
parity
in
what
we're
collecting.
We
should
then
identify
as
a
business.
What
do
we
find
the
most
valuable
and
maybe
trim
down
to
a
single
strategy
at
that
point?
So
that's
kind
of
where
we're
going
in
terms
of
should
we
should
we
instrument
every
feature.
Should
we
have
feature
to
instrumentation
parity?
Probably,
but
I
don't
think
we
have
an
infrastructure
to
support
that.
Yet.
A
Thank
you
both
yeah,
a
couple
things
that
add
to
this
too,
which
sort
of
answers
your
okay,
a
question
you
suggested
guidelines.
I
agree
with
you.
I
think
we
could
do
better
at
providing
more
guidelines
to
individual
stage
groups,
especially
as
we
mature
these
systems,
it's
sort
of
been
what
you're
viewing
is
like
the
history
of
get
lab
in
data
right.
So
this
team
was
added
at
this
point
and
they
had
this
point
of
view
on
how
it
should
work.
So
they
took
this.
A
You
know
approach
right,
but
we've
lacked
consistency
over
the
years
which
is
sort
of
you're,
probably
seeing
and
then.
In
addition,
you
know
our
our
taxonomy
isn't
consistent
right.
I
guess
related
our
taxonomy
isn't
consistent.
So
point
is,
as
we
mature.
I
think
it
makes
sense
to
provide
better
guidelines.
I
think
an
okr
is
an
interesting
idea
to
consider
sort
of
to,
I
would
say,
implement
and
clean
up
right.
The
instrumentation
so
yeah
definitely
take
that
into
consideration.
A
Do
know
anyway.
I
think
you're,
realizing
this,
like
each
team
is
responsible
for
the
instrumentation
of
their
metrics.
So
each
stage
group,
if
it's,
if
it's
verify
or
create
those
teams,
are
the
ones
implementing,
but
but
if
they
have
strong
guidelines
and
clean
taxonomy
and
schema
definition,
then
it
can.
We
can
make
it
easier
for
them.
E
Yeah
I'll
just
verbalize
this
and
then
fill
in
the
blanks
later
so
slide.
Nine
talks
about
the
eligibility
of
cloud
license
adoption
and
you
know
we
see
it
go
down
over
time
as
subscriptions
come
up
for
renewal.
I'm
curious
if
we
know
the
percentage
that
will
never
be
eligible
because
they
have
a
custom,
non-standard
msa
and
if
there's
a
way
to
work
around
that
without
or
and
apply
that
to
the
mutually
agreed
upon
terms
with
that
customer.
A
Yeah
great
question,
so
the
short
answer
is
all
customers
eventually
will
be
eligible
right
right
now:
we've
intentionally
skipped
customers
with
custom
msas
only
because
we
lack
the
visibility
into
what
language
is
in
their
msa.
It's
hard
unless
you
are
willing
to
manually,
go
review
each
msa,
so
we're
the
legal
team's
working
on
tools
to
give
us
better,
better
visibility
there.
A
But
it's
fine
today,
if,
if
a
customer
wanted
to
do
a
contract
reset
or
sort
of
revisit
that
msa
at
the
time
of
renewal,
they
absolutely
can,
and
then
we
can
include
cloud
license
with
that
and
I
think,
broadly
speaking,
our
preference
would
be.
There
are
some
msas
out
there
that
are
fairly
old
and
so
we'd
love
to
get
those
on
some
modern,
more
modern
terms
right,
so
that
sort
of
generally
speaking,
100
of
customers
eventually
will
be
eligible.
A
The
mechanics
of
how
we
go
about
dealing
with
that
at
scale
for
these
customers
that
have
custom
terms,
it's
still
tbd,
but
you
know
expect
over
the
next
six
months
or
so
for
some
of
the
plan
there
and
the
other
thing
I'd
add
to.
I
don't
know
if
this
was
implied
in
your
question,
but
some
of
what's
some
of
those
customers
in
those
msas
have
sort
of
negotiated
out
or
wanted
out
of
the
option
of
transmitting
the
usage
data
or
trans
transmitting
any
sort
of
data
from
their
instance
to
gitlab
servers.
A
I'll
give
a
personal
anecdote.
I
spoke
with
a
customer
last
week
where
once
they
understood
that
the
data
in
quotes
isn't
like
source
code
or
snippets
from
repositories,
or
you
know,
artifacts
or
whatever,
and
it's
aggregate
counts
of
things
for
cloud
license
bare
minimum.
It's
it's.
The
aggregate
counts
of
of
seat
utilization.
A
They
were
totally
fine
with
it
right
and
in
some
cases
where
a
customer
maybe
has
like
a
national
security
charter
or
something
like
that.
We're
working
on
sort
of
an
offline
cloud
license
which
sounds
silly
in
some
in
some
cases.
How
is
it
in
the
cloud
it's
offline
but
but
the
gist
is
the
customer
can
review
their
data
or
review
the
the
payload
and
they
manually
upload
it.
A
So
if
they're
in
an
air
gapped
environment,
for
example,
they
can
pull
that
data
out
of
the
air
gap
environment
and
then
from
a
from
a
workstation
that
is
connected
to
the
internet,
upload
it
to
sort
of
the
cloud
licensing
intake
system.
So
the
point
is
we'll
have
every
way
that
a
customer
needs
to
be
able
to
send
us
data
and
and
activate
their
instance
with
cloud
license,
including
custom
msas
will
be
able
to
support
that.
A
Great
thanks
for
the
question
I'll
pause
for
a
few
seconds
more
to
see
if
there's
any
other
questions
feel
free
and
verbalize
too.