►
From YouTube: Plan stage weekly meeting - 2019-12-11
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
C
A
A
Big
picture
updates.
One
of
the
things
that
I
would
like
to
do
is
just
walk
through
I'm
gonna.
Try
maybe
do
this
once
one
one
category
each
week
and
not
just
mine,
but
any
group
within
plan
was,
should
walk
through
theirs
and
just
get
feedback
from
the
team.
I
think
one
of
the
things
that
I
have
missed
may
give
up.
This
par
is
having
more
collaboration.
A
Around
strategy
and
kind
of
big
picture
goals
like
I
know
I'm
the
DRI
for
it,
but
I
also
think
that
the
team
has
a
valuable
input
and
should
contribute
to
it.
I,
like
I'd
like
to
see
everybody
a
little
bit
more
involved
in
that,
and
even
if
that's
just
like
talking
to
me
and
then
I'll
translate
that
into
the
actual,
like
file
so
I'm
gonna
share
my
screen.
I
think
I've
tracked
down
my
screen
freezing
to
my
external
video
camera.
A
A
This
is
the
category
strategy
for
issue
tracking
I
wrote
this
a
couple
of
months
ago
or
maybe
like
six
six
eight
weeks
ago,
I
guess
I
updated
this
last
and
I
wanted
to
just
kind
of
like
talk
through
the
purpose
of
the
category
and
kind
of
the
big
picture
and
vision
and
then
kind
of
get
some
like
pause
from
it
to
get
feedback.
So
one
of
things
it
wasn't
necessarily
on,
like
all
of
the
other
category,
starter
pages,
was
like
the
essential
intent
and
I'd
tried
to
break
that
down.
A
A
D
I
think
that
makes
sense
for
where
we're
at
I
mean
in
my
world
single
sort
of
truth
is
always
a
requirement.
Not
an
issue
issue
is
how
you
change
the
singles
works
truth,
but
I
realized
that
that's
not
a
universal
thing,
so
I
think
to
the
market.
We're
looking
at
issues
our
single
source
of
truth
for
most
so
I
think
it
makes
good
sense.
A
A
For
that
long,
so,
and
then
one
of
them
is
issue
should
take
less
than
one
second
to
load
and
there's
never
more
than
one
second
delay
and
probably
ain't
changes
on
the
issue
to
any
member
and
members
never
interact
with
issues
that
do
does
not
contain
the
most
recent
changes
so
like
this
is
a
particular
problem
right
now,
because,
like
our
comments,
take
a
long
time
to
load
issues
in
general
take
a
long
time
to
load.
Depending
on
how
many
comments
there
are.
If
an
issue
is
left
open,
my
browser
and
I
come
back.
A
There
are
things
that
are
out
of
date
on
it.
Unless
I
refresh
my
page
and
note
to
do
that,
and
so
like
that's,
where
I've
even
run
into
this,
quite
a
bit
get
lab
where,
like
issues
are
stale
and
I'm,
looking
at
them
in
a
state
away
and
then
I
try
to
do
something
in
that
good
care.
And
it's
just
not
cool.
Do.
D
A
A
The
other
thing
is
like
within
fifteen
to
thirty
seconds
of
first
singing
issue
above
the
fold.
Any
community
member
can
understand
the
purpose
of
the
idea,
that's
up-to-date
and
relevant
kind
of
how
it
contributes
to
the
bigger
goals
of
the
community.
The
value
of
it
where
it's
at
this
lifecycle
with
the
next
action
is
to
move
the
idea
forward,
who
owns
it
and
reasonable
expectations.
When
it
will
be
fully
implemented,
they
can
be
trusted
with
the
high
level
of
certainty
and
I.
A
Think
that's
where
I
issues
that
don't
satisfy
this
criteria
should
not
be
trusted,
and
one
of
the
goals
is
community
to
never
have
more
than
1%
of
issues
that
are
untrusted
and
no
single
issue
remains
untrusted
for
more
than
five
days
and
we
shouldn't
rely
on
humans
to
determine
whether
an
issue
can
be
trusted
or
not.
But
humans
are
responsible
for
maintaining
that
trust
and
this
an
issue.
A
It
starts
to
erode
that
kind
of
trust
and
I've
seen
that
this
week
in
particular,
and
a
couple
issues
I
brought
it
up
in
the
product
channel
where
it's
just
like
Cooper,
said
I'm
starting
to
lose
faith
in
get
loud
and
not
not
because
it
products
bad,
but
because
we
don't
do
what
we
say
and
I.
Think
it's
not
just
us.
It's
a
hard.
A
It's
like
a
real
problem
that
any
product
development
team
faces
and
everyone
that
I've
been
a
part
of
struggles
like
with
how
to
set
expectations,
so
I
think
there's
a
lot
of
room
to
do
that
in
a
better
way,
so
that
we
build
trust
instead
of
like
break
trust.
I
don't
know
if
anybody
has
any
thoughts
around
that,
but
it
seems
like
a
big
opportunity
for
us
to
not
just
make
better
relationships
with
our
community
members,
but
also
to
help
everyone
who
use
their
product
do
that
within
theirs
too.
Does
that
make
sense,
I
have.
A
Think
if
we
demonstrate
that
that's
possible
through
the
Kanban
pole
type
system,
then
it
will
propagate
more
organically
throughout
the
rest
of
the
organization.
But
yes,
I
would
ideally
like
to
do
that.
I
think
that's
a
healthier
way
to
work,
but
I
also
think
one
of
the
things
that
Sid
has
pointed
out
very
clearly
is
like
don't
slow
down,
because
once
you
slow
down
it's
hard
to
ever
get
back
up
to
the
speed
you
were
at
before
so
I.
A
Don't
think
we
should
look
at
this,
isn't
like
slowing
down
how
much
we're
delivering
but
doing
it
in
a
more
strategic
way.
Sort
of,
like
you
mentioned
where
we
do
the
highest
value
thing.
First,
ship
that
move
to
the
excess
value
thing
ship
that
and
I
would
love
to
see
us
work
in
that
way.
If
everybody's
open
to
trying
it.
A
There's
some
simple
mechanisms
to
do
that
like
because
we're
already
pointing
issues
like
and
that's
part
of
where
I
can
just
scroll
down
here
a
little
bit
what's
next
and
why
we're
working
on
these
big
epics
for
managing
sprint
release
cadence,
which
is
the
multiple
like
an
issue,
can
belong
to
multiple
milestones.
You
have
mouse
and
types,
but
once
we
do
that,
and
we
can,
we
can
measure
velocity
volatility
from
one
milestone
to
the
next
over
like.
If
you
have
every
of
the
same
type,
you
can
do
like
the
last
in
number
of
milestones.
A
D
Notion
of
trust:
do
you
think
that
our
large
backlog
is
hurting
the
trust
from
the
community,
because
I've
heard
a
lot
of
comments,
sort
of
outside
of
gate
lab
about
how
there's
this
huge
backlog
of
features
that
have
been
proposed
and
yet
we're
just
driving
forward
with
new
features
and
adding
more
breadth,
but
we're
not
actually
going
back
in
and
fixing
problems
that
have
been
around
for
two
years?
Have
you
heard
that
from
anybody
or
is
that
is
that
sort
of
an
isolated
thing?
I've.
D
A
Not
I
know
for
me,
it
took
me
a
little
while
to
figure
out
what
the
strategy
was
and
where
we're
gonna
be
going.
I.
Think
there's
also
the
problem
where
some
of
the
ideas
are
good
but
like
I
would
be
fine
if
I
went
to
the
product,
but
I
can't
prioritize
them
right.
A
good.
A
good
case
in
point
is
custom.
Emojis
right.
Everybody
like
there's,
been
like
a
cult
following
of
people
like
bugging
me
to
work
on
custom,
emojis
and
I.
A
Think
it's
a
great
thing
to
add,
but
it
doesn't
add
any
intrinsic
this
value
and
when
I
look
at
companies
that
will
not
use
our
planning
features,
because
we
don't
have
certain
things
like
better
support
for
scrum,
you
know
and
being
able
to
calculate
velocity
like
we
can't
gain
market
share
and
we
can't
get
in
traction
unless
we
have
those
things
it's
hard
for
me
to
justify
then
like
going
off
and
doing
custom
Boujis,
which
is
like
a
a
nice
quality
of
life
thing,
but
it
doesn't
add
business
value.
Necessarily,
you
know,
I,
don't.
D
A
But
it
makes
the
product
better.
I
mean
we
love,
we
love
custom
of
G's
and
slack
and
I
I
get
why
why
it's
important
yeah?
But
it's
also
the
kind
of
thing
like
and
I,
don't
want
to
close
those
issues
because
I
think
it's
fine.
If
the
community
wants
to
pick
it
up,
but
you
know
it's
hard.
I
do
think
there
are
criteria
where
we
should
go
back
and
close
issues
and
be
kind
of
just
like
straightforward
about
it.
D
Well,
you
know
we're
not
closing
them
if
we
put
them
on
an
epic,
it
was
like
you
know,
waiting
for
community
contribution
or
something
that
shows
that
we've
actually
looked
at
it.
We've
we've
evaluated
it
and
it
currently
doesn't
fit
our
business
plan.
How
do
we
annotate
that
or
denote
that
in
a
way
that
says
this
is
a
great
feature?
We
agree
that
we'd
love
to
see
it
implemented,
but
it's
just
not
the
cards
in
the
next
year.
A
We
could
create
that
epic
and
and
dump
stuff
in
there
just
being
like
would
love.
These
were
like
with
love
community
contributions
for
these,
like
I,
think
we
have
the
label
that
gets
annotated
automatically
by
at
lab
triage
yeah,
but
like
that's
where
it's
hard
is
like
the
labels
get
updated
by
a
bot,
but
nobody
looks
at
it,
and
so
maybe
somebody
thinks
that
we've
looked
at
it,
but
we
haven't
and
yeah.
D
D
It's
like
requirements,
management
and
things
like
that,
where
I
don't
really
want
the
community
contributing
just
yet
to
those
they're,
not
mature
enough
and
I,
don't
know
if
we'd
have
enough
guidance
for
the
community
to
be
effective
in
that
contribution,
but
you
can't
seem
to
get
rid
of
that
label.
So
it's
a
label
that
I
know
is
applied
to
things
that
don't
necessarily
it
shouldn't
necessarily
apply
to
you.
D
B
Yeah
I
wonder
if
we
should
fix
that
problem
them,
because,
ideally
I
think
it's
something
like
everything
that
goes
into
the
backlog
will
automatically
get
that
accepting
your
request
label.
There
might
be
another
rule
to
it,
but
we
should
figure
out
what
that
rule
is
because
we
want
to
take
and
I
know,
at
least
on
the
front
end
side.
There
are
contributors
that
are
looking
for
for
that
label
in
determining
what
to
pick
up,
but
there's
so
many
that
we
get
lab
internal
side.
Don't
really
have
any
any
control
over
prioritizing
some
of
those
things.
B
B
Also,
on
the
front
end,
we've
been
just
adding
like
a
like
a
weight
of
one
two
things
that
are
in
the
backlog
that
we're
hoping
to
get
community
contribution
from,
but
that
are
not
that
are
just
fairly
simple
to
work
on
and
we've
been
finding
like
during
the
hackathons
that
those
are
the
ones
that
are
actually
picked
up
first,
so
that's
kind
of
a
way
that
we're
getting
or
were
encouraging
community
contributions
on
things
that
we
really
want.
We
want
done.
B
I
also
wanted
to
touch
just
real
quick
on
the
whole,
so
the
perception
from
external
folks
on
get
lab
working
on
too
much,
as
opposed
to
focusing
on
the
on
our
current
product
on
stability.
Essentially,
do
we
think
the
problem
is
because
our
backlog
is
so
large
or
because
of
the
whole
breadth-first
depth
conversation?
D
Using
the
product,
the
backlog
being
very
large,
is
more
of
an
indication.
It's
more
of
us,
a
symptom,
not
the
actual
problem,
I
think
what
I'm
hearing
from
most
people
that
I've
talked
to
is
you
have
all
these?
You
know,
CITV
features
and
all
these
security
features
and
all
these
things
that
don't
necessarily
apply
to
every
business.
And
yet
you
don't
have
things
like
blocking
issues
or
very
basic
feature.
D
So
what
they're
saying
is
yeah
you've
got
a
great
product,
but
instead
of
fixing
just
really
basic
features
that
would
make
you
more
competitive,
you're,
adding
on
you,
know
more
security
scanning,
and
it's
not
that
they
don't
care
about
security.
It's
that
they're,
never
gonna
get
to
security
scanning.
If
they
can't
do
basic
issue,
management
and
I.
Think
that's
sort
of
their
point
is
all
those
things
are
nice,
there's
existing
tools
that
do
them.
I,
don't
know
if
I
want
to
use
those,
but
I
can.
D
What
I
can't
do
is
I
can't
work
around
fundamental
problems
in
your
product
and
if
I
could
have
fundamental
functionality
of
your
product,
I
would
be
using
external
tools
and
your
product
and,
as
you
added
those
extra
clothes
to
make
them
internal
I'd
be
happy
to
roll
over
to
them.
But
I
cannot
work
around
a
fundamentally
flawed
in
their
mind
product
just
because
it
offers
me
all
this
extra
scanning
that
I
don't
necessarily
care
about,
for
example,
so
I
think
that's
that's
really.
D
The
the
the
thing
I'm
hearing
and
the
thing
I'm
seeing
is
a
large
backlog,
kind
of
reinforces
that,
and
it
shows
that
hey,
there's,
20,000
open
issues
out
there.
Do
these
guys
ever
go
back
and
fix
these
problems.
That's
that's
the
perception
because
they
already
have
a
preconceived
idea,
a
huge
backlog,
just
sort
of
piles
on
and
says,
hey,
that's!
That
is
a
that's
a
symptom
of
this
they're,
not
fixing
their
core
problems,
understood,
marching
forward
and
adding
new
features.
Instead
of
actually
making
the
features,
they
have
really
really
solid.
Yeah.
A
Like
a
good
example
like
right,
these
are
the
top
user
issues.
I
need
to
update
this,
probably
it
with
current
counts
from
the
last
time.
I
did
this,
but
folks
were
frustrate
on
this
Trello
powerup
that
we're
we're
not
investing
more
in
in
our
integration
with
Trello
and
the
car
up,
so
that
we
can
attach
issues
right
well
like
for
me,
I
think.
That's
great
I
mean
it's
cool
if
somebody
wants
to
do
that,
but
that
doesn't
help
make
our
planning
functionality
better
right
and
I.
A
But
there's
like
lots
of
things
like
this
across
the
entire
product,
where
the
the
water
community
is
clearly
said
like
hey.
These
are
things
like
that
are
kind
of
smallish
that
are
really
important
to
us
that
we
want
you
to
do
and
we're
not
doing
some
of
them,
because
you
know
they're
higher
priority
issues
that
we've
determined
it
will
help
our
customers
and
help
our
business
better
in
a
more
expedient
way.
If
that
makes
sense,
so
I
think
that's
where
there's
a
lot
of
like
frustration.
A
F
There's
the
kind
of
like
to
Mark's
point,
there's
fundamental
ones
as
well
as
like
I,
understand
the
integration,
the
outside
systems,
kind
of
I
totally
get
that
but,
like
you
know,
being
able
to
create
an
issue
from
an
epoch
like
that
comes
up
in
every
conversation.
I
have
with
somebody
who's
thinking
of
using
plan
or
is
currently
using
plan,
and
you
know
they
asked
it
like
hey
it's
been,
it's
been
the
backlog
you
guys
are
working
on
it,
that's
great,
oh,
okay,
cool,
but
what
about
blocking
issues?
Well,
let
that's
coming
to.
F
D
Yeah
well,
the
other
thing
to
remember
is
where
the
merger
is
coming
from.
We
can't
wait
conversations
against
your,
because
our
planning
is
letting
us
down,
and
our
issue
tracking
is
very
good.
What
our
planning
is
letting
us
down
in
JIRA
they're,
not
integrating
a
single
source
solution
for
all
the
security
scanning
see
I
should
be
all
of
that.
That's
the
thing
they're
used
to
not
having
built
in
but
they're
used
to
having
bundle
to
the
product
is
planning
and
issues.
That
is
what
all
the
products
the
market
currently
they're,
trying
to
replace
a
product.
D
They
need
to
replace
not
just
the
issue
tracking
but
the
planning
as
well,
and
we're
not
offering
currently
a
deep
enough
solution
for
them
to
feel
they
can
actually
make
that
jump,
especially
when
you
get
a
large
corporate
users,
I
think
and
that's
what
we're
trying
to
fix.
Obviously,
but
I
think
that
sort
of
underscores
what
Gina
was
saying
is
all
that
other
stuff
is
great,
but
they
need
to
replace
a
planning
and
issue
tracking
tool
and
that's
what
they're.
Looking
for
and.
F
You
know
it's
not
often
like
are
it's
usually
not
the
the
dev
users
that
get
hung
up
on
this?
It's
the
management,
especially
on
the
product
side
and
the
director
side,
on
the
business
side
and
they're
the
ones
with
the
purse
strings.
So
like
a
lot
of
conversations,
I
have
with
engineering
based
users
they're
like
no.
We
love
you
were
great,
but
we
can't
convince
management
to
move
over
because
XYZ
and
they
won't.
They
won't
move
over
to
a
full
system.
F
A
Yeah
I
think
this
is
an
ongoing
conversation
that
we
should
talk
about
given
time
I
want
to
move
on
with
some
of
the
other
things.
The
the
things
that
I
would
love,
though,
is
for
everybody
to
take
a
look
at
the
issue,
tracking
strategy
and
more
in
more
detail
and
either
like
provide
feedback
in
a
slack
channel
or
whatever
channel
you
feel
is
best
if
you
have
suggestions
or
things
that
you
feel
strongly
about
or
things
that
aren't
there
or
that
should
be
there
or
that
shouldn't
be
there.
A
That
are
let's
talk
about
that
and
I
think
maybe
next
week,
if
you
know
mark
you
guys
want
to
pick
one
of
your
categories.
You
go
through
that'd,
be
awesome
and
I
think
this
is
something
that
we
should
do
on
an
ongoing
regular
basis,
because
the
only
way
like
you
get
everybody
on
this
call
has
a
different
perspective
than
the
proc
managers
and
it's
a
valuable
perspective,
and
it
has
like
data
points
that
we
are
exposed
to,
and
so
we
really
need
everybody
to
collaborate
and
contribute
to
this.
The
vision.
A
D
F
Was
great
yeah
I
really
enjoyed
it
I
think
what
we
should
do
just
to
avoid.
You
know
we
canceled.
The
last
two
days
was
in
handing
on
the.
We
should
just
lay
these
out
like
starting
the
beginning
of
the
year.
Just
say
like
this
week,
where
we
talk
about
this
one
next
week,
this
one
next
week,
this
one
just
we
can
lay
out
a
timeline
of
it
and
then
we
we
know
what's
coming
and
we
can
prepare
for
the
conversations
too
cool.
A
I'll,
add
a
I'll,
add
a
rotation
into
the
weekly
meeting
format
and,
like
maybe
in
a
big
picture,
update
it'll
just
be
the
categories
in
some
given
order
and
then
we'll
just
cycle
through
that,
and,
as
we
add
new
categories
or
change
things,
we
can
just
update
that
flow.
I
think
that
just
cool
sounds
good
good
idea.
C
G
Yeah
hi
everyone
nice
to
meet
you
all,
as
mentioned
I'm
Nick
brand
new
product
designer
and
plan
I
guess
prior
to
this
I
worked
at
Mozilla
for
a
couple
years
where
I
was
focused
on
a
password
management,
they
called
lock
wise,
so
I
designed
the
iOS
Android
experience
for
that,
as
well
as
assisted
with
the
desktop
work
as
well.
Prior
to
that,
I
worked
at
a
lot
of
consultancies,
most
recently
pivotal
labs,
subatomic
I,
like
a
various
workload
of
different
clients,
different
industries
for
racing
and
products.
G
In
terms
like
what
I
like
to
do,
my
free
time
hang
out
a
lot.
My
dog
and
my
wife,
a
lot
of
times
go
on
hikes
walks
around
the
area
a
lot
of
times.
We
just
check
out
different
breweries
in
the
area,
just
because
Colorado
is
quite
a
few
of
those
and
I
also
like
to
go.
Do
things
like
bowling?
We
bought
a
house
a
couple
years
ago.
It's
a
big
fixer-upper,
so
that's
been
in
a
lot
of
my
free
time,
kind
of
working
on
that
as
well.
E
G
A
F
That's
Colorado
in
general,
which
is
you
know
it
sounds.
It
sounds
like
more
close-knit
than
it
actually
ends
up
being.
Look.
We've
got
some
folks
up
and
like
Steamboat
Springs,
which
is
quite
a
drive,
it's
in
clear
weather,
it's
quite
a
drive
but
yeah
I
Boulder
in
Denver
I.
Think
we've
got
20
at
this
point
so
which
is
pretty
good
cool.
A
All
right,
I'm
gonna
hop
over
3ei.
We
have
what
15
minutes
or
10
15
minutes
and
then
something
like
that
anything
I
can
do
to
help
get
not
filtering
down
until
6:00.
It's
been,
we've
missed
three
milestones
and
I
would
like
to
see
it
be
done.
It's
one
of
those
it's
like
dragged
on
and
on
and
on
and
I
get
why
it's
complicated.
But
if
I
can
just
ask,
if
there's
anything,
I
can
do
personally
like
sink
time
into
doubt,
get
it
over
the
line.
B
B
A
B
B
F
B
B
He
just
had
one
question:
I'll
touch
base
with
Winnie
to
make
sure
he
can
respond
to
that
today,
but
it's
like
a
pretty
good
to
get
that
merged
in
today,
I'm
a
little
worried
because
it
is
behind
a
feature
flag,
which
means
this
one
will
go
into
Caleb
comm
on
Monday
and
then
we'll
turn
on
the
feature
flag
for
a
group.
Maybe
or
maybe
we
can
go
ahead
and
just
turn
it
on
for
everyone,
but
it
won't
be
defaulted
on
I,
don't
know.
B
F
D
B
A
A
Think
I
like
this
flow
here,
and
the
next
step
is
to
put
this
as
a
proposal
into
the
handbook
as
a
whole,
although,
as
we've
been
shopping,
this
around
just
like
different
groups,
I
dropped
this
in
the
weekly
product
meeting
yesterday
and
got
some
some
other
folks
to
kind
of
start
participating
in
it.
There's
pushback
that
more
or
less
like
solution,
validation
should
be
owned
by
UX,
with
participation
by
the
entire
product
team
and,
like
I,
think
that
that
is
largely
true,
but
also
like
not,
and
that.
A
The
reason
why
we
put
engineering
managers
is
the
person
who,
like
news
from
solution,
validation
playing
breakdown
is
like
that
is
the
last
gate
to
make
sure
that
the
solution
that
UX,
improv
and
collaborating
on
together
is
like
feasible
and
possible
and
I
didn't
know.
I
just
want
to
have
a
quick
chat
about
this
issue.
As
a
whole,
before
we
take
the
next
step
and
put
it
into
a
proposal
for
the
handbook,
yeah.
F
I
think
specifically
on
that
solution,
validation,
one
that
might
ohm
that's
gonna,
be
one
I,
think
it'll
be
beneficial
to
get
I'm
gonna
like
Scott
Williamson's,
take
on
it
because
I
know
he
wrote
a
lot
of
this
when
he
came
in
and
I'm
curious
what
his
intentions
were
because
I
know
what
this
meant
in
a
previous
life
with
him.
But
I,
don't
know
if
he's
changed
his
mind
about
it.
F
Is
that
to
really
just
say:
hey,
we
know
what
this
is
and
let's
cut
it
up
into
the
right
pieces
so
that
we
can
organize
move
it
forward
through
a
good
sequence
or
is
planning
breakdown,
really
engineering
planning
and
then
planning
breakdown
like
a
solution.
Validation
feels
like
the
right
spot
to
actually
have
that
really
hard
collaborative
conversation
as
a
group,
and
then
you
know
I,
don't
know
I
feel,
like
engineering
isn't
empower
to
be
like
you
are
asking
for
something
crazy
in
that
stage.
As
a
point
to
say,
you
know
this
is
the
gate.
F
Once
we
get
past
there,
we
should
all
be
on
the
same
page
on
what
it
is
and
how
big
it
is.
So
that
engineering
is
then
free
to
make
the
decisions
and
choices
they
need
to
without
any
additional
conversations
with
product
or
UX
to
really
get
there.
I
think
that's
how
I
that's
how
I've
always
done
it.
That's
how
I
see
it
I've
seen
it
work,
we're
just
pushing
that
conversation
further
right
and
I
think
we
need
to
keep
it
as
far
left
as
we
can
that's
why
tight
I.
A
You
know,
especially
like
the
designs
and
what
we're
dreaming
up,
but
at
the
end,
the
day
like
if
you
end
up
going
down
that
road
and
like
investing
a
ton
of
time
in
designing
this
solution
that
is
deemed
incredibly
complex
and
expensive
to
implement,
then
it's
just
a
waste
of
time
and
energy
and
money
and
I
think
the
goal
of
having
like
the
cross-functional,
like
our
conversations
in
the
validation
stages,
so
that
you
can
determine
that.
You
know
your
ideal
solution
fits
within
an
acceptable
budget.
Basically
so
I.
D
Took
a
first
crack
at
this
when
I
put
those
labels
in
the
responsible
party
and
the
reason
I
put
it
is
engineering
and
transition
of
e/m
is
I,
want
money
to
come
out
of
solution,
validation,
I,
want
the
engineer,
managers
to
say,
I
understand
the
problem,
we
can
solve
it,
the
design
is
valid
and
we
will
work
it.
We
are.
We
have
everything
we
need
to
work
it.
That
was
the
whole
intent,
because
I
feel
too
often
what's
happening
is
between
product
and
UX
were
designing
things.
D
I
mean
sort
of
tossed
over
the
wall,
the
engineering,
then
they
have
to
send
it
back
and
go
hey.
There's
still
questions
or
you
didn't
answer
these
details
or
we
need
more
information,
and
that
was
the
whole
point
is
I
want
to
have
that
discussion
in
solution
validation,
because
then,
when
a
his
planning
breakdown
they
can
have
at
if
they
want
to
break
it
down
front
and
back-end
fine,
if
they
want
to
break
it
down
into
three
front
any
issues.
D
Fine,
you
know
I,
don't
really
care
how
its
broken
now
but
I
agree
at
the
solution.
Validation
when
we
exit
that
phase.
That
is
this.
The
final
step
was
saying:
hey
everything
is
here,
it
can
be
implemented
and
that,
that's
not
to
say
more
questions
can't
be
asked,
but
there
needs
to
be
that
first
pass,
and
this
is
good
enough
and
I
think
that's
how
I
view
it
at
least
I
don't
know,
maybe
I'm
the
wind
on
this
one,
but.
B
B
If,
if
we
have
the
workflow
design
and
workflow
solution,
validation,
both
owned
by
one
member
by
UX
I,
feel
like
we're
not
gonna
get
a
whole
lot
of.
There's
not
gonna,
be
a
whole
lot
of
workflow
a
solution,
validation
we're
just
going
to
eventually
skip
that
that
phase
and
just
move
over
to
the
engineering
phase
or
the
planning
the
build
phase.
B
F
Think
he'd
bring
up.
You
bring
a
brilliant
point,
I
feel
like
the
solution.
Validation
part
of
the
development
flow
reevaluate
'add
after
we
added
that
design
stage
in
so
I.
Wonder
if
that's
why
this
a
lot
outside
of
this
proposal
like
I,
wonder
if
that's
why
some
of
the
feedback
we're
getting
is
what
it
is,
because
the
design
stage
came
in
to
help
solve
the
UX
side
of
the
equation,
but
I
don't
know.
If
we
went,
we
didn't
go
back
and
restate
what
solution.
Validation
would
be
if
design
now
has
its
own
workflow.
C
I
think
there's
some
ambiguity
around
what
that
design
column
is
and
I
think
how
I
took
the
solution.
Validation.
Is
that
that's
when
we
may
get
more
heavily
involved
with
the
research
team,
or
we
might
be
doing
that
research
ourself,
but
I
would
almost
expect
that
we
are
validating
that
things
are
viable
or
feasible
to
do
before.
H
Thoughts,
Hollyer
Nick
here
I
feel
the
same
way.
Actually
I
would
like
to
have
an
engineer
involved
as
early
as
possible
so
that
we
can
start
getting
that
technical
feedback
beforehand.
Ideally,
would
never
like
to
see
us
just
tossing
and
design
over
to
engineering
without
them
having
been
involved
in
some
of
the
design
decisions
from
the
start
and
offering
feedback
early
on
so
I
agree
as
well.
Yeah.
F
Yeah
and
I
think
we
should
just
stress
that,
just
because
we
have
decision
gates
doesn't
preclude
collaboration
before
that,
I
think
what
we're
really
just
trying
to
do
is
put
some
stake
in
the
ground.
That
says,
like
the
decision
was
made
at
this
point
by
this
party
to
move
forward,
and
that
doesn't
mean
that
we
can't
include
other
folks
throughout
the
process.
A
basic.
D
Rule
I've
always
had
for
these
types
of
things
is
the
people
that
let
it
out
like
whoever
owns
it
in
the
next
phase
needs
to
have
a
strong
say
in
releasing
it
from
the
previous
phase.
I
don't
want
to
have
responsibility
to
release
things
out
of
solution
planning
breakdown
for
engineering.
Unless
engineering
is
happy
with
the
solution,
because
I
don't
want
to
force
things
down
on
them,
I
want
them
to
say.
D
Yes,
we're
good
I,
really
think
they
need
to
have
a
stake
in
releasing
that
back
into
their
sort
of
workflow
development
workflow,
because
otherwise
we're
just
gonna
throw
things
over
the
wall.
You
know
if
we
are
collaborating
on
them.
If
we
say
yes
good
enough
and
we
push
it
down,
that's
not
getting
there
by
and
that's
that's
forcing
it
on.
Somebody
and
I
really
think
that
it
needs
to
be
almost
looked
at
the
other
way,
which
is
what
are
we
accepting?
If
we
can't
convince
them
to
accept
it,
then
we
need
to
do
more
work.
A
Yeah,
so
outcomes
I
also
think
having
engineering
in
early
earlier
will
help
them
propose
solutions
that
could
be
lost
expensive
just
because
they
understand
the
back
end
better.
So
like
would
you
want
to
say
that?
How
would
how
would
we
update
the
table
at
this
point
like
we're
UX,
more
or
less
like
swap
engineering
and
UX,
so
engineering
pull
stuff
out
of
design
and
then
UX
inés
off
on
stuff
before
it
gets
pulled
into
planning
breakdown
or
something.
H
That
would
be
helpful
for
me
is
to
have
an
understanding
of
kind
of
what
the
breakdown
expectations
are
for
each
of
these
stages,
because
to
Alexis's
point
before
when
I
hear
solution,
validation,
I
tend
to
think
more
of
research
and
verifying
that
the
solution
that
we're
looking
into
is
actually
a
valuable
solution
for
the
customer.
So
we
have
the
completion
criteria,
which
is
helpful.
But
what
are
what
are
some
of
the
expected
processes
within
each
of
these
stages?
That
for
me,
that
would
offer
a
little
bit
of
clarity.
A
Maybe,
since
the
notes
column
isn't
being
used,
we
can
rework
that
to
add
like
basic
processes
and
break
down
by
a
function.
It's
like.
If
you
look
at
the
the
plan
team
page
I
tried
to
kind
of
capture
that,
and
my
weird
Venn
diagrams
are
the
different
functional
roles
at
the
top
of
each
stage.
It's
like
not
very
clear
but
I,
think
being
more
explicit
in
this
table
would
also
help
it
translate
better
under
the
handbook.
A
H
A
A
Also
don't
want
to
lose
velocity,
one
of
the
things
that
I've
I've
had
a
lot
of
one-on-one
conversations
with
other
product
managers
and
other
groups,
and
they
the
feedback,
has
been
pretty
consistent,
where
some
some
groups
don't
use
issue
weights
to
do
calculate
velocity
or
do
whatever.
But
the
one
thing
that's
pretty
Universal
is
that
nobody
knows
how
capacity
playing
is
done
and
I.
A
If
we
just
if
like
we
can,
each
of
engineering
managers
can
work
with
their
teams
like
update
the
handbook
with
like
here's,
how
we
actually
calculate
capacity
and
here's
what
our
capacity
has
been
historically
over
the
last
several
leases
as
a
starting
point,
not
just
for
an
it,
would
help
me,
but
also
help
communicate
to
the
rest
of
like
other
groups,
how
we
do
it
so
that
at
least
there's
visibility
into
that
I.
Don't
I
want
to
get
kind
of
thought
from
everybody
on
that.
B
B
B
We
each
in
each
of
our
groups,
we
have
a
little
blurb
on
how
it's
just
a
short
one,
and
it
needs
to
definitely
be
more
detailed
but
on
how
we
do
capacity
planning
currently.
But
we
don't
really
include
like
these
are
the
if
we
choose
to
use
weights
I'm
just
an
example.
These
are
the
weights
that
we've
hit
in
the
past
couple
of
releases.
This
is
what
we're
using
as
an
average,
to
determine
what
our
capacity
is
for
the
next
release.
B
We
don't
have
any
of
that
kind
of
data
in
there,
so
I
think
it
would
be
helpful
to
to
add
that
and
I
don't
really
see
many
drawbacks
to
being
a
little
bit
more,
not
transparent,
but
just
visible
about
those
that
about
that
or
with
that
type
of
data.
So
now
I'm
all
I'm
all
for
including,
including
that
but
I'll,
add
my
comments
there
into
the
issue
beyond
what
I
put
in
there
and
then
we'll,
hopefully
get
feedback
from
Shaun
and
John.
Also
yeah.
F
A
One
other
thing
down:
would
you
like
I'm,
still
I,
know
a
little
bit
of
SQL,
but
not
enough
to
do
things
super
quickly
and
one
of
the
things
that
I
would
like
to
do
as
part
of
this
is
use
our
team
as
guinea
pigs
for
prototyping.
What
we're
gonna
build
in
the
product
in
terms
of
velocity
and
like
other
sorts
of
metrics
and
I,
think
we
could
probably
do
that
via
periscope
and
writing
a
couple
of
dashboards.
A
So
I
don't
know
if
you
would
be
willing
to
pair
with
me
on
that
for
a
couple
hours
over
the
next
several
weeks.
But
that
could
be
something
I
feel
like.
That
would
be
pretty
valuable.
So
at
least
we
can
understand
like
if
these
graphs
are
meaningful
to
us
and
if
it's
the
right
sort
of
data,
snake,
better
decisions
and
then
like
use
that
as
a
baseline
of
saying
like,
are
we
actually
improving?
Because
we
have
our
looking
at
this
data
or
not?
A
A
A
All
right,
if
we
have
nothing
else,
we
are
time.
This
is
probably
the
first
time
we've
ever
used
up
every
minute
of
this
call,
which
has
been
great.
Thank
you
for
coming
for,
participating
and
please
anyone
can
add
stuff
to
the
agenda
and
I
encourage
everybody
to
for
next
week
have
a
good
day.
I
team.