►
From YouTube: Product Group Conversation
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).
C
C
D
Since
we
don't
have
any
questions
and
the
doc,
maybe
we
can
just
start
with
like
a
highlight
of
the
highlights
like
what
are
you
most
excited
about
in
the
next
month
or
like
I?
Guess?
Maybe
one
positive,
maybe
one
slightly
more
like
a
concern
or
improvement
that
you
want
to
see,
and
then
one
of
the
maybe
features
that
you
know
that
are
gonna
be
coming
in
that
you're
really
excited
of
it.
Oh
yeah.
A
I
think
the
thing
I'm
most
excited
about
team
wises
is
there's
a
lot
of
talent
and
horsepower
on
the
team.
So
it's
been
fun
to
work
with
everyone
get
to
know
the
team.
So
I'm
excited
about
the
group.
That's
already
here.
My
number
one
priority
is
to
hire
more.
We
need
the
team
to
double
like
tomorrow.
So
that's
what
that's
my
number
one
priority
and
my
number
one
concern
is
not
having
enough
folks.
A
That
means
that
the
people
that
are
in
each
of
their
respective
chairs
are
sort
of
cupper
and
more
more
than
they
more
than
they
should
and
the
workloads
aren't,
aren't
sustainable,
so
I
want
to
I
want
to
help
fix
that
by
hiring
as
quickly
as
we
can
as
I'm
leaning
and
personally,
and
making
that
my
number
one
priority
as
far
as
the
product
I
don't
know.
If
I'm
gonna
pick
one
it's
it's
early
for
me
to
have
a
favorite,
but
I
am
impressed
with
the
overall
velocity
of
the
team.
A
A
My
goal
is
to
help
the
team
learn
new
customer
validation
and
qualitative
interviewing
techniques
to
derive
even
more
insights
from
our
customers
and
make
the
the
items
that
were
feeding
the
Machine
that
much
more
customer
relevant
and
impactful.
But
it's
awesome
to
work
at
a
place
where,
where
we're
getting
so
much
done
so
fast,
I.
E
C
This
merged,
just
before
you
came
on
full-time
Scott,
so
I'll
actually
jump
in
a
little
bit.
It
was
merged
about
three
weeks
ago.
As
you
understand,
we
haven't
actually
enacted
it.
Yet
it's
a
great
idea
that
we're
hoping
will
make
a
big
difference.
There's
a
large
lag.
You
know
from
doing
a
sequential
set
of
like
three
interviews:
oh
okay,
well,
there's
just
block
a
day.
You
know,
so
we
all
just
do
interviews
the
same
day.
It
hasn't
started
yet
really
looking
forward
to
it,
starting
we.
A
Have
I
understand
the
question
now
so
you're
saying
grouping
the
interviews
in
one
day
rather
than
spreading
them
out.
We
have
started
a
bunch
interviews,
I've
seen
in
a
number
of
searches
lately
where
we
have
grouped
the
bulk
of
the
interviews
and
the
same
day
or
in
a
48-hour
period
and
I
think
that's
working
much
better.
The
candidate
experience
is
better
because
they
don't
have
to
carve
out
time
away
from
work
multiple
days.
A
They
can
just
take
a
dedicated
chunk
off
and
as
a
candidate,
it's
far
just
sort
of
get
it
all
done
and
get
in
the
flow
rather
than
have
it
have
to
get
an
interviewing
headspace
multiple
times
on
multiple
days,
so
I
think
it's
a
good
candidate
experienced.
It
also
helps
our
team
make
good
decisions
like
everybody's
seen,
the
same
candidate
on
the
same
day.
It
can
be
briefed
on
it
right
away.
You
can
start
to
get
tight
on
what
you're
looking
for
or
not
looking
for
in
a
candidate,
because
you
can
provide
really
fresh
feedback.
F
+1
that,
as
well
as
the
interviewers
participate
in
that
process
with
Kenny,
who
believe
is
out
of
office,
it's
great
being
able
to
compare
notes
it
also.
It
allows
the
three
to
Calabrian
kind
of
a
justification
to
be
able
to
advance
to
the
next
stage
and
I
think
it's
just
a
it's
just
a
very
collaborative
way
to
approaching
the
problem
so
I'm.
Definitely
a
fan.
B
B
More
streaming
approach
like
today,
we
still
have
the
product
development
based
on
the
monthly
release,
so
immensely
iteration,
and
we
will
end
up
kind
of
working
on
any
theory
on
features
to
subject
to
be
deployed
in
the
next
iteration.
But
actually
we
are
asking
developers
to
merge
as
soon
as
possible
new
things.
B
So
we
will
have
a
lot
of
code
ending
the
current
release
that
will
need
to
be
behind
future
Flags,
who
will
be
ending
a
managing
a
lot
of
feature
flags
when
we
can,
because
sometimes
we
just
can't
so
you
have
to
delay
to
all
metric
question
before
getting
mad
at
the
right
time.
So
you
also
have
some
struggle
with
you
exist.
B
Corey
and
Tina
data
are
delayed
over
time,
so
it
could
be
very
easier
to
have
a
very
streamlined
process
where
we,
when
we
as
soon
as
we
already
in
the
uux
design
on
the
feature,
we
can
tell
the
development
right
away
and
when
the
development
is
finished,
we
published
it
right
away,
instead
of
actually
waiting
for
the
next
iteration
I.
Think.
A
It's
an
interesting
suggestion.
My
last
company
was
the
SAS
company
and
we
we
sort
shipped
when
things
were
ready,
so
I
understand
the
value
that
that
said,
we
really
have
a
lot
of
infrastructure
and
rhythm
built
up
around
our
monthly
releases.
So
this
hasn't
been
a
conversation.
I've
been
in
the
middle
of
yet
about
whether
we
should
move
to
a
more
continuous
delivery
of
features.
I
think
it's
a
reasonable
topic,
so
I'd
like
to
bring
that
up
with
engineering
leadership
and
product
marketing
leadership
to
decide
what
to
do.
A
There
I
think
the
company
is
very
geared
around
the
month
to
release
cycle
I
think
it
gives
us
a
chance
to
talk
about
what
shipped,
maybe
there's
a
way
to
still
retain
that,
but
get
value
out
to
the
market
fast
or
particularly,
on
our
SAS
offering.
So
it's
a
great
idea.
I
haven't
had
that
conversation
yet
Olivia.
G
H
D
G
A
A
When
you
do,
you
can
make
a
lot
of
mistakes
and
operate
on
gut
instinct
or
or
what
the
internal
lor
is,
and
so
I
saw
this
transition
at
SendGrid,
where
we
we
got
out
of
that
mode,
and
we
started
basing
our
decisions
on
what
we
heard
from
our
target
users
rather
than
what
we
thought
was
right
internally
and
if
some
magical
stuff
started
happening
like
the
product
experience
really
improved.
The
hit
rate
that
we
had
on
shipping
feature
successfully
really
went
up.
A
We
burned
a
lot
less
time
from
engineering
because
we
had
really
thought
through
what
was
important
and
what
problem
to
solve,
and
so
that
that's
where
the
magic
happens
is
when
PMS
and
designers
really
get
out
there
and
mix
it
up
with
customers
and
develop
that
intuition
about
what
problem
they
have
and
then
the
solutions
fall
out
from
that
I.
Think
assuming
you
have
the
solution
as
a
first
step
is
a
mistake,
so
I
guess
I'll,
say
over
years.
A
A
Well,
you
can't
expect
someone
to
you
know,
crank
monthly
release
and
having
as
much
out
going
on
as
we
do
and
go
out
and
do
successful,
customer
validation
and
research
unless
they
have
a
reasonable
scope
and
so
again,
that's
why
hiring
is
my
number
one
priority,
because
we
need
to
give
the
team
a
reasonable
amount
of
scope
per
p.m.
so
they
can
absorb
this
extra
work.
Hey.
I
Scott
yeah
real,
quick.
This
that's
great,
because
I
want
to
commend
the
product
team,
specifically
Brendan
O'leary,
for
doing
exactly
that.
We're
coming
out
with
an
issue
called
enforced
template,
inclusion
and
pipelines.
This
release,
it
was
specifically
asked
for
from
Goldman
Sachs
and-
and
so
you
know
it's,
we
had
a
call
and
demo
with
him
yesterday
and
they
said
that
was
exactly
what
we're
looking
for.
I
know.
It
was
unpopular
from
our
senior
management
side
of
things,
starting
with
all
the
way
up.
I
It
said
that
he
thought
we
should
implement
in
a
different
way
and
things
like
that,
but
it
was
exactly
what
Goldman
Sachs
was
asking
for
and
they're
very,
very
happy
with
it.
So
I
just
want
to
commend
Brendan
and
for
taking
the
stand
on
that
and
really
stepping
up
and
doing
what
the
customer
asked
us
to
do.
So.
Thank
you.
Yeah.
A
That's
great
and
I
would
I
would
qualify
that
a
little
bit
I
want
to
be
customer
driven,
but
I
want
to
make
sure
we
start
with
the
problem
rather
than
with
the
specific
solution.
Now
it
could
very
well
be
the
goal
that
what
Goldman
asked
for
is
a
solution
that
will
apply
broadly
I
just
want
to
make
sure
the
team
is
in
the
mode
of
get
behind
the
specific
ask
understand
what
the
problem
is
and
then
elegant
solutions
fall
out
of
that
it
can
be
dangerous
to
just
well.
The
customer
asks
for
X.
A
I
Does
and
I
do
think
it
was
in
that
spirit,
and
they
mentioned,
and
you
know,
every
other
financial
services
customer
I've
talked
to
who
said
that's
exactly
what
we
eat,
so
it
was.
It
was
in
that
spirit
in
that
light
of
doing
it.
Yes,
it
was
led
by
a
feature
request,
because
it
was
specific.
I
would
come
with
a
customer
request,
but
it
was
executed
in
a
way
that
really
served
the
purpose
of
what
they
were
trying
to
come
great.
J
A
J
A
Thanks
for
the
question,
it
was
a
circuitous
route
to
product
management,
I
started,
I
started
out
in
sales,
I
did
about
four
years
in
sales
and
then
about
four
years
in
business
and
fairly
early
on
targeted
product
management
as
a
function
that
I
wanted
to
be
in.
But
the
leap
to
go
from
sales
to
product
management
is
a
pretty
big
one.
That's
not
a
common
path
to
p.m.
so
I
went
back
and
got
an
MBA
and
focused
on
management
of
technology
topics.
A
A
About
10
of
the
last
12
years
has
been
managing
and
leading
large
p.m.
teams.
You
know
in
between
10
and
30,
so
I
think.
One
reason
why
this
was
a
fit
was
I've
scaled
and
run
pretty
large
teams
before
so
I
was
excited
to
get
that
opportunity.
I
live
in
Boulder
Colorado,
so
there
aren't
a
ton
of
companies
of
gitlab
size
in
the
local
market,
so
it
was
awesome
to
be
able
to
to
get
this
chance
to
work
at
a
company
with
this
kind
of
trajectory
from
where
I
want
to
live.
A
I
said
on
my
intro
Carl
repeats,
some
of
it
I
joined
because
I
loved
the
stage,
the
company's
at
I
love
that
customers
love
the
product.
I
love
the
ambitious
product
strategy
and
markets.
We're
in
and
I
appreciate
how
the
company
works,
how
organized
it
is,
how
disciplined
we
are
and
how
how
much
product
was
shipped
were
the
big
reasons
for
coming
is
there
anything
else
I
can
answer
in
there
Christy.
H
C
C
There
definitely
are
other
opportunities,
even
within
our
existing
categories,
to
strengthen
those
and
there's
always,
you
know
a
few
opportunistic
things,
but
those
things
were
looking
for
now.
Not
all
of
our
categories
are
equal
either.
Those.
So
some
of
those
categories
are,
you
know
more
strategic
I'd
say
defend,
for
example,
as
a
stage
has
a
ton
of
categories
in
there
and
and
that's
a
great
thing
where
we
have
nothing
in
that
stage
at
all.
C
We
will
eventually
build
it
up,
but
if
we
could
acquire
to
fill
that
that
would
be
making
so
much
more
sense
really
accelerate
things,
but
really
any
of
those
categories.
The
idea
is
that
you
know
the
accept.
The
acquisition
should
really
accelerate
our
product
strategy,
and
you
know
help
us
not
just
you
know,
add
a
bunch
of
people
but
add
a
bunch
of
capabilities
that
really
drive
that
strategy.
C
C
What
I
actually
plan
on
doing
is
going
over
that,
basically
the
entire
list
and
then
adding
sort
of
just
a
subjective,
at
least
a
low
medium
high,
which
of
these
would
make
great
acquisitions
because
some
of
those
things
you
know
there
may
be
a
gap,
but
we
really
need
to
develop
it
in-house.
Some
of
those
things
it's
like
well.
This
is
perfect
for
somebody
outside
and
then
some
of
them,
honest,
they're,
even
just
better
for
partners
like.
Maybe
we
just
fill
that
because
we
use
some
open
source
tool
or
even
a
paid
partner.
C
C
C
I've
actually
got
a
question
for
you:
Scott
whoa,
all
right
as
a
customer
results
is
definitely
one
of
the
big
focuses,
but
the
other
big
focus
is
how
you
phrased
it
in
the
doc,
but
it
was
data
ROI,
just
levelling
up
there
yeah.
This
is
something
we've
struggled
with
for
a
while
I'd
love
to
hear
your
thoughts
and
your
prior
experience
and
how
you
think
we
can.
You
know,
accelerate
that
you
know
becoming
more
data
data
aware
at
least
I,
don't
ry,
driven,
alright
yeah
great.
A
When
I
begin
to
harken
back
to
my
last
roll
at
SendGrid
when
I
joined,
we
had
hardly
any
telemetry
on
the
product
very
little
instrumentation,
and
so
we
were
flying
blind
more
than
you
would
think,
given
that
it
was
a
SAS
product.
So
we
just
made
it
part
of
our
definition
of
done.
Basically
that
anytime,
you
were
gonna,
build
something
you
needed
to
have
instrumented
it
so
that
you
know
whether
your
thing
was
successful
or
not.
We
also
asked
the
PM's
for
each
material
thing.
A
They
did
to
have
a
success
metric
so
that
we
could
track
that
and
know
whether
they
were
successful.
So
if
you
know
a,
if
you
know
what
that
success
metric
is
and
B,
you
instrument
things
as
you
build
it,
then
you
don't
have
to
catch
up
later.
So
that's
part
of
it
we're
in
catch-up
mode
right
now,
because
we
don't
have
great
instrumentation.
A
We
also
have
the
added
bonus
of
the
fact
that
a
lot
of
our
customers
run
on
Prem
and
it's
tough
to
get
real-time
usage
data
there.
So
we
have
some
blocking
and
tackling
a
to
get
better
data
from
on
Prem
customers
and
to
get
it
more
from
a
higher
percentage
of
them
and
to
improve
the
data
set
itself
and
then
B.
We
have
some
blocking
and
tackling
to
do
to
get
better
instrumentation
off
of
the
dot-com
experience,
which
we
should
be
able
to
get
in
a
much
more
real-time
fashion.
A
A
If
it
works
great,
we
keep
doing
it.
We
need
especially
that
growth
team
to
be
in
a
mindset
of
doing
quick,
small
experiments
to
try
to
drive
outcomes
either
for
the
number
of
people
signing
up
the
number
of
people.
Upgrading
the
number
of
people
using
additional
things
within
the
product,
so
it'll
be
awesome
to
have
a
team
trying
to
drive
these
cross
product
outcomes
so
that
the
other
PMS
can
focus
in
their
area
and
sort
of
benefit
from
a
team.
A
C
I
think
that's
been
pretty
good.
I'll
just
add
a
little
color
there
that
otherwise
I
looks
at
look
at
it.
Is
that
we've
sort
of
had
this
blessing
and
a
curse
that
we've
had
really
good
sales
performance
and
it's
you
know,
and
it's
been
out
of
doing
in
outperforming
expectation,
basically
and
and
so
that
has
allowed
us
to
sort
of
be
complacent
and
not
have
to
develop
this.
C
You
know
rigor
and
whatnot
in
terms
of
data
that
another
company
that
like
when
you
when
you
start
to
fail,
then
you
really
need
data
and
we
don't
want
to
wait
until
it
happens.
So
we
need
the
data
device,
but
we've
had
this
curse,
we're
sort
of
like
yeah.
We
haven't
really
needed
it,
so
we
haven't
prioritized
it,
and
now
we
really
just
do
need
to
prioritize
it.
Yeah
good
point.
A
I'll,
take
a
stab
and
mark
and
pile
on
I
think,
to
put
it
simply:
mark
owns
the
four-year
product
strategy,
so
sort
of
long-term
stuff,
plus
M&A
and
then
I
own,
the
one-year
execution
plus
kind
of
the
whole
product
management
function.
So
all
the
hiring
how
the
team
works,
how
we,
how
we
operate
our
process,
our
flow
in
our
one
year,
Exxon,
where
you
are
one
year
plans
across
the
product
line,
there's
sort
of
my
domain
and
then
mark
has
the
other
two
areas:
okay,.