►
From YouTube: 2020 05 13 Memory Team Planning Discussion
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
A
What
issues
should
I
pull
in
and
I'd
like
to
shift
that
and
work
with
product
management
to
make
sure
we're
in
sync,
with
what's
the
most
important
things
that
we
should
be
working
on
and
the
engineers
on
this
team
are
closest
to
the
code
they're
closest
to
knowing
where
we
could
have
the
most
impact
on
memory
and
performance
improvements,
and
so
making
sure
that
you
all
feel
a
sense
of
ownership
on
where
we
can
have
the
most
impact
in
driving
those
initiatives
forward.
Lots
of
good
suggestions
in
here,
if
you
haven't,
read
it
so
Matias.
B
Yes,
because
this
is
more
about
like
how
do
you
execute
on
a
proposal,
but
the
proposal
the
way
it
work
it
somehow
any
way
it
would
still
come
from
I
mean,
except
maybe
if
it
was
like
a
super
technical
thing.
I
didn't
remember.
I
was
like
this
big
problem.
We
had
with
our
Cassandra
cluster
that
would
like
constantly
fall
over,
and
then
this
is
not
something
that's
probably
initiated.
B
So
this
was
like
a
bigger
like
a
multi-month
thing
that
engineers
would
do,
but
it
I
would
say
that
was
the
exception,
so
so
so
maybe
I'm
getting
ahead
of
the
agenda
here,
but
because
it's
making
more
for
how.
But
the
key
idea
is
that
that
it's
not
the
PM's
Orient,
even
who
are
responsible
for
like
doing
things
like
storing
breakdowns
and
specifically
not
like
what
are
the
individual
action
items
even
down
to
a
Mars
may
be
that
mean
to
be
basically
stuff
that
end
up
on
the
back
on
the
board
right.
C
B
B
The
KPI
is
attached
to
this,
because
this
is
like
why
we
think
this
might
you
know,
move
the
needle,
but
like
kind
of
almost
like
bullet
points,
you
know
like
we
really
brought,
and
then
this
would
be
quickly
discussed
with
the
whole
team
and
then
engineers
would
take
over
from
there,
and
so
that,
like
we
would
still
be
able
to
work
on
things
in
parallel.
We
would
typically
have
only
like
up
to
two
people.
You
want
to
have
more
than
one
because
bus
effect
on
everything
you
know:
I'm
knowledge.
C
B
B
A
B
About
estimation-
and
all
estimation
was
a
very
small
component,
even
like
I-
think
it's
headed
here,
like
we
wouldn't
most
to
t-shirt
sizing.
Sometimes
we
didn't
estimate
at
all
because
we
would
more
decide
based
on.
Is
this
like
valuable
from
a
business
perspective
rather
than
because
I
mean
two
things,
so
we
had
like
one
heart
requirement,
which
was
if
it
takes
more
than
three
months,
we're
not
gonna
do
it.
There
was
like
one
hot
requirement:
we
had
from
xx.
The
rest
was
pretty
much
kind
of
open
to
us.
So
if
we.
B
A
not
gonna
be
people
being
for
a
quarter
or
whatever,
but
yeah.
So
it's
not
about
estimation,
it's
more
about
like
breaking
down
the
work
and
also
identifying
because
that's
easier
for
engineers,
because
they're
deeper
in
the
code
base
as
well,
it's
easier
for
them
to
see.
Okay
like
we
might
have
to
touch
this
in
this
part
of
the
code
base,
but
that's
a
really
smelly
area.
So
maybe
we
should
do
it.
This
is
that
way.
Oh
that's
might
add
a
week
of,
like
you
know,
paying
off
TechNet
and
whatnot.
So.
A
B
A
B
Definitely
didn't
mean
to
say
we're
not
doing
it
at
all.
It's
just
like,
maybe
even
just
like
formalizing
it
a
little
bit
more
might
just
be
helpful
so
that
we
understand
like
we
would
actually
have.
We
had
like
a
quarterly
I
mean
we
use
Google
Docs
a
lot.
We
can
use
a
good
level
issue
whatever
like.
We
would
have
a
quarterly
overview
that
we
regularly
checked
in
on
where
all
these
epics
I
guess
it
would
be
here.
B
A
E
E
Yeah
I
mean
my
main
point
is
to
make
like
proper
decision
on
the
engineering
side.
We
need
to
get
our
metrics
raising.
This
is
not
Northstar
metrics
or
like
whatever
we
prefer
to
use
to
measure
our
team
performance,
because
for
now,
as
I
understand,
we
don't
have
heard
set
and
it
would
allow
us
to
to
make
right
decision
without
overthinking,
PMS
or
EMS.
A
E
Mean
is
it
the
only
measurement
of
poverty
like
the
one,
and
only
or
we
should
have
some
extended
metrics,
which
would
also
include
like
some
known
just
because
most
Northstar
metrics
is
about
moving
right
and,
as
stated,
we
are
working
on
performance
as
well,
so
it
doesn't
include
basically
both
memory.
It.
D
E
C
D
Of
money
we
spend
on
get
lab,
comm
were
actually
have
a
number
of
activities
going
at
right
now,
I
try
and
do
that.
So,
to
give
you
some
context,
we
were
spending
projected
to
spend
I
think
18
million
dollars
on
it
for
users
this
this
this
year,
which
is
which
is
which
is
too
much
it's
it's
more
than
the
money.
We're
gonna
get
back
out
from
paid
users,
so
we're
taking
a
number
of
urgent
actions
to
try
to
reduce
that
cost.
So
Gil
accom
is
has
more
of
a
a
better
business
model
behind
it.
B
I
think
this
whole,
like
unplaned
work,
is,
is
really
high.
I,
don't
know
if
it's
useful
to
have
a
KPI
for
this
right,
because
it's
by
definition
unknown,
it's
unplanned
work
right.
So
you
don't
you
don't
really
know
you
know
next
month,
something
else.
So
is
it
maybe
better
which
we
did
more
like
you
know.
We
treat
like
that,
for
instance,
where
we
say
we
should
just
spend
like
X
percent
of
our
time
each
month
or
so
on.
Working
on
these
things
and
just
kind
of
like
you
know,
cut
ourselves
some
time.
B
A
Don't
know
that
we
need
to
get
that
for
lack
of
a
better
term
prescriptive
or
focused
on,
like
the
percentage
balance
cuz
in
my
history.
That
typically
becomes
an
argument
point
like
well:
we
spent
30
percent
on
X,
and
now
we
need
to
spend
a
lot
of
time
on
y
so
and
to
answer
another
question.
Alexi
kind
of
asks
is
that
the
only
way
we
measure
I
think
you
remember,
the
exact
wording
said
that
our
only
measurement
of
success
know
like
throughput,
are
still
important.
A
The
performance
impact
that
we
saw
that
we
have
are
so
important,
they're,
just
different
levels
that
we
look
at
how
successful
or
productive
we
are
as
a
team
so
that
that's
northstar
metric
couldn't
get
any
higher
right.
That's
that's
why
it's
called
the
Northstar
metric.
That's
the
long
term
goals
for
the
team.
Does
that
answer
your
question:
Alexi
mmm-hmm.
D
The
PM's
and
get
labs
are
the
directly
responsible,
individual,
the
DRI
for
prioritizing
work,
so
that
so
they
are
the
sole
owner
and
the
person
who
is
responsible
for
why
work
and
the
things
that
were
working
on
that
that
way,
there's
a
clear
owner
of
who
does
that,
but
that
doesn't
mean
that
they're
happy
and
put
their
camping
idea.
Is
it
can't
be?
You
know,
strong
suggestions
from
engineering.
As
far
as
you
know,
we
think
we
should
work
on
this
because
it
will
have
a
high
impact
just
that
the
end
of
the
day.
D
You
know,
if
there's
questions
about,
why
we're
doing
the
things
that
we're
doing
those
questions
go
to
the
p.m.
to
respond
as
to
why
so
that
that's
the
current
model
of
gitlab
but
I
do
want
to
stress
that,
even
though
it
that
sounds
like
a
big
job,
it's
or
that
a
lot
of
responsibility
or
I
would
say
control
its
is
in
the
PMT
and
estates.
It's
really
just
that
they
haven't
that's
a
single
person
responsible
and
I
had
hope
and
really.
E
D
F
This
male
improvements,
but
sometimes
it's
like
doing
like
the
bigger
story,
so
maybe
doing
proof
of
concept
prototype,
would
better
answer
us
like
how
much
effort
we
have
to
invest
to
get
a
result
out
of
it
because,
like
import-export,
it
was
very
intriguing
problem.
We
discover
it.
A
lot
was
it
like
something
it
like.
We
could
understand
ahead
of
the
time.
F
I
have
no
idea,
but,
like
some
of
the
aspects,
type
I
created,
have
a
ton
of
issues
like
I,
create
a
ton
of
different
random
issues
about
random
stuff,
but
sometimes
it
just
doesn't
make
sense.
It's
just
like
I
had
a
hunch
that,
like
it
seems
something
that
is
gonna,
be
beneficial
like
trying
to
validate
these
issues
like
this,
the
fastest
in
the
fastest
possible
way
to
understand
their
impact,
could
be
kind
of
key
to
being
effective
and
focusing
on
basically
growing
from
kind
of
selfish
perspective
on
time.
F
Spans
first
shows
the
impact
of
the
changes
because,
like
there
are
so
many
things
to
fix
up
details,
right,
I
could
get
a
heart
and
give
you
probably
like
100
of
the
different
things
like.
If
you
go
to
any
channel,
probably
gonna
see
a
number
of
them
p.m.
also
have
like
a
lot
of
ideas.
Everyone
has
ideas
once
you
start
working
with
it,
how
to
quickly
figure
out
the
one
which
are
more
important
than
other
how
to
validate
effort
to
require
it.
I.
B
Think
the
thing
is
a
really
really
sensible
thing
to
say,
but
also
one
thing
you
have
to
keep
in
mind
is
that
maybe
I'm
just
speaking
for
myself,
but
it
will
probably
take
me
ten
times
as
long
as
it
takes
you
to
prototype,
something
to
the
extent
that
I
can
say.
Okay
well,
I
believe
this
is
something
we
should
pick
up
now
and
then
and
then
you
shouldn't
make
the
decision.
Every
day
you
know,
am
I,
just
gonna
basically
go
rogue
for
a
couple
of
days.
B
You
know
work
on
this
random
thing
that
I
have
an
idea,
but
that
wasn't
really
in
the
planning
backlog.
So
if
there's
something
we
want
to
do
I'm
definitely
before,
but
I
think
I
think
right
now,
I
would
hesitate
to
do
it
because
I,
it's
still
hard,
sometimes
to
say
upfront
how
much
time
I
will
have
to
spend
on
it
and
I
I
would
feel
like
I
would
have
to
justify
it
somehow.
You
know,
because
I
wouldn't
be
working
on
things
if
we
had
a
breed
I'm
working
on
the
planning.
F
What
is
deficient,
if
may
take
any
shiny
more
time,
but
the
more
I
think
I'm
thinking
like
for
us
to
be
successful
and,
in
fact,
if
like,
we
need
to
touch
as
many
broad
items
as
possible
to
understand
like
the
patterns
within
application
and
in
order
to
achieve
that,
at
least
from
my
perspective
like
to
work
and
fix,
is
items
or
like
try
to
like
prototype
and
understand
different
divisions.
It's
like
tisha
is
always
begun.
It's
hard
like
if
you
start
something
new,
it's
hard,
but
maybe
over
time,
alright.
F
C
F
F
A
Thank
you
for
all
the
feedback.
I
think
so.
My
goal
for
this
was
to
make
sure
that
it's
explicit,
that
we
all
understand
that
we
are
very
much
owners
of
the
backlog
and
breaking
it
down
and
making
sure
it's
understandable,
actionable
and
we
can
move
forward
on
it.
I
think
seems
like
we're
all
in
agreement
there
and
we're
starting
to
jump
into
the
how
how
we
can
do
this.
So,
let's
move
on
to
the
Howell
portion
of
it
lots
of
good
suggestions,
so
I
focused
I,
was
probably
too
specific
on
this.
A
It
probably
should
have
just
said
planning
but
I
focused
on
the
planning
issue.
There's
a
lot
of
really
good
feedback
on
the
usefulness
or
lack
thereof,
of
the
planning
issue
and
participation
levels.
I
tried
to
summarize
down
here.
I
know:
I'm,
sorry
that
was
the
meetings
so
planning
issue.
The
general
feedback
was
lack
of
participation.
It
gets
stale,
it
doesn't
always
match
what
we're
working
on
in
the
milestone,
which
is
fine
if
I'm
answering
that
specific
question
the
planning.
A
So,
for
me,
the
planning
issue
when
Josh
and
I
are
looking
at
is
we're
trying
to
align
the
next
milestone
right
and
often
things
like
CI
minutes
or
like
important,
was
kind
of
a
rapid
action
thing.
They
came
in
and
kind
of
shuffled
what
we
were
working
on
for
the
current
and
subsequent
milestones.
So
to
me,
it's
completely
okay,
that
we
planned
something
and
then
it
changes
at
the
last
minute.
So,
yes,
they
she
was
gonna
get
stale.
My
concern
is
not
a
lot
of
collaboration.
It's
happened
in
the
past.
A
It's
typically
been
kind
of
a
one-way,
Josh
and
I
putting
in
issues
in
there
and
then
getting
feedback
from
the
team
which
I
work
on
next.
So
I
would
like
it
to
be
more
collaborative
I
know
there
was
a
suggestion
in
there
to
use
a
Google
Doc
to
be
more
collaborative,
my
concern
about
Google
Docs,
and
it's
in
the
handbook
right
using
issues
for
discussions,
because
more
visible
is
more
searchable
to
Lexi's
point
you
get
pings
on
it
when
there's
updates
and
yeah.
Those
are
my
thoughts
on
the
planning
issue.
A
B
Sorry
I'm
the
Google
Ducks
thing
because
I
came
from
me
like
I
I.
Think
I
just
wear
that
well,
I,
didn't
I,
don't
think
Google
Docs
is
a
better
tool
for
like
writing.
Something
on
this
I
think
as
long
as
we're
clear
on
I'm
all
for
doing
this
on
get
laughs,
but
maybe
I
think
that
my
main
point
was
there
was
no
clear
it.
C
B
Weren't
really
aligned
anymore,
so
maybe
what
we
can
do
is
we
can
still
have
the
planning
issue,
but
once
we
have
a
defined
backlog,
we
close
it
out
because
otherwise
I
think
it's
just
confusing
to
have
like
two
sources
of
truth
and
I
guess.
The
reason
I
mention
Google
Doc
is
because
we
say
we
deprecate
the
Google
Docs
when
we
like
you,
start
out
with
the
Google
I,
think
that
is
actually
in
the
handbook
somewhere.
You
can.
B
A
A
A
A
E
A
All
right,
no
and
I
have
a
hard
stop
at
6:50
all
right
on
to
meetings
and
how
we
can
improve
them.
I
think
so
lots
of
good
feedback
here
and
in
as
well.
Thank
you
so
suggestions,
moving
company
updates
to
a
sink
so
a
couple
thoughts
there.
We
do
have
the
section
in
the
dock,
so
we
can
just
skip
over
that
and
not
even
verbalize
it
at
all.
So
we're
not
using
time
on
that
or
I've
seen
other
teams.
They
just
have
a
within
slack
they'll.
A
A
It
seemed
like
the
preference
and
all
the
feedback
there
was
to
focus
on
walk-in
the
wall
and
timeboxing
and
making
sure
that
we're
spending
some
good
quality
time
they're
also
reviewing
unassigned.
It
seems
to
have
gotten
some
good
feedback
I,
like
Camille's
suggestion
I'm
having
like
a
monthly
recap
of
closed
items
and
my
suggestion
there
may
be
unreleased
day
what
people
think
about
that
to
celebrate
enclosed
items,
not
doing
it
during
the
key
meeting,
because
we're
already
cramped
for
time
on
that.
One.
A
E
E
B
E
Because,
from
my
perspective,
I
would
rather
like
to
hear
not
from
ticket
to
ticket,
but
from
person
to
person
to
hear
most
important
like
stop,
for
example
like
Alex
I'm
working
on
this
milestone.
It's
in
this
state
possible
challenges
like
this
and
not
like
go
through
my
mini
tickets,
I
created
to
like
handle
every
small
aspect
of
my
epic
because,
like
nobody
is
so
deep
down
in
the
story,
so
I
mean
I.
F
E
Ok,
yeah
and
I
think
yeah
I
mean
if
you
would
have
more
structured
epics.
After
what
materials
mentioned
like
this
point
pairs,
maybe
we
could
go
through
point
pairs
and
they
will
quickly
like
give
some
update
on
progress.
So
it's
a
particular
epoch
on
the
high
respect
for
everyone
would
feel
like
more
involved
than
probably.
You
would
not
understand,
like
small
details
about
my
issue,
fixing
some
specs,
because
it's
not
that
interesting
to
you.
I.
B
Think
it
sounds
good
I,
so
I
think
we
might
have
to
extend
the
meeting
then,
because
we're
like
six
people
or
so
so,
even
if
everyone
takes
five
minutes,
that's
already
posting
a
25
minute
time
frame.
So
yeah,
that's
my
only
concern
it
will
be,
it
will
be
longer,
but
we
can
try
it
and
we
should
then
definitely
be
okay.
Maybe
five
minutes
is
way
too
long.
Anyway.
Maybe
everyone
should
only
get
like
two
minutes.
B
E
B
B
Of
stand-up
format,
where
that
I
know
from
stand-ups
where
you
do
not
even
look
at
the
board,
but
you
just
go
around
in
a
circle.
Everyone
says:
oh
yesterday,
I
work
on
X
and
today
I
want
to
work
on
X
so
because
that's
usually
when
people
go
into
extreme
detail,
that
is
completely
not
interesting
to
the
other
people
in
the
circle,
and
that
is
also
something
that
is
I,
think
better
done.
Asynchronously,
also,
maybe
a
flight
blockers
with
something.
E
A
A
C
A
A
Thank
you
all
right
planning,
so
we
haven't
actually
gotten
to
any
planning.
This
we've
mostly
focused
on
how
we
function
as
a
team
and
I'm
sure
we
didn't
cover
everything.
So
then
we
only
have
a
limited
time
here.
So
if
there's
anything
we
didn't
cover,
let's
talk
about
asynchronous
a.
We
can
keep
adding
it
to
this
so
planning.
A
The
suggestion
was
out
there
that
we
have
more-
and
this
came
from
me,
more
synchronous
planning
discussions.
I
think
it
would
be
helpful
to
me.
That's
not
helpful
to
anybody
else.
Then,
let's
not
do
it
and
yes
to
matthias
question
when
you
first
joined
thought
Monday
meeting
was
the
planning
meeting.
It's
it's
not
intended
to
be
it's
more
of
an
update
on
what's
going
on
in
the
milestone.
What
folks
are
working
on?
Do
they
need
me
help?
A
Do
they
need
clarity
on
what
they're
working
on
next
so
Josh
and
I
have
largely
been
doing
the
planning
through
the
issue
and
talking
together
and
trying
to
get
feedback
from
folks,
but
with
the
explicit
agreement
that
this
team
is
owning,
defining
the
epics
breaking
them
down
and
making
sure
they're
actionable
just
trying
to
figure
out
how
we
can
get
together
and
make
sure
it's
happening
in
a
productive
way.
So
if
it's
not
synchronous
meetings,
how
do
we
want
to
do
this,
and
this
might
take
longer
than
the
12
minutes
that
we
have
left?
A
But
again
we
can
do
it
asynchronously.
So
any
ideas
on
how
we
can
start
planning
start
discussing
planning
for
the
next
milestone
and
make
sure
we
have
a
clear
picture
and
it's
prioritized
and
everybody
understands
like
if
we're
doing
the
point
pairs
or
who
is
responsible
for
what
and
how
we
actually
start
breaking
down
issues
and
epics.
A
C
B
B
It's
just
that
in
my
past
experience
like
these
meetings,
where
you
have
a
lot
of
people
in
the
room
and
talk
about
like
five
different
things,
just
because
it's
the
planning
meeting,
everyone
I
find
them
to
be
not
effective
and
there's
often
like
people,
zoning
out
and
because
I
know,
I'm
not
gonna
work
on
this
anyway
or
they
just
maybe
not
have
a
particular,
and
you
know
that
one
or
whatever.
So
so,
that's
why
I
prefer
this
like
working.
B
These
well-defined
lanes
like
where,
let's
say,
community
new
work
together
on
or
like
like
now
continue
and
I.
We
just
picked
up
this
telemetry
stuff
right,
but
some
stories
don't
still
need
to
be
groomed.
So
what
I
would
prefer
is
that
chin
you
and
I?
We
try
to
breath
our
head
around
this
thing:
try
to
groom
all
the
tickets
and
and
then
we
go
back
to
the
team
with
a
more
specific
proposal
for
how
to
do
this,
and
then
we
can
more
like
ask.
Is
anyone
interested
in,
like
you
know,
giving
feedback
to
this?
B
You
know
locally,
here's
our
suggestion.
What
do
you
think
about
it?
Do
you
have
like
points
around
the
step?
You
know
you
want
to
point
out
that
doesn't
make
sense
all
we
should
be
doing
differently
or
does
anyone
else
want
to?
You
know
pick
this
up
and
work
on
them
right,
so
so
more
like
yeah,
not
this
like
and
everyone
in
the
room
and
then
talk
about
it.
Five
different
things
but
like
here
other
things
we
work
on
and
then
we
have
dris
and
they
kind
of
drive
this
and
they
get
other
people's
feedback.
B
Whether
that's
asynchronously
or
synchronous,
I
think
can
be
decided
on
a
per
like
individual
basis,
because
sometimes
it
might
be
good
enough
for
people
to
just
you
know
you
feedback
an
issue,
and
sometimes,
if
it
gets
like
to
back
and
forth,
then
we
can
always
like
that.
It's
like
these
standing
meetings
I
would
like
to
keep
them
to
a
minimum.
To
be
honest,
agree.
A
Yep
yeah
and
in
the
way
to
avoid
that
unnecessary
folks
in
synchronous
meetings,
I've
done
it
in
the
past,
is
you
have
an
agenda
right
now?
If
you're,
not
part
of
the
agenda,
you
don't
show
up,
but
it
seems
like
I
was
the
only
one
that
thought
this
would
be
a
good
idea.
So
let's
not
do
it
and
figure
out
how
we
assign
the
dris
and
I
like
that
term
for
the
ethics
and
initiatives.
So
it's
not.
A
You
know
one
or
the
other
one
single
person
or
point
pairs,
but
DRI
is
for
the
initiatives
and
then
they
can
figure
out
how
to
further
break
it
down
and
how
to
get
the
rest
of
the
team
involved
instead
of
just
having
a
prescriptive
methodology.
If
we
need
every
Wednesday
to
talk
about
these
things,
so
let's
get
suggestion
anything
else
to
cover
here.
F
A
So
the
weekly
cadence
is
something
I've
done
with
other
teams
in
the
past,
rather
than
because
milestones
a
long
time
right
a
month.
You
can
lose
focus
on
the
goals.
It
didn't
agree
with
the
Matthias
comment:
I
guess
it's
been
difficult
with
teams
in
the
past
and
I
can't
remember
who
said
it
was
crazy,
but
trying
to
say
I
wasn't
trying
to
set
like
a
high
level
goals
more
of
like
okay
on
import,
I'm
gonna,
try
to
finish
X
by
the
end
the
week
and
we've
already
talked
about
how
we're
gonna
do
the
Monday
meeting.
A
A
This
came
from
the
Mattia
suggestion
about
how
many
days
are
left
in
the
milestones,
so
just
trying
to
figure
out
when
we
need
to
do
these
things
on
a
regular
basis,
so
creating
the
next
milestone
planning
issue.
I
can
like
this
doc
in
if
it's
helpful
or
y'all
can
just
throw
some
dishes
in
here
and
release
clothes
items.
A
week
before,
or
one
thing
we
haven't
done
on
a
regular
basis
is
reviewing
okay
hours.
It's
something
we
need
to
do.
A
A
So
we
have
five
minutes
left
I,
don't
think
you
can
get
too
much
of
the
roadmap,
but
there
is
a
roadmap
doc
they
put
down
here,
and
it's
right
here
take
a
look,
and
we
can
talk
about
that
asynchronously,
but
with
the
five
minutes
that
I
have
left,
are
there
any
other
topics
like
just
how
we
function
as
a
team?
How
anything
that
people
want
to
throw
out
that
we
can
talk
about
quickly
or
even
talk
about
asynchronously.
B
B
E
C
D
B
B
D
Just
in
the
topic
of
the
program
flight
I'm
happy
that
I
should
do
a
better
job
of
moving
them
through
the
validation
pages
culmination
would
be
a
bit
stranger
since
we're
not,
as
customer
focused
as
and
we're
not
trying
to
build
the
next
new
thing.
Our
customers
need
to
need
to
need
it
need,
but
solution,
validation
and
their
on
would
definitely
be
applicable.
I'm
bait
folks.
Well,
if
you're,
all
for
it,
I'm
totally
happy
to
statists,
are
putting
more
issues
up
at
front
and
working
through
the
process.