►
From YouTube: Field / Product Feedback Loop Kickoff
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
B
A
Follow
along
afterwards,
so
yeah
I
just
wanted
to
kick
this
off,
so
I
hadn't
kind
of
a
basic
agenda
attached
to
this.
This
conversation-
and
the
idea
here
today
is
I
just
wanted
to
kick
off
the
conversation
with
the
product
team
to
kind
of
align
on.
You
know
some
of
the
strategy
going
forward
and
how
we
can
actually
execute
on
this
better
feedback
loop
that
we're
trying
to
develop
so
as
a
starting
point.
I
just
wanted
to
review
quickly.
A
The
problem
with
that
model
is
that
unless
we
have
like
a
pre-sales
and
post-sales
top
10,
the
the
actual
asks
from
the
field
are
very,
very
different.
Like
I
remember,
you
know,
John
and
I
were
first
kind
of
talking
about
this,
a
you
know
a
year
or
more
ago.
You
know
looking
at
the
top
10
list
from
the
Tam's
that
have
come
out
of
existing
customers,
of
what
the
customers
needed
and
also
the
exact
same
kind
of
feedback
you've
gotten
from
the
cab.
So
we
get
the
direct
feedback
from
product
managers
of
the
cab.
A
Is
that
those
issues,
the
things
that
people
are
wanting
from
existing
customers
are
vastly
different
from
what
you
know
prospective
customers
who
are
looking
to
adopt
gitlab
want
to
or
need
to
be
able
to.
You
know,
get
over
that
barrier
to
actually,
you
know,
look
in
purchase,
get
lab,
so
there's
a
big
difference
between
those
two
things.
So
I
started
thinking
a
bit
of
this
a
bit
more
and
now
that
we
have
such
a
large.
You
know
product
management
team
across
all
the
different
stages,
and
then
each
stage
is
even
broken
out
into
smaller
teams.
A
A
They
would
be
kind
of
the
direct
points
of
contact
for
getting
this
feedback
to
the
product
team,
and
so
they
knows
those
folks
that
we've
defined
on
our
side
would
also
be
the
same
folks
that
we
would
say
would
be
you
know
ideal,
for
you
know,
collecting
feedback
from
the
field
and
then
getting
that
stuff
up
to
product
right
and
then
vice-versa.
So
the
other
part
of
this,
too,
is
that
you
know
right
now.
The
only
way
that
the
customer
success
team
can
go
out
and
find
out
about.
A
You
know
things
that
are
in
the
roadmap
or
or
what's
coming
in
the
next
releases.
It's
the
way
that
everyone
else
finds
out
about
that,
and
it's
just
through
you
know:
here's
what's
coming,
here's
what
actually
dropped
in
this
release.
Now
we
go
and
take
that
and
say:
okay,
now,
let's
figure
out
how
we
demo
this?
How
do
we
talk
to
customers
about
this
with
the
value
of
this
for
the
customer?
So
we
have
to
do
a
lot
of
that
parsing
on
our
side
as
well.
A
Ideally,
we'd
have
a
feedback
loop
going
the
other
direction
there
to
where
you
know
the
product
managers
working
directly
with
the
point
of
contact
and
customer
assessing
here's
what's
coming
out
in
this
release:
here's
why
we
did
this
here's
the
problems
that
it
solves
and
so
that
we
have
a
better
understanding
of
the
direction
that
products
doing
versus
us,
trying
to
interpret
that
and
doing
our
own
thing
in
the
field
and
seeing
how
that
goes,
not
always
directly
aligned.
I
think
we
do
an
okay
job
of
that,
but
it's
not
consistent
across
the
board.
A
So
a
lot
of
times
we're
not
we're
not
up
to
speed
on.
What's
changing
and
what's
what's
you
know
what
what
the
the
longer-term
vision
of
those
features
might
be?
So
ideally,
this
might
look
like
something
where
we
have
a
you
know:
monthly
cadence,
where
we've
got
our
team
on
customer
success,
that's
going
to
meet
with
each
product
manager
and
before
that,
the
key
here
is
that
you
know
the
way
we
do
it
now
is
taking
Salesforce
links,
posting
them
inside
the
issues
that
you
know
providing
some
details
of
why
they
want
that.
A
That's
all
good,
but
really
I
think
it
would
be
much
more
valuable
for
the
product
team
this.
What
I
want
to
give
you
guys
opinion
on
is
if
we
can
identify
the
trends
of
what
things
were
see
in
the
field
and
why
they're
good
asked
and
what
they're
trying
to
solve
I
think
that's
gonna,
be
a
lot
better
for
product
and
saying
they
need
this
feature
because
I
asked
for
this
feature
and
that's
part
of
the
requirements.
That's
not
that's!
Ok,
but
really
I!
A
Think
we
can
solve
things
in
a
different
way
than
just
you
know.
Hey
we
heard
you
need
this
direct
integration
with
bolts,
for
example,
but
really
the
underlying
story
is.
We
need
a
better
way
of
managing
external
variables.
You
know
right
so,
like
that's
the
that's.
The
broader
theme
story
around
that
not
just
we
need
malt
integration,
that's
one
piece
of
it.
That's
one
way
we
could
go,
but
I
would
rather
product
make
that
decision
and
because
you
know
it
makes
more
sense
right.
A
We
need
a
solution
for
that
and
we
can
take
that
back
to
the
customer
and
explain
to
them
why
we
chose
that
route
and
so
I
think
that
that
would
be
a
much
easier
way
to
do
that
if
we
collected
feedback
from
the
field
and
said
these
10
customers
had
requests
that
were
in
in
this,
you
know
managed
space,
for
example,
and
they
all
revolve
around
this
particular
type
of
problem
and-
and
so
instead
of
you
know
direct
point,
we
have.
We
have
themes
right.
A
So
the
idea
there
is
that
we
would
be
able
to
collect
that.
You
know
work
with
the
product
management
team
to
you
know,
provide
that
feedback
on
a
regular
cadence
of
I.
Think
monthly
makes
sense
right
now,
just
given
how
many
people
would
be
involved
and
not
trying
to
put
in
a
bunch
of
burden,
overhead
and
and
enough
time
for
us
to
collect.
You
know
new
changes,
because
I
think
the
one
thing
we're
seeing
the
field
too
is
like
look
we're
trying
to
push
ultimate
we're
trying
to
get
into
larger
enterprise
deals.
A
There's
a
lot
more
that
goes
into
those
deals.
Then,
then,
what
we
know-
because
we
just
haven't
been
in
that
space
of
you-
know
how
we
handle
compliance,
how
we
handle
you
know
certain
things
in
regulated
industries
and
so
I
think
we
need
to
hear
that
feedback
and
take
that
extract
it
out
and
give
it
to
product
in
a
more
meaningful
way.
So
that's
kind
of
the
underlying
gist
of
what
I'm
trying
to
solve
here
in
kind
of
the
way
I'm
thinking
about
approaching
this
open
it
up
just
some
feedback
on
that
for
now,
yeah.
B
No,
that
sounds
great,
no
you're,
absolutely
right,
I
mean
one
of
the
things.
Maybe
even
the
options
we
can
do
is
create
like
an
issue
template,
that's
really
like
a
use
case
reporting
from
the
field
where
we'd
say:
hey
I
was,
with
this
Salesforce
link
customer
here's
the
use
case
extract.
This
is
why
it's
valuable
this
problem
that
they're
trying
to
solve
and
then
because
one
that
allows
us
to
actually
have
it
in
a
form
we
can
have
a
discussion
on
in
total.
We
can
then
assign
we
can
assign
that
issue
to
like
feature
epics.
B
We
have
open,
as
like
customer
research,
validation
that
we
say:
hey
here's
the
15
field
reports
that
talk
about
this
similar
use
case
for
Knoll
rolls
up
to
this
item,
we're
trying
to
build,
and
then
the
other
side
of
that
is
you
know
we're
also
on
the
product
side
are
being
encouraged
to
map
opportunities
and
the
stuff
we're
working
on
to
actual
value
of
f
introduced,
and-
and
you
know,
of
course,
that
gets
complicated
right,
like
you
call
it
out,
is
okay
cool.
Is
this
customer
interested
in
this?
B
Is
there
one
person
that's
interested
in
this
on
that
side,
or
is
it
hey?
This
is
actually
keeping
them
from
expanding
into
an
ultimate
agreement
or
it's
spanning
into
a
new
stage
like
that's
the
those
are
the
big
details
that
we
need
to
be
able
to
quantify
and
actually,
when
we
say
why
are
you
doing
this,
we
can
then
go
hey.
A
I
even
look
at
like
some
of
the
issues
that
have
like
tons
and
tons
of
Salesforce
links
in
them
of
like
we
need
this.
We
need
this.
We
need
this,
but
they're,
not
they're,
not
they're,
all
disconnected,
in
the
mean
the
reason
why
they
need
that
is
a
lot
different
than
what
you
might
be
gathering
from
just
that
issue
itself,
and
so
I
think
that
that
distilling
that
out
into
something
more
meaningful,
is
the
valuable
part
I
mean
I
can
give
you
a
really
good
example
of
this.
A
Actually
that
just
happened
was
you
know:
I've
been
hearing
a
lot
in
the
field
around
our
container
registry
that
we
need
immutable
tags
right,
because
people
rely
on
mutable
tags
for
deployments,
because
they're
used
to
that
as
part
of
artifactory
they're
used
to
that.
As
part
of
you
know,
AWS
is
service
for
that
as
well,
and
and
and
but
the
reason
why
all
those
companies
have
chosen
to
go
that
route
is
because
they
don't
know
what
the
release
process
looks
like
because
they're
not
part
of
the
entire
development
cycle.
A
A
It's
like.
Okay,
that
sounds
like
a
mutable
tags,
but
actually
in
our
world.
If
people
are
using
releases,
that's
a
better
place
for
that
to
live
and
then
tags
themselves,
because
there
would
be
reasons
why
you
might
want
to
overwrite
a
tag
in
some
cases.
But
you
couldn't
do
that
if
you
had
that
model,
so
I
think
that
this
kind
of
that
kind
of
proved
out
some
of
this
thinking
of
like
no.
We
need
to
understand
the
themes
of
what
they're
trying
to
do.
A
A
So
yeah
so
I
think
so.
I
think
that
this
is
a
you
know,
I
think
the
hard
part
of
this
is
determining
you
know.
Should
this
be
at
the
product
group
level
like
the
product?
What,
if
I
forget
what
stage
group
or
stage
group
managers
should,
should
it
roll
up
to
like
that
level,
or
should
we
get
granular
into
each
cuz,
there's
so
many
different
stages?
Now
that
would
be
a
lot
of
people
on
this
yeah.
B
I
think
we
started,
we
started
a
little
higher
up.
You
know
so
one
of
the
one
of
the
more
difficult
parts
about
how
we
just
structure,
price
and
sell
the
product
is:
like
people
don't
buy
features,
they
buy
solutions
to
use
capes
oftentimes
those
use
cases
to
span
categories
and
groups
right.
So
like
Gabe
and
I
Gabe's
project
management,
portfolio
management,
I
can't
do
any
of
this
stuff.
B
I
need
to
do
unless
we
have
it
at
the
project
management
level
right,
and
so
we
end
up
having
collaborate
on
everything
so
that
we
can
understand
exactly
how
do
we
build
things
that
can
aggravate
up
but
also
solve
the
larger
use
cases?
A
B
A
And
then
you
know
other
other
thoughts,
I'm
like
what
we
would
want
to
you
know
some
before
we
jump
to
the
other
side
of
this
of,
like
you
know,
I
think
the
other
piece
of
this
is
getting
our
feedback
back
to
you
know
this
yes
team
on.
You
know
why
we're
doing
things
and
maybe
maybe
providing
us
a
little
more
than
what
we
can
get
out
of
just
looking
at
the
release
notes
and
looking
at
the
the
roadmap
and
in
theory
there
I
think
there's
some
there's
some
more
to
that.
A
Like
you
know,
maybe
it's
a
PM
team
provides
a
you
know,
a
quick
demo
to
the
experts
on
the
and
the
CSI
for
that,
and
then
we
can
take
that
in
and
roll
it
out
to
the
entire
team,
not
sure
there,
but
that's
the
other
part
of
this
that
I
want
to
also
solve
is
like
I
think
we
are
looking
for
a
little
bit
more
of
that
from
the
PM
team.
That's
more
that's
more
direct
feedback
rather
than
us
figuring
it
out
ourselves,
yeah
and
I.
A
B
A
Cool
I
mean
that
could
be
enough.
I
just
want
to
make
sure
that
we
I
think
that's
the
key
piece.
There
is
a
lot
of
times.
You
read
these
and
we're
like
well.
How
does
this
really
play
out
in
a
demoing
scenario,
for
example,
or
how
does
this
play
out
in
a
conversation
about
this
topic?
How
do
we
present
that
value
and
our
vision
of
that
value?
As
it
goes,
you
know
from
minimal.
You
know
lovable
stages,
okay,.
A
B
A
A
Any
other
considerations,
thoughts,
things
that
you
guys
would
want
from
product
that
could
make
this
better
easier,
so
I
think
we've
defined.
We
need
to
have
like
a
template
of
some
sort
for
this
feedback
for
each
one
of
these
I
don't
know
if
they
should
I
should
that
live
just
as
part
of
get
lab
the
project
itself,
or
should
it
be,
should
we
do
that
at
a
different
project,
thoughts
than
that
so.
B
A
Part
of
the
gate,
lab
or
group
should
be
a
separate
project.
Then
yeah
I
guess
that's
problem,
because
I
mean
the
only
thing
that
I
would
want
to
be
cautious
about
is
that
it
would
be
worthwhile
for
us
to
be
able
to
talk
about
actual
customers.
In
this
case
no
I
think
we
can.
Can
you
it.
So
you
can
have
a
private
group
as
part
of
gitlab
org
that
still
can
roll
up
the
epics
and
the
issues
can
still
roll
up
to.
You
can
still
like
link
those
you
just
wouldn't
be
visible.
B
B
C
One
of
the
things
that
would
be
helpful
to
I
don't
know
if
this
is
like
a
training
thing
or
mindset
thing,
but
you
know
like
salespeople,
they
focus
on
like
features.
And
what
do
you
need
like
what
use
case?
Do
you
need
to
support,
but,
like
a
lot
of
times
like
we
get,
we
get
feature
requests
and
not
the
use
case,
part
and
even
less
frequently
the?
What
is
the
customer
trying
to
accomplish
exactly.
A
C
C
That's
in
JIRA,
we're
like
I,
don't
think
it's
the
right
thing
to
do,
but
like
that's
what
everybody
asks
because
we're
not
getting
better
feedback
on
what
they're
trying
to
actually
accomplish,
and
so
I
think
the
more
that
we
can
train
folks
to
think
in
terms
of
like
how
is
my
this
person
trying
this
prospect
or
this
customer
trying
to
make
progress
and
like
how
can
we
help
them?
Do
that
and
not
even
talk
about
solutions
or
features?
That's.
D
B
No,
that's
great,
there's
been
a
couple
times
really
I
had
a
rep
drop
like
the
same
Salesforce
link
in
like
six
issues,
I
went
in
and
said:
okay
cool
but
like
I
need.
Basically
the
questions
you
have
in
that
template
and
then
the
customer
came
in
it
was
like.
Well,
if
you
don't
get
it
here,
you
go.
I
was
like
well
alright.
Now
this
is
awkward
because
I've
never
talked
like
I'm
just
looking
for
so
we
can
prioritize
so
I
like
that.
I,
like
that
format,
a
lot
yeah.
D
Yo
was
just
tired
of
seeing
Salesforce
links
just
post
it
everywhere
without
context,
I
think
you're,
right,
I
think
use
case.
Why
they're
interested
actually
like
the
current
solution
for
the
problem?
How
are
they
currently
working
around
that
and
making
it
work
for
them?
Maybe
that'll
give
us
some
insight
as
to
how
to
fix
this
for
them.
So
priority
is
important.
All
that
kind
of
stuff,
so.
A
I
think
they
that's.
We
need
to
be
doing
that,
but
we
also
need
to
be
aggregating
these
into
a
single
place
where
we
can
talk
about
that
to
the
group
leaders
because
I
think
that's.
The
key
here
is
like,
even
if
we
did,
that
of
like
here's,
the
here's,
the
customer,
here's
their
problem,
here's
how
they
get
around
that
here's,
what
they're
trying
to
do!
If
we
can
see
head
of
the-
and
we
can
say,
okay,
we
can
create
one
feature.
That's
gonna
hit.
Nine
of
these.
B
B
There's
a
lot
in
there,
especially
I'm,
only
I've
only
been
here
about
six
months
so
getting
in
there
and
trying
to
write
my
own
views.
--Is
there's
a
lot
in
there
and
especially
like
verifying
I'm,
doing
it
right
and
I'm
just
representing
something.
So
that's
all
I
was
calling
out
about
enablement.
There,
yeah
yeah.
D
When
I
first
saw
Josh,
Lambert
posted
sort
of
a
link
of
like
all
issues
that
I
had
links
and
and
you
can
sort
the
entire,
the
entire
and
caboodle
by
like
by
ARR
kind
of
thing
right,
but
I
suspect
as
a
grouper
stage
manager.
You
definitely
want
to
focus
down
to
what
what's
part
of
your
group,
so
yeah
I
mean
maybe
I
naively
assumed
everybody
was
just
like
using
periscope
and
looking
at
it
on
a
regular
basis
and
and
sort
of
had
great
insight
into
this.
But
maybe
that
was
just
a
pipe
dream
for
me.
D
A
D
D
A
A
Okay
and
so
then,
in
terms
of
next
steps,
I
think
what
I'm
going
to
do
so
from
my
side
of
things.
It's
about
identifying.
You
know
who
we
thinks,
gonna
be
the
best
person
or
people
I'm,
not
sure
yet,
I'm
from
our
side.
If
we
want
to
do
one
year,
I
mean
because
I
think
there's
there's
a
little
difference
in
like
European
and
the
US
based
or.
C
A
Everywhere,
outside
of
the
US,
based
that
we
have
different
kind
of
feedback
coming
back
there's
you
know
it
might
be
worthwhile
having
two
on
our
side
for
each
I'm,
not
short,
but
it's
pretty
obvious
who
it
would
be
on
the
product
management
side.
Right
I
mean
other
than
the
that
don't
have
group
group
which
I'll
have
to
go
and
look
who
doesn't
have
groups
yet
and
they'll
have
to
determine
inside
that?
Who
would
be
the
person
that
we
yeah.
A
B
A
B
Yeah
I
think
they'll
be
part
of
it.
I
think
it's
like
you
know
you
get
a
you,
get
a
feedback
and
they're
like
hey
like
here's.
This
problem
we
have
it's
super
important
like
I'd,
be
willing
to,
but
I
think.
Actually
maybe
we
need
a
clarifier
to
bring
this
up
a
little
I
think
it
even
be
more
useful.
It's
like
I'm
willing
to
interact
with
product
about
finding
the
right
solution
for
the
best,
because
then
that
allows
us
to
say
like
hey,
you
want
to
drop
customer
interview,
so
we
needs
validation.
B
Hey
we've
got
some
wireframes.
You
want
to
give
us
some
feedback.
It
kind
of
gives
us
that
opportunity
to
say
to
start
building
a
list
of
people
who
we
can
then
say
these
are
the
customers
we're
collaborating
on
to
make
this
to
get
this
right,
which
you
know
recruiting
for
that
kind
of
stuff
is
very
difficult,
especially
because
it's
basically
split
between
recruiting
UX
and
pians
so
like
solve
that
problem.
B
So
having
something
that
just
says,
like
here's,
a
list
of
people
who
could
be
willing
to
talk
that
maybe
in
work
with
anybody
on
your
end
or
in
sales
say
like
hey,
I-
need
to
talk
to
this
person
because
of
this
use
case,
they
said
they're
interested
in.
We
want
to
show
them
some
high
fidelity
wireframes
to
just
double
check
on
the
solution,
validation,
so
I
think
I
can
already
out
clean
up
that
issue
a
little
bit
to
kind
of
state
that
a
little
more
and
then
we
can
I
guess
yeah.
B
A
That
makes
sense
so
with
that
you
know,
I
think
a
lot
of
times
when
customers,
you
know
a
lot
of
customers
or
prospects,
are
willing
to
have
these
conversations.
If
they're
you
know
far
enough
down
the
path
of
saying
this,
is
nice
we're
going
to
go
I
think
you'll
have
more
you'll,
have
more
mileage
with
existing
customers
anyway
prospects
because
they're
not
going
to
do
that
unless
they're
pretty
serious
right?
The
key
here
would
be.
A
Is
that
if
I
think
we
should
only
do
that
if
we're
in
a
state
and
we're
in
a
place
where
we're
gonna,
actually,
you
know
make
progress
on
that
feature
in
the
next
X
amount
of
time.
I
don't
know
if
that
is
because
I
think
there
is
that
will
entice.
Customers
is
like
hey
if
we
can
get
this
out
in
three
releases.
If
you
help
us
now,
it
would
that
be
valuable
to
you,
so
we
can
kind
of
get
them
to
be
more
excited
about
the
prospect
of
like
yeah,
okay
yeah.
A
B
I
agree,
I
think
I
think
that's
how
it
is
like
hey,
okay,
like
if
we
get
multiple
of
these
use
cases
that
helps
us
get
through
the
problem.
Validation
stage,
which
is
like
this
is
something
worth
solving.
Some
customer
conversations
in
that
phase
are
helpful,
but
really
once
we
understand
and
know
the
problem
so
well
that
we
can
write,
we
can
come
up
with
a
solution
proposal.
That's
when
you
say,
hey
we're
working
to
do
this,
so
we've
got
a
lot,
yeah
walk
into
it.
That
way,
so
I
think
that's
a
good
call.
So.
A
Like
yeah,
let's
just
make
sure
that
this
part
of
it
is
kind
of
the
second
part
of
this.
This
feedback
is
like
here's
all
our
feedback
of
what
we
need
to
do
in
the
future.
When
we're
ready
to
make
progress
on
one
of
these,
then
that's
our
flag
to
go
back
to
the
customer
and
say
hey
products
taking
they're
gonna,
they're
gonna
focus
on
this.
Can
we
do
people
work
with
you
on
it?
Yeah.
B
A
D
A
C
Added
a
link
to
it'd
be
cool
if
we
gets
in
sales
folks,
depending
on
who
it
is,
might
have
a
harder
time
thinking
in
this
way,
but
these
were
talking
about
like
there
are
all
these
things
these
needs
it
can
we
build
one
solution?
That's
asked
why's
the
most
like
a
helpful
way
to
do
that
is
by
like
thinking
in
terms
of
job
stories,
so
I.
C
A
I'm,
definitely
anyone
who
would
be
a
DRI
from
the
CS
team
would
be
able
to
do
that,
like
the
salespeople,
probably
won't,
but
I
think.
The
idea
here
is
that
we're
collecting
the
feedback
from
the
sales
you
know
we're.
First
of
all,
we're
working
with
most
of
all,
and
you
know
if
they're
in
the
enterprise
or
mid-market
we're
going
to
be
working
with
them
directly.
So
we
hear
that
same
stuff.
They
do
but
I
think
yeah.
This,
yes
team
should
definitely
be
doing
it
in
context
of
that,
like
you
know,
I
need
to
you
know.
A
A
A
B
I'll
spin
up
a
I'll
spin
up
that
template
MRR
I'll
kind
of
just
stub
one
out,
and
you
know
Gabe
I'll
probably
pick
on
you
to
that
as
well.
Nothing
yeah,
it's
not
a
surprise!
So
I
got
to
that.
We'll
do
that!
Well,
I'll.
Add
it
to
the
agenda
for
the
product
meeting
and
just
talk
about
getting
dr
eyes
from
the
peroxide.