►
From YouTube: July Direction update for Analytics
Description
Bonus content below!
Presentation with hyperlinks to epics and issues.
https://docs.google.com/presentation/d/1ElReTjfL8shwKl77G5Z3IKYOuQBa08bKFsuPPRZIZk8/edit
Script:
https://docs.google.com/document/d/1LDMXNh2u1w_7zkyNwfDh7zpcpZKRmhoQ8YTsUlPT3a0/edit
00:00 Recap of direction as of January
03:22 These seven insights are as relevant today as they were in January.
03:54 My one reservation is about using DevOps Lifecycle in the Product UI.
05:36 Helping with adoption of plan is important for the business.
06:15 Learning #1 - The need for a way to tell the story about GitLab's metrics or dashboard offerings isn't isn't just a problem for the 13 analytics capabilities, it is a problem across the GitLab product.
08:36 Learning #2 - Refocussing value stream investments in an interactive experience that generates daily use.
10:44 Learning #3 - We need to make it easier and faster to get breadth across the lifecycle and focusing on a metrics library and generic capabilities will help.
12:09 Engaging other teams to build up the library.
12:48 New Diagram for Analytics Categories
A
Hello
and
welcome
I'm
John
Shackleford
product
manager
for
analytics
here
at
get
lab
today,
I
want
to
share
with
you
a
few
thoughts
about
the
evolution
of
our
strategy
for
the
analytics
area
back
in
January
Jeremy
Watson
shared
with
us
a
vision
about
how
to
unify
the
13
different
analytics
capabilities.
We
have
today
into
a
single
cohesive
story,
centered
around
the
flow
of
value
through
the
stages
of
the
DevOps
lifecycle
that
the
10
DevOps
lifecycle
stages
could
represent
a
value
stream
that
would
resonate
with
our
customers
was
a
great
insight.
A
It
provides
a
framework
for
describing
how
our
existing
capabilities
fit
together,
and
it
also
helps
us
map
out
opportunities
for
further
investment.
Jeremy
showed
how
a
feature
such
as
code
review,
analytics
and
productivity
analytics,
or
a
drill
in
on
some
aspect
of
the
value
stream,
highlighting
opportunities
to
streamline
a
particular
part
of
the
overall
flow.
A
We've
got
this
DevOps
lifecycle
across
the
top,
representing
the
value
stream
key
metrics
below
it,
and
then
a
chart
with
a
data
table
below
for
further
exploration.
The
report
object
as
Nick
calls
it
with
a
fiction
is
born,
and
then
we
went
on
to
reimagine
how
existing
features
like
productivity
analytics
or
it
could
be
reimagined
into
this
new
framework
and
we'd
also
decided
to
focus
on
metrics
that
are
areas
of
interest
for
our
customers,
such
as
the
doora
metrics
or
the
flow
framework.
A
Metrics
I
think
there
are
seven
fundamental
insights
behind
this
plan
and
they
really
resonated
me
with
me
when
I
first
saw
this
video
back
in
January,
and
these
are
the
seven
points.
First,
we've
got
13
different
analytics
capabilities
and
we
need
a
story
that
rationalizes
them
and
provides
a
framework
for
thinking
about
the
future.
To
the
value
stream
idea
is
a
perfect
fit
for
what
we're
trying
to
achieve,
and
it
gives
us
a
way
to
think
about
the
future
3.
A
If
we
use
the
stages
of
the
DevOps
lifecycle
as
a
way
to
structure
our
offerings,
it
can
help
us
even
depict
a
value
stream
in
the
UI.
For
we
need
a
consistent
user
experience,
Thank
You
Nick
and
existing
capabilities,
such
as
productivity
analytics,
could
be
read
envisions
to
fit
into
this
framework.
You
should
focus
on
metrics
our
customers
care
about
and
invest
in
the
planning
stage.
A
Of
course,
I've
left
out
a
few
points
about
the
different
tiers
product
group
instance
tiers
and
so
on,
and
the
idea
of
transforming
the
DevOps
core
and
to
being
more
about
ROI
and
measures
of
value,
but
I
think
that
captures
these
seven
things
capturing
the
most
salient
points
of
a
strategy,
so
we're
in
July
now
what's
changed
well.
The
first
point
is
that
I
think
all
of
these
insights
are
just
as
fundamental
now
as
when
I
first
heard
them
back
in
January.
A
A
So
we
live
these
stages
day
in
and
day
out,
every
time
we
create
an
issue
or
an
M
R.
We
fix
a
label
to
it,
indicating
which
stage
or
subgroup
were
part
of
it's
part
of
our
organization
structure
and
and
fundamental
to
the
way
we
think
about
I'm,
getting
like
as
an
organization
and
there's
a
product.
But
this
is
not
really
true
of
our
customers.
Even
big
fans
of
get
lab
are
not
going
to
have
these
ten
stages
top
of
mind,
and
especially
large
enterprises
tend
to
invest
in
their
own
process
frameworks.
A
They
come
up
with
their
own
name
nomenclature
about
how
IT
works
in
their
organization.
They
train
people
on
it
and
so
on,
and
they
tend
to
bristle
a
little
bit
when
other
nomenclature
and
process
frameworks
feel
like
they're
being
impose
or
are
competing
with
the
messages
and
terminology
that
they're
using
themselves
and
analysts
have
warned
us
about.
This
very
directly
have
been
confused
by
the
order
of
the
different
stages
in
the
lifecycle
and
I've
even
had
conversations
with
folks
in
marketing
that
have
said
hey.
A
We
should
be
too
careful
about
baking
in
our
organization
structure
into
our
UI,
so
that
area
is
one
I've
got
a
little
reservation
about
I
think
we
need
to
watch
carefully
and
collect
feedback
on
the
rest
of
them.
Make
a
ton
of
sense
to
me
and
I
think
everything
I've
seen
really
underscores
the
importance
of
number
seven
here,
investing
in
the
planning
stage.
This
is
given
the
way
that
stage
adoption
translates
into
growth
for
us
in
terms
of
expansion,
at
a
particular
customer
site
upgrades
to
higher
tiers
and
so
on.
A
Probably
unblocking
plan
adoption
by
creating
some
of
those
analytics
capabilities
that
project
managers
are
after
it
is
important
not
just
for
us
and
for
plan,
but
really
for
the
whole
business.
Okay.
So
let's
talk
about
the
three
learnings
the
first
I
want
to
talk
about.
Is
this
idea
for
a
unifying
theme
or
structure
to
bring
together
these
disparate
capabilities
and
I?
A
A
Whenever
customers
ask
us
the
question,
they
tell
us
about
get
labs
dashboards
or
the
metrics
that
you
have
it's
it's
kind
of
a
tough
story.
We
have
slide
decks
that
take
you
through
many
many
different
screens.
We've
got
demos
that
involve
lots
of
different
screens
to
try
to
answer
customers,
questions
about
what
dashboards
or
metrics
we
have
in
the
product.
Now
we
actually
create
this
question
because
when
we
sell
get
lab,
we
talk
about
helping
them,
go
faster,
improving
their
cycle
times
and
so
on.
A
They
say
show
me,
then
we
have
to
answer
this
question
about
dashboards
and
so
on.
I
don't
have
evidence
that
this
has
cost
us
any
deals,
but
in
the
demos
that
I've
observed
it's
a
frequent
source
of
disappointment
with
customers,
the
response
that
we
get
it
to
do
this
is
not
wow.
You
can
do
a
lot,
but
well,
it
looks
like
you
may
have
what
I
need
that
it's
really
hard
to
tell
I
guess
we
could
live
with
that
or
even
though
I
guess
you
just
don't
really
have
dashboards.
A
I'm
gonna
have
to
use
an
open-source
one
like
idea.
When
are
you
guys
gonna
solve
this
and
get
lab
and
I
think
to
remove
some
of
that
disappointment
and
friction
in
our
in
our
sales
process
and
then
our
customers
usage
of
the
tool?
This
is
a
really
important
thing
to
tackle,
not
so
much
because
it's
a
super
exciting
feature,
because
it's
expected
our
competitors
have
it.
This
is,
and
and
and
I've
seen
this
as
a
frequent
source
of
annoyance
or
disappointment
from
existing
customers
or
prospects.
A
The
Weisse
three
markets
heated
up
quite
a
bit
lately,
there's
a
lot
of
innovation.
Innovation
in
the
space
I've
witnessed
this
firsthand
before
I
joined
gitlab.
We
did
a
tour
of
analyst
briefings.
Retox,
probably
10
different
analysts
at
three
different
firms,
and
they
confirmed
this
with
very
concrete
examples
and
they
were
very
direct
with
us
about
how
advanced
our
competitors
have
have
come
in
the
last
18
to
24
months.
A
One
of
the
really
important
pieces
of
feedback
from
those
engagements
and
I
have
had
this
confirmed
by
customers
as
well
is
that
are
the
images
that
we
depict
of
the
future
state
of
value
stream
with
those
page
objects
does
not
resonate
with
people
familiar
with
vai
stream
offerings
as
a
value
stream
process,
mapping
kind
of
capability.
It
looks
to
them
like
a
dashboard,
not
like
a
value
stream
map
or
any
kind
of
representation
of
the
value
stream.
A
They're,
not
interactive
and
they're
not
likely
to
generate
a
lot
of
daily
use
to
drive
up
analytics
are
excuses.
I,
don't
think
it
means
we
don't
do
that.
Those
page
objects
I.
Think.
That's
really
important.
That's
part
of
that
dashboarding
and
reporting
story
that
we
need
to
tell
we
still
want
to
build
out
those
dorra,
metrics
and
so
on,
but
I
think
what
we
want.
The
centerpiece
of
our
value
stream
capability
to
be
is
is
a
visualization.
That's
going
to
be
and
sort
of
a
next-gen
of
a
Kanban
board.
A
That's
really
aligned
device
dream
that
has
our
rich
experience
around
being
able
to
see
things
through
the
flow
and
and
interact
with
them
in
order
to
build
that
we're
gonna,
need
it
more
sophisticated
data
model
and
calculation
system
to
support
that
it's
gonna
take
us
some
time
to
get
there.
In
the
meantime,
we
can
make
a
lot
of
progress
on
I'm
telling
that
story
with
dashboards
and
reports
and
scaling
it
and
when
it
comes
to
scale.
A
I
think
it's
really
important
that
we
have
a
framework
in
place
that
allows
us
to
do
this
many
times
and
go
for
for
breath.
You
know
if
we,
if
we
take
the
approach
where
we're
going
to
address
each
stage
of
the
develops
lifecycle
with
a
new
drill-down
experience,
that's
fairly
rich,
like
code
review
analytics.
For
example,
it's
going
to
take
us
a
long
time
to
get
this
kind
of
breadth.
We
need
to
tell
that
whole
gate
lab
story.
A
Instead,
we
want
to
lower
the
bar
by
making
it
so
that
all
we
have
to
do
is
figure
out
how
to
render
a
given
metric
and
all
the
other
work,
the
dashboarding
the
report
pages
and
so
on.
It's
just
a
it's
a
generic
capability.
If
we
were
only
doing
you
know
five
or
ten
of
these,
then
the
overhead
of
a
framework
investment
might
not
make
a
lot
of
sense.
But
you
know
the
number
of
metrics
that
we're
talking
about
hitting
is
closer
to
twenty
or
thirty
than
you
know.
A
A
How
does
this
work
in
the
real
world?
Well,
the
cross
stage?
Collaboration
can
be
tricky.
We
want
to
definitely
avoid
dependencies
and
weighting,
but
what
we
can
do
is
go
where
there's
already
momentum
and
action
and
find
out
how
to
contribute
to
that
by
making
what
other
stages
are
trying
to
achieve
easier
and
also
then
having
by
their
adoption
of
capabilities
like
the
report
pages
and
dashboards
drive
traffic
back
to
the
analytics
area.
So
that's
a
win
for
everybody.
A
Is
that
metrics
library
and
the
specific
kind
of
drill
downs
that
we
have
talked
about,
like
planning,
analytics
code
analytics
and
so
on
really
start
to
point
to
subcategories
of
that
metrics
library.
Please
feel
free
to
explore
this.
It's
all
hyperlinked
to
issues
and
epics,
where
there's
a
lot
more
detail,
would
love
to
have
your
questions
and
suggestions
thanks
a
lot.