►
From YouTube: 2023-06-28 Product Analytics UX/PM Sync
Description
This week with co-working!
Great discussion about usability testing the custom dashboard flow and kicking off user story mapping for viewing usage of Product Analytics.
A
Welcome
to
the
product
analytics
PM
ux,
weekly,
sync
for
June
28th,
2023,
jumping
into
the
agenda.
Looking
back
last
week,
we
didn't
have
any
action
items,
favorite
async,
so
moving
into
sticky
items
first
is
reviewing
latest
prototype,
reviewer
results
and
we're
testing
usability
around
the
custom,
dashboard
creation
flow
Kevin.
You
want
to
jump
in
talk
through
the
results.
B
Yeah
so
I
think,
like
so
far
the
first
round
of
testing
kind
of
show
that
we
don't
have
necessarily
some
usability
issue.
So
that's
that's
a
good
thing.
We
can
keep
going
with
that.
Some
of
the
stuff
that
we've
Gonna
notice
is
that
some
terms
like
Dimension
and
things
like
that
can
be
a
bit
blurry
and
it's
something
that
we
could
iterate
on
either
on
the
copy
or
just
simply
having
like
some
helpers
on
the
fields.
B
So
that's
potentially
one
of
the
things
that
that
I'm
thinking
about
changing
for
the
next
round
and
we're
thinking
about
that
James,
then
the
other
thing
about
kind
of
user
value,
I
think
it's
a
treaty
one
to
assist
with
on
moderated
testing
so
like
you
can
check
his
ability,
but
this
desire
ability
is
a
bit
trickier,
yeah,
so
yeah
hard
to
answer
for
now.
I'd
say,
though,
there's
still
like
the
general
flow
of
things,
all
right
and
I
think
we
should
pursue
like
this
this
direction
and
keep
testing
again
and
again.
A
No,
that
that'll
make
sense
to
me:
yeah
I,
agree.
Getting
user
value
out
of
these
sessions
was
like
the
script
wasn't
tuned
for
that,
but
we
definitely
tested
the
usability
I.
Think
we
went
in
with
the
hypothesis
or
just
the
assumption
that
there's
value
in
creating
a
custom
dashboard
based
on
other
discussions
that
we've
had
and
seeing
the
excitement
and
the
field
team
and
customers
as
we
talk
to
them
about
the
custom
dashboard
so
having
one
is
something
that
is
desirable
and
viable
to
customers
yeah.
So
that
seems
seems
like
we.
A
We
proved
out
it's
usable
in
its
current
flow.
We
have
ideas
around
iterating
and
scoping
down
now
and
yeah
I
think
you
mentioned,
or
saw
a
comment
from
last
week
that,
from
a
technical
perspective,
building
what
we
have
is
viable,
especially
removing
some
of
the
things
that
we've
talked
about:
removing
and
choosing
existing
visualization,
safe,
visualizations,
so
that's
exciting
and
then
at
Birth
iteration
Kevin.
You
have
voice
over
years.
B
A
A
Yeah,
because
that
if
we
remove
that
from
the
flow-
and
we
say,
hey
visualization
designer
is
its
own
big
ball
of
wax,
there
were
problems
with
what
does
a
dimension
mean
and
other
parts
that
are
part
of
that
flow
anyway.
So
a
custom
dashboard
is
I,
can
rearrange,
basically
the
default
dashboards
and
choose
only
the
panels.
I
want
on
them
and
that's
our
first
step
into
custom.
Dashboard
creation.
B
It
would
be
definitely
simplifying
it,
so
I
guess
in
the
end,
it's
like
do
longer
term.
We
feel
that
it
should
be
decorated
from
the
flow
yes
or
no,
and
if
yes,
then,
yes,
we
could
simplify
it.
Go
with
like
some
predefined
example
of
visualization
and
then
move
the
visualization
designer
outside
of
this
flow,
or
if
you
feel
that
they
should
be
tied
together
in
the
future,
then
I'd
say
we
should
keep
testing
with
visualization
designer
as
part
of
the
custom
dashboard
flow
I.
A
Think
they
should
but
I,
don't
think
that
we
have
to
do
that
now.
If
we
have
to
go
like
we
shouldn't,
stop
building
the
dashboard
designer.
Let's
get
the
dashboard
designer
out
there.
Let
users
build
play
with
it
and
that'll
give
us
more
information
about
the
usability
of
that
anyway
and
then
go
fix
the
visualization
designer,
because
if
we
go
into
like
if
I
edit
a
custom
dashboard
today,
too
many
screens
guys
I,
don't
have
no
idea.
What
that
looks
like
on
your
side.
D
D
C
So,
on
the
one
hand,
you're
trying
to
I'm
just
trying
to
understand
like
what
we're
trying
to
trade
off
here
like
we
want
to
go
higher
Fidelity
so
that
we
can
understand
what
the
user's
thinking
in
terms
of
having
more
choice
in
terms
of
picking
existing
visualizations
right.
But
then
James
is
suggesting
of
simplifying
the
number
of
drop-downs.
They
would
see.
What
would
because.
C
C
A
Problems
yeah,
so
I
think
it'd
be
helpful
to
share
the
flow.
So
today
this
is
what
we
tested
users
with
of
choosing
a
data
source
which
we
don't
support
today
and
building
a
visualization
as
the
first
step.
What
I'm
saying
is,
let's,
instead
of
say,
DB
or
file
here
just
say
pick
the
project
that
you
want
data
from
on
step.
Two.
A
Let's
go
figure
out
what
dimensions
should
be
called
and
all
of
the
other
things
that
have
come
up
around
the
visualization
designer,
because
we
can
launch
that
at
the
Dome
feature
where
you
explore
data
and
then
save
a
visualization
and
add
it
here
once
that
below.
We
feel
good
about
the
usability
up.
We
can
put
that
back
into
the
dashboard
creation,
but
we
don't
have
to
wait
to
release
dashboard
creation
and
test
it
with
this.
C
Okay,
so
effectively
build
two
different
I
mean
the
two
separate
workflows
anyways,
but
that
allows
us
to
push
out
dashboard
designer
sooner
and
then
oh
ideally
marry
it
back
together.
Once
you've
made
changes
to
whether
we
add
helpers
or
explain
things
better
or
rethink
the
nomenclature
for
the
utilization
designer
as
far
as
dimensions
and
measures
are
concerned
and
then
bring
that
back
into
the
dashboard
designer
experience.
Yeah.
A
A
The
current
flow
has
that,
as
like
the
last
step
in
the
process
where
you
can
save
your
dashboard
and
go
to
it
or
add
another
visualization,
and
it
takes
you
back
to
step
two
so
you're
saying
step.
Two
then
becomes
the
loop
and
step.
Three
is
really
the
final.
Like
once
you're
happy
with
the
visualizations.
You
have
continue
to
see.
B
I'm
thinking
that,
if
we
I
think
we
can
do
this,
if
we
just
follow
this
path,
I
think
we're
kind
of
branching
into
another
one
and
we'll
have
to
again
do
at
least
one
or
two
outside
of
that,
because
it's
kind
of
a
different,
it's
the
same
flow,
but
this
second
step
is
actually
quite
critical.
So
then,
if
we're
changing
it,
it's
it's
a
big
piece
of
the
soul
that
we're
changing.
So
then,
maybe
we'll
see
how
that
goes
in
terms
of
testing,
but
I
assume
that
beakers
were
changing.
B
This
part,
we
might
uncover
new
things
that
will
lead
us
to
potentially
to
another
round
of
testing,
which
is
fine,
I,
think
it's
just
something
that
we
should
consider
like,
because
we're
changing
this
whole
part
of
the
flow
it's
almost
as
if
not
that
we're
restarting
from
zero,
but
like
it's
a
big
change.
So
then,
therefore
we
might
be
in
for
another
two
extra,
that's
what
I
would
say:
yeah
like
I'm
saying
two
extra
like
if,
if
we
commit
to
that,
I
can
definitely
like
have
something
fleshed
out
by
the
end
of
the
week.
B
Iterate
on
the
tasks
that
we
give
people,
it's
called
moderator,
testing
and
then
launch
it
have
the
results,
maybe
either
earlier
next
week
and
then
keep
it
or
anything
like
that.
So
it's
like
it's
also
like
it's
fine
that
way
it's
not
going
to
take
a
lot
of
time
as
well,
I
assume
so,
but
it's
just
that.
It's
something
that
we
need
to
factor
in
like
okay.
If
we
want
to
like
change
that
direction,
it's
it's
all
right,
but
let's
at
least
make
one
or
two
extra.
A
It
seems
reasonable
and
we
don't
have
external
customers
on
yet
anyway,
we
won't
for
another
week
or
two
anyway,
so
we're
not
going
to
get
that.
You
know
Live
customer
feedback
any
sooner.
If
we
don't
do
the
testing
and
move
straight
to
build,
so
it
seems
reasonable
to
do
another
round
of
user
testing
with
that
reduced
flow
and
then
flip,
so
that
adding
additional
visualizations
happens
on
step.
Two.
B
But
yeah
this
is.
This
is
really
weird
like
having
some
kind
of
job
to
be
their
own.
Research
nailed
out
would
kind
of
help
us
I'm
like
okay.
Is
it
really
does
it
need
to
be
really
trimmed
down
as
an
resurface,
templates
and
stuff
to
have
them
pick,
or
should
they
be
able
to
create
it
themselves
so
yeah?
That's
that's
and.
A
I
think
long
term
yeah
they
do
need
to
be
able
to
create
themselves,
but
I,
don't
think
we
have
to
wait
to
release
the
feature
to
to
flush.
That
part
out
is
what
I'm
driving
at
is.
We
can
release
dashboard
creation,
as
this
is
the
first
step
in
that
flow.
You
can
build
a
dashboard
and
put
existing
visualizations
on
it.
That's
already
part
of
the
core
workflow
someone's,
probably
going
to
do
that,
then
we
want
to
give
them
hey.
A
I
want
to
go
design,
my
own
visualization,
like
I,
just
want
you
know
this
number
of
events
or
just
you
know
the
events
over
time
or
whatever
it
might
be.
Well,
let's,
let's
tackle
that
problem
next
and
then
we
can
work
it
back
into
that
job
to
be
done
if
I
need
just
the
data
I
care
about
on
a
dashboard
cool
awesome.
That
was
good
discussion
thanks,
y'all.
C
Because
I
think
engineering
wise
too,
and
you
know
I-
can
correct
me
because
I'm
probably
wrong,
but
that's
how
we
were
thinking
about
it
from
just
a
iterative
standpoint
of
like
you've
created
the
dashboard.
It
is
more
restrictive
because
you
can
only
add
existing
visualizations,
but
then
eventually
will
give
you
that
way
to
create
a
custom
one
and
then
yeah
that
will
kind
of
modify
the
job
to
be
done
back
with
the
dashboard
designer.
But
ultimately,
we'd
want
to
be
able
to
just
say
yeah.
D
The
first
iteration
of
going
from
a
new
dashboard
or
custom
dashboard
designer
to
the
visualization
designer
and
then
back
has
actually
just
been
merged
because
on
on
staging,
but
we
still
have
the
open
question
about
like
I
feel
like
I
would
be
more
comfortable
if
we
first
ship
the
dashboard
designer
and
then
ship
the
visualization
designer.
So
we
may
end
up
hiding
that
behind
like
a
feature
flag.
Until
we
have
the.
D
A
bit
more
figure
out
but
functionally
it's
it's
there.
The
flow
works
really
nicely
because,
like
you
said,
I
feel
like
if
I'm
grading
a
dashboard
yeah
I
want
to,
like
you
know,
play
around
for
this
and
create
a
new
visualization.
It's
also
slow
to
then
immediately
come
back
and
be
able
to
edit
but
yeah
how
we
release.
That
is
still
an
open
version.
C
D
It
also
seems
like
we're:
gonna
have
to
like
feedback
entry
points
because,
on
the
one
hand,
we're
working
on
our
feature
flagged
dashboard
and
visualization
designer
and
then
we're
also
testing
with
users
like
the
the
onboarding
process,
basically
for
creating
like
a
dashboard
with
the
other
float.
So
we
we're
kind
of
getting
like
yeah
like
different
feedback
from
different
implementations.
So
that's
also
actually
benefit.
C
A
Okay,
so
I
think
we
can
skip
over
next
validation,
since
we
have
another
round
of
this
and
we'll
pick
that
up
next
week
in
the
interest
in
moving
forward
in
the
agenda,
I
updated
the
existing
planning
issues
with
that
new
design
section
that
got
merged
into
the
planning
issue,
template
Kevin
and
Dennis.
If
you
could
take
a
look
at
the
16-3
issue
and
fill
in
any
design
worker
research,
work
I
when
I
say
filled
in
I,
just
dropped
in
the
template.
C
A
And
then
I
wanted
to
talk
through
I
started
a
user
story.
Mapping
issue
around
the
usage
quota,
billing
flows,
so
I
wanted
to
take
a
quick
look
at
that
with
the
time
that
we
have
left
before.
I
introduced
it
to
the
team
and
we'll
get
some
good
team
feedback
too
need
for
the
TV.
So
we
did
is
the
view.
Okay,
for
you
guys.
A
C
A
Good
okay,
thank
you.
So
what
I
want
to
do
is
engage
with
the
team
in
building
out
the
user
story
map
for
users
who
want
to
see
their
usage
of
product
analytics,
we're
circling
in
on,
like
there's
got
to
be
billing
based
on
some
sort
of
consumable
sort
of
consumption-based
pricing
or
usage-based
pricing.
What
that
actually
is,
and
the
price
of
it
EBD
sorting
through
that
now.
A
I
have
a
review
with
Sam
today
around
that
topic,
but
regardless
of
how
we
build
and
what
we
built
on
they're
going
to
want
to
see
how
many
of
that
thing
have
I
done
this
month,
and
what's
my
build
looking
like
today?
What's
it
projecting
like
into
the
end
of
the
month,
or
you
know
how
much
have
I
spent
last
month?
How
does
this
month
prepare?
A
A
Our
first
path
as
a
and
then
I
recorded
a
quick
video
and
uploaded
it
as
far
as
actually
going
through
and
creating
the
tasks
and
dropping
them
in
kind
of
the
first
step
of
what
are
all
the
tasks
that
someone
would
do
to
solve
for
this
problem.
So
I
wanted
to
get
feedback
from
y'all
about
this.
We
can
do
it
live
for
a
couple
of
minutes.
C
A
Hey,
let's
start
with
the
problem
to
solve
yeah
of
problem
analytics
users
connecting
to
the
management
event.
Cluster
will
be
charged,
something
based
on
usage
volume
of
something
being
sent
to
our
managed
cluster,
so
the
user's
work
for
them
is,
and
they
really
the
person
who
writes
the
check
I
want
to
see
my
team's
usage
of
product
analytics
and
team
is
multiple
teams
potentially
within
the
group,
so
I
can
ensure
we're
getting
value
out
of
that
investment.
C
They
probably
want
to
see.
Okay,
maybe
three
projects
that
are
collecting
events
like
what's
an
easy
way
to
see
like
the
distribution
of
that
but
I
think
from
a
first
iteration
I
guess
the
question
to
ask
is
like
for
the
first
iteration:
do
we
just
surface
information
only
at
the
project
level
for
now
and
then
it's
a
subsequent
follow-up
for
being
able
to
see
like
how
much
your
group
or
subgroups
are
using
all
of
it
or
how
does?
How
do
we
even
Bill
based
on
that
actually
is
another
yeah?
C
Can
a
customer
buy
five
million
events
and
then
all
their
their
groups
are
allowed
to
just
use
as
much
of
that
as
possible?
Or
do
we
restrict
it
or
do
they
buy
it
for
their
projects,
which
would
actually
be
a
very
important
question
to
ask
as
I
imagine,
Zora
or
whatever
we
use
for
billing
will
will
have
to
be
set
up
in
that
way?.
B
B
B
So
basically
I'm
just
I'm,
just
saying
that,
because
if
it's,
if
then
we're
going
to
start
charging
people
free
for
even
sorry,
that's
probably
where
it
should
be,
because
this
is
where
we
have
it
from
like
navigation
perspective.
I
get
a
lot,
but
that's
that's
already
going
into
the
solution
or
slash.
A
This
already
helped
me
with
one
of
the
instructions
needs
to
be
there's
a
lot
of
questions
that
we
don't
know
the
answers
to.
We
don't
need
to
know
the
answers
for
this
step
of
list
out
all
the
possible
paths
assume.
The
answer
is
yes
to
all
of
them
and
let's
flush
out
the
task
for
all
of
them,
because
we
don't
have
to
start
restricting
our
results.
Yet,
let's
go
really
really
wide
first
and
then
we'll
figure
out
what
we
actually
need
to
build
and
we
can
chop
things
out
like.
A
B
C
Oh,
if
you're
hey,
you
know
basing
it
on
number
of
events
or
number
of
users
that
were
not
double
counting
or
not,
or
not.
Counting
correctly,
such
that
sorry
like
if
you
pay
for
100
users,
on
your
application
to
run
analytics,
for
example,
and
we're
counting
100
only
on
a
per
project
basis,
then
we're
actually
allowing
them
to
use
more
than
they've
actually
paid
for
so
I.
A
Will
say
that
the
the
model
that
we're
that
we're
going
to
propose
is
that
it's
not
free
buy
or
it's
not
a
hard
stock.
When
you
get
to
the
end
of
your
quota,
which
is
the
way
that
CI
admits
mostly
works
today,
instead,
it'll
be
consumption
based,
so
that,
and
that
could
be
some
of
the
tasks
is
I
want
to
set
a
threshold.
A
I
want
to
set
a
hard
stop
and
there's
other
competitors
out
there
who
say
once
you
get
up
to
the
maximum
of
your
current
land
level
that
you
just
have
a
hard
stop
and
in
fact,
I
read
one
page
today
and
they're
looking
surprising
stuff
about.
Then
we
restrict
access
to
your
account,
so
you
can't
even
get
to
your
data
once
you've
spent
too
many
events
like
whoa,
whoa
It's,
like
that's,
that's
not
very
user,
probably
hold
on.
A
Some
questions
in
there
I
just
added
a
question
section
so
that
we
can
add
them
and
I'll
update
the
instructions
to
better
reflect,
hey,
there's
a
lot
of
unknowns,
just
assume
like
right
task
for
unknowns,
assuming
that
they're
they're
true
or
that
that's
a
thing
that
we
want
to
go
build
and
we'll
figure
out
if
we
can
and
if
we
should
go,
build
it
later.
But
let's
get
everything
out
there
to
start.
So
we
can
make
the
trade-offs
of
those
things.
Knowing
that
they're
a
possibility.
C
D
Yeah
I
definitely
feel
going.
The
usage
route
simplifies
this
all
a
lot
because
then
we're
not
dealing
with
a
shared
budget
across
namespaces
and
projects
and
subgroups
and
managing
that
would
have
been
its
own
giant
tool.
Tell
me
about
it.
Buddy
I
feel
like
it
would
be
possible
to
learn
for
a
project,
but
yeah
definitely
good
to
check
in
with
what
we
currently
offer.
Is
this
viable
technically
I
feel
like
it
is,
but
yes,
I.
A
Mean
how
many
other
companies
provide
usage-based
like
billing
and
pricing
that
use
our
backend
Billing
System,
to
do
that
so
I
assume
that
our
provider
provides
that
ability,
our
interface
with
that
could
need
some
work.
So
maybe
we'll
get
some
experience
with
that
part
of
the
stack
as
well.
Who
knows
I
guess
we'll
see.
A
D
Either
our
side
of
theirs
but
yeah
I
know
from
memory
that
a
lot
of
their
issues
don't
stem
from
the
fact
that
they're
working
with
existing
like
features
yeah
and
trying
to
group
that
together
and
make
the
building
more
obvious
and
visible
where
we're
starting
from
fresh.
So
we
have
cleaner
playing
field
to
work
with
yeah.
It's.
C
Just
more
of
a
Reconciliation
standpoint:
it's
like
I,
don't
know
how's
the
world
works
at
all,
but
if
you
start
buying
back
excuse
on
a
per
project
basis,
is
it
easy
to
to
reconcile
that
from
the
billing
perspective
at
the
group
level
so
that
we
can
surface
that
information
back
to
them?
Because
there's
going
to
be
someone,
that's
going
to
be
asking
the
question:
okay,
I've
got
30
engineering
we're
at
times
right,
they're
overtime,
30
engineering
teams
and
we're
they're
all
using
all
the
stuff.