►
From YouTube: Plan Stage Weekly - 2021-04-28
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
Cool
welcome
all
planned
weekly
april
28th.
A
I
have
the
first
point
just
quick
note:
team
update
julian's
moving
over
from
product
planning
to
project
management
because
he
is
participating
in
an
internship
for
learning
on
the
back
end,
he's
always
had
an
interest
kind
of
in
both
the
front
end
and
the
back
end.
A
So
we
determined
that
now
it'd
be
a
good
time
with
heinrich
kind
of
temporarily
going
over
to
the
database
sharding
team
to
help
out
with
the
back
end
stuff
on
on
project
management,
so
he's
already
kind
of
started
taking
over
or
taking
on
some
back-end
project
management,
stuff,
he's
finishing
up
his
product
planning,
front-end,
stuff
and,
of
course,
he's
still
around
for
any
of
the
end
stuff.
If
you
have
any
questions
or
anything
but
as
of
now,
he
is
on
project
management,
questions
comments.
B
Hello,
I
haven't
had
enough
coffee
today,
so
let's
see
how
this
goes:
y'all
yeah
immediately
I
zoom
in
I
I
just
wanted
to
go
over
some
some
research.
I
did
recently
around
jobs
to
be
done.
I
don't
know
if
y'all
know
what
jobs
are
you
probably
do
we
have
it
defined
in
the
handbook.
B
You
can
also
open
this
mural
and
kind
of
learn
more
about
it,
but
you
know
kind
of
moving
away
from
user
stories
and
thinking
more
about
what
are
our
users
trying
to
get
done
like
what
is
their
day
like
what
is
kind
of
like
their
ideal
selves
or
like
ideal
role,
and
how
can
we
help
them?
B
Get
there
right
so
and
there's
two
ways
to
think
about
it
like
more
activity
or
function
based
versus
kind
of
like
process
or
progress,
based
which
I
preferred
because
it's
more
like
you
know
what
what's
your
ideal
and
how
can
we
help
you
get
there
and
finding
those
gaps
is
where
products
kind
of
become
lovable
because
they
help
people
get
their
jobs
done
better.
B
So
I
shared
this
mural.
I
won't
go
over
it
too
in
depth
because
you
have
access
to
it
and
you
can
look
over
it
as
much
as
you
like.
I
also
am
creating
an
epic
here
to
kind
of
break
down
some
of
the
insights
when
I
have
time.
So
it's
it's
pretty
in
draft
right
now,
but
you
can
leave
comments
if
you
want
so
the
basic
steps
here
is
just
talking
with
a
lot
of
participants.
B
I
didn't
talk
necessarily
just
with
git
lab
users,
because
I
think
it's
interesting
to
see
you
know
it's.
It
shouldn't
be
tool
or
product
specific.
It's
just
like
talking
with
a
hiring
persona.
We
call
it
which
would
be
parker
or
probably
someone
like
gabe
or
kristin,
so
just
kind
of
understanding
who
those
people
are
and
what
they
want.
And
the
purpose
of
this
kr
that
I
was
working
on
was
to
validate
some
of
the
jobs
we
had
already
come
up
with,
and
plan
and
kind
of
map
those
to
our
different
categories.
B
So
the
category
I
was
looking
at
was
boards,
so
you
know
first
kind
of
just
mapped
out
the
general
kind
of
flow
of
what
parker
might
be
doing
more
on
like
a
any
given
iteration
here
and
then
drill
down
on
who
parker
is,
and
our
personas
are
not
really
supposed
to
be
like
gender
specific,
so
I'm
gonna
say
they
or
but
parker
kind
of
our
pm
persona
and
something
interesting
I
I
noticed
about
them
it
kept
popping
up
in
interviews
is
that
they
spend
a
lot
of
time
trying
to
understand
progress.
B
Trying
to
understand
where
things
are.
The
first
thing
they
do
in
the
morning
is
kind
of
like
get
in
and
they're
like
all
right.
Where
is
anything
like
what
were
the
things?
I
said
I
needed
to
do
today
like
what
did
the
team
make
progress?
Were
I
thought
you
know
they
might
and
then
there's
a
lot
of
like
stand-ups
in-person
stand-ups.
If
y'all
ever
did
them,
I'm
sure
you
probably
remember
and
a
lot
of
like
status
meetings
or
having
to
kind
of
like
schedule
meetings.
B
I
heard
a
lot
of
pain
points
around
having
to
schedule
meetings
and
catch
up
with
people
and
figure
out
what
was
going
on
and
that's
kind
of
the
same
thing
they
do
at
the
end
of
the
day.
At
the
end
of
the
day,
they
like
create
a
plan
for
the
next
day
and
they
create
a
bunch
of
tds
for
themselves
and
they
schedule
a
bunch
of
meetings
for
tomorrow
to
catch
up
with
people.
B
So,
like
you,
know,
they're
having
a
hunt
for
available
times,
they're
reviewing
their
own
views,
they're
checking
their
email
all
the
time,
and
this
is
kind
of
general.
It's
not
like
every
single
person,
but
just
a
general
parker,
and
they
really
love
again.
Can
I
think
about
gabe
and
kristen
right?
They
love
being
creative.
They
love
solving
business
problems,
really
like
ownership
of
a
product,
and
you
know
tied
to
that
like
when
they
have
leadership
or
a
lot
of
people.
B
B
B
That
ideation
aspect
kept
coming
up,
of
course,
like
generating
value
right
for
the
company
and
being
valuable
themselves
making
product
ideas
a
reality
with
their
team,
not
just
them,
and
what
also
came
up
a
lot
was
learning
from
like
the
diverse
skills
and
knowledge
of
their
team,
like
they
don't
need
to
know
every
single
thing,
but
they
really
love
learning
from
all
the
different
experts
on
their
team
again
supporting
thinking
of
ways
to
opportunities
to
improve
like
both
themselves,
their
product
make
their
team's
lives
easier
and
then
kind
of
the
inverse
right,
like
they
hate
keeping
things
up
to
date.
B
They
feel
like
they
spend
a
lot
of
time
kind
of
wasting
time
like
keeping
documents
and
status
of
work
items
et
cetera
up
to
date.
They
don't
like
micromanaging
people.
They
don't
want
to
feel
like
they
have
to
like
bother
their
team.
All
the
time
they'd
be
like
hey
where's,
this
where's
this
like
is
this
blocked
or
like
what's
going
on
here,
so
yeah
that
poor
or
stuck
communication
is
hard
and
many
people
mentioned,
especially
during
you
know
the
pandemic
right
now.
B
This
has
been
hard
for
them,
because
it's
it's
gotten
worse
and
maybe
they're
not
you
know
they
haven't
been
distributed
before,
like
I
mentioned
like
these
arbitrary
deadlines,
don't
like
that,
they
make
it.
You
know
it
feels
like
they
can't
produce
their
best
product.
B
They
just
have
someone
telling
them
what
to
do
when
it
kind
of
seems
like
arbitrary
or
the
person
doesn't
have
a
lot
of
visibility
into
what's
going
on
again
manually,
updating
getting
ordered
around
being
surprised
by
the
status
of
work
is
hard
when
you
know
they're
kind
of
at
the
end
of
maybe
a
cycle,
and
it's
like.
Oh,
I
didn't
realize
that
was
a
problem
which
causes
work
to
slip.
I've
got
switching,
you
know,
setting
up
meetings.
All
the
time
is
hard
for
a
lot
of
people.
B
They
spend
a
lot
of
time
literally
scheduling,
meetings
finding
times
when
everyone
can
meet,
and
you
know
the
time
spent
doing
all
these,
like
these
things
keeps
them
away
from
the
stuff
they
love,
which
is
you
know,
innovating
and
creating
and
helping
their
team.
They
feel
successful
again
when
this
one,
I
think,
was
interesting.
Someone
mentioned
like
I,
don't
even
want
my
team
to
need
me
like.
I
want
to
be
able
to
like
go
away
for
like
two
weeks
and
they're
fine.
B
You
know
they
know
what
to
do
they're
empowered
they
they
they
feel
like.
I
trust
them
and
they
know
what
they're
supposed
to
do.
I've
communicated
the
goals.
Well
to
them.
You
know
they're
successful
when
items
are
moving
to
the
workflow.
Of
course,
again
everyone
understands
goals,
and
basically
the
team
is
empowered
to
work
well
so
that
they
can
deliver
on
commitments
react
quickly.
B
They
can
leave
the
office
without
like
having
a
long
to-do
list
that
they
they
feel
like
they
need
to
get
to
tomorrow
or
that
they
haven't
gotten
to
today,
and-
and
one
thing
I
thought
was
nice-
is
that
parkers
don't
feel
like
upset
necessarily
by
failure.
They're,
just
like
hey,
that's
a
challenge
to
get
better
next
time,
so
I
thought
that
was
cool
and
you
know
they
don't
think
of
like
work
slipping
or
something
like
that
is
that
failure
of
the
team?
It's
just
like
hey.
B
From
gabe
and
kristen
that
they
they
just
want
to
help
us
and
make
us
do
better,
not
make
us
enable
us
or
empower
us
yeah
again
communicating
inspiring
solving
business
problems.
They
produce
good
quality
products,
of
course,
so,
like
users
are
happy
the
team's
motivated
and
when
they
accomplish
these
goals,
they
feel
proud.
Of
course
the
team
has
like
a
team
spirit,
they're
motivated
some
parkers.
I
thought
was
interesting.
Like
you
know,
they
do
well.
Of
course,
then
they're
trusted
with
better
projects.
B
So
maybe
this
is
kind
of
like
client
based,
but
it's
like
if
they
demonstrate
that
they
can
get
things
done.
If
they
have
a
good
track
record,
then
they're
they're
trusted
with
better
projects
whatever
that
means
whatever
better
is,
and
you
know
they
when
they're
having
a
good
time
in
the
role
they
just
like,
can't
wait
to
get
to
work
and
see
like
what
did
my
team?
Do,
I'm
so
excited
what
progress
did
they
make?
So
I
thought
about
this
mapped
out
some
of
the
insights
specifically
to
boards.
B
I
thought
about
like
okay.
What
maybe
did
parker
last
hire
a
board
for
what
would
be
harder
in
their
job
without
a
board,
so
that's
kind
of
like
what
do
they
need
a
board
for
if
you
know,
if
thinking
about,
if
they
didn't
have
a
board,
what
would
happen?
B
That's
probably
what
they
need
a
board
for
and
then
a
risk
of
not
having
access
to
it
so
kind
of
things
that
are
probably
pretty
obvious
right,
like
things
don't
get
delivered,
there's
basically
just
like
chaos,
no
single
source,
the
truth,
people
don't
know.
What's
going
on,
the
team
doesn't
feel
empowered
because
they
don't
know
like
what
to
work
on
next.
B
They
don't
understand
priority,
and
then
they,
you
know
you
feel
it
like
demotivates
you
because
you're
probably
not
delivering
effectively
either
and
then
thinking
about
kind
of
general
success
indicators
or
like
desired
outcomes.
Here
again,
y'all
can
go
through
this.
I
don't
want
to
spend
the
whole
time.
I
don't
want
to
like
spend
this
whole
meeting
on
this,
but
and
then
thinking
about
kind
of
what
about
our
product
might
pull
parker
away
from
the
the
kind
of
board.
B
I
guess
if
we
get
feature
specific,
that
they
have
currently
what
about
their
future
or
just
kind
of
like
life.
You
know
workflow
right
now
might
like
kind
of
push
them
towards
us
or
like
what
are
their
constraints.
Maybe
right
now
like
what
are
the
realities
like
they
literally
don't
have
budget
for
a
tool,
something
like
that
thinking
about
what
would
like
really
push
them
off
that
ledge
to
look
for
a
tool,
even
if
they
do
feel
those
constraints.
B
So
literally,
maybe
their
team
is
just
like
they
keep
missing
deadlines
or
their
tools
are
so
slow.
So
it's
like
okay,
I
can't
take
this
tool
anymore.
I
need
to
get
a
new
one
and
then
some
of
the
options
that
they
they
currently
use,
which
is
you
know,
a
lot
of
synchronous
meetings.
I'd
say:
that's
our
main
competitor
for
a
board's
tool
is
a
bunch
of
synchronous
meetings.
Also,
some
are
using
git
lab
trello
was
a
big
one
and
then
another
big
competitor
would
just
be
like.
B
You
know:
google
sheets
right
excel
documents
that
they
keep
updating
and
they
have
to
manually,
update
and
then
going
through
them
and
synchronous
meetings.
Stuff
like
that,
so
based
on,
like
all
this
information,
I'm
you
know
tldr'ing
it,
but
I
think
the
main
thing
the
boards
are
helping
parker
do
is
really
like
radiating,
that
the
current
status
of
work
continuously
and
what
I'm
trying
to
convey
with
that
is
that
it's
the
current
status
right.
So
it's
like
this
is
the
ideal.
B
It's
like
always
up
to
date,
and
that
doesn't
mean,
like
the
team
has
to
keep
it
up
to
date
or
like
any
anything
that
like
they
need
to
do
it's
like
kind
of
like
what
can
we
do
for
them
right,
current
status
right
continuously,
so
it's
like
always
there
that
way,
we'll
get
to
it
in
a
second.
So
I
think
that
would
be
the
main
job
and
I
think
like
to
get
that
job
done.
B
You
also
really
need
to
visualize
a
workflow,
of
course
right
if
you're
using
boards
tool
so
kind
of
mapping
that
out,
based
on
like
what
I
said
earlier
like
what
is
their
ideal.
Where
are
they
at
now
right?
B
I
think,
based
on
like
what
the
people
I
talk
to,
what
parker
really
wants
from
plan
is
to
be
empowered
to
be
a
innovator
of
solutions
right
that
improve
lives
and
grow
organizations
like
that's
kind
of
what
I
get
from
parker
like
that's
what
they
want
like
that's,
why
they
got
into
maybe
product
management
or
even
project
management
right.
What
they
might
want
from
boards
is
kind
of
like
a
partner
in
product
ownership
right.
So
how
can
we
kind
of
be
their
maybe
product
owner
or
like
you
know
like?
B
How
can
we
fill
that
role
for
them
and
like
help
them
keep
things
up
to
date?
Keep
things
on
track
things
like
that.
So
I
think
the
primary
job
kind
of
like
we
just
talked
about
is
really
just
aligning
teams
and
organizations
which
mean
like
that
alignment,
which
means
like
the
goals,
expectation,
status,
they're,
all
transparent
and
understood
so
transparent,
is
a
big
thing
here
and
again
kind
of
talking
about
workflows.
You
want
to
empower
the
teams
right;
they
don't
want
the
teams
to
have
to
rely
on
them.
B
They
want
the
teams
to
feel
empowered
to
do
their
job.
However,
they
need
to
do
it,
they
just
and
they
know
what
they
need
to
do.
They
understand
the
goal
that
they're
working
toward
and
again.
This
is
like
the
two
kind
of
functional
jobs
here,
so
the
status
of
things
right
now
in
talking
with
people
is
that
currently
to
get
like
this
alignment
idea
done
currently,
parker
has
to
like
basically
organize
a
meeting
organize
and
conduct
a
meeting
or
wait
for
stand-up
things
like
that.
B
If
perhaps
like
a
stakeholder
asks,
what's
the
status
or
like
how
is
this
one
thing
progressing,
so
the
status
of
work
is
pretty
unclear.
Priorities
unclear
they're
kind
of
wasting
their
time,
micromanaging
people
they
feel
bad
about
that
they
have
to
schedule
meetings
all
the
time
again.
They're
wasting
time
on
like
ensuring
everything
is
up
to
date
and
documentation
even
is
up
to
date.
There's
lack
of
awareness
on
impediments
like
progress
impediments
to
progress,
so
that
leads
to
those
unpleasant
surprises.
B
I
will
try
mapping
our
workflow
right,
which
we
mentioned
earlier,
to
get
lab
board
to
see
if
that
aligns
everyone
on
the
status
of
work,
so
this
could
be
an
optional
like,
or
this
could
be
a
way
to
us
and
then
the
ideal
would
be
that,
instead
of
when
a
stakeholder
asks,
you
know
what
what's
going
on,
they
have
to
like
schedule,
a
bunch
of
meetings
or
talk
with
individual
people
and
help
them
down
and
be
like
what's
going
on,
they
don't
even
need
to
do
anything
like
the
board.
B
Just
does
it
for
them.
It's
radiating
that
work
and
I
say,
radiating
all
the
time.
It's
a
weird
word,
but
it's
radiating
that
current
state
of
work
continuously,
so
it's
like
parker
doesn't
have
to
do
anything.
Teams
are
aligned,
they
know
what's
going
on,
they
know
the
priority.
The
ownership
of
the
task
is
transparent
and,
like
any
impediments
to
progress,
is
easy
to
spot
and
address
this
one.
B
I
don't
I
don't
know
if
we've
solved
yet
right
and
that's
okay,
like
I
think
it's
just
opportunity
that
they're
probably
still
wasting
time,
even
if
they
use
our
board,
currently
keeping
things
up
to
date,
and
that
is
maybe
an
issue
but
also
an
opportunity
which
I
kind
of
mentioned
here,
and
I
mentioned
like
what
is
ideal
here
but
yeah.
I
mentioned
this
as
well
here,
so
it's
like.
B
I
don't
know
if
we've
solved
this
in
our
flow,
if
we're
thinking
of
kind
of
like
the
little
items
parker
has
to
do
to
get
this
job
done
of
you
know,
making
radiating
the
status.
If
you
think
about
all
the
things
they
need
to
do
that
within
a
board.
Currently,
I
we
haven't
solved
every
single
problem
here,
like
we
can
think
we
can
make
things
less
manual.
Maybe
we
can
help
them
keep
things
up
to
date.
Maybe
we
can
make
our
workflow
management
like.
B
I
don't
know
that
we
really
have
a
whole
lot
of
like
a
workflow
management
tool.
Maybe
we
could
think
about
that
a
little
more
if
that's
prioritized
so
there's
some
opportunities
here
but,
like
I,
you
know,
this
is
just
to
get
a
general
idea
of
what
parker
wants
to
do
and
how
we
can
maybe
help
them
here
and
then
along
the
way,
is
there
some
ways
we
can
kind
of
like
differentiate
ourselves
or
maybe
innovate
like?
Is
there
a
way?
B
We
could
help
teams
better,
learn
from
each
other,
because
we
know
they
really
enjoy
that.
You
know
this
is
kind
of.
I
guess
I
don't
know
corny.
I
don't
know
I
I
feel
for
it,
but
I
love
it
like
you
know.
How
do
we
make
teams
feel
more
psychologically
safe
like?
How
do
we
make
them
feel
they're
safe
to
share
ideas,
be
open
about
collaboration
things
like
that?
I
think
a
cool
one
would
be
like.
B
Can
we
just
get
rid
of
stand
up
like
how
could
we
replace
stand-up
or
like
status
meetings?
Things
like
that?
Is
there
a
way
we
could
do
that
and
then
yeah
like
automation.
Of
course,
things
like
that
are
really
important,
so
yeah,
that
is,
they
have
like
jobs
to
be
done.
I'm
working
on
quality
management
too,
like
getting
really
deep
into
this.
If
y'all
are
interested
I'll
share
that
later,
but
cool.
So
this
is
into
the
agenda.
D
Thanks
alexis
that
was
awesome,
definitely
interesting,
seeing
a
peek
into
my
world,
I'm
wondering
so
this
one.
This
looks
like
a
bottom
up
like
issue
tracking
boards
jobs
to
be
done
in
terms
of
managing
the
team's
work
and
status.
D
Would
you
did
you
run
into
any
that
are
like
top
down
like
the
epic
level
planning
product
planning
down
in
terms
of
the
jobs
to
be
done,
and
could
that,
if
we're
going
to
move
epic
boards
and
issue
boards
together,
like
do
you
see,
alignment
between
the
jobs
to
be
done
for
both
of
those
objects.
B
Yeah,
I
think
so
I
was
talking
with
more
of
like
product
managers
right,
so
I
think
to
really
I
wouldn't
want
to
like
truly
validate
like
a
program
kind
of
board
through
this,
but
I
think
we'd
probably
want
to
talk
with
like
again
more
like
program,
specific
people,
but
I
think
it's
it's
kind
of
just
like
a
higher
level
right.
B
So,
instead
of
making
sure
individual
teammates
know
the
status
or
priority
or,
like
you
understand,
like
dependencies
or
impediments
between
like
teammates
right
within
a
project,
it's
just
like
higher
level
you're
having
to
manage
like
teams
now
so
instead
of
like
catherine,
has
an
issue
here
that
I
need
to
help
with,
and
I
don't
know
about
it
because
it
hasn't
been
flagged
up
and
like
helped
me
figure
this
out
right.
It's
like
oh
team
team.
I
don't
know.
B
What's
on
my
desk
team
red
bull,
that's
a
problem
and
they
haven't
told
me
about
it
and
I'm
like
having
to
hang
them
all
the
time
for
status,
updates
and
team.
You
know
cell
phone
depending
on
dependencies
on
them,
and
how
do
we
flag
that
up?
How
do
we
make
the
status
of
their
work
and
current
up
to
date
and
visible
to
everyone?
So
I
don't
know
that
answers
your
question,
but
I
think
it.
I
think
it's
just
like
a
higher.
B
D
Yeah,
I
think
here,
like
we
use
epics,
to
do
that
and
we
have
our
direction
pages.
We
don't
have
a
layer,
that's
doing
the
program
side.
This
is
all
on
us,
so
that
might
be
something
to
think
about
too.
But
I
do
think
that
the
epic
boards
for
sure
are
where
I
can
see
where
things
will
come
together,
because
just
looking
at
a
issue
board,
everything
looks
all
over
the
place
and
I
don't
really
see
precedence
or
how
things
are
going
to
come
together
and
like
the
bigger
product
itself.
B
E
E
Add
that
qualitative
evidence
from
my
customer
combos
kind
of
suggests
that
they
are
relatively
the
same
job
to
be
done.
It's
just
like,
if
you
think
about
a
zoom
button
right,
you're
like
zooming
out
and
then
you're
gonna
zoom
down,
because,
like
especially
in
safe
organizations,
the
product
manager
will
work
at
the
epic
level
and
then
the
the
product
owner
who's,
like
the
scrum
master,
basically
for
each
product
team,
will
work
at
the
basically
the
issue
level
and
take
the
epic
and
then
break
it
down
on
issues
for
the
team,
but
yeah
like.
E
I
think
there
might
be
a
little
bit
of
nuances
in
how
you
would
want
to
see
progress
between
the
two,
but
for
the
most
part
it's
it's.
It's
basically
a
very
similar
thing.
You
just
do
it
less
frequently
at
the
higher
level,
like
you
know,
at
the
epic
level
and
say:
if
you'll
do
it
quarterly
and
then
the
product
owner
will
do
it
bi-weekly,
basically
down
down
below.
So
that's
my
two
cents.
B
Yeah,
I
think
we
can
make
like
some
pretty
safe
assumptions
and
then
just
kind
of
validate
them
out
with
real
people,
but
I
think
that
makes
sense
though
kristen
gabe
donald
did
y'all
have
more
questions.
There.
A
Yeah
mine
was
the
same,
and
I
think
you
all
answered
that
I'm
just
going
off
of
when
I
was
at
larger
organizations,
larger,
more
traditional
organizations-
and
this
was
like
a
decade
ago-
there
was
typically
a
separate
role
for
project
manager
and
product
manager.
A
So
I
was
curious
if
that
in
our
research
of
other
organizations,
if
that's,
if
those
roles
have
been
kind
of
combined,
we
do
it
a
little
bit
differently
at
git
lab
too.
In
that
I
think
the
project
management,
the
traditional
project
management
responsibilities,
are
kind
of
shared
between
product
managers
and
ems
and
kind
of
everyone
on
the
team
but
yeah.
I
was
just
curious
if
our
research
has
found
that
that's
how
organizations
are
doing
it
now
are
kind
of
combining
product
manager
and
project
management
roles.
B
Yeah,
I
think
so,
and
I
think
that
when
I
was
talking
with
like
actually
the
the
people
that
would
pop
up
that
were
in
a
role
of
project
management,
those
were
actually
the
people
that
were
managing
like
quality,
which
was
kind
of
interesting.
So
those
are
you
know
when
I
recruited
for
people
I
didn't
recruit
on
role
I
recruited
on
like
what
are
they
doing?
Are
they
managing
abort
like?
What's
the
last
time
you
touched
a
board?
B
Are
you
assigning
tasks
things
like
that,
so
oftentimes
that
was
like
a
product
or
prod
product
owner
or
product
manager?
My
brain
hurts
but
yeah,
not
often
a
project
manager,
and
I
didn't
get
a
lot
of
like
scrub
masters
or
anything
like
that
either
so
yeah.
Maybe
it
is
combined
and
that's
kind
of
like
a
cool
thing
to
think
about.
We
can
think
about
why
right,
donald
yeah,
don't
do
you
have
any
context
on
that
gabriel
kristen
like
what
what
that
could
mean.
D
I
think
donald
said
it
correct,
like
ems,
take
on
a
lot
of
that
role
too,
and
here
like
we
aren't
really
chasing
people
the
same
way
a
project
manager
would
because
we
don't
really
own
shipping,
the
ems
do
and
the
engineering
team.
So
it's
a
little
different
here,
but
I
have
been
in
that
place
before,
where
you
have
to
do
both.
D
E
Yeah
a
lot
of
the
companies
that
I've
worked
with
now
they
either
just
rename
project
manager
to
product
manager,
but
don't
really
change
anything
about
what
the
role
actually
does
in
larger
companies.
That
do
say
if
you
have
a
product
manager
who
sits
kind
of
above
a
bunch
of
different
teams
that
each
team
is
run
by
a
product
owner
who's,
also
the
scrum
master
and
then
also
especially
where
there
are
lots
of
dependencies
between
teams.
E
Organizations
have
what's
called
the
delivery
or
release
manager,
which
is
effectively
like
a
product
project
manager
who
works
on
like
scheduling
dependencies
across
groups.
So
that's
what
I've
seen.
D
I
also
just
added
a
note
because
seeing
the
madness
of
that
mural
really
stood
out
to
me
all
the
different
tasks
I
know
gabe.
You
did
a
comment
recently
where
you
listed
all
the
things
that
you
do
regularly
cadence
in
your
week,
but
I
would
just
say
that
a
to-do
list
in
some
format
is
always
needed,
adding
and
removing
custom
items
from
a
to-do
list
to
keep
track
of
everything
and
that
all
of
those
different
activities-
and
that's
not
currently
in
git
lab
that,
where
you
can
just
add
custom
to-do's.
So.
B
Yeah
everyone
mentioned
tvs
at
the
end
of
the
that's
how
they
play.
They
plan
themselves
right,
they
play
on
a
team
and
they
plan
themselves
and
they
plan
a
product
and
one
interesting
thing
too
talking
with
internal
people
as
well.
I
did
that
a
little
bit
we
at
get
lab
as
like
parkers
focus
way
more
on
backlog
management
within
the
board
itself
versus
external
users,
which
are
participants
which
I
thought
was
interesting.
It
probably
makes
sense
right
because
we
don't
have
like
a
lot
of
backlog
management.
B
Necessarily
outside
of
the
board
is
my
assumption,
like
we
don't
have
that
true
kind
of
like
feature
within
the
list,
but
I
thought
that
was
an
interesting
thing
and
donald
trump,
like
I
think,
the
next
step,
or
just
in
general,
we
focus
on
like
one
persona
first
or
I
was
at
least
because
it
was
like
kind
of
like
that,
the
hiring
persona.
B
But
if
we
were
to
research
also
like
ems
or
I
guess
they
could
be
like
project
managers
to
your
point
or
you
know,
whatever
their
role
is,
then
it
would
be
kind
of
like
aiming
this
research
again
but
like
at
the
delaneys
as
we
define
them
at
gitlab.
If
that
makes
sense
cool
all
right,
I'm
happy
to
move
on.
Unless
we
have
more
questions,
I
don't
want
to
hug
all
the
time.
C
I
don't
know
where
we
are
in
the
agenda,
so
I'll
just
jump
in
real,
quick
and
say
that
I
also
did
validation
research
for
jobs
to
be
done
and
there
was
a
ton
of
overlap
with
what
alexis
did
after
seeing
all
of
her
information.
So
I
posted
my
board
there,
but
I
think
there's
value
in
and
us
maybe
like
talking
through
some
of
our
findings
together
and
then
separately.
C
I'm
struggling
a
little
bit
this
morning
to
kind
of
finalize
my
jobs
in
relation
to
the
jobs
that
currently
exist
on
the
plan
jobs
to
be
done
page.
I
think
that
there's
value
in
us
revisiting
that
page
as
a
whole
and
determining
what
maybe
is
a
primary
versus
a
secondary
job.
What
might
need
to
be
removed
or
tweaked
a
little
bit
because
of
potential
redundancy.
C
E
I'm
cool
that
I
was
just
gonna
say
I
think
you
and
alexis
have
all
the
research
like
in
your
head
and
you're
intimately
aware
of
it
so
I'll
follow
y'all's
lead
on.
However,
you
want
to
fix
up
the
jobs
beyond
pages.
C
I
started
on
a
proposal
this
morning
so
I'll
share
that
with
every
with
everybody,
in
the
merge
request
for
my
jobs
and
just
tag
everybody
in
it,
we
can
collaborate
from
there.
I'd
love
to
see.
D
E
I
think
we're
on
a
four
a
that's
my
item.
I
just
kristen
told
me
last
night
and
slacked
there's
just
maybe
some
confusion
on
what
we're
trying
to
accomplish
and
what
the
goals
are
and
like
what
the
ideal
end
state
was.
So
I
kind
of
wanted
to
not
talk
and
listen
and
like
help
us
clarify
what
some
of
those
things
are.
So
we
all
kind
of
like
understand
what
we're
trying
to
achieve
with
some
of
the
work
and
refactoring
proposals
that
are
floating
around.
So
I
guess
with
that
kristen.
D
Yeah,
I
think
well
yeah
for
me
personally
also
like
I
watched
the
video
I
tried
to
catch
up
on
all
the
issues
this
week
from
kickoff,
because
I
wasn't
here
for
that
day,
it
does
feel
broad
still
like
in
terms
of
there's
a
lot
to
do
include,
including
the
issue
redesign,
and
what
do
we
really
mean
by
that
and
alexis
asked
a
bunch
of
questions,
some
of
which
I've
answered
on
the
page,
but
we're
going
to
talk
through
more
of
these
today,
so
I
think
the
more
we
can
just
get
down
to
a
laser
focus
in
terms
of
the
expectations,
the
deliverables
and
what
the
design
designers
are
working
towards
and
make
sure
we
also
onboard
their
like
what
they
would
like
to
work
on
as
well.
E
I
think
it's
great
to
ask
questions
and
talk
through
it
if
anybody's
confused
and
then
we
can
update
the
issue
of
course,
but
since
we're
here
like
it
might
be
efficient,
but
I
think
from
my
vantage
point,
the
new
issue
view
came
about
for
a
couple
different
reasons,
one
because
we
want
to
eventually
have
issue
type
hierarchies
and
migrate
epics
to
that,
so
we're
basically
on
the
same
basic
object
model
for
our
planning
objects
and
then
also
to
refactor
to
a
single
tech
stack.
So
we
don't
have
a
bunch
overloading
technologies.
E
I
learned
a
lot
this
morning,
pairing
with
natalia
about
like
why
why
we
still
use
jquery
places
and
like
really
like
how
how
much
technical
debt
we
have,
and
so,
if
we
have
to
refactor
a
lot
of
the
issue,
view
to
get
to
the
single
tech
stack,
then
it
also
makes
sense
to
think
about.
Is
there
are
there
any
ux
improvements?
E
Do
you
want
to
make
to
better
support,
like
that
kind
of
view,
app
being
used
for,
like
basically
an
epic
hierarchy
as
well
as
an
issue
as
well
as
a
test
case
as
well
as
a
requirement?
So
I
think
that's
where,
like
in
in
my
from
my
perspective,
that
the
really
goals
are
refactoring
basically
to
a
single
tech
stack
for
our
surface
area
and
then
refactoring
epics
to
a
single
type
like
to
an
issue
type
hierarchy,
basically
and
then,
whatever
whatever
the
team
else
like
services
that
we
need
to
prioritize
for
refactoring.
E
D
That's
good
that
aligns
with
how
I
was
thinking
about
it.
I
think
that
the
ux
improvement
part
is
the
part
that
maybe
needs
more
definition,
because,
like
at
the
end
of
the
day,
would
we
if
we
had
the
issue
the
exact
same
it
is
now?
Would
that
be
okay?
As
long
as
we
met
these
other
goals,
do
we
need
to
have
a
change
in
the
ux
of
the
like
the
issue?
D
Detail
page,
those
were
the
some
of
the
open
questions
I
still
had,
and
maybe
I
missed
the
answer
as
well,
or
should
we
just
say
only
in
service
of
this
refactor
in
the
same
code
base?
Do
we
make
an
improvement
to
the
ux.
E
I
think
it's
up
for
debate
to
the
team
like
if
we
need
to
improve
ux,
I'm
sort
of
of
the
mind
that,
like
it's,
it's
not
basically
we're
going
to
do
a
lot
of
work.
Refactoring
everything
anyways
and
I
think
I
I
would
love
input
from
the
front-end
engineers
like
what.
If
we
kept
the
view
exactly
the
same
right.
E
What
would
that
mean,
and
would
it
be
more
work
basically
to
refactor
everything
to
what
it
is
now
and
then
make
substantial
changes
to
the
ux
and,
in
the
view
itself,
because,
like
I
don't
think
the
view
is
necessarily
scalable
for
the
vision
of
extensible
issues?
But
I
think
this
is
a
great
conversation
and
to
get
input
from
the
team
on
what
they
think
is
the
best
way
to
move
forward.
A
Yeah,
so
in
because
we
kind
of
took
that
approach
with
boards,
in
that
we
were
trying
to
work
a
refactor
into
getting
it
to
the
same
view
as
legacy
boards,
and
we
found
that
there
wasn't
a
whole
lot
of
benefit
to
that
like
it
still
took
a
decent
amount
of
time.
It
still
took
a
good
amount
of
work.
A
So,
if
we're
going
to
make
changes
for
the
better,
I
think
it
may
be,
it
may
be
the
same
amount
of
effort
to
just
go
ahead
and
make
those
changes
now
and
essentially
act
as
if
we're
starting
from
like
a
greenfield
project
with
issues,
as
opposed
to
saying,
let's
work,
let's
go
away
for
the
next
couple
milestones
and
completely
replace
the
code,
but
then
don't
really
have
much
to
show
for
it
as
far
as
new
features
or
any
improvements
to
the
to
the
issue
page.
A
I
think
it's
that
kind
of
shows
that
there
are
things
there
are
improvements
that
we
can
that
we
can
make,
and
I
think
it
makes
sense
to
go
ahead
and
make
some
of
those
changes.
Now,
while
we're
doing
the
refactor.
D
I'm
also
wondering
too
like
if
we
are
gonna
tackle,
like
just
redesigning
the
issues
and
or
ethics
and
every
page,
then
we
should
think
potentially
of
moving
one
of
the
design
sprints
at
the
very
beginning,
the
first
two
weeks
for
bigger,
broader
design
with
the
team
so
that
they
can
get
ahead
of
that.
So
we've
got
the
full
eight
weeks
to
think
about
this
new
world,
this
new
design,
as
well
as
how
that
supports
the
components
moving.
D
D
E
E
C
Yes,
so
I
think,
after
looking
at
the
issue
that
alexis
had
created,
she
also
maybe
had
a
similar
question,
which
is
what
are
we
what
we're
trying
to
accomplish
in
this?
What
do
we
want
to
have
kind
of
delivered
or
completed
at
the
end
of
this
session?
C
My
thought
was
that
we
were
going
to
just
maybe
do
smaller
experiments.
We've
done
a
lot
of
validation.
We've
done
a
lot
of
research,
I
feel
like
we
have
pretty
good
understanding
of
who
our
users
are
in
this
case
and
some
of
the
problems
that
they
have,
as
well
as
opportunities
to
improve
issues
and
some
of
the
other
parts
of
plans.
C
I
think
it
was
just
not
necessarily
what
my
expectations
were
in
terms
of
what
we
need
to
kind
of
accomplish
or
what
we
want
to
understand
at
the
end
of
this
design,
sprint
process.
So
that's
really.
My
biggest
question
is:
what
are
we
trying
to
accomplish
with
this?
I
feel
like
we've
talked
about
this
a
couple
of
times,
but
I
don't
feel
confident
that
it's
been
finalized.
Maybe
that's
just
me.
B
Yeah,
I
think
we
need
another
goal
without
the
output
and
I
guess
for
me
personally,
like
I
don't
feel
comfortable
like
I
don't
like
tackling
things
I
just
want
to
under,
and
maybe
I
could
be
like
a
solo
thing
but,
like
I
just
kind
of
want
to
understand,
like
validate
some
of
the
assumptions
we're
making
or
that
we
have
made
like
with
the
especially
like
external
participants,
maybe
before
I
start
kind
of
moving
things
around,
but
I
don't
know
like.
Maybe
we
actually,
let's
talk
about
the
goal.
B
D
F
D
Think
the
goal
is
still
the
same
right
like
just.
I
think,
we're
aligned
that
we
need
to
have
the
issue
types
combined.
We
need
to
move
epics
onto
issue
types
and
get
it
in
the
path
to
get
us
there,
and
the
ux
can
be
better
to
support
that.
So
the
what
we
need.
What
we
need
to
do
is
figure
out
the
steps
over
the
next
eight
weeks.
That
will
get
us
to
the
point
where
engineering
can
then
break
this
down.
B
D
D
We've
thought
through
every
single
field
and
widget
in
that
view,
and
so
that
when
the
engineers
pick
up,
they
know
what
they're
coding
for
and
why
and
then
it's
been
validated
and
then
how
do
we
have
a
consistent
view
for
issue
view
that
can
then
also
support,
epic's
requirements
and
all
the
other
issue
types.
E
Can
I
share
my
screen
real
quick
too
just
to
run
through
something
in
my
health,
so
like
going
back
to
the
why
this
work
stream?
And
why
now,
like?
I
kind
of
try
to
outline
this
this
thing
that
I've
brought
up
a
while
ago
and
raised
but
like
right
now,
it's
confusing
the
epics
are
at
the
group
level,
not
issues.
It's
confusing.
The
epics
are
not
at
the
project
level.
Like
most
organizations,
I've
talked
to.
E
They
want
to
do
all
their
playing
at
the
group
level
or
at
the
project
level,
but
not
split
between
the
two
there's,
basically
like
a
desire
for
having
more
clarity
about
in
your
work
item
hierarchy
so
like
instead
of
using
labels
to
know
like
if
something's
a
capability
or
a
feature.
However,
it's
fine
they
want
to
be
able
to
like
have
a
clear
definition
of
what
those
work
items
are
and
basically
like,
based
on
everything
that
I've
heard
over
the
last
18
months.
E
E
They
want
to
be
able
to
customize
each
issue
type
within
that
hierarchy,
to
have
different
metadata
on
it
and
then
like,
if,
if
you
kind
of
go
a
little
bit
further
too
like
if
you
have
everything
in
this
base
model
that
it
has
these
like
extensible
fields,
widgets
as
they're
called
this
idea,
it's
then
a
lot
easier
to
maintain
one
model
and
maintain
one
view
like,
for
example,
epics.
We
spent
a
long
time
creating
epic
boards.
If
epics
were
a
type
of
issue,
we
would
have
it
like
out
of
the
gate
already.
E
B
Yeah,
no,
I
think
so
I
think,
and
also
I
just
want
to
scope
it
like
to
you
know
what
we
think
we
can
accomplish
or
like
what
do.
We
need
now
to
move
forward
and
just
make
sure
we
understand
that
just
so,
we
don't
get
like
too
broad
and
like
kind
of
miss
the
mark
right
like
and
end
up
with
nothing
like
what
do
we
need
for
this?
B
First,
like
iteration
of
the
project,
meaning
like
doesn't
mean
we
can't
come
back
and
add
more
but
like
what
does
the
team
need
from
holly
and
I
or
like
just
ux
in
general,
for
this
first
iteration
to
move
forward
towards
this
like
shared
model.
E
I
think
the
the
there's
two
ways
you
can
approach
it.
You
can
approach
it
like.
What's
the
smallest
amount
of
work,
we
need
to
provide
to
engineers
so
that
they
can
move
forward,
there's
also
the
opposite
approach
of.
What's
the
ideal,
you
know
like
and
then
work
backwards,
to
remove
the
constraints
to
get
to
the
ideal,
and
I
think
it
would
be
great
if
we
sort
of
like
what
donald
said
earlier
thought
about
the
ideal.
It
doesn't
mean
we're
going
to
do
it
all
at
once,
or
we
have
to
do
it
all
at
once.
E
Let's
work
backwards
to
reverse
engineer
it
to
remove
like
the
specific
constraints
along
the
way
to
achieve
the
ideal,
and
so
I
think
I
would
like
to
see
more
of
like
that
kind
of
thinking,
even
if
even
if
we
don't
start
with
that,
if
that
makes
sense
so.
B
I
think
that
makes
sense,
but
what
I'm
trying
to
get
at
is
like,
if
you
think
about
green
field
like
vision
right
like
that,
could
be
a
lot
that
could
be
like
what
is
the
entire
flow
like?
What
is
the?
What
do
all
the
lists
look
like:
how
do
we
segment
everything
but
like
which
is
awesome
like
I
would
love
to
think
about
that,
but
that
could
that
could
grow
a
lot?
Is
there
a
way
that
would
be
helpful
to
scope
this
vision
work?
B
E
Yeah,
I
think
so
it
does,
and
I
would
say,
like
the
most
important
things
that
you
have.
We
have
to
figure
out
in
order
to
convert
epics
to
an
issue.
A
work
item
hierarchy
is
like
what
is
what
does
that
look
like
in
a
consistent
way
in
the
product
and
then,
if
you
were
like
how
do
the
relationships
work
right?
E
I
think
that
would
be
like
a
huge
chunk
of
it
and
then
do
we
need
to
make
any
changes
to
the
issue
detail
view
to
better
facilitate
the
experience
of
using
a
single
object
in
a
hierarchy
instead
of
like
epics
and
issues
and
all
this
other
stuff,
because
what
this
will
also
enable
us
to
do
is
we're
working
on
simplifying
groups
and
projects,
which
means
eventually,
groups
and
projects
are
the
same
thing
on
the
back
end
and
then
we'll
have
issues
available,
basically
at
the
group
level.
E
D
B
E
It's
kind
of
like
this.
I
think
it's
the
issue
here
but
like,
if
you
think
about,
if
all
these
things,
maybe
not
the
mr
and
the
vulnerability
that
are
outside
of
this.
But
all
these
are
just
like
issue
types
relating
them
together,
but
then
also
relating
them
across
different
work
item
hierarchies,
because
this
is
eventually.
E
This
is
basically
what
our
customers
want
to
be
able
to
do,
whether
it's
like
quality
management,
a
test
session,
there's
test
cases
in
that
which
are
linked
to
requirements,
requirements
to
link
to
the
issues
that
implement
them,
and
then
there's
this
roll-up
report,
and
each
of
these
have
different
sort
of
personas.
That
will
like
reference,
these
sort
of
workout
hierarchies.
But
how
do
you
facilitate
this
sort
of
a
relationship
where
you
have
like
related
blocking
parent
child
in
a
consistent
way?
E
And
that's
where
I
think
it's
a
huge,
huge
and
important
thing
to
think
through,
because
there's
more
and
more
teams
now
that
want
to
add
relationships
to
things
to
issues
and
merge
requests
like
vulnerabilities,
for
example-
and
this
is
part
of
like
when
you're
thinking
about-
should
we
focus
on
redesigning
issue
view
and
why
I
say
it's
sometimes
not
scalable.
If
every,
if
every
object
that
wants
to
be
related
to
an
issue
is
related
to
an
issue,
it
would
take
up
the
whole.
E
My
whole
screen,
like
above
the
fold,
probably
even
two
pages
worth
of
lists,
of
just
related
things
right.
So
I
think
that's
that's
one
of
the
reasons
why
I'm
thinking,
like
maybe
thinking
a
little
bit
more
greenfield
about
it
and
approaching
the
problem
kind
of
with
fresh
eyes.
D
We
could
also
delineate
on
that
spreadsheet.
It's
just
like
whether
it
design
could
talk
through
like
issue
description
doesn't
need
to
change
linked
objects.
Do
like
we
do
need
a
better
way
or
like
some
of
these,
maybe
can
stay
like.
Maybe
we
decided
discussions
and
comments,
we're
not
going
to
touch
but
like
having
just
a
little
formality
around
like
what
parts
we're
redesigning
and
why,
as
well.
B
Or
like
what
need
to
be
just
keep
them
consistent
for
now.
Is
that
what
you're
thinking
kristen
really
so
maybe
we
can
think
about
what
what
are
the
most
like
risky
objects
in
there
and
like
risky?
I
mean
like,
or
maybe
like
most
potential
like.
If
we
improve
them,
it
will
really
improve
the
users
quality
of
life.
I
don't
know,
does
that
make
sense.
C
So
what
would
be
helpful
for
me,
then,
is
to
maybe
align
on
kind
of
the
overarching
problem
statement
that
we
want
to
work
toward
and
then
move
toward
that
if
we,
this
was
very
helpful
for
me.
So
thank
you
all
for
explaining,
because
I
was
under
the
impression
that
we
were
going
to
be
doing
more
just
high-level
discovery
and
therefore
we
wouldn't
necessarily
be
delivering
anything
at
the
end.
C
So
that
being
said,
I
do
feel
like
it
makes
more
sense
to
do
a
little
bit
more
of
the
front-end
validation
and
exploration,
but
I
do
think
it's
important
that
we
align
on
kind
of
what
that
overarching
problem
statement
is
first
and
then
have
that
as
our
north
star
to
guide
us
throughout
the
remainder
of
the
the
process.
C
But
that's
something
that
we
can
talk
about.
Maybe
the
four
of
us.
I
know
we've
got
our
meetings,
I
think
tomorrow
and
alexis-
and
I
have
a
sink
today
to
just
kind
of
kick
off
some
of
this,
so
that
could
be
something
that
we
can
start
in
those
sessions
which
I
think
will
be
recorded
as
well
in
case
anybody
else
is
interested
in
what
comes
out
of
this
heck
yeah
yeah.
B
I
think
so
I
put
stuff
in
to
this
epic,
and
I
don't
mean
it
like
this
is
what
alexa
says
we
have
to
do,
or
anything
like
that.
I
was
just
trying
to
like
visualize
the
kind
of
the
scope
of
work
and
then
like
that
way.
It
might
help
us
kind
of
scope
it
down
a
little
if
it
seemed
huge
right
like
it
just
seemed
like
there
was
a
lot
of
focus
in
one
area.
Maybe
we
would
better
understand,
like
you
know
what
you
and
I
holly
have
to
do
in
a
project
like
this
right.
B
Also
so
yeah,
I
think,
like
you
know,
we
have
a
lot
of
research
to
your
point
that
we've
already
conducted
so
like
thinking
how
to
synthesize
that
and
capture
those
opportunities
and
things
like
that
as
a
starting
point,
but
yeah,
let's
edit
this
again,
just
a
starting
point.
B
B
I
mean.
Is
there
a
way
you
all
want
to
be
involved
engineering
managers,
engineers
whatever?
How
would
you
like
to.
G
Be
involved,
I
I
ideally
like
dude
and
donald
you
can
chime
in
it's
probably
actually
more
relevant
for
front
end
here,
but
like
it
sounds
like
a
lot
of
this
initial
work
will
be.
You
know,
scoping
and
aligning
kind
of
several
different
efforts
to
make
them
all
sort
of
like
fit
in
the
same
workflow
or
like
flow
of
work.
G
So
engineering
you
know,
should
be
involved
but
like
we
should
be
guiding
how
feasible
some
of
these
things
are
and
how
how
we
might
break
those
down,
but
but
also
like
there's
kind
of
a
balance
to
find
between
what
we
can
actually
spend
time
on
or
when
we
can
spend
time
to
like
kind
of
undertake
that
work
versus
what
we're
currently
working
on,
right
and
and
such
like,
we
wouldn't
want
to
be.
You
know,
trying
to
pick
up,
and
I
haven't
looked
at
the
epic
but
the
kind
of
prototype
phase.
G
Obviously
like
engineers
and
prototyping
things
things
like
that
providing
feedback,
but
even
earlier,
I
would
expect
like
some
some.
You
know
feedback
cycle
on
the
feasibility
of
what
we're
talking
about
the
actual
like
practical.
How
could
we
get
this
done
in
a
way
that
makes
sense,
so
we
should,
you
know,
promote
that.
However,
it's
possible.
A
You
know,
given
that
we
have
the
time
to
do
that
at
each
phase,
but
we're
testing
out
the
feasibility
through
prototyping
or
through
experimentation
on
the
engineering
side.
I
think
that'd
be
super
helpful.
D
H
H
Do
we
support,
say
one
issues
endpoint
in
the
rest,
api
and
deprecate
anything
we've
built
for
other
things.
That
will
be
issue
types
in
future,
epics
being
the
obvious
one,
but
then
also
on
the
graphql
api
we've
already
built.
I
think
requirements,
queries
and
test
case
queries,
even
in
the
case
of
test
cases
where
they're
already
issue
types
so
they're,
like
philosophical
design,
decisions
that
we
need
to
like
unblock
now,
we
kind
of
are
unblocking
them,
but
they're
kind
of
bigger
things
like
if
the
web.
H
If
the
web
interface
is
going
to
have
like
one
issue
list
from
which
everyone
will
filter
all
different
issue
types,
then
we
might
choose
to
make
that
decision
in
the
rest
api,
that
everything
should
just
be
an
issues
endpoint
and
you
use
filters
if,
in
the
ui
we're
going
to
have
like
a
separate
sidebar
thing
just
for
incidents
or
just
for
test
cases,
we
might
decide
that
the
rest
api
should
also
have
a
list
endpoint
for
those
things
as
well,
and
there
are
decisions
really
that
we
kind
of
have
to
make
now
like
we
can't
really
defer
them,
because
otherwise
we
have
to
stop
doing
the
work
to
like
to
convert
things
that
we've
already.
D
E
I
think
we're
almost
at
the
time,
but
I'm
just
going
to
say
I
think
that's
I
feel
like
we
can.
We
should
be
able
to
get
broad
alignment
on
the
philosophical
issues
early
right
but
like
if
there
are
still
questions
or
we
don't
agree
that
the
fact
that
like
we
should
maybe
consolidate
and
have
a
single
issues,
endpoint
and
issues
like
object,
and
then
you
know
you
can
build
different
views
in
the
product
by
passing
a
different.
E
You
know,
graphql
query
that
filters
by
type,
so
there's
flexibility
to
do
things
in
the
product,
but
it
also
like
the
whole.
One
of
the
benefits
that
I
see
from
this
is
less
surface
area
to
manage
in
terms
of
endpoints
and
things
and
updating
stuff
and
like
and
making
it
so
eventually
it
can
be
extensible
and
the
user
customers
can
customize
their
issue
types.
Basically,
so
I
guess
like
if
there
are
those
philosophical
disagreements,
please
raise
them
now.
E
H
Yeah,
I
don't
think
we're
blocked
now
we
resolved
something
last
week
about
putting
issue
type
into
the
rest
api
and
what
it
should
be
called
and
so
on.
Should
it
match
the
same
name
like
we
call
it
issue
type
on
the
back
end,
but
we're
exposing
it.
The
api
is
type
and
we're
adding
this
as
documentation
for
development
and
future.
So
I
don't
think
we're
blocked,
but
it's
just
you
know.
Should
we
uncover
something
in
this
investigation?
That
means
we
change
course.
H
Query
going
forward
and
filter
there
on
issue
type,
so
larger
decisions
like
may
be
difficult
to
reverse.
I
guess
but
yeah
I
mean
if
things
come
up,
we'll
just
raise
them
and
get
them
unblocked.
F
A
All
right
all
right,
conveniently
yeah,
I'm
sure
we'll
have
we'll
continue
this
conversation
yeah.
We
should
probably
have
some.
We
should
probably
book
some
engineering
alignment
meetings
like
kristin,
suggested
cool
all
right
have
a
good
day.
Everyone
talk
to
you
all
later.