►
From YouTube: Iteration Office Hours with CEO (Public Livestream)
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
B
Sure
this
is
iteration
office,
hours
and
I'm
here
to
listen
to
anybody
who
has
something
that
they'd
like
an
opinion
on
on
how
to
further
iterate
on
it,
namely
how
to
make
it
smaller.
Not
everything
I
say
will
be
useful,
but
it's
just
say
the
point,
because
iteration
is
the
hardest
thing.
I've
heard
multiple
examples
of
people
new
to
get
lap
that
had
to
hear
from
their
managers.
They
really
needed
to
go
faster
and
be
making
let
things
up
more.
B
C
C
So
still
it's
Bartek
here
I'd
like
to
ask
maybe
a
specific
example
to
help
better
understand
how
we
can
best
break
things
down.
If
we're
looking
at
developing
a
very
simple
table
of
user
information,
and
then
you
know,
when
we
look
at
this
sort
of
concept,
we've
got
a
number
of
things
that
we
then
add
to
it.
We
add
paging,
we
add
searching,
we
add
an
empty
state
as
an
example,
each
one
of
those
things
can
drive
the
product
forward.
B
A
D
D
Some
some
people
will
have
a
feature:
M
R
some
people
have
a
dot
and
then
they'll
have
a
separate
documentation,
M
R
and
there's
advantages
and
disadvantages
to
having
those
separate
and
having
them
together
and
I'm
trying
to
push
for
people
to
always
keep
it
together.
But
I've
heard
from
some
other
engineers
that
they
feel
that
could
slow
down
the
process
and
since
we're
trying
to
iterate
quickly,
I'm
just
wondering
if,
if
you
had
any
opinions
on
that
wow.
B
B
Any
change
we
made
to
get
live
has
to
meet
our
definition
of
them,
so
it
has
to
be
complete
and
tests
and
documentation
are
part
of
that.
So
you
should
not
ship
something.
Without
that,
iteration
doesn't
mean
ship
half
of
a
version.
It
means
ship
something
more
minimal
so
strip
down
on
the
functionality
like
ship,
less
functionality,
but
do
include
everything,
including
tests,
including
documentation.
D
In
this
case,
the
idea
is
that
within
one
release
the
documentation
will
be
done,
but
it
will
be
done
separately
in
two
parts
versus
contained
into
one
larger,
M
R.
So
that's
kind
of
the
disadvantage
is
that
you'll
have
a
bigger,
mr,
but
then
you'll
be
doing
it
together
versus
two
smaller
easier
to
manage
at
Mars,
but
that
would
that
would
have
two
different
people
responsible
for
merging
and
those
could
get
out
of
sync,
so
there's
kind
of
advantages
and
disadvantages.
But
oh.
B
Yeah,
that's
the
big
problem
like
why
there
are
two
people
responsible
for
merging
you're,
saying:
hey,
there's,
there's
a
person
who
has
to
approve
the
documentation
and
we
can't
wait
for
both
people
before
the
Ammar
gets
merged.
I
think
that's
then,
where
to
solve
it,
if
there's
a
different
quality
standard
for
Amar's
and
that
can
be
remedied
after
the
fact.
That's
fine,
so
I
think
there
should
be
documentation
in
the
original.
Mr
and
then,
if
there's
a
further
review,
let's
fix
it
later.
D
B
So
basically
do
compromise
a
bit
on
quality,
but
do
have
the
the
initial
outline
of
the
documentation
and
I
think
there's
always
for
documentation.
In
my
opinion,
frequently
the
developer
kind
of
has
a
stab
at
it,
and
they,
you
understand
everything
but
they're
so
close
that
there's
so
my
topic
that
it's
kind
of
hard
to
write
a
helicopter
view
documentation
have.
B
D
I'm
glad
that
you,
you
said
that,
because
that
I
actually
have
a
work-in-progress
issue
where
I've
been
trying
to
make
a
workflow
that
would
work
for
everyone
and
I
specifically
said
I,
believe
we
could
that
engineers
could
try
to
include
it
as
early
as
possible,
and
the
technical
writers
can
try
to
also
review
it
as
early
as
possible.
But
if
we
can't
get
to
it
or
we're
not
totally
finished
with
it,
we
shouldn't
be
allowed
to
block
NMR,
get
it
as
good
as
we
can
get
the
feature
merged
and
then
we'll
get
irate
afterwards.
D
B
It's
basically
that
the
feature
development
sets
the
pace
and
the
rest
of
the
teams
have
to
hold
on
to
to
that
pace
and,
if
they're
falling
behind,
that's
that's
on
them
and
they
might
have
to
like.
We
need
more
people,
we
deep
our
tooling
and
other
things,
but
we
cannot
stop
the
train.
So
the
train
doesn't
stop
I.
E
Was
wondering
if
that's
like
this
is
just
an
idea.
I'm,
just
kind
of
like
I
came
up
with
this
when
you're
talking
about
it.
What,
if
you
just
make
like
a
tag,
technical
writer
need
to
review
these
and
then
just
submit
it.
So
there's
like
a
minimal
documentation
that
said
mentioned,
but
then
there's
like
a
totally
need
to
be
relieved
it
to
something.
So
so
that's
kind
of
like
help
the
engineers
to
feel
like
okay,
I,
don't
need
to
make
this
perfect
just
need
to
get
something
written
and
then
making
something.
Yeah
I
know
baby.
D
B
You
ask
me
I'd
rename
our
technical
writing
team
to
our
technical
rewriting
team
I
think
they
should
never
write
the
initial
version
of
the
documentation
that
should
be
done
by
the
people
who
made
the
feature
and
they
should
continually
be
rewriting
stuff
to
make
it
easier
to
comprehend.
Understand
the
use
case.
The
value
and
everything
else.
B
E
E
B
So
I'll
tell
the
story,
and
we
should
probably
cut
this
video
up
to
have
that
story.
Next
to
that
statement,
so
I'll
try
to
tell
it
from
the
beginning,
so
at
gate
lab
we
learned
iteration
during
a
time
in
Y
Combinator
and
it's
a
very
specific
moment.
There's
a
group
conversation
or
a
group
session
at
Y
Combinator
every
two
weeks.
The
first
one
was
everyone
kind
of
saying
hey.
This
is
what
we're
gonna
do
the
next
two
weeks,
the
second
one
half
of
it
was
hey.
B
This
is
what
we
accomplished,
and
these
are
our
plans
for
the
next
two
weeks
and
we
fought
the
meeting.
I
thought
we
did
a
lot,
but
if
we
we
after
us
all
the
other
people
present
it
and
they
all
did
way
more
than
us
way
way
more
and
we
we
left
driving
back
and
we
said
to
each
other
look.
We
cannot
go
on
like
that.
Basically,
we
have
to
to
keep
up
with
the
rest.
B
We
have
to
take
our
Tremont
plan
and
put
it
in
two
weeks
and
accomplish
that
in
two
weeks
and
we're
like
that's
impossible
like
it's,
not
that
we're
slacking
off
like
we're
working
as
hard
as
we
can.
We
can't
work
longer
hours
or
anything
like
that,
but
we
discussed
as
a
group,
and
we
said
what
are
we
gonna
do
and
we
all
decide:
okay,
let's
just
try
to
ship
as
much
of
the
Tremont
plan
as
we
can
so
instead
of
saying
hey.
This
is
what
I
want
a
ship?
B
How
long
does
it
take
and
then
plan
for
that?
We're
just
gonna
say:
okay,
this
is
what
we
want
to
accomplish
in
the
next
two
weeks.
What
is
what
can
we
ship
of
that
for
everything
like
we
want
to
do
every
single
thing,
but
how
much
of
that
can
we
and
it
turned
out
that
for
a
lot
of
things
we
did
just
having
only
being
able
to
spend
one
or
two
days
at
it?
B
Would
you
still
be
able
to
ship
something
of
value,
maybe
only
like
half
of
the
value,
but
we
just
got
there
a
lot
quicker.
We
got
to
half
of
the
value
in
like
20%
of
the
time
or
sometimes
10%.
That's
where
the
value
of
it's
a
racing
game
from
we
were
able
to
go
much
faster
than
we
ever
thought
just
by
constraining
the
time
we
gave
ourselves
for
things
and
to
do
that.
She,
after
kind
of
relented,
relentlessly
cut
back
on
scope
and
features
and
sophistication.
E
B
Yeah
and
many
times
the
funny
thing
is
many
times
you,
your
ideas,
weren't
that
great
you
shipped
an
initial
thing
and
it
didn't
have
much
traction
and
you
just
yeah
better
ideas
for
the
next
two
weeks
or
you
double
down
on
things
you
never
fought
or
possible.
So
that's
the
the
great
thing
about
iteration.
It
allows
you
to
allocate
your
time
more
efficiently
because
you
can
take
smaller
steps
and
you
figure
out
where
you
stand
there
at
that
time.
E
B
We
came
back,
we
came
back
to
the
house
and
we
started
doing
that.
We
started
trying
to
ship
everything.
We
have
plans
for
the
next
couple
of
months
in
a
two
weeks
and
one
person
actually
stayed
behind
in
the
Netherlands
and
he's
like
what
has
gotten
into
all
of
you.
What
is
it
doing
to
you
that
we're
doing
we're
going
this
crazy
and
said
well,
this
is
then
it's
just
a
new
pace,
the
new
speed.
We
need
a
lot
and
I
think
we
still
have
a
lot.
E
C
Syd,
it's
bad,
sir
Kerrigan.
How
do
you
ensure
that,
when
working
in
an
iterative
fashion,
when
you're
breaking
things
down
into
the
smallest
item,
that
some
of
the
items
that
are
probably
probably
less
important,
don't
then
get
missed?
So
if
I've
got
a
particular
component
that
I've
broken
into
ten
items
and
my
highest
value
is
items
one
to
seven
and
then
the
last
three
inevitably
get
pushed
back
in
the
backlog
and
keep
getting
pulled
back
to
future
releases.
B
So
it's
a
good
thing
like
those
three
things
didn't
add
a
lot
of
value
and
it's
fine
that
they
don't
ship
and
if,
if
the
product
looks
bad
because
of
it,
maybe
the
wider
community
will
contribute
something.
Maybe
we
will
we
prioritize
them?
Because
we
hear
that
hey,
we
don't
have
a
great
product,
but
people
are
happy
with
your
lab,
so
I
think
it's
mostly
in
the
mind
of
the
creator
and
the
person
who
really
thought
about
it.
That
person
is
missing
it
and
then.
B
It
tends
to
be
like
the
hardest
thing
about.
Github
is
probably
keeping
complexity
down,
so
it's
actually
good
that
we
didn't
shoot.
Those
features,
that's
of
course,
unless
you
have
a
great
example,
I'd
love
to
dive
into
details,
but
I
see
it
as
a
feature
that
we
don't
ship
everything
that
you
could
think
of.
C
No
no
specific
example,
I
suppose,
if
I,
if
I
look
back
to
you
know
my
first
question
where
you
know:
if
you've
got
a
table
of
user
information
and
we
decide
that
paging
can
just
keep
waiting,
you
know
almost
feels
incomplete.
You
might
have
some
some
users
which
bring
back
a
lot
of
data
without
that
extra
piece
of
work,
because
we've
decided
that
other
things
become
more
important.
But
to
your
point,
I
think
you
know
we'll
get
to
a
situation
where,
if
it's
causing
enough
impact
to
customers
and
we'd
reprioritize
that
anyway,.
B
There's
a
more
painful
version
of
this
that
we
don't
practice,
but
someone
said
feature
requests
trackers
of
like
like
an
issue
tracker
for
what
features
people
want.
You
don't
need
to
do
that
because
if
it's
important
it
will
come
up
again.
I
don't
subscribe
to
that,
because
I
think
counting
the
up
votes
and
the
Salesforce.
The
links
and
issues
is
super
handy,
but
I
think
it's
a
funny
way
to
to
organize.