►
From YouTube: 2022-11-16 Product Analytics PM:UX Sync
Description
Weekly sync where we discuss the latest UX developments, questions and ideas in Product Analytics. In this week's call we talk about the what should happen once a user has initialized an analytics stack.
A
A
A
B
A
Cool
and
then
one
for
both
Robin
myself
to
update
the
NBC
issue
descriptions.
This
is
something
that's
ongoing.
We
have
made
some
new
issues
and
updated
the
descriptions
and,
like
just
earlier
today,
we
had
a
a
thread
and
a
call
with
Max
also
like
discussing
this.
So
this
is
something
that's
like
ongoing.
I
feel
like
an
will,
continue
to
be
ongoing.
So
I
wonder
if
we
shouldn't
mark
this
as
complete
for
now
since
we've,
since
it's
probably
like
an
ongoing
item.
C
All
yeah
all
of
the
issue
descriptions
are
up
to
today.
The
only
thing
that
might
deviate
is
just
on
the
back
end
implementation.
We
might
need
to
update
the
descriptions
based
off
that
conversation,
we're
currently
having
going
with
Max
and
we'll
see
where
that
goes
from
that
other
than
that.
There
is
also
only
two
issues
left
that
don't
have
implementation
plans,
which
are
also
relying
on
that
back
end
implementation
process.
So
as
soon
as
that's
done,
we'll
have
every
issue
marked
out:
I
have
weighted
with
implementation
plans
ready
for
scheduling.
A
Cool
but
yeah
in
in
terms
of
like
the
problem
to
solve
and
and
the
designs
I
feel
like
we're,
we're
a
good
like
solid
space
there
for
for
our
MVC
issues,
and
then
we
also
have
look
at
a
way
of
designing
a
way
of
returning
the
instrumentation
screen
connection
details.
This
is
also
can
I
check.
This
is
done
because
I
think
you
have
that
design
right.
C
A
C
The
APO
key
in
url
to
documentation
screen,
which
is
the
ticked
one
above
this,
is
a
separate
design
entirely
where
we
talked
about
having
some
way
of
getting
back
to
that
instrumentation
screen.
If
you
remember
last
week,
yeah,
either
with
a
button
or
a
modal
or
some
kind
of
way
of
showing
that
screen,
even
after
they've,
got
through
this
whole
implementation
process,
so
that
still
needs
to
be
done.
A
C
Thanks
so
just
a
general
question
around
priority
on
the
ux
stuff,
I
guess
more
or
less
so
now
we're
done
with
ux
for
the
onboarding.
So
this
is
less
of
a
conversation
now,
but
we've
got
more
use.
Ux
design
work
that
we
need
to
start
thinking
about
for
future
Milestones
like,
for
instance,
filtering
on
the
dashboard
edit.
C
How
we're
going
to
surrender
editing,
because
that's
the
next
big
feature
I'd
assume
that
we
sort
of
gonna
need
to
prioritize
or
start
building,
especially
for
optimize,
because
that's
the
thing
they
really
need
to
make
it
usable
for
them.
So
there's
a
conversation,
there's
a
question
around
prioritizing
front
end
over
ux
and
I.
Don't
think
we've
got
anything
in
the
pipeline
for
ux
at
the
minute,
so
we
need
to
start
looking
at
those
issues
and
getting
those
lined
up
and
yeah
just
I,
just
general.
B
B
B
What
is
going
to
be
next
is
we
need
to
get
the
dashboards
to
the
point
where
you
can
do
editing
of
what
the
widgets
that
are
on
them
in
terms
of
their
position
and
the
size?
That's
going
to
really
be
the
next
thing:
editing
the
actual
content
of
the
widget.
That's
going
to
be
a
lot
more
complicated
to
do
with
a
graphical
interface.
So
for
that
part
we
will
ask
users
to
hey:
go
update
the
yaml
file
that
defines
the
widget
and
they'll
need
to
do
that.
B
C
So
for
to
be
able
to
resize
and
edit
widgets,
we're
going
to
need
to
have
a
way
of
then
doing
that
and
then
saving
that,
if
that
makes
sense,
so
that
we're
going
to
need
to
have
some
kind
of
UI
flow
to
have
them
go
off
to
an
MR
to
generate
that
after
the
UI.
Obviously,
the
UI
is
going
to
create
in
the
needs
to
send
it
off
somewhere
to
actually
create
that
Mr
for
them
and
yeah.
That's
the
flow
I'm,
most
scared
about
doing.
B
I
wanted
to
check
in
on
after
our
conversation
yesterday,
we
talked
a
little
bit
about
the
internal
preview
and
having
things
be
pre-configured
and
pre-set
up
for
users.
Do
our
current
onboarding
designs
get
us
to
that
point,
or
will
we
still
need
to
iterate
on
top
of
those
to
get
us
to
a
you
turn
it
on?
You
have
some
dashboards.
C
A
That's
that's
what
I
wanted
to
to
mention
now
is
like,
because
I
wanted
to
bring
up
that
discussion.
We
we
had
last
week
you
and
I
Sam,
and
also
it
links
to
the
agenda
item
we
had
in
the
product
analytics
weekly,
where
I
think
like
if
this
is
a
misalignment
between
the
onboarding
MVC
and
what
we
want
for
our
internal
preview
and
also
for
our
customer
preview
is
that
we
want
those
like
the
the
audience
dashboard,
for
example.
A
To
always
be
there
technically
I
can
see
like
the
fear
in
Rob's
eyes,
for
like
how
we
technically
develop
that
because
like
do,
we
does
that
mean
that
we
create
a
Mr
from
the
start
like.
How
do
we
do
that
I?
Think
for
now
we
can
just
keep
it
simple
and
I.
Don't
don't
want
to
get
too
technical
in
this
call,
because
this
is
supposed
to
be
the
ux
call,
but
I
think
we
can
keep
it
simple
and
keep
it
baked
into
the
front-end
files
like
it
currently
is
for
now.
A
Then
we
can
figure
out
how
we're
going
to
allow
users
to
to
customize
that
and
I
think
that's
where
the
whole
ux
flow
and
investigation
research
then
comes
into
figuring
out
like,
and
you
know
how
we're
going
to
do
this
from
a
user
perspective
and
they're.
Also,
technically,
is
something
that
we
need
to
align
on
here.
So.
C
Although
we
can
build
it,
they
will
see
this
where
they
have
an
audience
and
a
behavior
or
whatever
the
other
screen
is
called
Already
pre-built
hard-coded.
They
won't
be
able
to
make
changes
to
it
or
edit
it
in
future,
or
at
least
for
now,
and
it
will
have
pre-configured
all
the
preview
widgets
it's
not
stored
in
their
code
base
at
all.
Is
that
correct.
C
Okay,
so
that
does
mean
yeah
I
know
it's
a
U.S
school,
but
technically
in
my
head.
I'd
just
expect
that,
if
dashboard,
if
dashboard,
if
dashboard
provided
from
backend
equals
audience
don't
show,
inbuilt
audience
is
pretty
much
the
basic
logic
I'm
thinking
off
the
top
of
my
head
for
future
rust.
Okay,
the
idea
of
that
idea
fills
me
with
far
less
dread.
C
We
are
skipping
the
Mr
process
entirely
and
just
providing
I
like
that,
and
also
in
some
ways
pushes
the
whole
button
issue
down
the
road
too,
because
to
get
to
you
won't
see
that
empty.
For
a
while
I
like
that
approach,
we
just
need
to
make
sure
that
what
we
do
in
the
front
end
schema
stuff
matches
what
we
would
get
normally
from
the
backend,
so
we
can
inject
those
and
make
sure
it
all
works,
which
is
fun.
That's
a
technical
problem.
Okay,
that's
I
like
that.
B
Thank
you.
An
idea
I
did
have
on
an
implementation
approach
and
feel
free
to
ignore
this.
What
if
we
had
a
central
to
gitlab
instance
folder,
which
had
you
know,
Central
gitlab,
folder,
slash
pre-configured
dashboards?
We
look
for
any
yaml
files
in
that
folder.
First
for
every
project
load.
Those
then
look
at
any
Project
Specific
ones.
That
way
we
wouldn't
have
to
bake
anything
into
the
front
end.
Specifically,
we
would
just
look
for
an
additional
place
in
the
back
end.
A
Yeah,
that's
that's
pretty
much.
What
I
had
in
mind
for
that
button
is
that
it
would
use
a
template.
I
think
what
you're
talking
about
is
even
a
step
further,
where
it
would
be
like
an
MR
with
a
group
of
files
that
that
we're
adding
at
at
once,
potentially
because
later
for
the
day
like
it
still
needs
to
be
managed.
C
Yeah
I
yeah
I
think
what
we've
done
front
end
wise
works
for
now
we
can
move
it
to
the
back
end.
If
you
want
I,
just
can't
think
of
a
place
that
you'd
actually
store
a
non-template
hard-coded
yaml
file
like
that
in
our
current
code
base.
I,
don't
think
we've
that'd
be
a
question
for
Max
honestly
more
than
anything,
but
the
concept
is
an
interesting
one
and
I
think
we
could
probably
capture
that
too.
B
A
B
B
C
B
B
C
No
and
they're
also
good
one.
If
we
can
get
the
map
scoped
out,
they're,
just
good
little
things
to
pick
up
in
the
city.
You
don't
you
know
we
can
just
create
them
as
and
when
you
don't
necessarily
need
to
have
them
tie
to
any
particular
dashboard.
So
it
gives
us
lots
of
front-end
work
to
do
if
we
get
them
scoped
out
from
a
design
perspective.
B
It'll
also
help
us
get
away
from
one
of
my
pet
peeves
are
line
charts
for
non-continuous
data
series,
which
everyone
does
and
it
I
think
it
bothers
me
more
than
the
average
person,
so
I'm
really
Keen
to
get
bar
charts
soon.
So
we
can
do
non-continuous
data
series
with
non-continuous
data
visualization,
but
that
might
be
more
of
a
personal
thing
for
me.
I.
A
A
A
A
One
of
the
main
things
that
I've
I've
been
feeling
about
odd
about
is
like
the
difference
between
some
of
our
epics
and
onboarding
flow,
and
it
seems
like
now
we're
all
three
aligned
on
how
that
is
actually
going
to
look
in
terms
of
like
what
what
the
user
sees
after
a
stack
has
been
initialized
because
yeah
like
rope,
Mississippi
still
one.
There
there's
a
contentious
like
trades
and
like
a
lot
of
confusion
about
it,
and
it
seems
like
we're,
we're
all
aligned
now,
which
is
fantastic.
C
B
It
in
my
mind
that
period
wasn't
contentious.
It's
just
showing
you
know
if
we're
on
slightly
different
pages,
that
that's
okay,
it's
not
okay.
If
we
stay
on
different
pages,
but
it's
always
good
for
us
to
have
a
conversation
and
I
mean
certainly
Dennis's
help
was
huge
in
this,
since
he
was
doing
a
lot
of
these
issue
updates
and
reorganization
as
well.
A
Yeah
I
I,
don't
think
I've
seen
a
group
with
so
many
different
epics
and
issues
All
In
Flight.
All
constantly
changing
and
I've
only
been
here
for
like
three
or
four
weeks,
and
everything
is
like
constantly
changing.
So
the
fact
that
we've
only
had
like
one
misalignment
thus
far
is
pretty
amazing.
To
be
honest,.