►
From YouTube: Ops Strategy Review - E-Group
Description
A
C
C
A
Mark
just
to
dive
in
on
that
a
little
bit,
you
know.
One
of
the
concerns
that
you
raised
in
the
product
leadership
review
was
this
notion
that
we
weren't
signalling
appropriately
our
long
term
intent
and
so
like,
like.
We
could
also
add
something
that
says
first
and
then
have
another
sentence
that
says,
and
then
over
the
three-year
horizon.
We
plan
to
improve
our
support
for
traditional
operators,
I
just
I.
From
my
perspective,
I
used
this
document
to
signal
primarily
to
internal
teams
what
we're
focused
on
and
what
needs
to
be
a
priority.
C
A
C
A
It
responded
in
my
mind,
Kate's
management
and
then
infrastructure
as
code
kubernetes
management
and
then
infrastructure
as
code,
but
I
do
think.
We
should
discuss
this.
What
I'm?
What
I
gather
from
the
product
marketing
the
strategic
marketing
team
is
that
our
planned
rollout
of
use
cases
is
going
to
immediately
start
targeting
get
ops,
and
so
we
could
adjust
prioritization
so
that
we're
working
on
I
mean
you
can
do
get
ups
today
with
gitlab.
A
A
A
Sorry,
yeah
I,
don't
think
that's
the
case.
I
think
you
could
tell
Agra
top
story
today
without
the
terraform
integration,
there's
tons
of
customers
who
use
get
lab
for
infrastructure
as
code
today,
we've
got
tons
of
use
cases
for
it.
There's
just
there's
not
a
lot
of
special
sauce
there
you're
using
our
source,
control
and
CI
to
do
it.
The
terraform
integration
is
our
first
hint
of
special
sauce.
A
B
A
B
My
guess
my
point
was
the
reason
I
actually
reprioritized
it
up
was
because
of
the
Alliance
team's
request
to
do
more
with
hash
leak
or
canal
and
now
I'm
hearing
that
we're
not
quite
ready
to
do
that.
It's
like,
let's
make
sure
we,
you
know
triangulate
there
so
that
I'll
go
back
and
work
that
okay
and
you
should
feel
like.
You
have
input
into
the
use
case,
kind
of
maturity
and
roll
out.
First,
okay,
cool.
C
D
E
A
Today
it
is
like
we
would
do
an
MVC
in
order
to
establish
ourselves
there
and
not
move
forward.
I
will
say
the
team
is
actively
considering
improving
or
updating
its
priority
or
elevating
its
priority.
We
have
kind
of
core
things
that
we
need
to
do
around
dogfooding
and
metrics,
and
these
kind
of
core
monitoring
experiences
but
I
do
think.
A
There's
some
value
in
establishing
ourselves
with
these
new
types
of
data
sources
around
these
are
experiences
some
more
DevOps
friendly
operations
workflow,
if
that
makes
sense,
because
you're
focused
on
what
your
actual
user
is
experiencing,
rather
than
some
system
metric
or
something
like
that.
So
it's
more
forward
facing
future
market
facing,
but
we
have
so
much
that
we
need
to
tackle
today
that
I
think
that
debate
is
still
ongoing.
So
today
it's
priority
is
low.
A
This,
the
staffs
page
one
is-
was
previously
not
considered
a
high
presence
eras
in
the
rooms
there's
the
manager
for
covering
that
that
area,
the
stuffs,
which
was
previously
not
a
priority,
but
in
realizing
that,
in
order
to
dog
food,
our
incident
management
capabilities
within
the
ops
team,
we
really
needed
this
Status
page
capability.
It
would
unlock
their
use
of
dogs
reading.
So
it
has
immediately
jumps
to
a
high
priority.
The
team
is
super
focused
on
it
in
12.9.
D
A
Some
additional
work
in
fall
ten,
but
I
don't
expect
in
syrup.
Please
correct
me
if
I'm
wrong
I,
don't
expect
ongoing
improvements
to
that
beyond
that.
Now
that
we're
dogfighting,
we'll
probably
get
a
lot
of
requests
for
improvement,
but
I
don't
expect
it
to
be
a
high
priority,
so
that
is
Status,
page
I'll
pause
there,
okay
and
then
on
error
tracking.
A
Similarly,
we
have
improved
their
tracking
I
think
it's
moving
to
viable
in
twelve
nine,
and
then
we
will
be
dogfooding
Ansel's,
we're
continuing
to
increase
the
dogfighting
of
error
tracking,
we'll
get
additional
feedback
from
that
and
have
to
make
decisions
about
prioritizing,
but
again,
I.
Don't
expect
it
to
have
significant
additional
prioritization.
A
Yeah,
it's
interesting
so
I've
been
when
you
think
about
when
we
start
dog
training
a
part
of
the
product,
it
is
immediately
going
to
put
pressure
on
us
increasing
its
prioritization
and
I.
Think
that
will
cause
tension
about
whether
or
not
we
wants
to
prioritize
the
kind
of
adding
additional
in
some
cases,
gonna
be
adding
support,
cutting
dog
fruiting
for
additional
functionality
so
like
if
we
want
to
support
dog
footing
the
triage
workflow,
but
we're
already
dog,
training,
error,
tracking
and
incident
management,
there's
going
to
be
a
tension
between.
A
Should
we
improve
our
capabilities
to
enhance
the
dog
fooding
of
error,
tracking
and
instant
management
or
work
on
building
support
for
the
new
workflow.
So
I,
just
I
know
that
as
one
of
the
values
of
dog
for
knees,
you're
gonna
get
feedback
and
that's
going
to
affect
your
prioritization.
But
there
are
still
new
dog
fruiting
initiatives.
We're
gonna
have
to
go
drive
and
we'll
have
trade-offs
between
existing
dog
fooding.
F
Number
six
I
was
curious.
This
is
I
had
actually
similar
to
a
country
driving
earlier
at
the
high
level,
but
you
don't
need
to
put
it
into
these
three
categories,
but
just
curious
how
you're
thinking
about
the
percentage
of
the
product
investment
this
year
and
how
much
of
that
is
some
things
that
you
expect
to
get
adopted
and
get
Smouse
quickly
versus
over
the
long
term.
Yeah.
A
That's
a
great
question:
I
would
in
blanket
terms
think
of
our
configure
investment
as
things
that
we
want
to
get
returned
on
this
year.
Those
are
places
where
we're
hoping
we
get
increased
cloud
native
adoption
and
the
kind
of
kubernetes
management
and
infrastructure
as
code
pieces
are
already
used
cases.
Our
users
are
hungry
for
the
investments
in
monitor
I
think
it
is
like.
A
A
It's
a
great
thought
experiment,
though,
to
think
about.
Where
are
we
investing
in
long
term
versus
short
term?
I?
Think
I
saw
an
mr
this
morning
you
all
must
have
had
a
discussion
about
investments,
thesis
tears,
but
I
do
think
of
monitor,
as
in
is
of
all
the
categories,
maybe
other
stages
other
than
defend
the
one
where
we're
in
the
most
longer-term
investment
to
here
do.
F
F
A
I
have
analyst
data
I,
don't
have
like
direct
survey
data
from
our
customers,
but
certainly
the
analysts
suggest
that
and
they
think
of
it
in
terms
of
workload,
not
necessarily
organizations.
There
are
organizations
who
plan
to
get
started
and
then
what
what
applications
are
moving
and
they
expect
I
think
in
by
2828
sin,
then
I
think
by
2023.
They
expect
thirty,
five
percent
or
something
of
applications
to
be
cloud
native
deployed
so
increasing
rapidly.
A
Why
the
entity
key
we
as
an
example
of
one
that
we've
spoken
to
recently,
that
their
platform
team
has
been
kind
of
one
of
our
primary
outreaches,
but
we've
not
done
a
survey
as
far
as
I
know.
That
says,
within
your
use
of
get
lab.
How
many
the
question
I
would
ask
is
a
little
bit
less
communities
and
more?
How
much
are
you
how
much
containerization
do
you
have
if
your
continued
rising
your
apps,
that's
a
good
target
for
us
for
the
point
in
Tsukuba
days,
if
you're,
not
it's
a
difficult
client.
F
I
appreciate
the
you
know,
you
answered
my
question.
Seven,
the
my
interest
in
those
those
three
most
strategically
important
capabilities
is
just
it's
helpful
for
me
to
sort
of
frame
and
how
the
teams
to
be
talking
bugs
with
customers.
What
we
really
expect
is
going
to
be
the
meat
of
that
conversation,
because
I
think
a
lot
of
the
a
lot
of
the
capabilities
that
we
spend
time
talking
about,
can
get
us
off
track
and
I.
Think
if
we
can
get,
we
know
where
to
return
or
to
yeah.
You
say:
look
eighty
percent
of
time.
F
A
And
the
one
new
one
that
I
think
in
our
product
leadership
off-site
I
suggested
adding
to
the
like.
Not
our
current
strategy
in
ops,
one
but
I
think
is
an
interesting
one
that
I'd
love
to
get
your
take
on
McBride.
Is
this
the
number
three
incident
management
which
is
regardless
of
how
you're
doing
I
just
like
how
you're
monitoring
your
application
are,
deploying
your
application
or,
where
you're
deploying
it?
A
If,
if
we
could
convince
you
to
just
create
your
instance
and
collaborate
with
developers
for
responding
to
those
incidents
or
whoever's
responders
instance,
in
get
lab
with
our
incident
management
capabilities,
we've
kind
of
like
locked
them
into
the
complete
cycle,
and
then
we
can
pick
off
their
usage
of
those
tools
on
either
end
of
this
I.
Think
of
this
is
like
we've
got
you
on
CI
and
we've
got
you
on
incident
management.
F
Love
the
idea
of
the
features
having
a
specific
place
in
the
customer
journey
and
there's
a
reason
why
that
feature
is
helping
conversion
but
we're
also
like
a
deaf
lawyer.
Chloe.
Do
you
look
at
the
in
a
whole
section,
but
you're
gonna
zoom
into
these
three?
Are
these
the
three
that
you
wouldn't
service?
Oh
yeah,
those
actually
past
announce
me
defect
the
most
high-value
capabilities
we
would
be
talking
about
or
their
other
things
that
is
actually
more
likely
to
spend
time
on
X
and
then
get.
C
F
C
D
A
Yeah,
we
have
intentionally
deprioritized
clustered
cost
management.
There
are
some
things
we
could
do
to
set
up
basic
alerts
for
when
your
clusters
are
over-provisioned
or
you're,
basically
like
wasting
resources,
but
that
I
don't
think
we
have
the
kubernetes
usage
today
to
effectively
play
in
there,
especially
when
there
are
existing
competitors
that
are
kind
of,
like
specifically
focused
on
install
this
thing
on
your
cluster.
They
get
closer
to
get
an
improvement
on
your
cluster
cost.
F
If
the
usage
before
the
optimization
yeah
all
right
in
seven
at
number,
eight
as
well,
this
was
I
think
you
made
just
answer
this:
not
only
writing
of
any
of
your
previous
cancer
trying
to
sandwich
CD,
as
the
customer
motion
is,
that
did
I
hear
that
correctly
or
very
different
customer
motion.
Do
you
think
that's
good?
Oh.
A
Yeah,
sorry,
that
is
not
our
current
customer
motion.
It's
one
we're
considering
as
a
primary
set
of
priorities.
Today
we
are
planning
on
essentially
like
feeling
for
specific
use
cases
lightly,
filling
in
the
whole
workflow
so
including
CD.
So,
if
you're
on
kubernetes
and
you
can
use
our
kubernetes
management,
install
these
apps
for
your
platform
teams,
monitor
them
with
our
tools
and
get
incident
management.
That
is
an
explicit
strategy
that
says
we're
kind
of
foregoing
the
I.
A
Don't
care
what
you
do
in
between
whether
you're
using
kubernetes
or
not
I'm,
just
gonna
capture
your
incident
management
strategy.
So
we
are
not
pursuing
that
today.
We
have
some
capabilities
in
incident
management
that
allow
you
to
do
that.
But
it's
not
a
explicit
motion
that
we're
pursuing
today.
It
could
be
one
that
we
do
yeah.
So
our
current
motion
is
that
next
step
of
we
know
lots
of
people
get
stuck
on
CD
because
they
don't
have
a
good
understanding
of
kubernetes.
A
F
A
F
A
A
So
I
was
trying
to
think
of
like
the
lightful
moments
that
aren't
just
oh,
you
get
you
get
the
same
thing
that
you
would
get
from
three
tools,
but
in
one
tool
and
so
I
put
some
of
them
down,
but
I
think
it's
a
great
challenge
for
the
team
to
think
through
what
are
those
delightful
moments
that
would
be
unique,
so
the
one
I'll
just
verbalize,
one
that
I
thought
of
was
in
incident
triage.
If
we
could
immediately
showcase
to
you,
hey,
there's
a
stack
trace
in
this
incident.
A
Let
me
tell
you
who
the
developer
was:
who
last
touched
that
line
of
code
where
the
stack
trace
ends
right?
That's
a
thing
that
no
other
tool
I'm
aware
of
can
make
those
kinds
of
connections
and
is
a
way
delightful
experience
and
then
the
other
one
was
when
you
start
a
new
project
setting
it
up
for
operations
so
like
giving
the
project
a
an
infrastructure
project
in
infrastructure
definition,
project
connection
to
some
run
books
where
they
can
define
how
they
operate
that
and
continue
to
iterate
on
it.
Today.
A
F
That's
all
the
and
see
you
know
the
other
reason.
Why
did
I
think
this
is
an
important
one
for
us
to
be
able
to
answer
it
really
in
every
section,
but
whatever
stages
is
getting
a
customer
to
light
capabilities
is
a
lot
easier
than
getting
a
few
of
the
convince
their
company.
So
you
think
change
and
usually
need
a
pretty
dramatic
difference
in
order
to
actually
cost
an
organization
to
make
change
in
to
get
budget
and
things
like
that
and
where
we
have
unique
differentiators,
where
somebody
can
go
and
say,
look
yeah.
F
F
D
A
That's
awesome,
I
will
share
last
week.
I
did
nós
briefing,
maybe
it
was
just
Monday.
Are
they
no
spoofing
with
the
red
monk
team
and
one
of
the
things
they
kind
of
pushed
back
on
was.
It
seems
like
we're
telling
a
story
that
is
integration
story
and
that
to
your
point
like
that,
integration
is
not
what
sells.
The
thing
that
sells
is
some
like
delightful
capability
that
no
other
that,
as
a
result
of
your
integration,
nobody
else
can
replace
the
thing
that
they
went
to
was.
A
Actually
they
were
commenting
on
my
presentation
that
I
kind
of
skipped
over
the
fact
that
we
do
review
apps
and
they're
like,
but
that's
the
thing
that
is
so
unique
to
get
lab
that
only
get
lab
does
as
a
result
of
this
integration,
and
those
are
the
things
that
you
should
be
popping
out
and
saying.
Nobody
else
does
review
apps.
F
Todd
for
product
marketing,
yeah
I
think
we
could
probably
be
more
explicit.
It
might
be
good
for
us
to
do
a
quick
sort
of
run
through
with
product
and
pick
the
you
know,
six
to
nine.
You
know
maybe
there's
one
per
stage
like
that
unique
differentiator
that
we
think
really
are
ones
that
we
can
call
out
that
nobody
else
does
just
so
when
we're
trying
to
give
is
because
typically.
F
All
right,
no
ten,
this
was
so
I
see
your
questionnaire,
but
I
must
not
I.
Don't
think
I
asked
my
question.
Well,
the
what
I
was
trying
to
ask
is
on
the
secure
direction
page.
It
says
we're
targeting
developers,
developer,
team
security,
team,
SEC,
Ops
teams,
way
engineers,
QA
teams,
but
end
of
the
day.
If
there's
one
person,
maybe
two
that
are
gonna,
actually
be
a
champion
and
go
push
and
advocate
and
tell
Eric
I'm
not
going
to
give
up
at
you.
A
A
Another
way
that
you
hear
about
this
in
the
industry
is
they
call
it
like
a
managed
service
provider
in
the
sense
that
they
are
providing
underlying
services
for
their
developers,
including
things
like
a
platform
and
a
platform
to
deploy
their
applications
to,
as
well
as
tools
to
use
for
monitoring
and
logging,
their
application
and
common
tools
like
the
identity
provider,
that
they're
using
across
different
teams
that
are
creating
software
for
that
same
tool.
So
I
think
it
would
be
that
platform
team
I
mean.
F
F
A
A
D
A
C
A
You
know
one
of
the
things
to
like
and
we
use
this
term.
We
use
the
persona
DevOps
DevOps
engineer
and
if
you
look
at
our
definition
of
the
persona,
it's
more
about
the
central
platform
team,
helping
the
customer
we're
helping
the
individual
app
development
teams
with
things
like
build
package
and
release.
But
we're
talking
about
that
same
persona
but
as
applied
to
you
like
deploy,
configure
and
monitor
right
and
that.
E
E
F
F
On
this
is
that
you,
even
in
this
conversation,
they
know,
as
we
kind
of
have
a
had
to
walk
our
way
to
who's.
Actually,
the
person
making
a
decision
and
I
think
it's
super
important
for
us
to
know
who's,
helping,
drive
a
decision
and
be
a
champion
because
that's
who
needs
to
understand
and
value
these
capabilities
and
and
I.
F
Think
when
you
have
these
conversations
with
customers
and
you
find
people,
they
say
wow
that
person
not
only
wasn't
her
champion
but
gets
it
and
isn't
advocating
for
it
right
now,
their
title
hood
and
let's
see
if
that
starts,
to
make
a
pattern,
because
that's
that's
the
person
you're
you're
trying
to
convince
to
make
the
decision.
F
A
I
totally
agree
and
I
will
highlight:
I
had
been
remiss
in
being
handbook
first
here,
and
so
we
always
kind
of
said.
Oh
there's,
this
persona,
that's
not
listed
on
our
personas
page
today,
in
a
discussion
with
the
ops
team,
we
started
an
mr2
ad
at
least
the
basis
of
this
persona,
and
then
we
have
ongoing
UX
research
to
like
you
know,
flesh
it
out
as
we
learn
more
about
it,
but
it
is
an
unknown
and
we'd
been
referring
to
it.
A
F
A
And
I
think
today
we're
a
little
bit
early
days
in
you
had
said.
Who
is
that
target
long
term?
I
think
is
a
long
term
target
today.
We're
focused
on
the
app
operators,
then
we'll
be
focused
on
the
platform
operators,
but
were
we
still
got
to
get
kind
of
like
that
underlying
usage?
First,
before
we
have
the
bar
at
platform,
operators.
E
A
But
the
teams
have
existing
tools
that
are
frankly
better
than
what
we're
proposing
they
take
over,
and
so
it's
kind
of
this
pain
point
of
I'd
like
you
to
take
two
steps
back
in
order
for
us
to
start
building
and
investing
in
our
product,
and
we
still
have
dries
on
the
other
side,
but
I
think
you
could
universally
say
that
was
in
the
ops
section.
The
product
managers
are
hungry
for
dogfooding
and
are
the
ones
pushing
for.
Please
use
our
product
rather
than
the
other
way
around
and
so
I'm
not
cannot
concerned
about
that
feedback.
A
Yeah
we've
been
getting
great
feedback
from
the
teams,
we've
consistently
gotten
feedback,
our
and
we've
gotten
great
feedback,
and
it's
affected.
Our
prioritization
I
really
have
minimal
concern
about
the
product
management
organization,
not
prioritizing
that
feedback
we
have
been
super
hungry,
like
I,
still
have
yet
to
see
where
we
have.
A
We
have
taken
those
steps
back,
Eric.
You
said
we're
like
asking
them
to
take
the
two
subs
back,
we're
trying
to
meet
them
in
the
middle
today,
but
we
still
need
to
then
take
the
two
steps
back
start
using
that
product
and
then
I
I'm
not
concerned
that
the
products
organization
will
would
love
that
feedback.
We're
hungry
for
feedback
in
this
part
of
the
product.
A
E
A
It's
so
the
answer
of
release
is
because
we
don't
see
today
our
support
in
monitor
and
configure
are
about
cloud
native
support,
and
so
that
could
be
I'm
saying
it's
not.
Maybe
the
answer
is
not
CD,
because
you
asked
about
an
app
too
see.
Usage
of
release
drives
enables
usage
of
these
later
stages.
Now,
if
I
don't
know,
if
there's
a
specific,
like
here's
a
feature
that
releases
missing
that
would
enable
that
usage.
It
might
just
be
more
that
in
as
were
focused
on
this
cloud
native
abuse
case.
E
A
And
sorry,
you
would
I'm
getting
a
little
bit
wrapped
around.
Are
we
talking
about,
will
drive
usage
in
the
stage
his
dogfighting
would
help?
But
if
our
customer,
if
our
customers
still
aren't
adopting
cloud
native
principles
or
using
containers
or
kubernetes
like
dogfooding,
helps
in
so
much
as
it
prepares
us
for
that
feature,
but
it
doesn't
immediately
drive
new
users
of
configuring,
monitor.
A
Yeah,
it's
if
you
think
about
where
I
started
of
saying
we
want
to
build
tools
for
application.
Application
developers
are
also
performing
ops
tasks
in
that
cloud
native
world.
A
E
B
A
Yeah
Tara,
for
me,
is
the
answer
and
that's
what
we
were
talking
about
a
doob
today,
our
infrastructure
as
code
MVC,
and
it's
kind
of
trying
to
think
of
what
can
we
uniquely
do
is
a
integration
with
Tara
form
in
the
merge
request.
I
do
think
there
are
other
things
we
can
do
for
other
infrastructure
definition
tools,
whether
those
are
chef
or
puppet
or
others
that
enable
a
really
cool
experience
with
those
tools
in
git
lab.
A
You
can
kind
of
think
of
them
as
other
languages
that
happen
to
have
their
code
stored
in
get
lab
and
what
are
the
unique
things
we
can
do
to
support
those
specific
languages
and
so
I?
Don't
it's
not
just
today.
It
means
terraform,
because
that's
our
first
MVC,
that's
our
like.
What's
next
but
I
expect
it
to
expand
to
not
just
terraform
and
really
about
how
do
you
you
can
do
this
today,
but
how
can
we
make
the
experience
better?
How
you
doing
today.