►
From YouTube: Geo Admin UI Project Call
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
Hello
everyone:
this
is
the
the
Geo
team
now
joined
by
our
new
product
designer
cinching,
and
today
we're
going
to
spend
an
hour
talking
about
the
user,
interface
and
user
experience
in
geo.
If
you
are
a
systems
administrator,
it
is
time
to
rejoice
because
obviously
going
to
solve
all
of
your
problems
within
the
next
hour.
So
that's
what
we're
going
to
do?
I
have
to
do
this
now.
It's
traditional.
B
B
There
deliberately
isn't
anything
on
the
agenda,
because
I
wanted
this
to
try
and
be
a
bit
of
an
open-ended
discussion,
but
the
main
goal
that
I'm
trying
to
get
from
having
us
all
on
the
call
together
is
just
to
understand
how
we
will
all
work
together
because
having
a
product
designer
is,
is
new,
Fujio
and
I
just
want
to
figure
out
just
the
expectations
between
us
of
who's,
who
is
responsible
for
which
piece
how
that
works?
What
they'd
look
like
looks
like
and,
most
importantly,
how
we
turn
ideas
into
things
that
we
ship.
B
C
A
D
A
Yeah,
okay,
I
mean
I
can
start
because
I
obviously
have
expectations
so
the
way
I.
Imagine
this
going
forward,
and
maybe
I
start
with
some
history.
First
geo
as
a
product
has
I
would
say,
is
quite
back
and
heavy
a
lot
of
the
work
that
the
engineering
team
has
been
busy
with
happens,
sort
of
at
the
back
end.
So
sometimes
those
are
like
we,
for
example.
Now
there
are
performance
related
optimizing,
some
queries.
A
Often
there
are
a
lot
about
adding
or
improving
to
existing
functionality
and
the
way
they
that
has
worked
out
I
think
in
the
last
month
is
we,
we
add
new
features
or
we
iterate
on
top
of
other
features,
but
the
the
user
or
the
UI
changes
are
not
necessarily
sort
of
top
of
mind
right.
We
we
have
some
some
patterns
in
the
Geo
interface,
that
you
can
sort
of
copy
right
and
iterate
very
quickly,
or
you
know,
like
our
our
engineers,
are
able
to
add
some
sort
of
small
things
to
the
UI
as
well.
A
I
think
many
of
the
engineers
actually
are
quite
capable
in
that
regard,
which
is
cool,
but
now
the
game
is
kind
of
changing
a
little
bit
because
zach
is
around
and
he
is
able
to
I
think
create
a
lot
of
like
functionality
on
the
front
end
and
I
saw
it
like
I
actually
was
quite
impressed.
I
I
saw
the
merge
requests
for,
for
example,
design
repositories
that
he's
working
on
right
and
he's
moving
I.
Think
quite
of
the
code
to
do,
which
is
all
front-end
framework
yeah.
D
A
C
A
Case
all
of
the
things
I
said
mean
that
we
have
no
user-facing
work
to
do
right,
actually,
I
think
they
have
a
lot
of
work
to
do
and
yeah
and
I
think
now.
I
think
that
the
task
for
us
really
is
look
at
my
perspective
is
okay,
we
have
maybe
not
every
feature
will
necessarily
have
a
UI
component.
That's
fine
right,
most
features,
they'll
have
some
user
experience
unless
they're
really
completely
like
and
facing
I.
A
What
are
the
expectations
they
have
and
they
perform
all
the
tasks
that
they
want
to
write
and
if
not,
how
can
we
enable
them,
and
those
are
the
discussions
I'm
looking
forward
to
having
and
I
have
some
examples
actually
prepared
to
give
you
sort
of
a
flavour
of
like
some
of
the
problems
we
have
right
now
and
that
I
think
we
use
your
tackle
so
yeah.
That's
me.
B
It
allows
us
to
see
certain
information
and
not
everything,
and
it
allows
us
to
do
certain
processes,
but
not
all,
and
it
feels
like
it's
something
that
has
been
iterated
over
to
get
to
where
we
are.
But
we
haven't
had
the
opportunity
to
step
back
and
say
what
do
we
actually
want
to
achieve
from
this?
And
what
is
it
supposed
to
do
as
a
whole
product,
not
just
as
a
set
of
functionality?
That's
been
built
over
time
and
I.
Think
that's
where
it's
really
valuable.
E
B
A
B
B
But
I
was
wondering
if
you
have
certain
practices
that
work
for
you
that
you
are
bringing
within
your
experience
here
that
have
worked
well
for
you
in
the
past
in
terms
of
how
to
deal
with
engineering
teams
or
how
to
work
with
product
managers
to
realize
what
what
the
products
and
features
should
look
like.
If
there's
certain
things
that
you
want
to
still
be
doing
in
this
role,
yeah.
D
Sure
I
think
it
depends
on
the
products
characteristic
and
creams,
of
course,
but
like
thankfully,
my
previous
experience
was
always
surrounded
by
like
tones
of
developers
so
very
used
to
that
development.
Very
and
personally,
I
like
developer
and
talking
to
them,
because
it's
always
fun
so
I
don't
have
any
problem
with
that.
But
the.
But
the
thing
is
like
I,
have
look
into
the
product,
I
mean
not
in
the
very
detail
level
yet-
and
this
is
my
first
time,
while
working
fully
remotely
so
I
think
there
will
be
some
challenge
in
the
near
future.
D
My
personal
opinion
I
really
love
to
get
the
feedback
from
all
the
team,
so
not
just
from
the
designer
I
would
say.
This
is
very
important
for
me
to
improve
the
quality
of
the
design
and
also
improving
the
user
experience
itself,
because
this
type
of
product,
of
course
I,
will
take
into
more
detail
about
the
technical
things,
but
still
I'm,
not
a
developer,
so
my
knowledge
will
be
not
yet
there
so
I
would
love
to
listen
to
others
feedback,
especially
for
from
the
developer
and,
of
course,
from
p.m.
D
like
this
is
kind
of
like
daily
activity.
So
sorry
for
when
I
will
ping
you
a
lot
if
I
start
using
sketch
or
whatever
real
design
workflow,
but
that's
the
reason
why
I
prefer
to
have
some
design
review
within
the
team
so
sometimes
include
the
designers
in
other
team,
but
that
I
would
say
it's
kind
of
more
similar
to
design
critic.
So
this
is
our
review.
Also.
D
This
is
a
scattering
feedback
from
the
developers
and
the
PM
and
the
other
as
related
people,
giving
me
the
feedback,
but
yeah
I
can
set
up
a
ground
rule
like
because
this
is
how
I
prefer
to
improving
my
design.
So
I
would
love
to
have
that
desire
review
session
if
this
is
doable.
But
my
question
is
like
if
I
want
to
conduct
this
design
review
session,
like
do,
I
have
to
make
a
synchronous
or
to
have
to
set
a
certain
time
and
okay.
D
B
Sorry,
my
husband
works
in
the
same
study
as
me.
What
I
would
say
is
that
it
sounds
like
the
design
review
is
a
process
where
you're
going
to
be.
You
need
to
get
feedback
from
a
quite
a
number
of
people
and
the
way
that
the
Geo
team
is
is
located
across
the
globe.
It
may
be
more
beneficial
to
do
that,
either
with
one-on-one
sessions
with
individual
people
or
to
post
something
up
on
a
discussion
issue
where
you
gather
where
you
gather
feedback
that
way
in
an
asynchronous
way.
B
That
can
be
quite
an
adjustment
when
you're
not
used
to
doing
it
asynchronously,
but
it
is
absolutely
worth
the
effort,
because
I
think
that
you
get
quite
a
lot
of
benefit
from
the
asynchronous
process.
I
think
people
are
given
the
opportunity
to
sit
back
and
think
about
what
they're
observing
or
what
they
have
read.
They
go
away
and
think
about
it.
Have
a
sandwich
have
a
cup
of
tea
and
then
they
come
back
and
they
provide
really
valuable
comments
on
what
they
have
seen.
B
Sometimes
there
can
be
more
valuable
than
what
comes
out
off
the
top
of
someone's
head
in
in
a
one-to-one
synchronous
meeting,
and
we
have
a
number
of
examples
like
that.
Let
me
get
a
link
where
someone
will
propose
an
idea,
put
it
up
for
discussion
in
a
particular
project,
and
then
we
go
back
and
discuss
what
has
happened,
although
come
to
think
of
it.
Now
that
discussion
project
is
really
for
someone
who
meta
things
about
how
the
team
works
or
how
the
team
operates.
B
This
is
what
I'm
looking
at
this
is
how
the
pieces
like
this
is
how
the
pieces
fit
together
in
your
mind
and
an
ask
for
feedback
that
way
and
then
paying
specific
people
depending
on
who
you
need
to
feedback
from,
and
also
that
way,
it's
readable
after
the
fact
by
anyone
who's
interested
in
it,
and
even
though
we
record
everything
and
put
it
up
on
YouTube,
sometimes
it's
difficult
to
consume
hours
and
hours
of
of
material
prayers.
A
written
discussion
might
be
valuable
that
I'd,
encourage
you
to
experiment
and
see
what
works
for
you.
A
This
is
I,
think
something
that
we
will
like
have
to
have
to
balance
a
little
bit
when
we
make
changes
to
the
to
the
UI,
because
it
sometimes
too
may
be
enough
if
you've
heard
from
from
Zach
right
and
you've
heard
from
a
customer
when
you're
like
okay,
you
know
we
can
probably
move
forward
with
this,
because
I
feel
confident
in
this
change.
If
it
is
sort
of
a
three
months
operation
right,
then
we
lose
a
lot
of
velocity
in
the
in
the
process.
Right
and
I.
A
Think
that's,
that's
always
the
the
challenge
right
I,
like
I,
would
like
that.
That's
awesome
is
my
challenge
right,
because
I
would
like
to
have
tons
of
validation
right
and
but
that's
not
feasible
right.
So
we
need
to
I.
Have
a
light
touch.
Sometimes
you
know,
but
sometimes
maybe
it'll
possibly
require
is
like
thinking
very
carefully
about
it.
That
depends
a
little
bit.
E
E
This
in
general
would
be
nice
for
kind
of
how
we
have
like
that
retrospective
area,
or
we
can
just
drop
notes
in
I,
think
that
might
be
something
we
can
do
with
part
of
design
to
where
we
have
places
that
maybe
as
we're
working
through,
we
notice
things
maybe
are
like,
for
instance,
with
the
customer
and
the
notes
about
the
how
the
secondary
UI
is
kind
of
useless
from
their
opinion.
I
might
be
good
place
to
be
tracked.
Those
sort
of
comments
so
that
sort
of
feedback
somewhere
kind
of
this
have
enough.
A
Actually
so
we
have
this
sort
of
geo
customer
project
where
I
collect
all
of
the
customer
feedback
when
I
speak
to
people,
but
I
can
I
can
show,
but
maybe
we
need
something
like
similar
like
a
geo
design,
sort
of
issue
right,
which
is
like
right
every
time
you
notice
something
that
you
are
like
I'm
happy
with
you
like
put
it
in
there,
so
we
have
it
recorded
and
we
didn't
sort
of
talk
through
that.
Well,.
A
B
Then
maybe
what
we
need
to
do
is
as
son
John
gets
more
comfortable
with
the
with
the
role
here.
The
you
can
propose
the
label
that
we
need
to
add
to
those
issues,
because
it
might
be
some
part
of
your
workflow
that
needs
that.
That
needs
to
happen
that
we
don't
know
about
so
I
think
we.
If
we
leave
that
open
to
you,
then
you
can.
You
can
let
us
know
how
you
want
us
to
label
them.
Yeah.
D
B
Think
another
question
that
that
I've
got
was
the
the
biggest
project
that
we
have
coming
up
now
is
about
changing
the
admin
UI,
and
that
in
itself
is
a
very
ambiguous
statement.
Change
the
UI.
Let's
you
know,
let's
update
it
and
make
it
better,
and
that
is
very
yes,
it's
just
so
open
and
I'm,
but
I'm
wondering
how
we
go
from
this.
B
Ambiguous
statements
are
actually
getting
down
to
workable
issues,
and
is
it
something
where
we
raise
an
epic
and
then
we
start
raising
issues
for
the
for
the
design,
work
itself
and
the
research
that
needs
to
happen
and
the
questions
that
need
to
get
raised,
and
then
all
of
that
research
is
collected
on
the
issues
themselves
and
then
from
there.
We
can
go
in
and
separate
it
out
into
sub
epics
with
Fabian's
help
it
does
that
sound
like
the
right
way
to
be
going
about
this
yeah.
D
I
think
so,
like
because
I
saw
the
UI
and
I
said
this
is
the
basic
level
and
also
design
team
is
to
have
the
UX
scorecard
and
I
think
this
will
be
applied
to
our
team,
pretty
soon
I
think
in
December.
So
it's
on
that
criteria.
I
can
go
to
the
go
through
the
UI
based
on
the
heuristic
evaluation
and
then
I
can
kind
of
suggest
you,
the
okay.
This
has
some
usability
problem
and
then
I
came
right
down
on
the
issues
and
it
could
be
one
epic
or
I.
D
A
What
we
could
do
is
schedule
some
open
sort
of
interviews
with
those
people
and
say
just
show
me.
You
know
what
you
like,
what
you
use
the
geo
AI
for
UI
for
the
last
time,
all
right
and
then
just
let
them.
Let
them
talk
through.
You
know
like
what
they
do
want
the
UI
and
get
sort
of
a
baseline
of
what
those
folks
actually
expect
when
they
use
our
user
interface
and
I.
A
A
So
the
eliciting
the
the
stories
of
what
these
these
people
are
trying
to
accomplish.
Right
and
I.
Think
that
may
help
us
then
prioritize
specific
things
to
improve
in
the
in
the
product.
That's
sort
of
the
one
thing
that
we
I
think
we
just
need
to
do
and
that's
may
be
quite
time-consuming,
but
I
think
otherwise.
It's
hard
right,
yeah.
D
A
Being
said,
I
also
think
that,
through
like
support
issues
and
things
that
like
happened
in
the
past,
we
may
have
like
two
or
three
things
already,
where
we
are
relatively
certain
that
they
are
problems
that
we
need
to
solve
right
when
we
don't
talk
to
to
customers.
First
I
actually
I
have
an
example
or
something
that
like
happen,
that
we
can
look
at
as
well,
and
so,
if
we
pick
like
a
few
of
those,
we
can.
We
can
then
also
discuss
this
like
okay.
How
do
we?
How
do
we
move
them
like
forward?
A
You
know
like?
Is
there
may
be
an
opportunity
for
redesigning?
Is
there
an
opportunity
for
for
Zach
to
refactor
and
improve
our
our
front
end,
and
that
becomes
a
little
bit
more
concrete
right,
because
I
think
they
are
like?
We
already
know
of
some
tasks
that
we
are
not
able
to
perform,
or
that
are
not
great,
and
we
can.
We
can
just
sort
of
move
them
along
as
well.
A
I
think
that
gives
us
sort
of
a
good
balance
of
discovery
and
and
concretely
already
generating
value,
because
one
of
the
risks
that
I
see
is
we
could
probably
just
remove
the
entire
UI
and
start
from
scratch
right.
It's
like
because
I
don't
think
there
is
a
lot
of
design
consideration
like
holistically.
It's
it
was
iterated
upon.
It
is
functional
at
a
minimal
level,
but
that's
that's
about
it,
but
I
would
like
to
avoid
sort
of
a
a
big
sort
of
value
deferral
into
the
future.
A
Where,
like
we
need
to
let
go
away
for
six
months
and
then
we're
going
to
like
pop
out
with
this,
like
an
amazing
thing,
so
I
think
maybe
we
can
like
do
this
sort
of
dual
dual
track
thing
in
the
beginning,
where
we
we
pick
a
few
examples
of
where
we
already
think
we
can
make
a
difference,
start
working
on
them,
and
that
may
also
help
us
understand
how
we
can
work
with
each
other
right.
What
are
your
requirements
and
then
also
schedule
those
interviews
and
actually
like
listen
very
carefully
to
the
Systems
Administrator
I.
E
Think
to
Eileen
would
probably
good
to
kind
of
talk
to
I.
Think
she'd
have
many
other
questions.
Tell
prepare
us
for
a
meeting
like
that.
Yes,
personally,
I
think
it
would
be
extremely
beneficial
to
talk
with
the
customers
and
kind
of
just
watch
them
work
through
our
UI
along
and
then,
of
course,
if
there's
some
straightforward
issues
that
we
can
tackle
as
well,
but
I
just
I
get
nervous
a
little
bit
of
making
assumptions
too.
E
A
B
So,
if
a
bean,
if
I
summarize
there,
it
sounds
like
it,
sounds
like
because
of
customer
interactions
that
we've
already
had,
we
have
some
very
concrete
ideas
on
improvements
we
need
to
make,
and
those
are
issues
that
exist
in
the
system
already
and
we
need
to
do.
We
need
to
do
those,
yes,
but
we
still
need
to
work
with
some
German
on
those
to
just
firm
up
the
idea
that
is
there
and
how
that
fits
into
the
UI
as
a
whole
and
then
on
an
in
edit
on
the
separate
track.
D
Yeah,
actually,
that
was
what
I
was
going
to
suggest
us
to
have
my
father
in
you.
You,
you
got
the
right
point,
I
guess,
because
normally
as
a
UX
designer,
we
start
from
like
the
discovery
faith
we
meet
the
user
or
interviewing
the
user,
and
based
on
that,
like
observation,
normally
I
would
like
to
come
up
with
some
journey
map,
so
this
could
be
their
daily
life
and
if
we
provide
this
user
flow
for
them,
this
will
reproduce
their
pain
level
of
their
daily
life.
For
example,.
A
D
Like
you,
that
I
can
also
start
looking
into
the
research
documents
and
research
related
issue
in
the
design
report.
At
the
same
time,
we
also
have
issues
some
of
the
things
might
be
very
critical
and
some
of
the
things
might
be
very
like
minor
usability
issues
or
something
so
I
can
work
on
this.
So
I
think
it's
a
very
good
idea,
and
if
we
just
if
I
just
start
working
on
one
or
two
issue
and
then
I
think
probably
I
can
suggest
you
to
hey.
Let's
just
change
its
workflow
in
this
way.
D
A
A
A
Think
I'd
like
to
jot
down
my
my
thoughts
because,
from
my
experience,
get
lap
is
terribly
unorganized
in
like
having
that
information
anywhere
right.
It's
like
I,
don't
think
you
can
like
go
to
a
place
and
say:
hey.
I
would
like
to
talk
to
systems
administrators
in
companies
that
use
geo
resource
does
not
exist,
unfortunately
other
than
in
my
geo
customer
project.
B
The
other
thing
I
wanted
to
ask,
so
it
sounds
like
Fabien
you're,
going
to
be
creating
issues
and
ethics
and
will
contain
that
information
about
the
customers.
I
think
then
we
also
need
to
identify
what
the
use
those
other
concrete
issues
are
that
you're
talking
about,
so
that
we
can
figure
out
about
scheduling
those.
Yes.
A
A
B
B
That
makes
sense
for
the
team
and,
if
there's
any
proposals
for
how
we
can
work
together
more
effectively
or
things
that
we
need
to
change,
to
be
able
to
deliver
value
better
I
really
encourage
those
ideas
coming
forward
and
being
discussed,
because
the
most
important
thing
for
me
is
having
an
effective
team.
I
don't
want
to
just
follow
process
because
that's
like
the
way
that
it
might
be
done
or
the
way
that
it's
been
done
in
the
past.
B
So
if
you
have
ideas
that
you
want
to
put
forward,
please
with
by
all
means
raise
them,
let's
discuss,
let's
try
and
adopt
those
I
just
wanted
to
put
that
out
there
before
we
get
into
something
concrete,
because
that
I
think
is
really
important
to
me
that
you
feel
comfortable
with
with
proposing
change.
So.
B
D
A
No,
it's
like
like
I
think
this
is
something
you
know
it
yeah
I
think
we
should
I
have
pretty
aligned
to
this
regard.
We
do
things
sometimes
a
little
bit
differently
in
geo
if
we
feel
that
makes
sense
and
makes
the
makes
the
team
productive
yeah.
So
don't
don't
here
obliged
to
follow
this
one
process
just
because
it
is
written
down
somewhere,
but
let's
see
if
we
can
make
some
changes
and
then
we
can
also
try
to
merge
those
changes
back
into
the
bigger
process.
A
A
C
A
Concrete
issue-
and
this
is
like
something
that
it's
not
very
detailed
yet
because
I
didn't
want
to
like-
spend
too
much
time
getting
details
on
it,
but
I
I
want
to
explain
to
you
what
the
problem
is
here
that
I
think
clinically
solve.
Can
you
that?
Do
you
have
the
issue
open,
yeah,
everyone,
okay,
so
I
think
one
very
concrete
problem
that
systems
administrators
have
and
I've
seen
this
now
on
a
couple
of
customer
calls
is
geo
is
great
when
the
bar
here
of
like
repositories,
is
100%.
A
Everybody
is
happy
right,
because
this
is
what
it's
supposed
to
do,
but
right
one
of
the
like
I,
think
main
tasks
that
a
systems
administrator
will
engage
with
is
to
you
know,
start
investigating
when
the
number
is
not
100%
all
right.
So
let's
say
we
have
97
out
of
100.
Nfs
objects
are
our
synced,
but
three
aren't
at
the
moment
for
anything
other
than
repositories
and
uploads
and
I
believe
design
repositories
as
a
systems
administrator
you're
essentially
done.
There
is
nothing
in
the
UI
you
can
do
right.
A
The
only
thing
you
can
do
is
call
the
support
and
say
like
hey.
Something
is
not
sinking
in
NGO
and
I.
Don't
know
why
right
and
then
what
happens
is
you
will
get
like
a
few
commands
to
run,
which
may
or
may
not
be
documented
in
order
to
figure
out
essentially
those
like
for
things
like
which
things
are
not
replicated
all
right?
A
Get
details
right
then
identify
the
things
that
are
wrong
and
offer
at
least
a
couple
or
so
of
manual
interventions
right
as
in
hey.
Let's
try
this
again
or
maybe
Reve
Arif
I
it,
because
that
is,
you
know
that
will
probably
that
empowers
them
to
kind
of
do
this
by
themselves.
At
the
moment
they
have
to
contact
support
and
the
user
experience
of
saying,
hey,
let's
login
to
the
rails,
console
and
then
perform
these
specific
commands
right
is
is
not
great.
I
can
give
you
an
example
actually
of
off
this
one.
E
A
For
example,
this
is
the
like.
This
is
a
suggestion
to
a
customer
that
we
like
had
yesterday
right
is
to
like
essentially
find
unsynched
attachments
so
uploads.
You
know
a
user
needs
to
perform
these
tasks
here
in
in
the
rails,
console
and
that's
like
we
actually
sent
them
this
and
say
like
go
to
the
rails,
console
into
this
and
I
think
what
we
should
do.
A
A
surface
like
essentially
do
something
very
similar
to
what
we
are
doing
with
design
repository
so
I,
just
like
expose
an
API
that
allows
you
to
do
this
and
then
allow
the
user
interface
to
or
in
the
user
interface,
a
way
to
perform
those
those
sort
of
actions
of
you
know
like
identifying
and
then
and
then
yeah
be
very
fine.
There
are
some
problems,
though,
and
I
think
this
is
not
where
the
design
cart
comes
in
and
Zach.
Maybe
you
have
something
to
add
here.
A
We
do
this
kind
of
already
for
uploads
and
projects
right,
so
you
can
go,
and
this
is
sort
of
at
the
bottom.
The
second
screenshot
you
can
go
and
you
have
sort
of
like
not
like
other
pages
that
allow
you
to
go
there
and
then
like
look
at
all
your
projects,
all
your
all
your
uploads
right
and
then
look
at
like
synced
pending
failed.
A
You
can
perform
some
bad
batch
operations,
though
so
we
have
parts
of
this
functionality
already,
but
not
for
everything,
and
so
there
is
a
little
bit
of
a
concern
on
my
end
that
this
sort
of
pattern
that
we
have
here
doesn't
scale
super
will
right,
because,
essentially
for
every
new
thing
that
we
have
to
add
right,
we
would
have
to
like
add
a
new
page
at
this
filter
right
and
then
we
end
up
with
like
10
or
15
like
bits
in
the
menu.
So
my-
and
this
is
this
is
no
way
I
am
at
this.
A
E
Yeah
and
just
iterate,
and
what
you
just
said,
that's
exactly
what
we
did
on
the
new
designs
repositories
for
you
right
now,
that's
in
flight,
so
continuing
to
do
that
could
be
not
good
and
so
right
off,
like
one
thing
that
I
really
have
been
thinking
about
like
when
I'm
working
on
this
is
who
and
feel
free
to
shoot
me
down.
Who
actually
cares
about
this
stuff?
That's
successful!
A
E
A
I
think
that's
actually
quite
right,
because
the
the
pattern
that
I've
observed
from
from
customers
is,
if
everything
is
good,
like
everything,
shows
100%.
The
summary
view
is
perfectly
fine
all
right,
because
you
look
at
it,
you
say
like
100
percent
is
100
percent.
Unless
they're
lying
right,
I
am
satisfied
right
right,
but
as
soon
is
that
like
goes
goes
down.
A
People
get
you
to
read
right
and
it's
like
I've
seen,
support
items
which
people
say
like
okay,
we
have
ninety-seven
percent,
but
this
is
like
either
disaster
recovery
relevant
right
or
like
some
things,
will
randomly
fail
for
users
right
and
so
for,
like
this
is
a
little
bit
like
unless
there
is
an
explanation
right,
missus
like
hey.
Actually
we
are
you
know
these
are
pending,
where
they
will
happen
right,
that's,
okay,
but
as
soon
as
it's
like
for
some
random
reason,
this
is
not
happening.
People
get
very.
A
B
There's
a
whole
bunch
of
things
that
synced
and
there's
a
whole
bunch
of
things
that
didn't
sink
but
you,
but
by
looking
at
the
successful
things
you
were
able
to
figure
out
that,
for
some
reason
everything
that's
thinking
starts
with
just,
for
example,
it
starts
with
the
later
a
and
everything
that
doesn't
start
with
the
literary
is
not
sinking
okay.
So
what?
How
does
that
help
me
debug
this?
D
A
Essentially,
can
you'd
like
to
present
a
sort
of
detailed
view
right
and
then
you
can.
You
can
make
the
type
something
that
you
filter
on,
because
it's
like
oh
I'm,
actually
interested
in
repositories
right
and
the
rest
I'm,
ignoring
right
or
you're
interested
in
LFS
objects,
but
like
this
sort
of
like
having
a
separate
like
screen
for
everything,
feels
very
wasteful
yeah.
But
these
are
like
and
they
think
so.
This
is.
A
We
don't
need
to
come
to
a
conclusion
in
this
call
right,
but
those
are
the
types
of
sort
of
issues
that
we
I
think
we're
not
necessarily
equipped
to
to
tackle,
particularly
well
like
until
like
a
month
ago
or
so
right,
and
so
this
is,
for
example,
something
we're
working
on
this
together
would
be
really
fun
right.
Like
I
opened
this
issue
and
I
described
the
problem,
and
if
we
now
can
like
go,
go
there
and
second
say
like
well:
actually
you
know
from
a
front-end
perspective
right.
A
A
Okay,
you
know
like:
why
are
we
surfacing
the
information
that
regard
that
can
way,
and
once
we
have
that
figured
out
right,
we
can
break
it
down
into
okay
in
the
backend
right.
What
do
we
actually
need
to
enable
right
the
front
end
right?
What
are
the
specific
tasks?
How
can
the
front
end?
Look
like
right.
A
This
is
the
design
you
know
those
are
as
a
task
for
it
for
Zach
and
then,
if
we
can
sort
of
compile
a
package,
let's
say
right
off,
maybe
10
or
so
issues
that
require
to
to
implement
that
and
functionality
right
then
I
will
probably
promote
this
to
a
sub
epic
right.
We
we
seem
like
this
is
what
we're
going
to
do.
You
know
and
then
we're
just
going
to
like
shove
it
through
the
pipeline
and
finish
it
as
quickly
as
we
can
that's
kind
of
how
we
eat
how
we
do
it.
D
Now
that
was
pretty
clear
to
me
and
then
I
think
I
really
need
to
spend
some
time
with
the
discovery
faith,
because
I
have
a
very
strong
assumption
like
this
is
very
personal
things,
but
like
based
on
the
description
on
the
handbook.
So
our
primary
target
user
is
sees
me.
They
stop
me,
but
I.
Think
they're
very,
like
under
a
lot
of
stress
because
of
a
lot
of
information
on
diapers
channel
that
they
have
so
I'm,
just
wondering
like
which
information
do
they
really
need
to
see
and
which
information
Asian
is
like?
D
A
If
you
do
some
menual
things
which
are
not
so
well
documented,
if
at
all
so
like
it's,
it's
really
like
one
of
those
situations
where
the
the
user
right
of
our
system
is
not
empowered
to
solve
their
own
problem,
and
so
they
always
depend
on
on
us,
helping
with
them
solving
it,
and
that
makes
me
also
relatively
confident
that
from
sort
of
a
back-end
technical
perspective,
this
is
not
impossible
because
the
the
functionality
already
exists
on
some
level
right.
We
just
need
to
surface
it
all
right
and
I.
A
Think
that's
that's
kind
of
the
question
here.
So
what
do
you?
What
do
you?
So
this
is
I.
Think
already
it's
a
relatively
sizable
chunk
right
of
work.
I'd
say
what
do
you
think
about
taking
taking
this
one
like
up
as
a
like
a
first,
let's
figure
out
how
we,
how
we
work
with
each
other
like
how
we
how
we
can
approach
this
right?
It's
not
so
much
about
speed,
it's
more
about.
You
know
like
starting
to
do
something
concrete
right.
A
D
Yeah
sure
I
love
to
but
I'd
like
to
know
better.
So
currently,
this
is
just
an
issue
created
today,
but
I
like
to
know
the
priority
in
terms
of
the
product.
So
do
you
think?
How
do
you
feel
like
this
issue
is
very
urgent
or
no
because
I
to
more
dive
into
like
user
in
general,
like
how
are
they're
doing
like
how
are
their
daily
life
in
the
their
companies,
because
I
might
start
googling
their
blog?
A
How
should
I
say
it's
like
we
shouldn't?
We
shouldn't
focus
all
of
our
like
effort
completely
on
this
and
drop
everything
else
right.
That's
not
that's!
Not
the
intent,
but
I
do
think
that
this
is.
This
is
a
concrete
piece
that
we
have
of
improvement
and
I've
I've
seen
this
now
a
couple
of
times
why
we,
where
we
do
this
with
customers
and
I,
think
it's
a
sort
of
from
there
like
you
are
a
changes
right.
A
This
is
maybe
one
of
the
first
things
we
should
try
out
because
I
think
they
are
it's
concrete
enough
to
do
something
and
it
will
have
a
higher
customer
facing
impact.
So
I
think
I
think
it's
a
it's
an
it's
hard
for
me
to
say
how
it
is
in
priority
compared
to
all
of
the
unknown
issues
that
we're
going
to
surface
in.
There
is
discovery
right.
I
can't
I
can't
know
that
this
point,
but
I
say
it
for
like
what
I
know
about
the
UI
I
personally,
like
feel.
This
is
not
unimportant
if.
B
I
can,
if
I
can
ask
the
question
again
like
it
I
want
to
see
if
I
can
rephrase
the
question
that
Sundering
asked
is
the
question?
Actually
how
urgent
is
this
in
comparison
with
developing
your
base,
understanding
of
the
user
of
Sydney
and
the
and
the
product
of
Geo,
because
you
need
to
spend
time
getting
that
base
understanding
and
the
understanding
of
the
users
before
making
certain
types
of
decisions
about
the
way
forward?
A
Okay,
sorry
I
think
I
may
have
misunderstood.
You
I,
like
I,
would
say
like
getting
the
base.
Understanding
is
more
important
right.
It's
like
you
should
you
should
you
should
take
the
time
and
get
yourself
up
to
speed
with
you
know
like
understanding
how
these
things
work,
but
that
being
said,
I
I
think.
Maybe
this
is
just
my
approach
right.
A
B
What
I'd
also
like
to
suggest
is,
while
I
know
that
the
product
designer
and
the
product
manager
roles
are
quite
different.
They
both
revolve
around
understanding
what
users
need,
and
perhaps
the
methods
that
Fabien
used
to
onboard
himself
into
geo
and
the
life
of
users
might
also
be
a
way
onboarding
like
you
might
have
value
in
in
chatting
together,
so
that
you
can
share
how
you
did
it
because
you
needed
to
get
up
to
speed
and
go
through
a
whole
backlog.
B
A
B
A
B
A
D
A
The
thing
is
like
also
you
think
this
is
maybe
this
is
sometimes
a
little
bit
gitlab
specific,
alright
Ness,
like
I,
think
sometimes
we
push
ourselves
to
to
do
things
even
when
they're,
not
whether
a
little
bit
uncomfortable
or
an
even
like
when
the
when
it's
not
really
risky
right
as
an
you
know,
like
data
loss
or
electing
second
seriously,
go
wrong
right.
So
the
question
is
also
I.
Think
for
me
going
back
to
the
like
big
rewrite:
it's
like
we
around
now
right
and
our
customers
have
concrete
problems
right.
A
So
maybe
there
are
small
things
we
can
do
already
that
make
their
life
a
little
bit
better
right.
It's
not
going
to
be
amazing
instantaneously,
but
it's
going
to
be
a
small
improvement
right
and
I
think
this
is
you
know,
for
example.
Maybe
here
you
in
a
week
we
say
like
well.
Actually
you
know
like,
like
zach,
has
a
suggestion
says
like
I
have
this
idea
we
could
maybe
already
like
merge
all
of
those
things
into
one
and
it's
not
going
to
be
well
than
before,
but
we're
going
to
like
already
improve
it
right.