►
From YouTube: ux roadmap mini ama 2022 08 16
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).
C
I
guess
first
question:
what's
different
than
what
we're
doing
with
maintaining
our
sage
and
category
direction
pages,
it's
not
a
question,
it's
more
like
feedback
or
like
something
that
would
be
cool
to
work
through
together.
Is
that
like
when
I
read
the
the
ux
roadmap
handbook
page,
it
makes
sense
and
the
way
we're
packaging
up,
as
you
said
in
your
comment
here
makes
sense.
But
if
you
want
to
verbalize
that
first,
you
want
to
verbalize
just
for
the
recording,
or
would
you
like
to.
A
A
A
So
it's
a
way
to
take
those
and
put
them
into
what
we
call
themes
which
is
really
just
a
grouping.
So
it's
a
way
of
working
with
all
of
those
issues.
I
wouldn't
say
that
it's
different
than
the
direction
pages.
It's
just
a
different
way
of
looking
at
it.
It's
they
should
work
together.
You
know
it's
allow
teams
to
act
on
all
these
individual
objects
in
a
more
holistic
way
right.
A
So
somehow
or
another
once
everyone's
down
with
road
maps,
I
think
it
would
be
great
if
they
could
link
be
linked
on
direction
pages,
for
instance,
so
people
can
go
back
and
forth.
You
know,
but
they're
not
meant
to
take
away
from
all
the
work
that
product
does.
It's
meant
to
be
additive.
It's
really
just
meant
to
sort
of
help
us
take
all
that
and
and
then
figure
out
a
way
to
work
on
it
like.
How
do
we
do
all
that
stuff.
C
C
C
It
rubbed
me
the
wrong
way:
the
intentions
weren't
good,
but
as
a
product
manager.
I'm
like
I'm
confused
about
this,
because
we
already
have
direction
pages
that
we
maintain
as
a
single
source
of
truth
that
we
put
out
to
the
field
that
we
like
tell
everyone
about
to
go.
Follow
that
we
update
every
month.
C
But
I
also
think,
like
part
part
of
what
like
made
me,
feel
tension
I'll
phrase
it.
That
way
is
also
just
like
we
have
so
many
processes
like
we
have
and
a
lot
of
these
processes
are
happening
like
in
silos
right
to
a
certain
degree
like
now.
We
have
this
next
prioritization
framework.
We
have
to
have
a
certain
ratio
of
things
that
we
work
on.
We
have
ux
themes,
we
have
ux
roadmaps,
we
have
product
direction
pages,
we
have
jobs
to
be
done.
We
have
category
maturity,
scorecards,
which
basically
jobs
to
be
done.
C
We
have
top
12
initiatives.
We
have
this
next
prioritization
thing
and
it's
all
sort
of
sort
of,
like
everyone's
everyone's
feeling,
the
pain,
points
of
competing
priorities
and
things
like
that
and
everyone's
sort
of
going
off,
creating
their
own
ways
to
try
to
solve
it,
and
it's
just
creating
more
noise
and
less
signal.
Does
that
make
sense.
A
Absolutely
the
timing
for
some
of
this
is
not
great
right,
everyone's
sort
of
coming
out
with
new
solutions.
All
the
same
time,
I
think
that
they're
relational,
but
the
first
thing
I
want
to
address
is
something
that
you
brought
up
a
few
times,
which
we
also
were
aware
of
and
concerned
about,
is
using.
A
Road
map,
we
were
very
cognizant
of
how
that
could
be
interpreted,
and
we
tried
to
explain
it
by
in
in
the
documentation
the
text
of
the
of
the
handbook
by
saying
it's
not
taking
away
from
the
road
map
that
product
has
put
together.
You
know
it's
it's
or
the
even
the
north
star.
It's
it's
really
referencing
those
same
things.
They
are
the
same
thing.
That's
why
it's
just
a
wrapper
around
that
content,
so
so
designers
and
product
teams
will
know
how
to
actually
work
off
of
that
vision
or
that
that
direction
page.
C
Well,
I,
like
the
term
road
map.
I
like
it
better
than
direction.
It's
no
one
outside
of
get
live
knows
through
the
direction
like
that's
something
we
came
up
with.
That
is
not
industry
standard.
Everyone
says
what's
github's
roadmap
or
you
know,
like
that's
common
yeah.
I
think
it's
just
like
classifying
it
as
a
ux
roadmap.
Instead
of
just
like
saying,
we
have
a
direction.
C
This
process
is
it's
definitely
this
player
saying
if
you
want
to
verbalize
additive
but
like
how
do
we
de-duplicate
things
so
that
this
is
maybe
how
we
present
our
direction
pages
or
our
roadmaps,
and
we
just
call
them
a
roadmap
or
a
product
map,
or
something
like
that.
You
know
like,
I
think,
that's
sort
of
where,
like
the
outcomes
that
we're
all
going
after
are
the
same
yeah,
it's
just
sort
of
like
how
do
we
simplify
things
down
for
everyone?
A
So
we
were
leery
of
those
two
things
conflicting
and
also
just
coming
in
and
trying
to
get
the
ball
rolling
initially,
as
opposed
to
starting
out
by
saying
how
can
we
merge
directions
with
this
ux
roadmap
direction
pages
with
the
extra
map,
I
mean
that
that
seemed
like
a
bigger
thing
that
I
agree
with
you.
We
should
definitely
figure
out,
but
we
were
going
to
figure
it
out
afterwards,
once
we
started
moving
down
this
path,
how
do
direction
pages
merge
or
work
with
ux
roadmap
so
that
this
concept?
A
A
A
E
Gave
from
your
example,
like
category
maturity,
score
cards,
job
to
be
done,
ux
road
maps,
ebx
themes
is
probably
from
that's
been
themes,
top
12
initiatives
right,
so
the
ux
themes
are
based
on
jobs
to
be
done,
which
then
can
be
tested
with
category
majority
scorecards,
which
then
the
ux
themes
can
also
be
prioritized
based
on
product
investment
themes
or
even
built
around
those,
as
well
as
the
top
12
initiatives.
So
ux
themes
themselves
are
a
container
of
all
the
things
we
already
are
doing.
C
Yeah,
I
think
my
my
beef,
though,
is
like
don't
call
them.
Ux
names,
they're
pro
they're
product
things,
they're
not
specific
to
ux,
just
like
I'm
a
product
manager,
but
I
don't
consider
my
product
roadmap,
my
roadmap,
it's
it's
a
team
thing
right,
it's
my
product
group,
but
is
in
our
hierarchy
right
and
I
guess,
like
that's
sort
of
the
things
like.
I
just
want
to
have
a
theme,
a
set
of
themes
right
and
those
themes
can
be
based
on
jobs
to
be
done,
which
is
fine
right.
C
C
Invest
in
what
we
don't
do
and
trying
to
be
like
kind
of
more
data
driven.
That
way-
and
I
guess
that's
just
where,
like
I'm,
I
want
to
like
everything.
That's
on
the
ux
roadmap
page
is
like
a
great
process,
but
it's
the
packaging
of
it
separate
from
everything
else
and
then
trying
to
like
figure
out
how
to
reconcile
this
call
later,
like.
I
don't
have
two
two
different
theme
labels,
one
for
my
theme
for
product
one
for
like
my
ux
theme
and
have
everything
be
like
confusing.
A
C
C
Why
do
we
have
ux
scorecards
and
then
category
maturity,
scorecards
and
then,
like
all
these
different
things
and
then
jobs
to
be
done,
and
then
all
these
over
like
how
do
they
all
relate
together
and
the
way
that
I've
always
been
thinking
about
is
the
same
way
where
you
have
jobs
to
be
done
right?
Those
get
put
into
themes,
I've
even
grouped
that
on
my
job,
so
you
know
page
already
and
sort
of
themes,
and
then
that
is
sort
of
how
we
think
about
where
we're
going
and
what
what
problems
we're
trying
to
solve.
C
So,
I
guess,
like
I
hope,
I'm
not
too
much
or
coming
across,
like
I
am
negative
about
it.
I
just
think
it's
it's
important
to
not
create
these
sort
of
silos
right
because
even
in
the
the
issue
that
talked
about
the
workshop
right,
I
think
one
of
the
bullet
points
is
like
the
product.
Designer's
gonna,
take
the
outputs
of
this
and
then
they're
gonna
go
schedule.
Everything
right
like
what
I
want
to
happen
is.
I
want
the
outputs
of
this.
A
A
A
So
it's
it's
doing
that
and
then
when
when
it
says
that
the
designer
would
prioritize
things,
it's
not
it's!
It's
taking
the
road
map
that
you've
already
prioritized
and
making
sure
that
they're,
you
know
pushing
for
those
types
of
things
to
actually
happen.
When
you
do
your
planning,
your
milestone,
planning,
you
know,
that's
that's
what
it's
getting
at,
but
they're
all
related
to
each
other.
It's
not
like
all
of
a
sudden.
The
the
designer
is
changing
the
way
that
they're
working
with
their
team.
You
know,
that's
not
the
intent.
You
know
they're,
not
leading
anything.
A
C
Yeah
I
I'll
sort
of
bring
up
too,
like
I
didn't,
listen
here,
because
it's
sort
of
outside
product
and
ux
in
engineering,
but
there's
also
the
sales
organization
and
the
marketing
organization.
They
maintain
what
they
call
use,
cases
and
solutions
and
all
the
same
stuff.
That
is
the
same
thing.
That
is
a
jobs
to
be
done
and
a
theme,
and
so
like
what's
interesting
about
this,
is
they've
duplicated
that
all
the
same
things
that
we're
doing
in
r
d.
C
But
it's
packaged
differently
and
it's
in
not
necessarily
a
good
way
because
now
there's
like
a
disconnect,
because
we,
if
you
go
talk
to
somebody
in
marketing
they're,
like
yeah,
I'm
working
on
document
on
all
plans,
use
cases
right
and
solutions,
and
it's
sort
of
like
when
I
look
at
what
that
comes
out
to
be
it's
the
same
exact
content
that
we're
producing
in
r
d
so
like.
I
think,
there's
also
that
this
is
outside
the
scope
of
this
first
step.
B
C
B
E
C
B
A
Well,
the
job
to
be
done
is
it's
a
it's
a
way
of
phrasing,
the
user's
goal
that
they're
trying
to
achieve
right?
Why
would
they
hire
us
as
a
tool
to
achieve
their
goals
and
then
that's
at
a
higher
level?
It's
agnostic!
That's
that's
where
it's
it's
supposed
to
live,
to
help
generate
solutions
or
ideas
for
solutions
or
what
a
product
could
be
or
might
be
helping
the
user
solve
those
problems.
You
know,
therefore,
they
would
then
hire
us
to
do
the
job
right.
A
That's
where
jobs
to
be
done
comes
from,
so
we
would
take
that
as
a
starting
point
to
help
us
wrap
our
issues
into
a
jobs.
Degree
done
theme
right
that
that
makes
sense.
Everything
within
that
theme
should
be
helping
support
solving
or
achieving
that
job.
That
goal
right
and
the
solution.
I
remember
there
was
something
weird
about
how
it
was
contexted,
but
at
a
general
level
the
solution
is:
how
are
you
solving
that
particular
thematic
goal
or
job?
What
is
the
design
solution?
For
instance?
A
B
C
E
Yeah
yeah,
so
I
think
the
idea
came
about
around
two
years
ago
when
we're
working
on
adding
a
new
filter
from
one
of
the
pm's
insecure.
I
think
it
was
like
I
can't
remember
its
time
but
pick
one
category,
so
we
go
and
add
a
filter
and
then
another
pm's
like
hey,
you
know
we.
We
also
want
to
add
a
filter
as
well,
because
the
page
is
kind
of
shared
and
then
I
just
started
looking
around
like
who
else
wants
to
add
filters
and
there's
like
five
more,
we
don't
have
the
filtered
search
component.
E
We
have,
you
know,
limited
space
and
then
we
start
looking
at
what
problems
are
we
trying
to
address
right?
There's
filtering,
there's
types
of
ways
to
advance
filter
and
we
started
like
expanding
on
that
like
this
is
all
about
trying
to
allow
users
to
narrow
down
on
specific
things,
but
we
were
already
siloed
enough
where
everyone's
like.
I
want
to
filter
for
this
specific
tool,
and
then
you
know
if
the
other
team
needs
it
whatever
so
they're
just
like
well,
let's
expand
out
and
stop
just
delivering
like
one
drop
down
in
the
ui.
E
At
a
time,
let's
solve
the
problem
holistically
with
you
know
a
single
design
solution,
that's
looking
at
all
the
needs
and
use
cases
that
have
been
presented
and
then
that
just
expanded
out
we
just
kept
doing
that
for
thread
insights.
It
was
like,
and
it's
turned
into
you
know,
working
with.
You
know,
potentials
for
adding
vulnerabilities
to
issues
right,
but
then
that
has
workflows
and
use
cases
to
account
for
how
would
that
look?
So
that
turns
into
a
theme.
E
We
have
a
direction
right,
but
the
direction's
often
like
a
bullet
point
and
we
can't
like
mvc
our
way
towards
that
bullet
point
so
like
designers,
should
be
designing
just
the
whole
workflow
around
that
job
to
be
done
or
that
problem
and
delivering
that
which
then
gets
turned
into
nvc's
through
planning
breakdown,
and
therefore
we
can
maintain
our
direction
and
our
approach
and
our
design
intent
as
opposed
to
kind
of
just
just
trying
to
get
stuff
off
our
plate
and
deliver
it.
Yeah.
C
This
is
like
this
is
where
we're
trying
to
go
over
here
and
plan,
and
it's
the
whole
idea
of
users
just
want
to
filter
things
down
and
search
for
things
right,
like
it's,
the
same
job
to
be
done
just
with
different
objects
across
all
the
different
stages.
Right-
and
I
said
hey
like:
can
we
you
want
to
work
together
on
this
and
figure
out
how
we
can
have
a
globally
optimal
solution
and
they're
like
no?
No,
we
just
want
to
go
fast
and
we're
going
to
get
done
right.
C
So,
like
yeah,
it's
the
sort
of
thing
like
when
you
have-
and
I
I
identify
that-
and
I
said
hey
like
we're,
doing,
duplicate
work
across
like
six
different
teams
and
none
of
it's
consistent
and
none
of
it
like
is
cohesive
and
it
doesn't.
It
doesn't
behave
the
same
way
across
these
different
objects,
and
it
should
because
it's
really
like
the
same
job,
there's
nothing
special
about
filtering
and
searching
really,
if
you
really
boil
it
all
down.
How
is
this
going
to
solve
that?
E
Well,
I
mean
what
this
aims
to
achieve
is
I
mean
you'll
be
able
to
see
what
every
other
team's
themes
are
right.
So,
at
a
higher
level,
you
can
understand
the
problems
they're
trying
to
solve
so
that
you
can
collaborate
with
those
teams,
as
opposed
to,
like
you
know,
semi-cryptic
issue,
title
and
you're
like.
I
have
no
idea
what
that
means,
but
really
it's
just
searching
searching,
contain
retainer
image
types
rate,
but
it
might
be
something
different.
E
The
global
problems,
not
something
we
are
set
up
to
solve
for,
like
signing
teams,
global
autonomy
for
specific,
wide,
ranging
features.
This
is
more
about
getting
designers
to
focus
on
just
one
level
up
from
the
feature
delivering
that
as
well
as
getting
teams
aligned.
Even
though
it's
gonna
still
be
active
alignment,
it's
not
passive.
A
Yeah,
I
think
this
was
a
a
secondary
goal
to
help
teams
higher
than
secondary.
But
you
know
whatever
secondary
in
between
secondary
primary
goal,
is
to
help
teams
better
see
what
everyone
else
is
doing
in
order
to
help
fight
that
siloing
effect
that
we
everyone
knows,
we
have
in
a
way
that
isn't,
I
guess,
mvc
to
some
degree,
one
way
to
solve
what
you're
saying
gabe
is
to
change
the
way,
we're
organized
work.
A
Instead
of
teams
working
on
groups
in
groups,
teams
work
on
workflows,
they
design
an
entire
workflow,
that's
their
purview
or
multiple
workflows
whatever,
but
that's
a
huge
org
change.
That's
a
huge
paradigm
shift
that
is
well
outside
andy
and
I's
scope
and
ability.
So
we're
we're
trying
to
see
if
there's
other
things
that
we
can
do
that
within
our
existing
framework.
A
Yeah,
the
the
thing
is:
it'll
still
we'll
have
these
road
maps,
but
we
have
to
also
still
communicate
them
and
aim
people
at
them
when
they're
having
hey
you're
having
these
problems,
seeing
what
everyone
else
is
working
on,
don't
forget
check
out
some
of
all
the
roadmaps.
You
know
somehow
there
needs
to
be
a
mechanism
and
annual
mechanism.
I
don't
know
where
you
read
or
watch
everyone's
roadmap
walk,
walk
through
five
minute
video
you
know
like
every
year
team
creates
those.
Perhaps
that
might
be
one
solution
like
we'll
have
to
figure
that
out
too.
B
C
These
two
things,
so
there
is
only
one
theme
so
there's
this,
which
is
something
that
I'm
getting
ready
to
like
have
the
product,
some
of
the
product
managers
start
working
on
right
and
then
there's
this.
Where
there's
this
like
ux
theme
label
here
and
what
I
meant
by
bottoms
up
themes
is
like
it's
exactly
the
same
thing
context
is,
I
think
what
you're
saying
is
ux
theme
where
we're
looking
at
our
jobs
to
be
done.
We're
looking
at
what
our
customers
need.
C
It
has
this
much
value
behind
it,
speaking
of
ar
or
future
ar,
and
I
want
to
invest
in
it.
So
I
would
like
to
make
an
investment
case
to
have
more
people
be
devoted
to
solving
this
theme,
or
you
know
that
sort
of
thing
so
it'd
be
nice
if
we
could
figure
out
a
way
to
only
have
one
set
of
theme,
labels
and
that
way
like
we
don't
have
overarching
labels
fatigue
either.
C
Right,
like
you,
can
have
themes
that
come
from
the
top,
because
they're
the
top
12
initiatives
and
you're
going
to
label
all
of
your
epics
and
issues.
Accordingly
or
you
can
have
some
from
the
bottom
up
where
the
product
designer
and
product
manager
realize
hey,
here's
a
grouping
of
themes
are
things
that
should
map
to
this
theme
that
map
these
jobs
be
done.
Let's
go
ahead
and
bubble
it
up,
so
that
leadership
can
see
this
set
of
things
that
we
want
to
work
on.
Does
that
make
sense.
A
Yeah-
and
I
think
that
that
would
be
great
if
we
could
figure
out
a
way
to
merge
two.
I
I
also
agree
with
everything
you're
saying
there
shouldn't
be
multiple
ways
to
skin
this
cat
we're
at
time.
Unfortunately,
but
I
think
the
next
step
would
be
to
figure
out
how
to
how
we
can
work
together
on
this.
A
You
know,
maybe
maybe
once
we
create
the
roadmap
or
go
through
the
do
the
workshop
anyway.
You'll
have
a
better
idea
of
how
we
can
do
this,
because
I
don't
know
anything
about
your
process
that
you're
showing
here
but
you're,
about
to
know
more
about
the
ux
roadmap
process.
So
maybe
we
can
take
those
two
knowledges
and
work
together
to
figure
out
how
to
merging.
E
C
I
don't
care,
it
doesn't
have
to
live
in
the
product
handbook,
but
just
some
single
source
of
truth
that
people
could
look
at
so
they're
not
like,
because
if
you
imagine
a
new
person
coming
into
gitlab
today,
a
new
product
manager,
a
new
product
designer
and
seeing
all
these
different
places,
they're
going
to
be
really
confused
and
then
engineering,
I
think,
also
has
something
similar.
That's
like
duplicate
content
as
well,
so
just
something
to
think
about
and
I'll
be
thinking
about
it
too,
but
yeah
looking
forward
to
the
workshop
thanks
for
that.