►
From YouTube: How Product and Design can iterate better
Description
Iain and I review the design iteration survey results and discuss what we've done to improve, what can still be done and how that should be reflected in the handbook.
A
Okay,
so
the
first
question
is:
how
often
does
your
product
designer
break
design
problems
into
smaller
issues
that
can
be
incrementally
delivered
over
time?
I
think
we
do
this
every
milestone.
I
I
think
the
evidence
that
I
would
see
to
do
this
is
we
have
these
redesigned
epics.
Should
I
share
me,
I
can
even
share
my
screen.
A
Can
you
you
can
see
my
screen
right?
Okay,
and
so
you
know
this
as
an
example
we
create.
We
did
have
one
of
these
for
the
container
registry,
and
this
is
the
one
for
the
package
registry
and
what
I've
seen
you
do.
That's
really
helpful.
Is
you
create
all
of
these
issues
at
once
with
the
designs
included,
and
then
you
review
these
with
nico
who's,
our
front
end
engineer
and
we
add
weights
to
them.
We
prioritize
them
based
on
the
weights
and
if
they're
blocked
by
anything.
A
A
The
second
is
there
another
question.
No,
then
there's
a
bunch.
Oh,
how
would
you
rate
yours?
Okay,
that's
I
just
got
into
that.
Then
a
lot
of
people
in
the
like
what
can
be
improved,
talk
about
things
like
partnering,
with
engineering
being
more
involved
in
strategy
discussions
and
being
willing
to
like
talk
through
some
of
the
maybe
ux.
That's
not
design
interactions.
A
So
in
the
first
on
the
am
I
talking
too
much.
Okay
on
the
first
part
on
the
partnering
with
engineering,
I
think
we
learned.
Maybe
in
1303
we
had
our
first
design
technical
investigation
issue.
At
the
same
time,
I'll
share
my
screen
again
and
the
valuable
thing
about
this.
Was
you
had
the
chance
to
work
with
david
on
figuring
out?
What
is
the
user
flow?
What
are
all
the
different
interactions?
A
So
I
thought
that
that
was
a
really
good
proof
point
for
that,
like
design
interacting
with
engineers
and
something
we
like
to
stick
to
on
the
strategy
front,
I
feel
like
we
do
regular
discussions
about
like
one
thing
that
I've
noticed
that's
helpful
is
trying
to
have
the
milestone
plan
up
a
week
early.
That
was
a
shift.
A
It
also
gives
us
another
interaction,
point
to
like
measure
what
like
talk,
discuss,
strategy
and
bubble
up
what
design
work
is
going
on,
so
I
think
that's
really
useful,
and
then
I
think
those
are
the
major
takeaways
that
I
had.
I
feel
like
we're
doing
a
lot
of
those
things.
I'm
sure
there's
room
for
some
other
things
that
we
improved.
A
That
was
a
big
change
for
me.
Is
this
like
slipping
baseline
of
how
we
plan
design
issues,
and
we
kind
of
corrected
that
maybe
three
milestones
ago,
where
it
felt
like
we
got?
We
had
a
really
productive
a
few
months
of
design
like
we
redesigned
the
container
industry,
the
package
registry.
We
have
the
dependency
proxy
and
I
think
I
started
just
like
putting
in
last
minute
issues
into
the
milestone,
and
we
had
this
discussion
about.
A
No,
it's
good
to
have
time
to
design
before
we
start
implementing,
because
it's
going
to
make
us
both
be
aligned
on
strategy
and
interactions,
and
then
it's
going
to
result
in
better
defined
issues.
So
I
think
that
was
the
other
big
iteration
that
we've
had
towards
addressing
these
things.
So
I'm
feeling
pretty
good
about
how
we're
tackling
that
stuff.
B
Instead
of
taking
a
user-centered
approach
and
being
able
to
say,
okay,
first
milestone,
let's
deliver
caching
in
the
request,
forwarding
and
really
kind
of
focusing
on,
instead
of
breaking
up
a
large
initiative
just
into
small
pieces
and
having
to
wait
until
the
end
to
get
results
for
our
users
being
able
to
break
them
down.
So
that
conversation
was
a
little
bit
harder
than
some
of
our
others.
So
I
wonder
if
that's
an
area
that
we
could
improve
on.
A
I
think
so
yeah,
I
think
we.
I
noticed
that
that
same
thing
in
that
project,
because
it
was
one
of
those
things
that
it
was
hard
to
attack
iteratively,
because
we're
looking
at
the
end
we're
hearing
what
our
customers
are
telling
us
that
they
want
this
functionality,
and
I
don't
I
at
least
wasn't
imagining
the
skateboard
into
the
moped
into
the
car.
A
I
think
we
iterated
eventually
ended
up
iterating
on
it
and
we
we
talked
about
it
at
our
think,
big
and
then
we
had
another
brainstorming
session
and
I
think
we
have
a
plan
now,
but
I'm
wondering
how
we
could
have
what
we
should.
Maybe
what
we
could
have
done
is
realize
that
sooner
that
it
was
going
in
that
direction
and
that
maybe
the
conversations
were
getting
were
too
big
and
we
were
operating
in
this
waterfall
method.
B
Yeah,
I
think
the
warning
flag
went
up
where
for
me,
when
we
were
talking
at
the
thinkpig
and
the
engineers
were
talking
about
how
an
entire
milestone
was
going
to
be
dedicated
to
just
the
models
and
in
my
mind,
because
I
don't
know
anything
about
models,
because
that's
just
not
my
purview
like
that
means
we're
not
delivering
value,
and
so
it's
not
an
mvc.
It's
just
a
step.
B
I
wonder
if
we
can
be
a
little
more
pay
a
little
closer
attention
to
when
we
start
seeing
those
as
flags
when
we're
just
delivering
code,
not
delivering
value
and
that
can
kind
of
help
us
reshift
our
focus
like
first,
we
need
like,
if
you
needed,
to
deliver
value
in
the
next
milestone
towards
that.
How
would
we
do
it
and
maybe
identify
that
earlier?
We
got
there
just
like
you
would
address,
but
I'm
kind
of
saying
we
could
get
there
earlier.
B
A
A
A
Maybe
there's
something
else
there.
That's
like
sometimes
we're
gonna.
We
may
need
to
deliver
things
that
may
not
necessarily
deliver
user
value,
but
that
they
could
still
be
useful.
But
when
we're
when
we're
in
that
mode,
that
should
be
a
flag
for
both
of
us
to
say,
like
we're,
not
delivering
value,
and
we
may
not
deliver
value
the
next
month.
This
may
take
three
milestones:
okay.
Well,
then,
we
got
to
think
about
the
skateboard.
A
We
got
to
think
about
what
we
could
do
first
as
an
mvc,
and
that
could
be
the
the
warning
that
prompts
us
instead
of
it
being
what
happened
was
we
talked
through
like
how
we
were
going
to
build
it?
We
took
a
day
or
two,
and
then
we
came
up
with
a
more
iterative
approach.
I'm
trying
to
think
how
that
could
turn
into
a
handbook
update.
A
B
I
wonder
if
that's
actually,
you
sundered
that
quite
nicely
where
we
identify
it
as
a
flag,
daring
planning,
I'm
not
sure
where
this
would
fit
in
the
handbook,
particularly
but
something
to
say
is
if
we
are
delivering
something
in
a
milestone
that
doesn't
actually
directly
give
value
to
our
users.
That
would
be
using
the
feature
that
it's
a
flag
we
should
talk
about,
doesn't
necessarily
mean
it's
wrong
or
not
what
we
should
be
doing.
B
A
Think
it's
a
good
place
to
start
and
it's
you
know
just
adding
that
to
the
to
our
how
we
work
section
of
like
when
we
see
this
it's
a
flag
and
we
should
people
should
call
it
out
that,
are
it
could
be
you
or
me,
or
it
could
be
anyone
on
the
team
really
that's
true,
and
then
we
can.
We
could
iterate
from
there
like
once
we
see
like,
is
this
working
or
this?
Why
didn't?
If
it
didn't
catch,
something?
Why
didn't
it?
Then
we
could
improve
it
from
there.
I
like
that.
B
A
I
think
the
other
area
now
now
that
I'm
being
critical
is,
I
think
we
can
improve
on
how
we
work
cross
team
across
teams.
I
noticed
there's
room
for
improvement
on
and
we
had
this
was
this
came
up
in
our
retro
of
we
had
a
few
issues
that
we
were
dependent
on
another
team
for
and
we
didn't.
I
didn't-
do
a
good
job
of
creating
that
visibility
earlier
on.
B
B
That's
awesome.
I
know
we
couldn't
really
do
that
for
the
future
you're
describing
but
also
being
able
to
chime
in
or
bring
in
the
designers.
We
have
a
voice
in
the
strategy
and
prioritization
stuff
like
that.
So
if
we're
aware
of
cross-functional
things
earlier,
we
can
also
help
guide
and
talk
to
our
pms
about
making
things
priority.
So
that
would
be
how
it's
just
as
well
granted
this
the
example
you're
using
didn't
have
one
of
those,
because
this
was
a
database
interaction,
not
okay,
but.
A
We
have
another
example
coming
up,
though,
possibly
where
we'll
need
to
work
with
the
secure
and
defend
teams
on
the
dependency
firewall,
and
so
I
think,
roping
getting
the
keep
getting
the
pm
and
the
designer
included
in
the
process
earlier.
So
we
get
better.
Discussion
will
be
really
valuable
and
as
much
lead
time
as
possible
is
good
because
everybody's
busy-
and
we
all
have
our
own
things
going
on
for
sure.