►
From YouTube: Demystifying the Metrics Conversation
Description
David with Field Enablement and John with Product Marketing discuss 2-3 of the common reasons why sales reps struggle with Metrics in the sales conversation; and highlight a few practical tips to overcome these challenges.
Notes Doc:
https://docs.google.com/document/d/1S5g424xQuQ_XJ9PW4SUSvHG6bMpsLoBc8B7ivnnYYY0/edit?usp=sharing
B
B
B
B
B
C
B
B
All
right,
so
less
than
one
out
of
five
have
watched
the
videos,
so
that'll
be
a
key
piece
today
of
one
of
the
calls
to
action
is
to
do
carve
out
some
time.
There's
some
really
really
compelling
resources
on
that
page.
I've
gotten
a
lot
of
positive
feedback
from
your
peers
that
have
checked
it
out
and
all
right.
One
more
question:
one
more.
B
Poll
so
I
mentioned
that
many
sellers
find
the
metrics
conversation
difficult.
So
this
question
is:
what
do
you
find
to
be
the
most
difficult
part,
so
choose
the
one
answer
that
is
most
applicable.
If
you
don't
see
one
that
resonates
with
you,
there
is
an
other
option.
What
we'd
love
for
you
to
do
is,
if
you
choose
other,
please
put
you
know
what
is
your
challenge
in
the
chat
window?
B
B
A
B
Thanks
everybody
thanks
for
providing
your
input
and
again,
if
you
put
other,
if
you
would
please
put
those,
but
what
your
other
comment
would
be
in
the
chat
window.
We'll
take
a
look
at
that
later,
so
the
rest
of
this
session
today
we're
going
to
pivot
to
talking
about
five
practical
tips
to
help
make
this
metrics
conversation
less
intimidating.
B
B
And
the
first
one
we'll
talk
about
so
we're
not
going
to
cover
everything
here,
but
one
of
them
is
what
you
shared
right.
Is
that
nico
talks
about
the
challenge
that
most
organizations
are
simply
not
measuring
today,
and
I
view
this
and
hope
you
do
as
well.
It's
like
this
is
an
opportunity.
This
is
your
chance.
You
are
the
subject
matter
expert.
We
are
the
subject
matter,
experts
on
how
to
help
them
get
to
where
they
can
measure
the
efficacy
of
their
software
development
practices.
B
So
lean
into
that
right,
you
are
the
trusted
advisor.
So,
first
and
foremost,
I
think
it's
a
mindset
shift
of
just
knowing
that
this
is
an
opportunity
for
you
to
add
value.
To
that
conversation,
your
call
to
action
for
this
section
as
embracing
the
role
as
the
trusted
advisor
is
to
check
out
these
videos.
B
B
Is
that
true
of
your
organization
right,
great
place
to
start
the
conversation
and
then
nico
also
talks
about
it
as
playing
the
role
of
the
trusted
advisor?
It's
absolutely
critical.
We
understand
what
problems
our
technology
helps
to
solve
and
that's
exactly
the
really
the
purpose
of
customer
use
cases
so
encourage
everybody,
and
it
will
continue
to
repeat
that
of
use
case
use
case
use
case
really
help
helping
customers
understand
where
and
how
git
lab
is
uniquely
positioned
to
be
the
best
solution
to
solve
those
challenges.
A
A
I
want
to
show
an
image,
because
I
think
it's
relevant
based
on
what
you
just
said,
david,
because
if,
if
we're
really
talking
about
use
cases,
what
is
a
use
case
right
and-
and
I
I've
used
this
view-
I've
created
this
view
recently
to
help
really
illustrate
to
simplify
this.
The
use
case
is
really
about
people
personas,
who
have
a
problem
in
their
development
life
cycle
in
their
workflow.
That
problem
is
costing
them
money.
It's
causing
a
problem.
A
There's
there
there
they
need
to
fix
that
problem,
and
so,
when
we
built
the
use
cases,
we
built
it
around
understanding
what
trying
to
understand
what
those
problems
are
and
then
how
does
gitlab
uniquely
solve
that
problem
and
all
of
the
work
we've
been
doing
for
the
last
several
months
has
been
all
around.
How
do
we
better
define
and
document
what
these
problems
and
pain
points
are,
and
so
the
term
use
case
just
set?
A
It
aside
just
realize
we're
focusing
on
their
problems
and
their
solutions
and
and
our
solutions
to
how
do
we
help
them
solve
that
problem?
So
as
we
get
into
this
and
as
as
you
meet
with
customers,
really
the
opportunity
that
all
of
you
have
and
I'll
say
this
a
couple
of
times,
I
think,
is
an
opportunity
to
learn.
A
You
know
from
each
of
them,
as
you
have
your
conversations
and
as
you
listen
and
start
to
tell
stories
right.
The
stories
that
that
you
want
to
try
to
be
able
to
tell
are
are
stories
of
how
we've
helped
other
people
to
solve
similar
problems.
I
don't
know
if
mark's
on
mark
crits
is
he
on
I'm
going
to
call
mark
out.
Mark
did
it
yesterday
and
today
in
commit
where
he
told
a
story
about
how
so
many
of
his
customers
in
the
intelligence
community
have
this
air-gapped
network
problem.
A
So
he
tells
a
story
about
the
problem
they're
having
and
how
gitlab
then
solves
that,
and
he
did
it.
He
did
a
gitlab
presentation.
He
did
a
commit
presentation
on
it
specifically,
but
those
stories
are
what
allows
you
to
connect
and,
as
you
listen
and
you
start
to
tell
those
stories
whether
it's
case
studies
that
we've
published
for
you
take
goldman
sachs
as
an
example,
you
could
take
other
case
studies
that
have
really
really
solid
metrics
about
showing
the
benefit
and
improvement.
A
We
can
start
to
then
connect
with
customers
and
they
can
start
to
understand
both
better
about
their
problem
and
how
it's
been
solved
and
how
other
people
have
measured
solving
their
problem,
but
it
really
means
carefully
listening
and
one
of
the
things
I've
I
I've.
I've
stressed
it's
a
lot
of
people
and-
and
I
know
ryan,
when
you've
taught
people
about
note
taking
and
doing
discovery
calls
it's.
It's
active
listening
to
start
to
understand
what
their
problems
are
and
where
their
problems
are.
So
we
can
start
to
tease
out
well,
what's
the
benefit?
A
C
Thank
you.
So
you
know
I'm
just
three
months
in
to
this
role
and
I'm
curious
to
understand.
We
I
it's
like.
We
reference
a
lot
of
enterprise,
sized
customers
with
our
case
studies
and
I'm
curious
to
know
from
your
perspective,
what
commercial
customers
customer
stories
could
the
commercial
team
utilize
in
their
storytelling
to
help
their
customers
understand
the
metrics
that
matter
the
most
to
that
segment,
and
I
want
us
to
think
about
it
from
both
an
smb
and
a
mid-market
perspective.
A
A
There,
david
in
the
proof,
points
link
on
the
left,
there's
a
link
to
it.
That
takes
you
to
a
proof,
points
page.
That
has
all
the
proof
points
in
a
single
handbook
page,
but
here
we've
highlighted
it
based
upon
the
different
value,
drivers
and
you'll
notice
that
we've
organized
it
based
upon
mid
market
or
smb
and
and
what
I
one
of
the
things
we've
done
recently
is:
we've
we've
pulled
from
the
proof
points
page,
some
of
the
ones
we
think
are
highlighted
and
worth
highlighting
here
where
in
fact
there
are
metrics
associated.
A
You
take
a
look
at
chorus
as
an
example
that
you
know
of
how
they
reduce
cycle
time.
They've
built
faster,
and
you
know,
that's
a
story
about
get
lab
ultimate
right
and
how
they
incorporated
security
or
jasper
solutions,
how
they
also
reduce
cycle
time.
So
the
metrics
are
there
and
I
don't
think
the
metrics.
I
don't
think
these
metrics
are
fundamentally
different
because
of
the
size
of
my
organization.
A
C
A
These
were
all
enterprise
customers,
but
they
talked
to
them
about
the
economic
impact
of
rolling
out
gitlab
and
they
gathered
that
data
and
then
the
other
one
that
I
think
is
worth
noting
and
mahesh
is
going
to
do
enablement
on
it
next
week
we
added
the
links
to
it
here
is
he's
he's
been
working
on
building
a
a
roi
model?
That's
both
standardized
and
he's
going
to
do
enablement
on
that,
and
so
I
included
links
to
both
his
slides
and
the
model
sheet
here.
So
you
have
that
as
available
as
well.
C
A
D
It
so
there's
a
couple
proof
points
I
added
in
the
notes.
So
chris
hill
did
a
talk
and
he
talks
about
the
metrics
piece
for
t-mobile
with
aws.
So
there's
a
webinar.
We
did
you
can
so
a
lot
of
times.
It's
better
to
have
the
customer
tell
the
story
than
us
telling
the
story
if
there's
another
customer
struggling
with
metrics
and
chris
kind
of
using
some
of
the
door
examples
in
there,
and
then
there
was
another
one
I
threw
in
there.
I
lost
the
document.
D
D
You
talk
about
and
then
there's
another
customer
smb.
I
think
they
were
issue
track.
I
got
to
find
the
list,
they
were
talking
about
a
whole
bunch
of
metrics
and
why
it
was
good.
It
just
wasn't
pulled
out
specifically
as
metrics
we
might.
There
was
a
lot
of
really
good
examples.
Yesterday
is
all
I'm
trying
to
say:
that's
it
no.
A
Yesterday
was
fantastic
and
we're
going
to
be
call
cultivating
and
pulling
from
that
some
of
these
stories,
because
these
are
the
things
they're
going
to
live
on.
We
had
over
almost
100
speakers
different
different
speakers
who
presented
so
it's
awesome,
but
thank
you
for
that
adam
and
you're
spot
on.
So
let
me
talk.
A
I
want
to
talk
a
little
bit
about
the
kind
of
metrics
you
should
be
looking
for,
and
I
think
at
the
simplest
of
terms
there
and
we
included
in
here
there's
two
different
metrics
right,
there's
a
metric
of
the
economic
impact
and-
and
you
think,
about
business
metrics
of
what
is
the
business
impact
that
a
a
change
will
have
of
we're
talking
about
increasing
revenue,
we're
talking
about
lowering
cost.
You
know
we're
talking
about
the
the
fundamental
metrics
that
are
going
to
make
that
are
going
to
drive
people
making
business
decisions
about.
A
You
know
they're
going
to
buy
or
whether
they're
going
to
buy
something
or
not
at
the
end
of
the
day-
and
this
is
this
kelly
may
be
true-
that
in
in
commercial
and
smaller
organization,
it
may
be
less
true,
but
I
know
in
large
enterprises
when
anytime
there's
a
large
purchase
of
a
significant
amount
of
money.
I
think
it's
really
relative
to
the
organization.
A
A
There
is
a
process
for
all
of
them
and
they
have
to
be
able
to
demonstrate
and
talk
about
what
will
be
the
business
impact
of
how
they're
going
to
do
that
and
the
more
we
can
become
dialed
into
understanding
those
business
metrics.
The
metrics
that
are
really
related
to
revenue
related
to
growth
related
to
lowering
costs
related
to
lowering
risk.
If
you're
talking
to
the
public
sector
a
lot
of
times,
they
will
quantify
risk,
then
it's
going
to
be
easier
for
them
to
make
the
business
case.
A
What
is
it
devops,
research
and
assessment
team?
It
was
a
little
group
started
by
nicole
forsgren
and
jean
kim
and
jez
humble,
and
they
started
three
years
ago
or
four
years
ago,
going
off
doing
really
detailed
research
into
devops
adoption
and
nicole,
because
she's
a
statistician
and
has
a
phd
in
numbers.
I
think
they
have
a
phd
in
numbers.
A
A
How
often
are
they
deploying
that's
pretty
straightforward,
pretty
simple:
how
long
does
it
take
from
an
eye
from
when
they
start
put
a
change
to
when
it
gets
to
production
lead
time?
It's
called
lead
time
in
in
in
the
industry.
You
could
call
it
cycle
time.
The
way
we
would
call
it,
but
it's
the
mean
lead
time
for
changes
cycle.
Time
is
a
lot
of
times
what
we
would
call
it.
A
The
the
keynotes
again
is
the
team
at
google
google
acquired
dora,
google
bought
dora
last
year
and
then
nicole
forsgren.
She
went
to
go
work
at
github,
but
jess
humble
and
the
dora
stuff
still
lives
at
google
cloud
and
google
cloud
has
taken
it
a
step
farther
and
they've
actually
built
a
tool
that
will
suck
the
data
out
of
an
existing
system
and
they
actually
talk
about
it
in
their
keynote
and
will
showcase
the
data.
The
real
data
from
an
existing
devops
tool
chain,
as
in
in
those
four
dimensions-
very
cool
stuff.
A
It's
stored
on
github
today
that
the
project
is
it's
open
source
and
I
actually
have
an
open
issue
with
dan
and
a
couple
other
people
to
think
about.
How
can
we
take
this
and
adopt
it
for
us?
I
also
have
another
conversation
with
my
unc
about
well.
If
google
cloud's
our
partner,
why
wouldn't
they
move
their
stuff
to
get
lab
versus
github,
so
two
separate
conversations,
but
it's
a
really
powerful
thing
to
get
to,
but
understanding
in
your
conversations,
these
four
metrics
will
raise
your
knowledge
and
will
raise
your
profile
with
customers.
E
E
A
Well,
I
mean
we,
I
think
we
are
on
some
levels.
I
mean
if
you
look
at
the
at
currently
in
the
git
lab
in
the
way
we
measure
cycle
analytics
and
the
way
we
have
capabilities
of
measuring
things
within
gitlab.
In
fact,
we
are
at
some
level,
but
but
the
point
of
this
conversation
to
be
clear
is
is
less
about
gitlab
the
product
is
more
about
us
having
these
conversations
with
our
prospects
about
the
metrics
that
matter
in
in
their
organizations
to
try
to
try
to
drive
the
conversations
in
that
direction.
So.
A
I
don't
know
yeah,
but
we
can
go
down
and
pass
things
yeah
yeah
and
when
you
talk
about
the
metrics
inside
the
tool
when
we
start
to
talk
about
value
stream,
management
and
understanding
what
the
value
stream
is
of,
of
how
we're
managing
and
measuring
the
value
that
we're
delivering,
we
have
a
whole
team
focusing
on
that
from
a
product
perspective.
And,
frankly,
if
you
look
at
where
the
market
is
going
and
you
talk
to
gartner
and
forester
and
analysts
value
stream
management
is
going
to
become
a
more
and
more
hot
topic.
A
In
fact,
gartner's
future
work
around
measuring
the
tool
chain
and
doing
research.
It's
going
to
be
more
around
value
stream
as
this
forest.
Both
of
them
are
moving
in
that
direction,
so
so
stay
tuned,
but
I
don't
I
don't
want.
I
don't
want
to
get
too
far
off
onto
that.
I
want
to
stay
on
this
because
I
want
to
make
sure
that,
as
we
come
out
of
this,
that
the
team
is
able
to
feel
more
confident
having
some
conversations
to
know
where
there's
some
resources
to
learn
more
to
have
those
conversations.
E
It
was
a
year
and
a
half
ago
now
on
site,
they
loved
it,
and
then
they
have
invited
me
again
to
come
back
this
time
virtually
and
present
on
the
19
report
results
because
there
are
some
fundamental
differences
there.
So
I'm
in
my
neck,
deep
right
now
studying
the
report
and
doing
exactly
that
and
sharing
on
the
virtual
conference.
A
Thank
you,
hugo,
but
that
you're
spot
on
the
door
report
is,
is
brilliant.
There's
a
they
wrote
a
book
about
it.
If
you
want
to
go
even
deeper,
yeah
accelerate
but
just
start
with
these
and
ask
the
questions
and
learn
and-
and
I
think
that's
really
key
david-
do
you
want
to
talk
about
positive
business
outcomes
a
little
bit?
I
know
I'm
watching
time.
I'm
going.
I've
talked
too
long,
yeah.
B
So
if
you're,
if
you
understand
what
your
primary
your
customers
primary
value
driver
is,
these
are
some
suggestions
of
more
of
the
technical
metrics
that
you
might
want
to
talk
about
of
the
software
development
process.
So
question
for
you,
so
why
why
do
you
feel
like?
Why
do
you
think
it's
it's
important
to
connect
the
positive
business
outcomes
with
the
technical
metrics.
B
All
right
I'll
tell
you
now,
I'm
sure
you've
got
other
insights
as
well,
but
it's
you
know:
you're
the
subject
again:
you're
a
couple
of
reasons:
you're
the
subject
matter
expert
you
you've
seen:
we've
talked
about
it.
You
see
nick
nico's,
video.
Many
organizations
are
not
doing
this
right,
so
you
can
provide
unique
insights
that
differentiate
you
from
other
folks
that
they're
talking
to
by
providing
that
connection,
but
probably
maybe
more
importantly
than
that
is
this-
is
this
goes
hand
in
hand
with
conversations
with
your
champion.
B
If
you
can
successfully
help
your
champion
understand
how
those
technical
metrics
empower
enable
the
positive
business
outcomes,
that's
going
to
help
them,
sell
it
internally
to
those
folks
that
sign
the
checks.
So
it's
super
critical
and
the
best
way
I
can
think
to
reinforce
that
and
make
sure
you're
working
with
your
champion
to
amplify.
That
message
is
the
mantra
right
so
think
about
what
I
hear
you
saying,
mr
mrs
customer
is
that
these
are
the
positive
business
outcomes
that
you're
you're
trying
to
achieve
to
achieve
those.
B
These
are
the
required
capabilities
that
you
need
and
you'll
probably
want
to
measure
those
required
capabilities
with
some
of
these
metrics
right.
But
let's
now,
let's
tell
you
how
we
do
it,
how
we
do
it
different
and
better
than
anybody
else
and
don't
take
my
word
for
it.
But
here's
the
proof
points.
So
please,
please
make
sure
you
continue
to
think
about
application
at
least
mental
model
of
the
mantra
so
that
you're
connecting
those
positive
business
outcomes
to
the
metrics
john
one
last
tip.
A
Know
your
proof
points
I
mean
the
the
proof
points
that
are
both
in
the
value
framework:
the
google
doc,
whichever
version
you're
looking
at
you
know,
that's
a
subset
of
them.
We
have
them
all
listed
in
a
detailed
web
page.
Those
proof
points
I
think
are
golden.
They
should
be
relatively
easy
to
put
your
hands
on.
You
shouldn't
be
familiar
with
them
depending
upon
the
market
you're
in
the
store
you
want
to
tell
they've.
A
They
all
have
tags
in
them
about
whether
we're
talking
about
ci
or
cd,
about
the
different
use
cases
that
are
relevant.
We
have
they're
tagged
about
what
version
of
git
lab
they
used
what
market
they
were
in,
so
there's
all
sorts
of
little
ways.
You
could
search
that
and
find
them,
so
you
don't
necessarily
have
to
memorize
them
all.
A
Lord
knows
I
don't,
but
you
should
be
able
to
read
them
really
quickly
and
pick
out
what
you're
looking
for
and
then
then
they're
all
hyperlinked
to
the
actual
case,
study
of
the
actual
details
so
use
those,
because
those
are
ways
to
demonstrate
that
in
fact,
others
like
them
have
achieved
similar
kinds
of
outcomes.
So
and
then
you
know
the
value
framework.
I
can't
I
can't
stress
enough
we've
this.
This
is
the
one
year
birthday
of
the
value
framework.
B
I
see
we
are
in
time
to
take
us
home
these,
so
a
few
calls
to
action
that
are
listed
in
the
note
stock,
but
just
to
verbalize
them
here.
Please,
please,
do
make
the
time
you
know
carve
out
some
time
to
review
the
resources
on
this
on
this
page
and
I'd
encourage
you
to
you,
know:
self-assess,
look
if,
if
there's
one
or
two
of
the
tips
that
we
shared
today,
that
you
would
like
to
personally
improve
upon
like
focus
on
that
and
really
and
ask
others
about
how
they
do
it.
B
If
you've
got
best
practices,
we
don't
pretend
that
this
is
right.
This
is
our
first
iteration.
We
would
love
feedback,
so
share
the
feedback
with
your
program
manager
for
your
team
of
what
hey.
What
else
do
you
need?
What
could
be
most
helpful
so
that
on
our
next
iteration,
we
can
continue
to
improve
if
you've
got
best
practices
to
share
for
any
of
these,
please
share
those
with
your
program
manager,
your
enablement
program
manager,
because
we'd
love
to
capture
those.
B
Lastly,
due
to
make
sure
you
tune
in
next
week,
again,
mahesh
is
going
to
do
a
session
on
the
roi
model
and,
as
always,
we
love
and
welcome
your
feedback.
So
there's
a
link
to
the
survey
in
the
google
notes
doc.
So
please,
let
us
know
how
we
did
and
where
and
how
we
can
improve
all
right.
Thanks
so
much
everybody
appreciate
the
active
participation.
Talk
to
you
soon,
thanks.
Everyone
have
a
good
day.