►
From YouTube: Create:Editor Product/UX Weekly - 2021-01-13
Description
Weekly Editor group sync between Product, Design, and UX Research
A
All
right,
hello,
everyone-
this
is
january
13th
and
our
editor
weekly,
ux
product
and
design.
Sync
is
about
ready
to
start,
so
I
have
just
a
couple
quick
items
in
the
products
section
and
michael
you
added
one.
Thank
you.
I
think
that
this
came
up
before
about
a
group
conversation
or
some
kind
of
presentation
related
to
settings
and
navigation,
specifically
the
progress
towards
our
okr
or
or
lack
thereof.
A
In
this
case,
I
think
we've
made
great
progress
towards
the
okr
and
should
finish
up
pretty
strong
there,
thanks
to
the
the
completion
of
the
solution,
validation
and
the
work
of
the
team
to
to
ship
a
couple
things
in
13.8.
A
I
will
look
into
this.
I
don't
know
what
the
calendar
looks
like
for
group
conversations.
I
think
that's
probably
going
to
be
the
most
effective
thing.
I
know
it
was
pretty
well
received
for
static
site
editor
when
we
did
that
one
to
kind
of
address,
everybody's
questions
about
what
we're
actually
working
on
and
and
how
they
can
give
feedback
yeah
I'll
check
on
the
schedule.
There
that'll
be
an
action
item
for
me.
A
A
Maybe
it
might
be
better
for
like
end
of
february,
because
I
we
have
some
really
great
work,
shipping
in
or
slated
for
13.9
and
if
we
could
just
show,
even
in
staging
or
or
like
prior
to
to
rolling
out
on
the
omnibus,
like
just
on
dot
com
like
a
couple
other
things
that
might
be
even
more
effective,
even
though
it
won't
technically
be
part
of
our
quarterly
okr.
It
could
we're
about
to
like
implement
some
of
the
stuff
that
we
would
be
talking
about.
A
So
it
might
be
good
to
just
have
some
of
that
that
I
can
demo
for
the
group
conversation,
but
I'll
look
at
the
schedule.
If
that
doesn't
work
out,
then
sometime
in
february.
B
A
A
Those
are
both
relatively
minimal
effort,
so
I
feel
confident
we're
going
to
ship
them
in
thirteen
nine
but
they're
they
have
high
impact
and
they're
they're.
They
were
validated
in
the
process
of
you
know
working
this
quarter
so
it'd
be
great
to
just
show
that
they're
shipped.
A
So
moving
on
michael,
you
want
to
voice
over
this
question
or
topic.
C
So
this
yesterday
there
was
a
support,
comment
that
popped
up
again
around
the
frequently
visited
links
in
the
drop
down
menus
for
projects
and
groups
in
yeah.
I
think
in
the
moment
that
seeing
that
I
was
like
oh
what
do
we
need
to
actually
validate
to
say
it's
okay,
to
go
ahead
with
like
just
making
the
change,
because
if
we
go
through
the
history
of
how
frequently
appeared
into
the
world,
it
seemed
almost
like
magical,
because
the
initial
plans
were
always
to
have
recently
visited.
C
A
Amber
alert
or
something
on
my
phone
just
making
sure
it
wasn't
something
I
needed
to
like,
take
shelter
or
something
okay,
yes,
data
is
is
the
answer
and
I
think
chad
had
some
initial
dashboard
for
a
query
that
we
could
look
at
here
when
he
instrumented
that
and
it
never
made
it
into
a
full
dashboard.
But
I
believe
the
data
is
available,
so
we'll
take
a
look
at
how
often
users
are
interacting
with
that
area
and.
A
I
think
if
we
are
going
to
make
the
change
making
the
change
when
we
address
that
top
nav
proposal,
that
you
have
makes
the
most
sense,
rather
than
just
switching
it
out
and
then
continuing
to
iterate.
That
could
just
be
one
of
the
phases
of
that
iteration.
A
C
Cool
I'm
just
going
to
take
this
moment
just
segue
into
my
one
point
in
design.
Yeah
yeah
I'll,
create
the
epic
for
consolidating
the
top
nav
sometime
today,
and
I.
A
A
That's
perfect:
I
appreciate
it.
I
have
been
meaning
to
make
it
as
well
for
a
couple
weeks
just
to
in
preparation
for
the
wrap-up
of
the
validation,
and
that
would
be
helpful.
I
think
the
13
13.9
planning
was
going
really
well.
I
met
with
roman,
even
though
he's
just
finishing
up
some
of
his
leave.
We
chatted
yesterday
about
thirteen
nine.
We
have
a
good
you
know
chunk
of
issues
to
work
on.
A
We
have
plenty
of
work
to
do,
but
we
did
kind
of
identify
this
work
as
something
we
would
do
in
1310,
the
top
nav.
So
anything
we
can
do
to
refine
the
issues
now
and
start
planning.
We
also
may
have
some
front-end
bandwidth
to
pick
up
at
least
some
technical
exploration
or
first
mvcs
behind
a
feature
flag
or
just
generally,
like
start
momentum
on
this
work
in
thirteen
nine.
So
it's
likely
when
I
record
the
kickoff
call
on
tomorrow,
because
we
don't
have
friends
and
family
day
and
it
might
slip
to
friday.
A
Try
not
to
work
that
day.
But,
as
I
record,
the
kickoff
call,
I
probably
will
highlight
your
solution,
validation
and
just
show
where
we're
headed
and
then
say
that
it's
not
gonna
ship
in
thirteen
nine
but
we'll
start
working
on
it
so
yeah
anything
you
can
do
to
to
prepare
I'll
I'll,
certainly
help
you
know,
put
it
in
the
right
place
and
parent
it
to
the
right
epics
and
as
as
much
as
necessary.
Just
let
me
know
if
you
need
any
help.
A
We
speaking
of
milestone,
planning
1310,
I
think,
is
going
to
be
when
I'd
like
to
shift
a
bit
of
our
focus
back
towards
the
static
site
editor
in
a
way.
But
you
know
in
a
sense,
in
the
sense
that
I
want
to
start
executing
on
enrique's
architecture
for
the
new
wysiwyg
editor,
the
rich
text
editor.
A
We
had
a
review
on
monday
and
it
went
in
my
opinion
very
well.
I
think
we
have
strong
buy-in
from
leadership
that
this
is
a
one
of
our
top
opportunities
for
the
group
to
consolidate
the
editing
experience
around
a
single
rich
editor
and
starting
with
a
wiki
or
issue
descriptions
depending
on
which
one
has
the
lowest
level
of
complexity.
A
A
The
the
link
to
the
opportunity
canvas-
I
don't
believe
it's
public,
but
it's
open
to
everything.
Gitlab
is
in
the
agenda,
but
the
feedback
was
was
very
positive.
Everybody
seemed
on
board,
with,
with
our
approach
I
was
able
to.
A
So
all
that
in
the
under
the
umbrella
of
reusability
and
consistency-
and
those
are
key
themes
for
our
group
and
and
the
company
in
general
right
now
so
everybody's
on
board
very
happy
to
hear
that.
A
In
the
process
of
creating
this
iteration
plan,
it
might
be
helpful
to
have
one
or
two
directional
mock-ups
for
how
this
might
look
in
the
wiki
or
in
issue
descriptions.
As
far
as
like.
A
The
mvc
goes
like,
I
think,
we've
we've
explored
in
the
past
what
it
could
look
like
in
its
ideal
state,
and
but
you
know
now
that
we've
identified
the
actual
architecture,
the
actual
projects
and
features
that
that
will
be
inherent.
B
A
And
we
know
that
we're
gonna
go
with
you
know,
standard
pajamas
design
system,
I
think
putting
it
together
and
making
it
very
clear.
What
we're
building
for
the
mvc
would
be
would
be
helpful,
not
that
you're
not
busy
michael,
but
let's
maybe
that's
my
next.
C
Question
I
was
curious
from
a
timeline
perspective
when
would
be
ideal
to
have
that
ready,
like.
A
I
think
we
probably
have
enough
for
at
least
a
couple
weeks
before
we
need
to
probably
more
than
that
before
it
actually
changes
our
our
plans
like.
I
think
this
would
be
more
for
like
addressing
conversations
about
oh
well
like
are.
We
gonna
have
image
uploads
in
the
mvc
or
like
what
buttons?
Where
should
the
buttons
go,
and
what
options
will
actually
be
available
and
things
like
that?
A
lot
of
it
can
be
done.
A
Communicating
via
you
know,
text
and
in
the
issues
in
in
writing,
but
it
would
be
good,
especially
to
speak
to
like
by
1310.
Kickoff
like
having
a
visual
to
speak
to
is,
is
very
helpful,
so
something
sometime
in
the
next
like
two
to
four
weeks,
probably.
A
I
dropped
this
last
link
in
here
because
we
talked
about
this
during
the
issue
refinement
today,
and
I
thought
it
was
just
kind
of
an
interesting
product
principle
and
discussion.
So
I
wanted
to
surface
it
here
as
it
related
to
settings
and
in
general,
but
there
was
a
an
issue
and
a
discussion
on
multiple
issues
going
around
last
week
and
it
opened
up
a
conversation
that
I
had
been
aware
of,
but
not
necessarily
weighed
in
on
directly
as
the
as
the
new
pm.
A
There
are
several
issues
out
there
that
have
been
created
over
the
years
to
like
turn
off
the
web
ide
or
you
know,
disable
editing
from
within
gitlab.
Most
of
them,
I
saw
were
rooted
in
the
desire
to
enforce
other
development
environments
on
a
team
so
like.
Maybe
they
really
just
want
somebody
to
use
vs
code
because
they
have
a
very
specific
implementation
or
some
plugins
that
they
they
require
in
in
a
organization.
A
At
a
certain
point,
though,
this
becomes
overwhelming
to
have
too
many
settings
as
we
know,
because
we
have
too
many
settings
already.
It's
not
something
I'm
inclined
to
prioritize.
We
don't
have
enough
demand
to
override
our
principles
of
defaulting
to
on
and
having
you
know,
an
opinionated
perspective.
I
also
feel
like
I
don't
fully
understand
the
impact
of
turning
off
web
editing
altogether
across
the
entire
application,
because
turning
off
the
web
ide
is
one
thing,
but
you
could
do
the
same
thing.
A
A
There's
also
the
upcoming
like
pipeline
editor
and
not
having
access
to
that
there's
a
whole
other.
You
know
a
whole
other
part
of
the
application
that
you
would
be
turning
off.
I
I
had
previously,
you
know
kind
of
just
aligned
with
our
decision
that
had
been
made
before
that
we
should
not
turn
off
web
editing
as
a
as
a
toggle
in
the
settings
pending
demand.
You
know
my
my
convictions
are,
are
strong,
but
loosely
held
right
like
I
can
be
convinced
by
data
that
this
is
the
wrong
stance
to
take.
A
But
for
now
I
think
that's
that's
where
we
stand,
and
this
issue
came
up
that
actually
highlighted
a
very
valid
reason
why
you
wouldn't
want
to
use
the
web
ide,
which
is
that
the
web
id
can't
commit
it
can't
provide
signed
commits,
and
you
can't
do
that
at
all
through
the
web
interface
right
now.
We
don't
have
a
workaround
for
that,
and
the
web
ide
actually
can
commit.
A
To
projects
that
have
enabled
only
sign
commits
so
it's
kind
of
a
way
around
that
at
least
that's
what
I
understand.
I
haven't
been
able
to
verify
that
because
I
don't
have
a
project
set
up
in
that
way,
and
so
I
need
to
do
that.
Anyhow,
the
discussion
you
can.
You
can
watch
the
recording,
but
the
decision
was
basically
instead
of
addressing
the
request
in
this
issue,
which
is
to
disable
the
web
ui
or
the
web.
A
Editing,
because
it
can't
do
signed
commits
the
solution
that
we're
looking
towards
is
actually
to
provide
the
ability
to
sign
commits
through
the
web
editor
and
until
that
time
we
would
want
to
respect
the
settings
of
the
project
and
prevent
users
from
committing
from
the
web
ide
if
they
require.
If
the
project
requires
signed,
commits,
there's
probably
two
issues.
A
If,
if
we
can
at
least
get
that
done
at
least
then
we're
not
like
a
workaround
for
these
people
who
rightfully
want
to
have
their
workflows
enforced
and
their
their
signed,
commits
100
signed,
commits
on
their
project
and
then
I
think
it'll
be
us,
collaborating
with
the
source
code
group
to
figure
out
an
approach
for
signed
commits
in
the
web,
which
honestly
I
don't
know
enough
about
to
propose
a
solution.
It
sounds,
like
others,
have
figured
out
a
way
around
this,
but
we
certainly
wouldn't
want
anybody
to.
A
C
For
this,
which
recording
were
you
referring.
A
Yeah
I
just
spammed
the
channel,
so
let's
this
was
the
backlog
refinement
in.
A
This
was
today
earlier
today
for
me.
A
A
A
Got
it
all
right,
I
feel
like
I've
rambled
enough,
catherine,
you
want
to
jump
into
some
research
topics.
A
B
Related
to
disabling
the
editors,
but
not
exactly
that
topic,
but
it's
something
I've
seen
in
a
couple
other
places
like,
for
example,
the
merge
request
templates,
how
you
can
add
a
checklist
and
then
someone
would
write
in
saying
my
team
members
are
not
clicking
all
the
checks
check
boxes
on
this
list.
How
can
I
enforce
this?
B
B
And
so
it's
this
interesting
thing
where
it's
kind
of
a
team
process
problem,
but
they
want
to
handle
it
and
enforce
it
in
gitlab,
but
we're
not
sure
where
we
kind
of
land
on
that,
because
it's
extra
configuration
and
whatnot
but
yeah.
I
don't
know
what
the
answer
to
that
is.
But
I've
seen
that
in
a
couple
other
places.
A
That's
interesting
yeah
I
mean
you're
right.
It
does
come
down
to
just
you
know,
workflow
and
team,
like
collaboration,
best
practices,
enforcing
how
you
want
to
work
with
your
team
to
an
extent
we
have
some
settings
related
to
that
like
enforcing,
signed,
commits
or
push
rules
in
general
and
and
merge
request
templates,
but
like
making
them
required
yeah.
It's
a
it's
a
tough,
it's
a
tough
thing
to
enforce,
but
not
make
too
overwhelming
for
configuration
right,
because
any
enforcement
would
require
some
configuration
of
the
rules
to
enforce.
A
In
this
case,
I
also
kind
of
feel
like
if
your
engineers
on
your
team
are
using
the
web
ide
to
go
around
something
that
you've
told
them.
They
need
to
do
like
use
say
like
eclipse
as
their
ide,
then
they're
probably
have
a
problem
with
the
ide
and
they're
gonna
find
another
way
around.
It's
not
really
up
to
us
to
disable
web
ide.
A
It's
not
gonna
prevent
them
from
finding
a
way
around
your
requirement,
necessarily
maybe
sometimes
that
might
be
a
little
naive,
and
maybe
there
are
some
cases
where
this
is
the
only
workaround
that's
possible,
but
I
kind
of
have
a
feeling
these
people
are
smart
and
they'll
they'll
find
a
way
around
it.
If,
if
there
is
a
way.
B
A
I
mean,
I
think
I
think
it's
just
been
an
interesting
issue
for
me
to
to
process,
because
it
helps
illustrate
some
of
the
gaps
in
the
web
ide
being
adopted
by
organizations
and
and
for
any
reason
why
they
specifically
would
not
want
people
to
use.
It
is,
is
a
data
point
for
me
to
understand
how
we
can
make
web
ide
better?
Another
specific
example.
I
know
I
said
I
was
going
to
turn
it
over
to
you,
but
another
example
was
like.
A
I
think
it
was
a
university
that
wanted
to
teach
a
course
and
or
or
maybe
as
a
high
school,
but
an
educational
institution
that
wanted
to
teach
a
course
and
they
wanted
to
make
sure
their
students
were
committing
from
the
command
line
and
learning
git
flows
that
way
and
the
web
ide
allows
them
to
kind
of
abstract
and
simplify
that
by
opening
the
file,
making
a
change
and
clicking
a
button
to
commit.
A
B
A
It
find
a
way
to
assess
that
knowledge
elsewhere,
because
we
can't
like
build
that
into
our
build
that
complexity
in
the
product
to
enforce
artificial
constraints.
I
guess.
B
Right
yeah
definitely
an
interesting
topic.
B
Yeah,
so
basically
I
have
so.
We
have
two
points
related
to
this,
so
the
first
point
is
more
of
a
an
overview
of
kind
of
the
plan
over
the
next
couple
of
weeks,
and
then
the
next
point
I
think,
we'll
we
can
talk
a
bit
more
about
just
like
what
we
saw
in
this
in
this
study,
so
I'll
just
share.
Well,
actually,
maybe
I
I'll
share
my
screen,
it's
kind
of
not
needed,
but
I
would
do
it
I'll
share
my
career
at
this
portion,
but
basically,
what
I've
shared
here
is
an
epic.
B
It
used
to
be
an
issue,
but
it's
now
an
epic
and
and
what
I've
been
finding
from
these
left.
Sidebar
studies,
but
also
a
parallel
study.
That's
going
on
around
the
documentation
site
is
that
we
and
also
the
operations
first
click
test
is
that
we
kind
of
need
to
take
a
step
back
and
take
a
bigger
look
at
the
mental
model
of
the
of
our
users
and
understand
what
they're
thinking
of
the
way
we're
categorizing
items,
what
they
even
expect
to
do
in
certain
places
when
they
first
sign
into
gitlab.
B
B
So
what
I
plan
to
do
over
the
next
couple
of
weeks
is
to
take
in
the
results
from
our
different
benchmarking.
Studies,
consolidate
the
findings
across
each
study
and
create
a
report
on
kind
of
like
the
state
of
the
nav
bars,
because,
basically,
in
each
study,
we'll
get
information
on
the
success
rate.
B
What
are
the
ways
that
they're
categorizing
information,
because
that
might
give
some
insight
into
how
our
information
could
be
categorized
as
well,
if
we're
seeing
patterns
around
the
way
that
our
major
competitors
are
doing
it,
it
may
not
be
ideal.
It
kind
of
depends
on
whether
they
did
all
this
research
as
well,
but
at
the
very
least,
you
could
find
what
users
are
expecting
to
see
if
they're,
using
similar
products
as
well,
and
they
kind
of
go
from
one
to
the
other
and
how
they
might
think
about
it.
B
What
information
should
be
in
there
and
why
kind
of
why
it
was
added
there?
Was
it
more
of
a
discoverability
concern.
You
know
a
group
implemented
a
new
feature
and
wanted
to
display
it
there.
So
people
could
find
it
was
it
a
link
to
something
that's
commonly
needed,
some
of
the
most
popular
tasks
or
things
like
that
or
job
to
be
done
just
kind
of
mapping
out
what
type
of
information
we
have
already
and
if
that
aligns,
with
the
way
that
we
want
to
structure
it
going
forward.
B
And
then
you
can
compare
that
back
with
the
benchmarking
studies
to
see
which,
on
which
structures
users
were
more
successful.
So
that's
kind
of
the
whole
overview
of
the
plan,
and
I
wanted
to
just
share
that
so
that
if
you're
also
familiar
with
other
navigation
structures
or
if
you
think,
there's
anything
interesting-
that
we
could
take
a
look
at
feel
free
to
share
it
in
this
epic
or
bring
it
up.
Because
that
would
be
really
helpful.
A
Effort
well,
a
this
is
great
and
I'm
very
excited.
This
is
obviously
a
huge
area
of
him
where
we
can
improve
and
a
really
great
plan
to
do
that
when
it
comes
to
competitors.
A
You
may
already
have
these
on
your
radar,
but
I
think
finding
some
not
necessarily
competitors
but
other
like
large-scale
applications,
platforms
like
salesforce
or
atlassian
that
might
have
similar
problems
that
they're
trying
to
solve
where
they
have
like
a
huge
breadth
of
users,
user,
personas
and
and
they
need
to
solve
a
whole
bunch
of
needs
in
a
single
navigation
menu
or
something
like
that
salesforce
and
at
last
you
know
the
two
that
come
to
mind
but
I'll
I'll,
try
and
yeah.
Think
of.
B
It
more
that's
a
really
good
point,
that's
something
that
I
was
considering
for
like,
for
example,
the
documentation
site.
We
have
a
a
similar
left,
sidebar
problem.
A
B
I'm
not
sure
how
from
scratch
we're
going
to
go
in
gitlab.com,
but
I
don't
know
we'll
just
consider
different
proposals
of
how
competitors,
but
also
as
you're
saying
companies
that
are
kind
of
solving
problems
for
different
groups
of
users
or
different
types
of
products,
how
they
present
this
information
to
people,
because
I'm
not
sure
if
we
need
to
go
big
big
or
you
know
it
would
still
be
like
an
incremental
rollout.
But
I
basically
I
don't
know
how
how
different
this
will
look
right
now,
but
it's
interesting
but
yeah,
that's
the!
C
Cool
my
two
cents
on
this
is
I
really
like
the
approach
of
looking
at
the
different
studies
that
have
been
done
and
then
seeing
the
overlaps,
because
I
think
that's
an
interesting
area
that
we
may
have
overlooked
in
just
analyzing
one
individual
one
at
a
time.
So
I
think
that's
really
good.
Regarding
the
content.
B
B
But
if
you
have
any
thoughts
on
what
you
might
like
to
see
or
what
you
think
would
be
helpful
pokerita.
Let
me
know.
C
Yeah,
so
I
I
think,
that's
exactly
it
the
word
you
used,
there
was
organically
grown
and
the
navigation
over
time.
It's
just
grown
like
that,
and
I
think
we
should
focus
more
of
our
efforts
on
where
users
think
content
should
be
versus
what
our
mental
model
is,
and
it's
like.
The
clash
of
the
mental
models
is
our
biggest
problem
right
now
for.
C
Calling
projects
or
repositories
synonymously
all
over
the
place,
but
it's
not
like
things
like
that
and
mapping
like
what
our
users
think
what
we
think
and
seeing
where
that
kind
of
lines
up.
I
think
that
would
be
a
better
kind
of
time
spent
on
like
like
if
you're
ordering
priority.
I
would
probably
I
would
love
to
see
that
higher
than
let's
say
competitor
analysis,
because
in.
B
B
C
Is
that,
like
it
maps
with
the
way,
our
users
think
about
hierarchical
groups,
because
I
think
that
is
a
key
thing
in
gitlab-
that's
different
than
github,
where
we
have
this
idea
of
like
this
hierarchy
of
projects
and
groups,
and
then
you
get
into
the
repository
versus
like
just
a
list
of
repositories
associated
to
one
group.
There's
this
nested
hierarchy
of
global
things
versus.
B
C
I
think
that's
a
good
point
and
then
we
probably
could
do
the
competitive
analysis
is
like
you
can
split
that
off
or
give
that
off
to
someone
else
to
do,
but
I
would
want
to
focus
your
efforts
on
content
analysis
and
with
a
future
looking
rather
than
saying
like.
Why
did
we
put
certain
things
here?
I
think
that'd
be
good
to
tell
a
story
of
like
oh
we
put
this
here,
but
sometimes
that
reason
might
have
been.
C
We
didn't
know
where
else
to
put
it,
so
we
just
stuck
it
there,
but
I
think
it'd
be
more
bias
for
action
or
that
principle
where
we
think
about.
Where
should
we
take
things
where
we
just
say,
like
things
are
the
way
there
are,
we
can
play
detective
and
try
to
figure
out,
or
we
can
say
no.
This
is
where
it
should
be,
so
we're
like.
Okay,
this
is
where
the
new
goal
is,
and
let's
figure
out
a
way
to
get
there.
D
C
Sending
the
future
pose
and
saying
this
is
the
rules
or
like
guidelines
of
why
we
think
that
this
it
should
happen
this
way,
and
I
think
that
would
help
with
the
future,
because
one
of
the
problems
we
have
right
now
is
there
is
no
rhyme
or
reason
to
add
things
to
issues,
or
should
it
be
a
new
menu
item,
we
don't
have
a
rule
defining
in
product
to
say
yes,
if
we're
going
to
do
something.
C
B
Yeah
yeah
this
that
was
great
that
was
wonderfully
put,
and
that
ties
into
a
lot
of
what
I
want
to
think
about,
and
I
almost
think
we
might
go.
I
might
experiment
with
starting
from
scratch
in
the
card
sort,
because
you
know
you
could
do
different
types
of
card
sort.
You
can
do
a
closed
one
where
you
already
give
them
the
categories
and
they
sort
things
into
it.
B
A
Yeah-
and
I
mean
just
to
reiterate,
michael-
I
think
what
you
said
was
spot
on
about
meeting
our
users
where,
where
their
expectations
are
and
mapping
to
the
mapping
to
those
and
and
then
helping
to
find
those
rules
and
document
those
rules,
because
we
don't
want
to
have
to
be
in
this
position,
another
18
months,
where
we're
cleaning
it
up
and
doing
a
big
overhaul
right.
A
If
we
can
identify
those
patterns
and
the
decision
making
process
is
a
little
more
clear,
then
we
can
document
that
in
pajamas
we
can
document
that,
for
our
product
teams
and
and
categories
can
be
empowered
to
to
make
the
right
decisions
in
the
future
and
certainly
yeah.
All
of
the
the
current
options
will,
you
know,
will
need
to
get
cleaned
up
and
find
a
good
pattern
for
those.
A
But
if
our
lot,
if
the
logic
for
why
we
made
that
decision
isn't
clear
to
the
entire
company,
then
we
could
find
ourselves
in
the
same
place
fairly
quickly.
Given
the
rate
that
we
introduce
new
features.
B
Yeah
yeah,
it's
it's.
Definitely
it's
a
big
and
interesting
thing
because
we
introduced
so
many
new
features,
but
I
really
couldn't
well.
There
are
some
of
them.
I
know
why
they're
kind
of,
like
the
maybe
the
flagship
or
the
important
feature
of
the
category
or
area,
but
there
are
others
where
you're
like
well.
Why
didn't
that
feature
get
added
here?
B
In
theory
it
could
be
added,
but
it
didn't.
I
don't
know
why,
but
yeah
it'll
be
really
important
to
have
a
system
for
that
going
forward.
B
And
I
talked
a
lot
about
this
point
and
I
think
I
think
we're
out
of
time.
Are
we
out
of
time.
C
A
C
Was
a
useful,
deep
dive
on
that
point,
so
I
appreciate
that
catherine.
Don't
worry
about
going
over
time
for
that.
B
Oh
yeah,
but
but
basically
for
this
for
your
point
down
there
michael
about
iterations,
were
you
kind
of
thinking
in
theory,
if
we
were
going
to
make
a
change
like?
Is
that
us.
D
C
Yeah
yeah,
it
feels
like
that
one
from
the
left
side
tree
test-
it
was
like,
oh
like
this.
Iteration
thing
is,
like
you
know,
are
you
are
you
planning
to
share
this
with
the
rest
of
the
different
groups
so
that
they
can
take
action
and
read
it
and
take
their
own
action,
because
some
of
those
things
like
iterations
feels
like
there's
an
opportunity
to
do
something
there,
but
I
don't
think
it
should
be
us
to
say
yes,
we
should
move
it
over
here
or
not,
or
would
this.
B
C
Waiting
upon
that
left,
nav
thing
that
you
just
talked
about
on
the
future
vision
or
like
the
direction
of
that
like.
B
Yeah,
I
would
say
that
I,
at
the
very
least,
I
would
want
to
consider
across
the
different
benchmarking
tests
that
we
did
for
the
left
sidebar
just
to
see
if
there
were
anything
related
to
the
task
that
was
kind
of
throwing
people
off,
because
sometimes
the
task
wording
really
does
mess
with
things.
Unfortunately,
but
but
yeah,
basically
putting
a
pin
in
there.
Iterations
is
an
area
that
that
also
caught
my
attention
from
that
test.
But
it's
what
was
interesting
about
it
was
that
I
didn't
I'm
trying
to
remember.
B
B
That
was
one
area
that
I
remember
seeing
people
going
to
to
look
for
things
about
the
the
two
week
cycles
and
velocity,
but
at
the
same
time
it
may
not
belong
somewhere
like
that,
if
you're
thinking
about
the
process
of
actually
creating
the
iteration
that
might
be
more
related
to
the
issue.
So
it
kind
of
depends,
like
the
burn
down
chart
in
the
iterations,
might
make
more
sense
and
might
be
more
aligned
with
analytics,
but
the
actual
creation
of
the
iteration
might
be
more
aligned
with
the
issue.
A
All
right
well,
as
you
mentioned
we're
over
time,
so
I
don't
want
to
keep
anybody,
but
this
has
been
a
great
conversation
and
look
forward
to
more
updates
related
to
the
left
nav.
I
think
that's
probably
good
after
because
I
feel,
like
we've,
come
up
with
a
really
great
iterative
approach
to
the
top.
Now
the
problems
related
to
groups
and
projects,
and
instance,
level
features,
and
I
really
think
we're
going
to
have
an
impactful
change
there.
So
as
we
work
on
that.
B
It's
like
an
area
that
it
doesn't
necessarily
make
or
break
the
experience,
because
you
can
still
achieve
most
of
those
tasks,
even
if
you
can't
do
it
with
a
cop
now,
but
as
I
was
seeing
in
the
solution,
validation
findings,
just
how
excited
some
of
the
participants
were
about
the
consolidated
drop
downs
and
things
like
that.
And,
oh,
my
goodness.
A
Well,
have
a
great
rest
of
the
day
to
both
of
you,
and
I
will
chat
with
you
on
slack
and
any
issues
and
hope
that
you
will
take
our
friends
and
family
day
on
friday.