►
From YouTube: CS - Product Feedback Initiative 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
All
right
yeah!
So
thanks
again
for
everyone
to
for
joining
this
today.
You
know
this
is
a
a
kickoff
and
kind
of
a
essentially
a
reboot
of
what
we
had
worked
on
from
q1
and
q2
of
this
year
around
essentially
building
out
a
better
mechanism
for
us
to
have
feedback
from
what
we're
hearing
out
in
the
field.
What
we're
hearing
in
the
industry
and
bringing
that
back
to
the
product
team
so
that
we're
able
to
be.
B
A
Effective
with
you
know,
our
prioritization,
mostly
right,
so
give
you
some
background
right.
We
have
this
process
there,
well,
actually,
stepping
back
even
further
than
that.
You
know
about
a
year
and
a
half
or
two
years
ago.
Our
process
for
giving
this
feedback
was
essentially
a
top
ten
list
of
of
issues
that
have
been
compiled
by
you
know.
Tams
and
sa
managers
to
you
know
bring
to
the
product
team
and
say
hey.
A
These
are
the
things
that
we're
hearing
that
are
loudest
from
our
customers
have
lots
of
upvotes
all
that
kind
of
stuff,
with
our
issues
and
and
and
so
that
process
we
didn't
like
very
much
because,
first
of
all,
there's
a
big
difference
between
feedback,
we're
getting
from
existing
customers
and
prospective
customers
and
a
lot
of
that
feedback,
because
they're
tend
to
be
the
people
we
talk
to
the
most
are
from
existing
customers.
So
there
were
some
gaps
with
that
right.
A
So
there's
that
process,
then
from
there
we
moved
to
this
process
where
we,
you
know,
started
to
collect.
You
know
up
votes
on
issues,
we're
still
doing
this.
This
is
not
something
that
is
going
away
and-
and
you
know
essentially
the
loudest-
you
know
the
ones
that
have
the
most
activity.
Those
are
the
ones
that
get
kind
of
you
know
pushed
to.
The
top
of
that
list
goes
into
sensei,
and
then
we
get
compiling
a
lot
of
data
right
so
that
one's
pretty
good
as
well,
something
we
want
to
continue
to
use.
A
However,
some
of
the
problems
with
that
is
that
we
don't
have
we're
not
having
the
candid
dialogue
conversations
with
the
people
who
are
actually
speaking
with
those
people.
So
it's
hard
to
understand
impact
hard
to
understand,
prioritization
and-
and
also
you
know,
I
think
the
other
part
of
that
is
that
we're
getting
feedback
that's
directly
coming
from
customers
say
you
know,
I
use
the
example
oftentimes
it's
like
hey.
We
need
a
integration
with
xyz
servicenow,
for
example.
We
need
this.
We
need
this.
A
We
need
this,
but
really
what
we're
actually
hearing
from
the
field
is?
We
need
an
external
mechanism
for
us
to
have
author.
You
know
to
do
approvals
and
get
that
back
into
git
lab
right.
That's
a
more
generic
solution
that
we
can
accommodate
many
many
many
change
management
solutions
out
there.
So
you
know
this
process
kind
of
came
out
of
what
I've
worked
with
in
previous
organizations,
and
I
think
this
works
pretty
well
right
is
that
we've
got
10
different
stages.
A
Have
representatives
so
thanks
again
for
all
those
people
from
the
cs
and
the
product
organization
who
volunteered
for
this
to
essentially
help
collect
this
data
and
have
conversations
with
the
product
team?
So
they
can
hear
you
know
what
those
things
are
that
where
we're
hearing
out
there,
what
are
the
loudest
ones,
but
then
also.
What
is
the
rationale,
reasoning
behind
that
and
are
there
ways
that
we
can
present
it?
So
product
can
take
that
and
actually
make
decisions
based
off
of
how
we
best
think
it
will
fit
into
our
product
versus
go.
A
Take
this
and
go
put
it
in
there
right,
which
is
a
lot
of
times.
What
we're
hearing
right
now
and
that's
not
a
super
effective
way
and
ends
up
with
lots
of
technical
debt.
It
takes
a
really
long
time
and
and
it's
not
very
scalable,
either
right,
and
so
you
know
idea-wise
here.
So
we
have
the
idea
that
we
want
to
collect
data
from
pre
and
post
sales.
A
So
we
have
a
sa
and
a
tam
two
two
two
in
some
cases,
on
each
side
of
that
to
collect
the
feedback
from
those
people
to
bring
it
to
the
product
organization
and
the
best
effective
way
that
we've
found
to
do
this
and
we've
done
some
trials
with
some
of
the
the
teams
in
the
past
few
months
is
essentially
throughout
the
the
course
of
the
month,
and
this
is
if
you,
if
you
pull
open
the
document
on
the
the
feedback
guidance
doc,
which,
by
the
way,
we'll
be
moving
this
to
the
the
handbook
shortly,
but
just
want
to
do
this
for
a
collaboration
and
thanks.
A
Everyone
from
you
know,
product
and
csus,
who
has
contributed
to
this
and
provided
some
some
feedback
on
this
as
well.
Essentially,
you
know
taking
feedback
from
this.
Yes
team.
We
hear
this
from
the
customers,
creating
an
issue
into
an
issue
template
inside
that
product
feedback
project
that
we've
created.
There's
a
template
in
there
that
outlines
all
the
information
that
we've
determined
that
the
product
managers
want
to
hear
from
that
put
all
in
there
and
then
the
week
after
release.
A
So
when
we
have
a
little
bit
of
breathing
room,
you
know
we
have
a
conversation
with
the
the
team,
so
the
the
small
team
that
you
all
kind
of
organize
on
your
own,
independent
time
to
to
go
through
the
list
that
has
come
up.
Hey,
there's
four
items
in
here:
high
priority
items
right:
these
are
only
for
things
that
are
really
critical.
All
the
smaller
you
know
hey.
You
know
these
are
backlog,
type
issues.
You
know
ideas
things
along
those
lines,
that's
not
really
what
this
is
for.
A
These
are
for
things
that
are
pressing
to
impact
icv
or
potential
growth
of
the
customers.
There's
a
comment
there.
No,
so
that
being
said,
you
know
if
you
take
a
look
at
this
document.
I
call
this
share
to
make
this
a
little
bit
easier.
A
Yeah
again,
you
know
kind
of
go
through
this.
You
can
see
the
history.
You
can
see
that
feedback
product
our
project
here
with
the
boards
already
set
up
with
all
the
swim
lanes
for
each
individual
group,
and
then
you
know
this
is
conceptually
the
idea
here.
Right
we've
been
talking
about,
feedback
comes
from,
the
field
goes
to
product
and
vice
versa.
We
hear
things
from
the
teams
on
how
we
should
implement
this
stuff,
and
it
comes
back
to
the
cs.
Team
of
you
know
hey.
A
This
is
what
we
are
implementing
for
that
go.
Take
this
back
to
the
team,
so
we
can
better,
sell
it
and
better
talk
to
our
customers
about
how
we're
implementing
these
solutions
information
around
the
feedback
stuff,
I'm
not
going
to
go
through
this.
I
just
wanted
to
get
down
to
the
bottom
here,
because
this
is
kind
of
what
this
team
is
responsible
for
right
this.
A
This
initiative
is
that
the
cs
team
here
will,
you
know,
collect
feedback
right
between
the
the
release
in
the
in
the
22nd
of
the
month
prior
to
prioritize
the
the
issues.
The
cs
stage
leads
right.
The
people
who
are
on
this
call
from
the
cs
organization
review
that
talk
to
the
teams,
who
would
submit
that
to
get
more
information
around
that
and
then
the
week
after
release,
you
know
have
an
hour
conversation
with
the
product
team
cs
and
product
together
in
their
in
just
your
specific
stage.
A
These
all
happen
at
their
own
times,
based
on
your
time
zones
and
whatever
else
works
for
the
that
smaller
group
discuss
the
feedback,
any
action
plans
and
then
also
this
is
a
good
place
for
us
to
provide
some
some
as
we
get
through
month
after
month.
You
know-
and
we
do
work
on
some
of
these
high
priority
issues.
Getting
feedback
from
that
product
organization
to
the
cs,
team
lead
to
bring
back
to
the
rest
of
the
cs
organization
so
that
we
have,
you
know
an
idea
of
hey.
This
is
coming,
there's
some
delays.
A
There's
this
is
our
implementation
strategy.
Can
we
can
we
get
some
people
to
help
out
with
beta
testing,
or
you
know,
give
us
you
know,
get
on
a
call
with
someone.
So
we
can
better
understand
that
that
kind
of
conversation
and
then
that
kind
of
just
happens
in
a
cyclical
fashion
that
way
right
then,
ultimately,
hopefully
the
results
we'll
have
here
is
you
know
fewer
urgent
escalations
with
customers.
You
know
oftentimes
in
pre-sales,
we
hear
those.
We
need
this
one
thing
or
we
aren't
going
to.
We
can't
move
forward.
A
You
know
it's
some
requirement.
Maybe
procurement
thing,
maybe
a
you
know
something
that
this
feature
parody
of
their
existing
solution,
whatever
that
may
be
trying
to
reduce
that.
So
there's
there's
not
as
much
disruption
into
the
flow
of
the
product
team
and
then
better
alignment
with.
A
You
know:
industry
trends
right
what
we're
hearing
out
there
from
forrester
gardener
the
direction
that
people
are
going
with
devops
with
software
development,
all
that
that
space,
so
we're
kind
of
staying
ahead
of
that,
because
we're
getting
that
information
from
the
people
that
they
talk
to
right
and
that's
going
to
help
us
with
you
know
being
in
those.
A
You
know
leaderboards,
but
also
help
us
make
sure
that
we're
you
know
staying
ahead
of
the
competition
and
you
know
kind
of
taking
the
next
steps
for
the
next
best
thing
that
we
can
do
with
our
product,
so
smoke
a
lot
there
pretty
quickly
and
just
wanted
to
to
lay
that
out
as
an
initial
piece
kind
of
giving
some
concept
of
what
this
looks
like
and
then
real
quickly
before
I
I
stop
and
kind
of
open
up
some
discussion
here
here
is
the
here's,
the
project
that
we
had
set
up.
A
A
Then
your
your
team
will
be
able
to
kind
of
look
at
hey
here's
the
priority
or
here's
the
the
high
priority
issues,
and
then
we
have
prioritization
associated
with
that,
and
we
can
kind
of
have
a
dialogue
and
conversation
here
link
to
existing
issues
in
the
gitlab
tracker,
all
that
kind
of
stuff
that's
associated
there.
D
Good
yeah,
just
just
to
reiterate
yeah,
I
don't
really
have
anything
to
say
other
than
that
looks
really
good
is
a
good
starting
point.
Yeah
the
plan
for
rollout
is
my
interest.
You
know
when,
when
we
get
started
on
this,
what's
the
plan.
A
Yeah
and
that's
not
something
I
need
to
spend
time
with,
you
know.
This
is
why
I
had
to
get
getting
sakamoto
involved
in
this
juice,
because
you
know
for
this
to
work
effectively.
The
cs
team
has
to
be
putting
this
information
into
that
for
the
the
team
leads
to
be
in
these
conversations.
Otherwise
it
doesn't
work
right.
That's
the
biggest
risk
of
this
is
that
if
we
don't
get
that
initial
feedback
put
it
in
a
way,
that's
meaningful,
then
we
don't
have
anything
to
talk
about.
A
Then
nothing
happens
right
and
then
we're
back
to
the
same
place.
We
were
before
so
I'm
going
to
make
sure
to
be
dedicated
there
and
also
asking
you
you
all
as
well
from
the
cs
side
to
to
when
you
see
those
things
come
up
inside
our
our
channels
inside
issues
on
calls
and
stuff
make
sure
that
we're
hey.
This
sounds
like
something
we
should
be
talking
about
with
the
product
team.
A
B
I
have
maybe
not
having
another
question.
I
saw
someone
slack
and
handbook
messages
over
issue,
prioritization
work
group.
I
think
sophie
shared
that
and
I
wonder
if
there's
any
crossover
between
these
two
initiatives,
whether
whether
our
let's
say
feedback
loop,
can
also
provide
some
inputs
into
that
work.
That's
been
done.
A
Yeah-
and
I
just
saw
that
for
the
first
time
of
yesterday-
so
I
don't
know
if
sophie,
if
you
know
I
definitely
want
to
you,
know,
there's
some
overlap
there,
of
course,
and
I
want
to
make
sure
that
we're
not
duplicating
efforts
or
also
you
know,
causing
it
to
pull
into
too
many
different
directions,
but
it
seems
like
there's
some
overlaps,
but
also
some
important
pieces
that
are
kind
of
missing
from
both
sides.
There
too,
so
I
think
that
there's
there's
some
alignment
there
as
well.
E
Yeah
there
is
a
lot
of
overlap
and
I
think
the
working
group
for
issue
prioritization
is
more
along
the
lines
from
a
product
perspective
like
what
are
what's
the
cost
of
delaying
a
feature
or
something
like
that.
What
what
does
that
look
like
for
our
customers?
E
What's
that
going
to
cost
us
as
a
company,
so
it
kind
of
goes
along
the
lines
like
we
need
to
collect
that
information
as
a
cs
team
from
our
customers
and
then
the
working
group
we're
trying
to
work
on
a
model
to
be
able
to
understand
if
we
don't
get
some
feature
set
in
like
what
is
that
going
to
cost
us
as
a
company.
F
A
Yeah,
that
makes
sense-
and
I
think
so
I
think
the
the
the
tracking
piece
and
the
working
with
you
know
getting
the
right
high
prioritization
stuff
is
still
critical
piece
that
we
need
to
do
here,
but
sounds
like
maybe
decision
process,
maybe
maybe
better
that
I
don't
know
I
mean
it
could
be
mean
that
we
need
to
refactor
where
we
put
this
information
so
that
we're
doing
it
in
one
place
I'll
have
to
talk
with
you
a
little
bit
more
about
what.
A
E
E
A
C
So,
overall,
I
really
like
the
proposal.
I
think
this
is
gonna,
make
us
all
a
lot
more
efficient
at
communicating
with
each
other,
because,
speaking
for
myself,
I
mean
there's
a
lot
of
you
all
out
there
that
are
talking
to
customers
so
having
all
of
this
info
in
a
single
place,
I
think
it's
gonna
be
very
helpful
for
everyone,
two
things
I
think
we
could
add
to
this
to
get
even
more
value
out
of
it.
You
all
are
all
talking
to
prospects
in
pre-sale
situations.
C
As
part
of
this
meeting,
I
would
love
to
discuss
if
there
are
any
high
priority
ones,
big
deals
or
areas
you
expect
to
need
support
from
the
product
team.
If
we
know
about
that
sooner
rather
than
later,
you
know
we
can
tee
up
the
various
product
managers
to
make
sure
you
have
the
the
support
and
coverage
you
need
to
move
those
deals
along
further
another
one
for
the
the
product
managers.
C
I
think
and
ask
we
can
make,
is
you
know
we're
constantly
developing
new
features,
planning
out
new
capabilities
and
getting
that
user
feedback
is
critical
to
make
sure
we're
building
the
right
thing?
I
think
each
of
the
pms
should
be
able
to
come
with
a
list
of
this
is
what
we're
building
and
we
need
feedback
on.
C
Can
you
please
connect
us
with
some
of
your
accounts
interested
people,
so
that
you
know
we're
not
individually
hunting
for
interested
users,
but
you
know
get
more
in
connection
with
this
is
the
type
of
account
we
want
to
talk
to
about
this
type
of
feature.
I
think
those
are
two
things
we
can
add
to
this
sort
of
standard
agenda
to
get
more
out
of
it.
A
A
That
come
out,
and
you
know
seems
like
mileage-
varies
depending
on
the
specific
ask
where
we
either
get
nothing
or
we
get
a
number
of
you
know,
customers
that
are
interested.
I
know
that's
really
hard
to
do
and
they
also
kind
of
from
the
cs
side.
It's
also
like.
Well,
we
see
a
lot
of
that
and
it
happens
very
often
so
it's
hard
to
stay
on
top
of
that.
So
this
will
help
from
the
communication
standpoint
and
yeah.
I,
like
your.
I
like
your
thoughts
on
that
in
the
first
one
there.
A
My
only
concern
about
that.
Bringing
you
know
trying
to
get
the
right
people
lined
up
there
is,
I
think
those
tend
to
be
a
little
bit
more
timely
than
this
monthly
cadence
stuff
to
kind
of
think
about
how
we
would
do
you
know.
Usually
it's
like
hey.
We
need
to
get
product
involved
in
this
conversation
next
week
versus
next
month
right.
So,
if
we're
only
meeting
once
a
month,
so
I
guess
we'll
have
to
kind
of-
I
do
think
that's
important,
but
think
about
how
we
can
how
we
can
incorporate
that.
F
What
I
see
in
this
regard
is
that
actually,
especially
tams,
are
really
good
at
it
because
for
us
product
it's
we,
we
can't
ship
everything.
In
a
few
weeks,
often
we
are
working
on
topics
for
two
months,
yeah
and
and
basically
like
in
in
usually
it's
martin
bremer,
who
reaches
out
to
me
with
various
kubernetes
issues
and
customers
running
really
interesting
setups
for
us,
and
I
think
that
times
really
have
that
knowledge
that
okay,
I
have
a
customer.
F
A
Okay,
yep
that's
good
feedback
and
yeah.
I
think
some
of
those
longer
I
mean,
especially
when
we're
in
the
when
we
have
it
on
the
roadmap
as
something
that's
going
to
happen
in
the
next.
You
know
three
to
six
releases.
That's
a
a
good
time
for
us
to
you
know,
start
collecting
feedback
from
the
field
of
what
we
hear.
What
the
use
cases
look
like-
and
you
know
also
you
know,
bringing
in
you
or
whoever
other
product
managers
who
may
be
interested
in
getting
that
feedback.
A
That's
a
good,
conversational
piece
that
can
happen
as
part
of
that.
So
I
think
adding.
That
is
something
of
like
hey.
Maybe
this
isn't
a
critical
issue,
but
something
that
we
want
to
get
on
the
radar
for
the
product
manager
in
the
space
that
we
can
start.
You
know
honing
in
what
those
requirements
are
for
this
feature
to
be
developed
and
and
make
sure
we're
aligning
those
correctly.
F
I
would
I
would
change
here
so
like
I
think
we
are
speaking
about
two
two
topics.
One
is
where
you
have
critical
issues
and
and
really
things
where
you
want
our
input
and
want
our
attention
and
then
what
sam
mentions
is
the
other
way
around
where
we're.
Actually,
we
are
asking
for
your
care
and
and
inputs
for.
A
About
this,
being
bi-directional
right
is
that
you
know
that's
where
we're
getting
the
stuff
from
product
as
well,
where
we
need
that
input
and
there's
a
better
pathway
for
product
to
take
that
to
cs
versus
just
you
know,
putting
out
a
a
request
to
the
entire
team
where
oftentimes
you
don't
get
much
back
from
that.
As
my
experience
and.
A
A
F
I
would
have
an
extremely
operational
question.
I
just
opened
the
issue
list
in
the
cs
product
feedback
project,
and
I
see
that
issues
just
got
the
label
of
the
stage.
F
A
A
Yep,
okay,
and
so
I
think,
some
of
the
next
steps
you
know,
I'm
going
to
relay
information
to
the
cs
team
to
start
getting
some
of
these
components
together.
A
I
asked
to
you
all
is
that
you
know
work
with
your
counterparts
from
product
or
cs
to
you
know,
get
something
scheduled
for
that
that
week
after
after
the
release,
this
next
release,
so
we
can
try
going
through
this
process
and
seeing
if
what
iterations
we
need
to
make
what
changes
we
need
to
make
and
and
and
kind
of
go
through
the
steps
here
and
you
know,
align
for
the
next
next
month
after
that,
my
other
action
item
I'll
work
with
sophie
to
understand
how
we
can
better
coordinate
with
the
new
working
group.
A
That's
been
established,
so
we're
not
overlapping
or
if
we
are
that
we're
doing
an
effective
way,
and
if
we
make
some
iterations
there,
we
will
and
then
yeah
from
there.
I
think
we'll
just
see
how
this
works
with
this
process
and
also
also
mention
by
the
way
to
to
the
cs
team
that
you
know
as
part
of
this,
the
product
is
going
to
be.
You
know
looking
to
to
also
try
to
get
in
front
of
customers,
or
at
least
try
getting
beta
testers
and
things
along
those
lines.
G
Hey
brian,
if
I
can
make
one
suggestion,
I
know
the
process
that
you
outlined
is
is
for
that
sync
meeting
to
happen
the
week
after
the
release
day
22nd.
But
I
would
suggest
it
happened
in
the
first
five
business
days
following
the
22nd,
because
one
of
the
deadlines
for
pms
when
they're
planning
the
next
milestone,
is
to
have
our
target
scope
of
issues
for
the
next
milestone
by
the
fourth
of
the
month.
And
if
the
22nd
falls
on
a
monday
or
tuesday
and
we're
having
that
meeting
the
week
after.
G
For
example,
I'm
just
starting
a
calendar
invite
for
my
group
now
and
I'm
going
to
target
the
24th
of
every
month
and
we
can
adjust
within
my
group
a
few
days
a
few
days
before
a
day
before
a
few
days
after.
But
the
24th
of
the
month
would
give
the
pm
or
the
first
five
days
following
the
22nd,
would
give
the
pm
a
chance
to
adjust
what
they're
planning
for
the
next
milestone.
C
A
Okay,
yep,
that
makes
sense
yeah.
I
I
I
I
only
picked
that
just
just
it
was
my
guess
of
when.
G
It
was
going
for
for
discussion,
but
when
I
thought
about
it,
some
more
like
if
we
want
to
react
really
quickly
for
the
next
milestone,
we
want
to
meet
sooner
or
later
and
then
on
your
other
point
of
what
might
be
a
problem
with
having
this
cadence
only
once
a
month
in
case
something
comes
up
before
then,
if,
if
the,
if
the
folks
that
are
that
that
are
filling
out
those
issues
with
discussion
at
the
monthly,
they
could
always
tag
the
pm
ahead
of
time
and
says:
hey.
G
I
filled
out
the
the
issue
in
that
project
based
on
the
template.
It
has
all
the
details
and
we
want
to
get
eyes
on
it
beforehand.
It
could
be
done
async
before
that
monthly
meeting,
perfect.
A
C
Perhaps
what
we
could
also
do
here
is
for
each
of
the
the
different
stages
put
a
slack
channel
together.
Then,
if
the
various
representatives
change
from
either
side,
it's
easy
for
someone
to
to
leave
if
they're
not
involved
anymore
or
catch
up
if
they're
coming
in
and
then
that
would
also
support
a
lot
of
the
the
async
activity
activities.
We
were
just
talking
about.
A
It
could
be
actually
I
we
do
have
one
one
channel
already:
the
cs
product
feedback
channel
I'll,
invite
you
all
to
that
and
just
have
one
channel
there.
So
it
might
be
good
for
people
to
see
kind
of
some
collaboration
there
from
other
groups,
and
you
know,
I
think,
sometimes
actually
quite
often
times.
Some
of
these
things
are
crossing
over
multiple
stages,
which
is
something
I
didn't
talk
about
here,
real
quickly.
A
You
know,
if
that
happens
there
I
was
just
thinking
we
might
just
want
to
have
the
assignee,
as
victor
mentioned
be
you
know
both
the
product
managers
from
those
different
stages,
no
matter
where
it's
put
or
also
you
could
put
on
two
labels,
and
we
can
have
make
sure
we
have
that
that
conversation
between
the
teams.
G
Yeah
I
like
having
that
common
single
slack
channel
that
you
have
in
the
collaboration
guide
there
for
ces
product
feedback.
A
Yep
and
then
we
can
also
invite
you
know
that
way.
People
can
come
in
from
that
or
not.
You
know
the
dris
from
the
cs
team.
They
can
come
in
there
and
ask
questions
or
like
you
had
mentioned.
If
we
need
something
earlier,
then
that
time
you
know
hey.
Can
you
jump
on
this?
Here's
the
information
good
conversation
point
there
cool
a
few
minutes
left
here
and
I
I
know
yeah,
okay,
anything
else
that
we
should
have
or
thoughts
questions
things
we
need
to
change.
G
Thanks
for
thanks
for
getting
this
rolling
brian,
I
think
it's
going
to
be
really
helpful
on
both
sides.
Ces
and
product.
G
A
A
part
of
this
awesome
well
we'll
break
then,
and-
and
I
will
follow
up
with
all
the
stuff
that
I
had
from
action
items
and
thanks
again
for
joining
and
I'll
put
the
recording
and
I'll
I'll
paste
in
the
channel
there
as
well
invite
everyone.
There
thanks,
see
y'all.