►
From YouTube: Product Analytics PM/UX Sync 2023-05-17
Description
Weekly Sync to discuss open items on issues with Design, next prototypes, etc.
Today we talked about what's next in the Experimental Phase and how we as a group can quickly prototype to validate user value, our ability to build and viability for the business of possible work.
A
B
B
So
yeah
that,
because
I've
seen
like
we
have
a
bunch
of
like
workflow
design
issues
that
I
am
actually
not
working
on
so
yeah.
That's
that's
just
one
thing:
if
you
want
to
stop
pulling
ux
issues,
we
can
also
look
at
like
label
backlog
or
ready
for
design,
because
I
created
a
bunch
when
I
didn't
ux
scorecard
at
that
time.
Okay,.
A
Sure
to
sign
so
if
I
can
change
the
link
to
the
workflow
ready
for
design
I
think
that's
the
best
indication
of
what's
coming
next
and
then
things
that
have
that
labeled
that
are
in
the
backlog.
We
can
also
look
at
anything
that
doesn't
have
workflow
but
as
ux,
that's
in
backlog,
but
I
think
that
list
is
going
to
be
too
big
to
be
reasonable
to
go
through
on
a
weekly
basis.
A
Okay,
I'll
switch
up
the
link
to
also
include
the
ready
for
design,
and
then
we
can
talk
through
anything
that
is
in
play
that
you
need
that
we
want
to
discuss
or
the
need
synchronous,
discussion,
cool
cool,
all
right,
I'm,
just
going
to
change
that
now.
So
it
looks
like
there
is
one
item,
then
in
ready
for
design.
That's
the
cube
query,
rendering
visualization
funnel.
A
A
I
think
for
later
on,
yeah
I,
don't
think
it's
ready
to
schedule.
The
end
I
think
the
back
end
stuff
is
not,
but
we're
petting
or
holding
off
of
the
front
end.
So
the
priorities
in
16-1
would
be
any
support
for
a
front-end
team
to
get
the
visualization
designer
dashboard
stuff
done
and
after
first
customers
are
on
the
platform.
Then
we're
going
to
roll
that
work
forward
or
release
that
work.
So
they
can
start
to
create
visualizations,
create
custom,
dashboards
and
add
those
safe
visualizations
to
the
dashboards.
C
A
C
A
A
C
B
D
B
Holiday
went
into
the
enterprise
process
and
then
we
kind
of
had
a
few
stuff
that
I
didn't
necessarily
accounted
for
that
needed
to
be
embedded
into
this
kind
of
new
iteration.
So
now,
I'm
just
kind
of
adding
it
and
I
don't
think
it's
it's
kind
of
a
lot
of
work,
but
the
only
thing
that
I'm,
probably
gonna
ask
everyone
is
just
to
kind
of
go
through
it
and
and
see
if
they
have
anything
else
they
they
would
like
to
add
before
we
proceed.
B
A
B
C
Yeah
we
have
the
cascading
like
settings
framework
like
okay,
you
can
over,
you
can
override
and
it
does
that
already
I
haven't
reviewed,
NMR,
so
I
think
from
a
design
point
of
view.
I
don't
know
that
we
want
to
have
the
control
to
opt
in
or
out
of
overwriting,
but
at
the
same
time
it
also
just
needs
to
be
known
that
if
you
do
Define
it
at
the
project
level
that
it
would
override
at
the
instance
level,
so
it
still
needs
guidance
for
the
user.
D
Course
yeah,
but
that
was
my
main
feedback
while
reviewing
that
changes,
that
it
isn't
clear
to
the
user
that
these
are
overriding
admin
settings
and
then
also
making
clear
that
you
could
selectively
overwrite
settings
yeah.
It
didn't
necessarily
like
impact
all
of
them,
which
I
think
we
should
also
make
sure
that
that's
something
that
we
want
to
do,
because
that's
the
current
functionality
of
it.
D
No,
it's
all
values
are
optional.
Okay,
my
feedback
on
it
was
that
we
could
do
something
similar
like
we
did
for
deletion
protection
which
cascaded
down
from
admins
groups
and
projects
where
you
have
like
a
toggle
to
basically
say
I,
want
to
use
admin,
settings
or
I
want
to
use
project
settings
and
then,
when
you
toggle
to
project
settings,
you
get
the
form,
but
also
you
have
to
like
expect
that
there's
more
explicit
language
and
control
about
when
which
like
track
is
enabled
yeah.
C
A
C
Yeah,
it's
just
for
cascading
and
neon
correct
me
if
I'm
misunderstanding
how
it
works,
because
it's
been
a
while
but
like
when
you
set
it
at
a
higher
level.
You
can
set
like
it
to
not
be
overwritten
at
subsequent
levels,
and
so
that's
why
I'm
be
careful
around
cascading,
where
we
actually
want
the
opposite
of
that
yeah
ux
pattern
may
like
this
may
look
similar
cascading.
D
Provides
that
as
an
option,
but
it's
not
enforced
by
default-
it's
something
that
you
can
use
to
bold
onto
your
settings,
the
Locking,
which
is
very
handy
for
something
like
compliance,
but
for
us
less.
So
so
it's
still
if
we
wanted
to,
we
could
still
use
the
framework
and
just
like
not
use
the
locking
mechanism
at
all.
A
C
C
I
think
it's
worth
noting,
but
you
also
have
to
have
the
that
opens
up
another
question
of
like
will
we
have
group
level
dashboards,
and
what
does
that
look
like?
How
does
that?
How
would
that
differentiate
itself
between
setting
the
cluster
at
a
at
a
at
an
organizational
level
versus
like
I
just
want
this
one
to
connect
so
like
until
we
kind
of
go
through
whatever
that
information
architecture
looks
like
or
how
we're
going
to
be
able
to
distinct
the
two
I
I
say:
let's
table
it
and.
C
Yeah
I'm
sure
there
will
be
because,
especially
if
you
look
at
like
value
stream
analytics
like
obviously
that
operates
at
the
group
level
and
I've
initially
said,
we
should
also
look
at
connecting
it
at
the
group
level.
But
the
more
I
thought
about
it.
Like
there's
yeah
like
you,
you
would
want
to
set
an
instance
potentially
at
your
group
level,
but
then
what
impact
does
it
have
when
we
have
group
level
dashboards?
It
may
just
be
where,
if
you
set
it
at
the
group
level,
it's
going
to
affect
both.
C
C
Now
you
say
that
I'm
going
to
throw
another
wrench
at
you,
yeah
now
think
about
custom
dashboard
repositories
and
how
we
Define
those
configurations.
Now
you
set
them
at
the
group
level.
Does
that
mean
all
of
your
projects,
Will
Follow
That
repository,
or
is
that
specifically
for
group
dashboards
at
that
level?
And
now
that
you
have
the
two
of
bring
your
own
cluster
and
I'm?
Pretty
sure
you
hate
me
now
by
bringing
your
own
cluster
and
custom
dashboard
configurations?
D
A
C
All
potentially
yeah,
it's
all
potentially
useful,
I
just
want
to
avoid
the
case
where
we
start
implementing,
bring
your
own
cluster
to
groups,
and
then
that
has
its
own
impact
based
on
how
it
affects
Subs
like
lower
level
but
also
same
level
dashboards.
Then
I
don't
want
us
to
end
up
like
implementing
custom
dashboard
repository
for
group
level
and
that
somehow
behaves
differently
or
the
impact
that
it
has
at
the
same
or
lower
levels
is
different
than
that
of
bringing
your
own
cluster.
So
it's
just
more
of
a
overarching
strategic
decision.
A
How
can
we
add,
you
know
a
group
quickly,
prototype
things,
get
them
in
front
of
users:
validate
hey
they're,
going
to
Value
this.
It
solves
a
problem
for
them
and
hey
as
a
team.
We
can
go
build
this
thing
quickly
and
actually
get
it
out
there.
So
we
get
real
data
and
not
build
a
bunch
of
functionality
and
drag
around
a
bunch
of
tech
debt
that
nobody's
using
that's.
C
Yeah
I
think
it's
gonna
maybe
have
to
be
a
mix
depending
on
how
confident
we
are
in
terms
of
the
level
of
effort
to
implement
an
experiment
and
I'm
using
that
word
deliberately,
because
if
we
look
at
what
we're
doing
as
far
as
kind
of
our
general
AI
strategy,
we
are
building
things
out
and
testing
them
out
in
production,
but
at
the
same
time,
I
think
there's
value
in
having
Kevin
or
someone
conduct
like
put
together
a
quick
prototype
to
walk
someone
through
I.
Don't
know
what
our
flow
is,
but
I.
C
You
know
it
you
can
cover
you
correct.
You
can
update
me,
but
you
know
we
used
to
kind
of
go
through,
like
figma
prototypes
I,
think
where
we
would
walk
the
user
through,
like
here's,
what
it
would
look
like
so
I
think
it'd
be
a
level
of
like
okay,
for
if
we
take
AI,
for
example,
natural
language
occurring.
We
already
have
some
of
the
code
for
that
and
in
other
cases
perhaps
we
may
want
to
actually
build
part
of
it
out
to
actually
prove
whether
it's
feasible
technically.
C
In
that
case,
we
would
have
to
make
the
decision
of
like
how
much
more
effort
would
it
be
to
actually
build
it
out
as
an
experiment
knowing
the
customers
that
may
that
are
using
it.
It
may
disappear
that
feature
that
experiment,
or
is
it
better?
Where
we
just
say
hey,
can
we
set
up
like
a
walk
through
visually
to
validate
whether
even
customers
are
going
to
use
this
or
not.
A
C
Yeah
and
that'll
that'll
play
into
how
we
design
it
as
well.
If
you
want
to
leave
continuing
on
the
right
hypothetical
example
of
like
natural
language
clearing,
we
also
have
what
we're
building
at
git
lab
like
the
option
to
opt
in
and
out
of
experiments.
So
if
we
can
design
in
such
a
way
that
it's
not
as
intrusive
like
you
know,
you
still
have
the
visualization
designer.
You
still
have
data
exploration
there,
but
if
you
opt
into
it,
then
it
adds.
C
You
know
an
additional
field
where
you
can
start
querying
it
and
stuff
like
that,
then
that's
something
worth
exploring
too,
but
it's
a
fine
balance
because
you
know
we
can
spend
a
lot
of
time.
Thinking
about
it
and
yeah
we
could
have
just
designed
something
and
walked
not
just
but
like.
We
could
have
just
walked
through
a
visual
representation
of
it
to
see
if
that
would
actually
make
sense
or
not,
but
we
have
options,
I
guess
the
short
answer
to
that.
We.
A
Have
options
I
want
to
get
us
into
the
habit
of
bias
to
action
and
biased,
build
or
to
to
get
in
front
of
users,
whether
that's
but
something
that's
built
in
the
code
base
or
something
that's
on
figma
and
not
spend
six
weeks
on
building
out
a
clickable
prototype
or
designs
iterating
internally,
a
bunch
because
we
don't
get
as
much
value
out
of
that
as
we
do
of
getting
something.
That's
brought
those
good
even
or
80,
as
good
in
front
of
a
user.
A
A
lot
faster
in
getting
immediate
feedback
and
knowing
hey
yeah
I
would
use
that
that
solves
this
problem.
For
me
today
or
I,
don't
see
how
that's
helpful
at
all.
That
gives
us
a
lot
more
to
to
chew
on
and
iterate
with
than
you
know,
we
kind
of
like
it.
We
kind
of
don't
and
then
get
a
bunch
of
people
weighing
in
with
an
opinion
who
aren't
using
product
analytics
or
aren't
trying
to
solve
the
problems
that
we
want
to
solve
with
Analytics.
C
That
would
probably
require
a
lot
of
work
on
the
technical
side
of
things
where
it's
like
we're,
basically
re-architecting
it
from
the
code
like
from
the
ground
up,
then
that
would
make
sense
to
actually
build
that
visual
prototype
to
actually
see
it
like
with
this.
Would
this
make
you
work
faster?
So
it's
it's
like
I'm
gonna,
give
you
the
classic
answer.
I
was
like
I
agree,
but
it
may
depend
it
depends.
It
depends.
C
I
mean
that's,
the
answer.
I
always
gave
as
an
engineer.
What
do
you
mean,
but
what
I
mean
is
like
I?
Don't
want
a
discount
like
I,
think
there's
still
value
in
like
really
putting
together
like
is
it
designs,
like
you
know,
and
where,
in
some
cases,
the
clinical
prototype
is
actually
more
valuable
because
yeah?
If,
if
we
have
to
end
up
like
rewriting
the
code
to
prove
out
a
concept,
then
that
may
not
be
worth
it
either.
Yeah.
A
I
think
that's
it
not
just.
Is
it
viable
for
a
user,
but
is
it
viable
for
us
to
build?
This
is
a
super
important
question
as
well,
as
does
it
move
us
forward
towards
our
goal
of
increasing
that
Weekly
active
user
account,
so
there's
a
couple
of
things
that
we
can
take
into
account
when
we
start
to
look
at
a
prototype,
regardless
of
what
it
looks
like
is
it
you
know
me
sketching
something
out
and
handing
it
Kevin
and
Kevin
making
it
look
pretty,
and
then
we
get
together
in
this
meeting
and
say:
hey
yeah.