►
From YouTube: Plan 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).
A
Okay,
well
welcome
everyone
to
the
plan
group
conversation
today
is
May
21st
2019,
as
always
our
slides
are
available,
and
please
ask
questions
in
the
documents
and,
if
you've
written
a
great
question,
we'll
probably
ask
you
to
verbalize
it
as
well.
So
far,
there's
no
questions
so
we'd
love
for
someone
to
be
the
first
person
to
step
up
to
the
plate.
A
That's
a
great
question
volunteer.
We
are
working
at
probably
the
highest
priority
from
a
sourcing,
a
recruiting
perspective
for
a
product
manager
for
plan.
It's
on
all
of
our
radars
in
terms
of
companies
that
were
looking
for
sourcing
from
Interview
priority,
making
sure
the
interviews
are
scheduled
concurrently,
making
sure
that
deep
dives
are
being
done
and
the
issues
are
being
prioritized
appropriately.
So
from
a
prioritization
perspective,
it's
it's
probably
at
the
top
of
the
list
right
next
to
some
of
the
other
director
positions,
I
I,
don't
think.
There's
anyone
in
like
super
late
stage
pipeline.
A
D
Eriko
up
I
got
a
question
for
you
to
talk
a
little
bit
about
recently
published
a
Magic
Quadrant
about
enterprise,
agile
planning
tools,
and
it
was
really
exciting
because
get
bob
was
recognized
as
a
visionary.
You
want
to
talk
a
little
bit
about
kind
of
the
way
you
see
us
as
a
visionary
and
how
you
see
us
evolving
in
this
space
to
continue
to
grow.
Yeah.
A
Absolutely
that's
a
great
question,
John
I'll
answer
and
then
actually
might
turn
back
on
you
to
answer
your
own
question
just
to
give
people
on
the
call
a
marketing
a
product,
marketing
perspective
as
well,
and
just
so
everyone
knows
the
Gartner
Magic
Quadrant
is
is
the
visionary
quadrant
is
the?
Is
the
bottom
right
quadrant?
So
that's
the
one
that
essentially,
you
have
a
great
vision,
so
to
speak,
with
visions
on
the
x-axis
and
then
ability
to
execute
is
on
as
on
the
y-axis,
so
so
room
for
improvement.
A
A
Talks
about
what
are
some
of
the
stakes
of
other
ppm
tools
in
the
market
right
now
and
really
what
you
look
at
is
you're
looking
at
a
very
old-school
mentality
of
shipping
software
and
implementing
agile,
and
we
are
actually
going
more
for
the
agile
devops
space,
meaning
we
don't
want
super
convoluted
workflows.
We
don't
want
customized
query
languages
in
our
products,
just
so
people
can
search
and
filter
on
on
issues
and
epics.
A
We
don't
want
there
to
be
a
whole
lot
of
complexity
in
our
in
our
planning
product,
because
complexity
introduces
a
whole
lot
of
friction
in
terms
of
the
adoption
of
the
tool.
It
actually
starts
to
introduce
a
lot
of
frustration
and
loathing
from
a
developer
and
from
a
knowledge
worker
perspective,
and
so
I
think
this
is
actually
validation
of
our
strategy.
You
can
go,
read
it
on
the
plan.
Direction
page,
you
can
it'll
talk
about
how
we
want
to
get
the
industry
to
an
aspect
of
plan,
break
the
plan,
replan
break
it
replan
again.
A
This
is
not
the
old-school
mentality
of
project
management.
You
know
10
years
ago
it
was
create
a
plan,
stick
to
the
plan
and
do
it
and
we
used
to
have
this
term
wag
I'll
write,
which
is
these
teams
that
were
planning
in
a
waterfall
methodology,
but
also
we're
trying
to
adopt.
You
know
agile
methodologies
at
the
same
time-
and
it
was
almost
like
this
running
joke
that
you
were
a
wedge
I'll
shop.
We
want
people
to
adopt
agile
devops,
which
means
we
want
plans
to
be
broken
in
order
for
plans
to
be
broken.
A
It
means
that
your
planning
and
project
management
technology
has
to
be
very,
very
flexible
and
I.
Think
it's
great
that
Gartner
recognizes
that
we
are
we're
thinking
about
it.
This
way,
not
a
lot
of
other
tools
in
the
space
are
thinking
about
it.
This
way,
and
so
I'm
happy
to
go
into
more
detail,
but
that's
my
thoughts
on
it.
A
I'm
happy
where
we're
at
obviously
I'm
not
super
happy
that
we're
not
higher
up
on
the
execution
bar
in
terms
of
what
how
Gartner's,
I'm
analyzing
us
there
I
think
we
have
some
room
for
improvement,
but
overall
I'm
I
like
that
we're
in
the
visionary,
Quadrant
I
think
it
speaks
a
lot
to
where
we're
going.
Do.
D
Even
tools
to
connect
the
data
between
other
tools,
there's
a
whole
segment
of
tools
that
are
just
just
trying
to
connect
between
other
tools
and
and
they
started
to
realize
and
I
think
they
saw
the
potential
of
where
we're
going
and
the
vision
where
we're
headed
is
really
solving
problems
that
both
small
teams
having
large
enterprises
have
now
I
know
as
we
go
forward.
There
will
be
some
complexity.
We
add
in
we're.
A
B
It
sure-
and
maybe
this
has
been
in
the
works
for
a
long
time
and
I-
just
personally-
haven't
seen
this
before,
but
I'm
curious.
If
you
could
expand
on
the
way
that
the
plan
team
is
split
between
like
to
plan
unit
race
planning,
as
it
seems
like
an
interesting
split
around
like
size
and
capability
for
org
size.
I.
Don't
I'm
not
aware
of
us
doing
that
in
other
stages
and
I'm
curious.
What
makes
that
different
for
plan
or,
if
we're
concerned
about
like
diverging
and
in
terms
of
our
approach
to
planning
for
like
orga
size.
A
Yeah,
that's
a
great
question:
I'll
answer
and
I'd
love
for
Shauna
and
Donald
to
jump
in
on
this
one
as
well.
So
this
is
actually
something
that
we
are.
We
are
working
towards
in
in
most
other
stages,
and
when
you
look
at
the
product
hierarchy,
we
have
stage
group
and
then
category
and
what
we've
had
for
a
long
time
is
one
product
manager
and
one
kind
of
engineering
team
per
stage.
We've
now
broken
stages
into
multiple
groups,
where
a
group
has
multiple
categories.
A
So,
as
you've
mentioned
and
I'll
pick
on
team
planning
for
a
while
team
planning
has
you
know
boards,
and
it
has
time
tracking
and
it's
got
project
management
as
categories.
That
is
something
that
a
single
product
manager
will
be
focusing
on
with
a
single
PM
team.
We
also
have
obviously
two
other
categories
and
plans,
so
the
long-term
plan
for
plan
is
that
there's
three
PM's
one
per
group
and
if
you
look
at
the
product
organization
as
a
whole,
the
goal
is
for
there
to
be
a
product
manager
per
group.
A
E
Yeah
from
an
engineering
perspective,
one
thing
that's
kind
of
interesting,
but
not
it's
not
a
huge
factor,
but
one
thing
I
did
find
interesting
when
we
talked
about
this
split
is
what
it
means
it's
the
effectively.
One
team
does
much
more
open
source
work
than
the
other,
because
everything
that's
in
core
is
open
source
and
everything
that's
in
every
other,
tier,
isn't,
and
because
that
the
split
is
almost
Kor
paid
tiers.
It
works
out
that
way.
So
that's
another
way,
I've
sort
of
thought
about
it.
E
When
talking
with
my
team,
I
think
from
an
engineering
perspective,
it
feels
like
there's
those
natural
boundaries
for
like
ownership
of
features
as
well.
Hopefully
we
will
be
hiring
a
new
engineering
manager
for
plan
soon,
so
we
will
have
two
back
end
engineering
managers
and
we'll
be
able
to
split
the
back-end
team
before
we
split
the
rest
of
the
the
stage
in
the
same
way,
obviously,
because
with
three
engineering
managers
and
one
interim
PM,
that's
that's
not
the
ratio
we're
looking
for,
but
you
know
it's
how
the
hiring
worked
out.
E
F
F
F
F
We
just
make
sure
we
just
need
to
make
sure
that
we
are
aligned
and
that
each
of
those
groups
are
working
very
closely
together,
maybe
under
Eric
or
a
director
level,
to
make
sure
that
everyone
is
constantly
communicating
with
each
other
and
constantly
working
toward
that
same
higher
level
goal
great.
Thank
you.
G
E
So
we've
been
together
for
a
while,
and
you
know
that
we've
had
what
we
call
functional
group
updates
and
there
were
conversations
in
one
form
or
another
for
a
while
and
I
just
kind
of
always
did
them
using
get
lab
pages
because
I,
you
know
like
to
talk
through
the
product.
I,
don't
really
have
many
cases
where
any
to
use
get
on
pages.
Otherwise,
so
it
was
kind
of
fun.
E
So
yeah
I
have
considered
trying
to
match
the
slide
template
in
CSS,
but
I'm
really
not
good
at
CSS,
and
it's
probably
not
a
great
you've
so
much
time
so
I
didn't
yet.
But
if
anybody
wants
to
like
the
the
project
is
open
source,
so
you
know
anybody.
Anybody
can
do
that
if
they
want
to
I.
Just
not
it
basically
Philippe.
You
had
a
question
about
graphic
UL.
H
Yeah
Thank
You
Shannon,
you,
you
started
to
reply
on
the
door.
Thank
you
for
that.
So
yeah.
When
I
hear
graph,
Korea
and
you're
out
of
flexibility
and
when
I
hear
that
my
security
sensors
are
that
good?
So
I,
wonder!
Oh,
but
do
you
work
with
the
security
team
to
ensure
that
everything
related
to
graph
QL
is
safe
and
that
we
don't
burn
some
gates
that
were
not
expected
in
the
first
place?
H
E
So,
like
I
said
here,
this
is
kind
of
a
weird
one,
because
we
sort
of
took
this
on
from
create.
So
like
we
kind
of
swapped
some
stuff
with
them,
because
elastic
search
and
search
in
general
used
to
belong
to
plan,
then
it
moved
to
create.
So
we
took
the
graphical
work
off
them,
so
they
did
most
of
this
so
I'm,
just
like
basically
repeating
what
they
did.
E
The
main
I
think
they
already
did
work
with
the
security
team,
but
the
main
thing
that
they
did
was
that's
in
the
graphic
ul
API,
it's
much
easier
to
perform
an
authorization
check
on
a
specific
field
or
a
specific
type.
So,
like
you
know
graph
QL,
you
can
nest.
You
can
request
another
object,
just
like
the
the
child
of
an
object
which
I'm
not
saying
is
a
panacea.
E
If
this
was
very
clear
in
the
slides,
actually
there's
also
very
limited
to
the
moment,
it
doesn't
actually
expose
a
lot
just
because
we're
mostly
focusing
on
making
it
what's
the
word
we're
mostly
focusing
on
the
sort
of
the
infrastructure
for
it
by
which
I
mean
like
you
can
authorize
types
and
fields.
We
have
monitoring,
we
have
logging
documentation
all
that
stuff
and
then,
as
we
go
forward,
we'll
actually
fill
out
the
the
resources
available.
E
So
it's
probably
something
that
we
need
to
tackle
on
an
ongoing
basis
as
well,
rather
than
just
treat
it
as
done
so
check
back
in
and
get
security
reviews
when
we
add
a
new
major
set
of
functionality
to
the
graph
QL
API,
particularly
in
sensitive
areas
like
at
the
moment.
We
don't
expose
any
user
management
through
the
graph
QL
API,
but
some
when
we
do
that
I
think
that's
a
that's
a
really
good
spot
to
hit.
Actually,
while
I'm
talking
about
graphic
UL.
E
The
thing
that
makes
me
nervous
about
graph
QL
is
performance
because,
like
you
can
do
anything,
I
had
like
the
trick
to
performance
optimizations.
A
lot
of
the
time
is,
do
less,
but
you
don't
control
that
so
much
here,
but
we've
we've
talked
about
some
approaches
there,
Fabian
sorry
Philippe
did
you
have
anything
you
want
to
follow
up
on
that?
First,
no,
that
that's
perfect!
Thank
you
very
much
cool
Fabian!
You
had
a
question.
Do
you
want
to
verbalize
it?
Yes,.
I
So
first
thing:
since
I'm,
a
big
fan
of
the
plan
features
in
gitlab,
so
I
think
you
guys
are
doing
amazing
work.
So
one
thing
that
I
was
wondering
about
is
I,
am
I,
think
we're
we're
introducing
many
new,
interesting
capabilities
for
project
management,
which
are
extremely
valuable
but
sort
of
out
of
selfish
interest
as
a
product
manager.
We
also
use
git
Lab
for
managing
our
own
product
and
I
was
wondering
if
we
are
also
seeing
yourself
sort
of
competing
with
dedicated
product
management
software.
I
A
Yeah
I
wrote
some
thoughts
there,
Fabian
thanks
for
the
question.
The
short
answer
is:
yes,
we're,
obviously
thinking
about
ways
to
make
the
product
manager
persona,
essentially
more
usable
or
more
delighted
as
they
use
the
product,
so
to
speak.
There's
a
lot
of
work
happening
right
now
on
epic
visualization.
A
Some
of
the
features
in
project
management
will
overlap
like
very,
very
heavily
with
respect
to
like
what
a
product
managers
going
to
need,
and
so
epic
visualization
is,
is
starting
in
12
and
12
1
we're
spending
a
lot
of
cycles
on
doing
epic
visualization
doing
drag-and-drop
trees
within
an
epoch
itself
within
an
issue
and
understanding
where
that
issue
lives
in
the
hierarchy.
So
that's
like
one
aspect
of
like
a
very
near
change
that
we're
going
to
make
that
I
think
will
help
not
only
project
managers
but
also
product
managers.
You
and
I.
A
The
other
thing
that
I've
been
I've
been
kicking
around
as
well.
I'm.
Glad
you
brought
this
up
is
I.
Think
roadmaps
is
something
that
we
are
under
serving
a
little
bit
and
I.
Think
there's
a
huge
opportunity
here.
If
you
look
at
road
maps
right
now,
it's
basically
just
a
very
simple
Gantt
chart
of
epochs.
You
know:
there's
no
color
coding,
there's
no
ability
to
drag
and
drop
things
on
on
the
road
map
and
I,
think
road
maps.
A
When
you
think
about
a
category
I
get
laughs,
a
category
should
be
a
standalone
product
at
another
company.
There's
multiple
companies
that
have
put
that
it
popped
up
around
just
doing
Road
mapping.
You
look
at
you
know:
aha,
like,
as
you
mentioned,
you
look
at
like
the
prod
pads
of
the
world
and
they're
actually
doing
really
unique,
takes
on
on-road
mapping,
and
so
I've
been
thinking
about
pulling
Road
mapping
out
as
a
category.
A
Now
that
we've
taken
VSN
and
move
that
to
to
manage
I'm
thinking
that
we
probably
pull
Road
mapping
up
into
its
own
category
and
then
we
start
to
kind
of
dive
a
little
bit
deeper
there
and
then,
as
Mark
mentioned.
Obviously,
the
personas
is
a
big
part
of
this
right,
which
is.
We
also
want
to
link
every
issue
every
feature
back
to
a
persona.
So
the
details
will
then
should
be
linked
from
that
from
that
link.
As
well
so
thanks
for
the
question
yeah.
I
J
A
I
didn't
know
this
question
was
coming,
but
I
did
have
a
slide
just
in
case
it
did
show
up
on
the
on
the
group
conversation
so
slide.
6
is
the
is
a
slide
I
put
together
for
I
think
how
we
become
a
leader
in
this
space
and
so
I'll
just
quickly
talk
to
that
slide,
so
I
think.
The
first
thing
we
have
to
understand
is
understanding.
Like
the
history
of
this
space.
I
talked
about
this
a
little
bit
with
John's
question
on
the
on
the
NQ.
We
have
to
learn
from
the
past
mistakes.
A
We
will
embrace
the
small,
primitive
mindset
where
we
develop
a
very
sharp
tool
that
can
be
used
in
a
number
of
different
ways
and
and
maybe
becomes
a
Swiss
Army
knife
over
time.
But
what
that
does
is
it
allows
us
to
essentially
spend
a
lot
less
engineering
effort
and
create
a
lot
more
use
cases,
and
so
we
have
to
learn
from
the
industry's
past
mistakes.
A
That's
number
one
number
two
there's
just
some
table
stakes
things
that
project
managers
need
that
we
don't
yet
have
we
have
to
get
that
functionality
in
place,
and
so
these
are
things
like
epic
dependencies,
visualizing
epics
epics.
That
span
maybe
more
than
one
group,
and
so
there's
obviously
links
here
that
you
can
go
and
take
a
look
at
and
please
participate.
Any
of
you
should
go
and
participate
in
any
of
these
issues.
If
you,
if
you
care
deeply
about
them
so
there's
one
aspect
is
getting:
functionality
doesn't
exist
into
the
product.
A
Another
aspect
of
it
is
making
the
functionality
that
exists
a
little
bit
better.
We
need
to
make
our
product
more
lovable,
there's
not
a
single
category
that
is
marked
as
loveable
maturity
in
plan,
and
so
it's
moving,
some
of
those
things
to
loveable
and
I'd
like
to
start
with
boards.
I
think
boards
is
one
of
the
things
that
most
of
us
love
about
this
product.
It's
a
thing
that
obviously
JIRA
acquired
Trello,
literally
just
for
boards,
and
so
it's
very,
very
powerful.
It's
a
really
easy
way
to
get
started
with
really
any
task.
E
We
talked
about
splitting
the
plan
team.
One
thing
I've
used
boards
for
there
is
I
created
a
project
just
a
private
project
and
I
created
issues
for
each
team
member
who
needs
to
be
on
one
of
the
two
teams
with
labels
for,
like
you
know
where
they're
based
in
the
world,
if
they
have
any
preference,
whether
they're
senior
or
intermediate,
and
then
I,
can
just
drag
those
between
the
two
teams
and
see
if,
like
yeah,
all
those
factors,
balance
out
so
there's
kind
of
a
weird
use
of
boards.
But
yeah
I,
don't
food
eating
again.
A
Absolutely
yeah,
thanks
for
that
Shawn.
Let
me
move
on
because
we're
running
out
of
time
here
we
want
to
attract
other
use
cases
there
are
there
are
things
in
the
project,
management
and
portfolio
management
space
that
we
don't
have
any
functionality
around
today.
These
are
things
like
quality
management
requirements,
management.
These
are
really
old
areas
and
when
I
say
old,
they're
they're
very
embedded
in
a
very
legacy
IT
mindset
of
developing
software
developing
requirements.
A
These
are
areas
that
are
ripe
to
be
disrupted,
that
we
can
go
and
attack,
and
so
I'm
excited
for
these
areas,
and
we
haven't
done
anything
in
them.
So
it's
expanding
the
user
base
of
who's
going
to
actually
use
our
planning
features.
We
need
to
increase.
Adoption,
though,
is
another
big
one
that
we
we
don't
often
talk
about
this,
but
epics
are
an
ultimate
feature,
which
means
that
we
have
a
very
small
percentage
of
gitlab
customers
actually
using
epics
if
they're,
not
using
a
open-source
project
on
Caleb
comm.
A
If
you
read
through
all
the
comments,
I'm
like
why
we
haven't
necessarily
done
it,
yeah
there's
some
technical
challenges
and
how
you
map
custom
fields
to
the
various
aspects
and
get
lab,
but
I
think
if
we
actually
just
put
some
thought
into
this,
we
could
we
could
actually
make
this
something
really
really
easy
to
do.
And
just
so
everyone
knows
you
can't
import
JIRA
issues
today,
but
it's
just
a
simple
CSV
import
and
it's
just
going
to
take
title
and
description.
It's
not
gonna
grab
all
the
rest
of
the
stuff.
So
these
are
my
thoughts.
J
J
I
guess
I'd
love
to
see
that
fleshed
out
with
a
little
bit
more
of
a
concrete
plan.
For
you
know
what
what
do
people
really
need
with
issue
boards
I
mean
I,
know:
I've
got
my
pet
things
that
I
remember
from
using
Trello
that
aren't
captured
in
that
epic.
Yet
just
feels
like
that
needs
to
be
left
a
little
bit
more.
A
Yeah,
look,
let
me
just
tell
you
where
we're
starting
there.
Real,
quick,
I'm
gonna,
actually
update
an
issue
description.
The
group
board
move
sorry
deepness.
Let
me
rephrase
multi
select
move
issues
in
boards
is
something
that
is
top
of
mind
which
is
in
that
epoch.
So
that's
where
we're
starting
and
then
we'll
figure
out
where
we
need
to
go.
But
the
fair
point
will
flush
that
out
cool
things.
Yeah.
K
E
We
do
get
quite
a
lot
of
community
contributions
just
because
plan
is
stage
that
subsisted
get
live
for
a
long
time,
but
I
haven't
been
so
I
know
at
the
moment.
For
instance,
we
have
a
community
contribution
in
to
add
a
new
issue
tracker,
the
name
of
which
I've
forgotten
to
like
external
integrations
there,
which
is
really
awesome
and
I,
think
that's
getting
close
to
being
ready,
but
we're
not
tracking
this
in
any
way
other
than
like
the
throughput
charts
and
so
on.
A
A
lot
of
that
comes
down
to
education
in
some
cases
the
big
requests
are
things
we
already
want
to
do
or
they
align
with
our
vision.
So,
for
example,
I
was
on
on
the
phone
with
a
big
customer
last
week
that
asked
for
multi-issue
moving
in
boards.
It's
like
a
no-brainer
like
we
should
go.
Do
that
to
make
boards
more
lovable
and
we're
gonna
go.
Do
that
I
think
it's
prioritizing
12
1
or
12
2,
but
for
things
that
like
may
be
misaligned.
A
That's
where
we
put
a
little
more
thought
into
it
and
becomes
a
little
bit
more
of
a
conversation.
It
becomes
a
more
of
a
an
education
like
hey.
Do
you
need
that?
Because
your
framework
says
you
need
it,
then
that's
a
different
bucket
that
we
would
put
it
into
or
do
you
need
it,
because
it's
just
how
you've
always
done
it
in
another
project
management
tool,
then
it
becomes
more
of
a
conversation
on
how
we
can
either
adapt
their
workflow
to
our
tool
or
you
know,
can
you
can
you
reuse
a
small,
primitive,
but
yeah?
A
We
definitely
don't
want
to
just
do
anything.
Customers
asked
us
to
do
because
then
we'll
get
into
this,
this
situation,
two
or
three
years
down
the
road,
maybe
five
years
down
the
road
where
we've
got
this
feature
with
sorry,
we've
got
this
product
with
a
million
features
in
it.
That
just
is
just
a
disparate
mess
of
things
that
is
hard
to
use
and
hard
to
navigate
and
everyone
hates
it.