►
From YouTube: Plan group weekly meeting 2019-07-31
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
C
D
The
the
results
are
in
and
Gartner's
peer
review
process,
which
required
us
to
have
close
to,
but
I
think
50
different
large
enterprises
do
reviews
of
us
and
we
earned
the
customer
Choice
Award.
You
know
and
puts
us
in
the
likes
of
JIRA
and
Microsoft
with
Azure
DevOps,
slash,
TFS
amazing
results
were
you
know
we
have
the
best
rating
on
top
of
that
of
all
those
a
4.6
compared
to
everyone
else.
A
cherry
picked
a
couple
of
the
reviews
that
were
there
just
to
give
you
a
highlight
of
what
people
were
saying.
D
So
everyone
on
this
team
has
been
working
incredibly
hard
to
build
and
evolve
issue
management
into
project
planning
and
agile
planning,
and
you
know
what
we're
on
the
map.
This
is
awesome,
so
congratulations
were
visionaries
and
Gartner's
review,
which
puts
us
in
an
awesome
place
as
well.
So
I'm
excited
to
see
where
we're
excited
with
where
we've
gone
and
how
far
we've
come.
I'm
incredibly
excited
about
where
we're
gonna
go
next,
so
with
that,
thank
you.
What.
C
D
Know
it's
it's
interesting.
I
haven't
done
in
a
gap
analysis,
you
know,
Victor
was
gone
and
Gabe's
here
and
I.
Think
one
of
the
things
we
need
to
do
with
Vic
with
Gabe
is
take
a
look
at
this
and
see.
What
does
this
tell
us
where
we
should
go?
I
just
said
gave
a
link
to
the
critical
capabilities
document
that
Gartner
uses
I'm
looking
for
it.
I'll
put
the
link
in
here
as
well.
The
gardener
uses
to
define
when
they
do
to
Magic
Quadrant.
Where
did
zoom
go
I
hate
too
many
monitors,
there's
them.
D
And
you
could
take
a
look
at
this
document:
it's
not
public,
it's
internal
only,
but
that
document
is
what
they
write.
They
write
that
and
they
do
that
study
before
they
do
the
Magic
Quadrant
and
then,
when
they
do
the
Magic
Quadrant
they're,
looking
not
only
at
the
product
but
the
business
as
well.
So
there's
a
lot
more
that
goes
into
the
Magic
Quadrant,
but
that
sets
the
bar
that's
the
least
the
baseline
criteria.
D
And
if
you
look
at
it,
you
can
kind
of
get
a
sense
as
to
where
we're
at
you
know
we
are
not
the
strongest
tool.
If
you
look
at
the
ranking
of
this,
you
know
we're
kind
of
in
the
kind
of
a
middle
lower
half
of
the
pack
of
overall
four
scores,
for
you
know
scrum
team
and
we're
a
little
higher
for
cutting
a
single
team.
You
know
Kanban
and
if
you
go
all
the
way
to
the
bottom
of
this
document,
it
shows
you
where
the
Lord's
ago,
you
can
have
it
at
the
bottom.
D
Happy
happy
to
share
and
happy
to
do
this.
The
other
thing
we
can
do
and
Gabe
does
this
I
do
this
typically
with
the
product
managers,
but
you
know
more
people
are
welcome
either
to
listen
in
or
dr.
connect
or
past
questions,
but
we
have
the
ability
to
go
back
to
these
analysts.
In
this
case.
You
know
this
reports
Tom
Murphy
or
Mike
West
and
Keith
and
Tom
Murphy.
The
analysts
who
write
this.
We
can
go
back
to
them
with
questions
and
do
what
are
called
inquiries.
D
We
can
get
30
minute
sessions
with
them
where
they
basically
will
tell
us
what
they're
hearing
from
customers.
They
will
tell
us
what
they're
seeing
at
the
market.
They
will
give
us
insight.
So
it's
an
opportunity
for
us
to
use
them
as
a
resource
and
have
dialogue
with
them
and
we
can
set
them.
We
have
as
may
as
we
want
as
long
as
we
can
be
meaningful
dialogue,
typically
I
as
a
product
marketing
manager,
I
technically
am
involved
in
setting
it
up,
but
it's
usually
a
partnership
with
product
management.
Usually
it's
product
management.
E
D
And
we
will,
we
do
have
to
be
cautious
about
having
an
army
of
people
show
up,
so
we
do
have
to
be
thoughtful
about
not
overwhelming
them
and
having
a
single
person
or
a
couple.
People
drive
the
conversation
but
yeah
absolutely
I'll
get
with
Joyce
and
get
an
issue
open
to
do
it
with
both
both
for
store
and
guard
or
both
of
them
cover
us
and
I
have
relationships
with
a
handful
of
these
guys
and
gals
over
the
years.
So
yeah.
E
You
good
cool
yeah,
so
I
just
wanted
to
kind
of
highlight
some
evolving
changes.
Just
like
did
high-level
product
organization
in
collab
and
then
also
specific
to
the
plan
team,
so
Scott,
blimps,
MVP,
Park,
is
kind
of
mandated
or
suggest
recommended
that
we
adopt
a
kind
of
a
more
validation
prior
to
just
jumping
in
and
building
features,
and
there's
been
a
lot
of
back
and
forth
between
the
product
managers
about.
Is
it
gonna,
slow
things
down?
E
This
still
is
aligned
with
like
our
milestone
process
and
our
release
process,
and
so
there's
a
I
just
opened
a
merge
request
this
morning
for
like
adding
a
kind
of
a
planned
cross-functional
team
page
just
to
talk
about
some
of
these
planning
things
in
the
handbook.
I
would
love
people
to
kind
of
weigh
in
on
that,
but
one
of
the
big
things
that
we
want
to
work
towards-
and
we
definitely
want
to
build
in
the
product
itself-
is
better
reporting
for
teams
so
like
as
a
product
manager
right
now
coming
in
and
saying
like.
E
What
can
we
fit
in
a
given
release?
We
don't
have
good
quantitative
data
about
what
our
velocity
is
from
like
a
weight
standpoint
I
can
see
how
many
issues
we
complete
on
average.
Each
month,
but
we
it's
it's,
not
helpful
for
making
commitments
to
the
broader
organization
to
our
customers
about
what
we
can
get
done
and
what
we
can
fit
in
and
how
to
make
trade-offs
and
how
to
discuss
that
as
a
team
and
what
we
need
to
break
down
to
more
like
pieces.
E
So
part
of
working
towards,
like
kind
of
more
combine
flow
is,
is
trying
to
start
to
collect
that
data
more
intentionally
over
time,
even
if
it's
manually
before
it
gets
put
into
the
product.
So
there's
a
there's
two
kind
of
combine
boards.
That
kind
of
represents
that
and
workflow
that
artists
try
to
adopt
it.
I
will
post
a
link
to
the
Paige
once
the
merge
request
goes
in.
C
Is
there
anything
apart
from
reviewing
that?
Mr?
Is
there
anything
you
need
from
us
like
as
engineer
as
far
as
you,
product
designers
or
whatever
in
the
short-term?
Like
you
know,
apart
from,
like
you
know,
mention
you
on
issues
like
make
sure
you're
in
the
loop
on
things
there
anything
else
you
want
to
get
from
us
in
the
immediate
future.
That
would
help
a
lot
I.
E
Think
that
that
that's
in
the
immediate
future,
probably
I,
think
that's
where
you
know
when
we
talk
about
doing
getting
ready
for
12.3
and
things
that
haven't
been
properly
validated
from
like
a
problem
or
solution.
If
we
haven't
done
enough,
customer
abuse
for
like
a
given
huge
feature
set
I
would
love
to
get
UX
involved
is
just
in
kind
of
making
sure
we
are
doing
those
customer
interviews
and
discovery
calls
before
we
go
in
and
build
something
and
like
that's,
where
we
kind
of
have
to
balance
it
out.
E
We
can't
just
put
pause
on
everything
to
go
back
and
redo
everything
if
we
have
like
hit
it
to
a
tee,
but
this
is
more
of
like
as
we
move
forward.
We
want
to
start
thinking
about
big
features.
We
want
to
do
customer
interviews
prior
to
to
make
sure
that
we
understand
the
problem
correctly,
to
make
sure
that
we're
validating
the
solution
and
doing
some
of
those
light
prototypes,
so
they'll
only
go
to
build
something,
we're
building
something
that
is
actually
needed
and
fits
the
the
job
that
we're
building
the
feature
for
and
will
be.
E
You
know
broadly
accepted
internally
and
externally,
I
think
in
the
immediate
like
if
you
are
blocked
on
something
or
if
something
is
taking
a
long
time
to
finish
or
there's
like
kind
of
ambiguity.
Please
include
me
in
that,
because
I
want
to
come
and
help
solve
the
ambiguity
and
get
things
moving
so
that
we
can
ship
stuff
so
I,
like
I'm.
Still
wrapping
up
I'm
gonna
be
working,
probably
mostly
on
more
of
like
the
the
process
will
become
I,
guess
a
more
real
thing,
probably
through
12
floor
planning.
C
C
Also
I
think
just
to
verbalize
it
that's
in
the
doc,
but
people
watching
the
recording
won't
necessarily
see
the
doc
at
the
same
time,
I
also
linked
to
the
geo
planning
page
I.
Don't
think
we
necessarily
want
to
do
things
exactly
the
same
way
that
the
geo
group
do
them,
but
it's
useful
to
to
see
how
they
do
things,
because
they're
also
trying
to
take
a
more
combat
like
approach
and
if
we
can
steal
something
from
them
great.
E
I
think
next
next
week,
I'll
do
a
demo
of
everything
once
it
gets
kind
of
in
place
a
little
bit
more
I
like
to
get
some
the
documentation
up
in
some
of
they're
like
foundational
pieces
in
place,
and
then
we
can
walk
through
like
a
couple
hypotheticals
but
like
I,
said
I,
don't
want
to
like
change
everything
in
one
week,
just
it's
just
something
we
can
slowly
evolve
to
over.
They
coming.
You
know
several
weeks,
two
months,
yeah.
C
F
Yeah
we
are
we're
really
close
to
having
an
author
sent
out
for
another
p.m.
which
is
which
is
good
and
and
yeah.
So
that's
super
exciting
so
that
so
the
team
is
scaling.
We've
obviously
got
a
new
engineering
manager,
starting
the
team's
going
to
be
splitting
and
focusing
on
different
things.
Super
exciting
time.
I
think
it's
also
a
good
time
for
us
to
make
sure
that
we're
really
strong
on
a
lot
of
this
process
stuff
one.
F
B
F
Think
I
would
I
think
I
would
classify
it
as
like.
Yes,
we've
we've
committed
to
I.
Don't
know
if
committed
is
the
right
word,
but
I've
said
we've.
We
validated
it
there's
a
problem
and
we've
validated
that
a
solution
makes
sense
whether
or
not
we've
committed
it
to
a
specific
customer,
or
you
know
committed
to
build
I,
don't
think.
Actually
it
is
necessarily
true,
although
it's
probably
a
good
idea
at
that
point,
because
we
have
we've
essentially
found
a
product
market
fit
for
lack
of
a
better
term.
Yeah.
E
The
way
you
can
think
about
it
is
work,
move
from
left
to
right,
and
so,
if
everybody
only
is
working
on
one
thing
as
soon
as
they
finish,
maybe
the
issue
they're
working
on
it's
in
dev.
They
can
just
pull
from
like
a
backlog
of
stuff
that
is
ready
to
go,
and
this
also
gives
flexibility
for
the
product
manager
and
the
rest
of
team
to
get
to
you
to
tweak
some
of
the
requirements
or,
what's
gonna,
be
built
right
right
up
until
the
moment
that
it
it
started.
E
E
So
it's
kind
of
just
a
it's
kind
of
a
workflow
system
that
makes
it
really
simple
to
kind
of
pull
and
move
things
on,
and
then
the
next
layer
is
measurement
on
that
and
you
can
kind
of
better
measure
the
throughput
and
like
what
the
team
can
get
done
and
they
give
a
period.
So
that
way
you
can
know
what
to
commit
to
and
how
to
communicate
that
to
the
broader
or
wider
community.
Internal
and
external
I'm.
C
From
an
engineering,
sorry
from
a
development
perspective,
there's
a
couple
of
things
that
sort
of
you
know
jump
out
to
me
from
the
Geo
boards.
First
of
all,
really
heavy
use
of
the
workflow
labels,
so
I
know
in
the
backend
team
were
pretty
inconsistent
like
sometimes
we
use
those.
Sometimes
we
don't
like
and
that's
that's
not
saying
some
people
use
them
and
some
people,
don't
that's
saying
pretty
much.
Everybody
uses
them
some
of
the
time.
C
So
if
it's
the
same
on
the
front-end
team,
like
that's
the
thing
is
you
know
we,
as
engineering
teams,
need
to
make
sure
we
were
more
consistent
about,
but
also
geo
is
pretty
much
100%.
Back-End
I
think
in
fact,
crucial
who
spends
most
of
his
time.
Working
on
plan
related
stuff
is
technically
a
chioce
front-end
person
as
well.
So
you
know
we
might
need
a
couple
more
boards
for
the
details.
They're
about,
like
you
know,
does
this
need
front-end
and
back-end?
Does
this
new
front-end
like
we
do
right
now,
but
we
can.
C
Assuming
everything
goes
well
because
that's
the
perfect
time
to
be
already
in
the
process
of
making
these
incremental
changes,
so
we
can
still
get
feedback
from
them,
but
we
also
can
give
them
a
direction
so
that
they're
not
just
we're,
not
just
expecting
them
to
come
in
and
do
this
from
scratch,
like
gapes
up
a
great
job
here,
but
we
don't
want
every
new
p.m.
to
have
to
do
what
Gabe's
done
yeah
so
yeah
thanks,
Gabe,
basically
saying
they're.
Ok,.