►
From YouTube: UX Showcase: My PM experience
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
Cool
I'll,
try
and
catch
up
on
time.
Let's
see
how
we
do
so
so
desktop
one
and
presentation.
Where
is
the
there?
It
is
lovely
okay.
So,
for
the
last
three
or
four
months,
I've
been
on
interim
apprentice
pm
for
the
the
optimize
group,
formerly
known
as
analytics
group.
A
So
I
just
want
to
sort
of
talk
about
my
experience
of
being
a
pm
and
some
of
the
learnings
that
I've
taken
away
from
it
and
how
I'm
going
to
apply
those
learnings
to
to
my
future
life
as
a
designer.
So,
as
I
said,
I'm
in
the
optimized
team,
which
is
the
stage
group
formerly
known
as
value
stream,
which
is
the
artist
formerly
known
as
analytics
and
as
I
said,
I
was
a
senior
designer
for
the
the
the
optimized
team.
A
I
get
so
confused
with
this,
and
then
I
I
stood
in
for
a
few
months
as
the
product
manager
and
now
larissa
has
joined.
She
moved
from
a
different
part
of
gitlab's
product
and
now
I'm
back
to
being
a
designer
and
I'd
say
that
our
time
within
the
analytics
team
we've
seen
how
I'd
phrase
it
as
a
some
iteration.
A
So
we've
had
a
few
pr
different
product
managers
sort
of
stepping
in,
and
this
has
had
a
sort
of
a
bit
of
an
impact
on
the
way
that
he,
the
team,
has
sort
of
collaborated
and
how
we've,
how
how
we've
maintained,
focus
and
and
all
that
sort
of
good
stuff.
A
So
some
of
the
key
challenges
that
we've
had,
which
have
sort
of
related
to
this
turnover
of
pms
is
optimize,
has
a
number
of
different
categories
which
are
still
relatively
nascent
both
to
gitlab
and
also
to
the
markets
themselves.
So
priming
product
market
fit
has
been
difficult.
There's
a
lot
of
technical
constraints
with
the
the
data
scope
that
we're
working
in
when
it
comes
to
working
across
the
instance
and
and
finding
the
right
amount
of
performance.
A
And
then
we
there's
also
a
lot
of
stakeholders
that
we
need
to
that.
We
need
to
keep
happy
and
and
balance
and
and
and
satisfy
with
some
of
the
stuff
that
we're
shipping.
So
these
are
all
some
of
the
things
that
that
potentially
led
to
some
of
the
turnover,
as
well
as
as
as
sort
of
like
shaping
the
way
that
our
team
operates.
A
So
what
it
feels
like
to
design
within
this
sort
of
context,
where
the
pm's
changing
a
lot
of
the
time
is
that
it's
been
lots
of
different
pivots
and
what
sometimes
felt
like
wasted
work,
not
really
being
able
to
plan
two
or
three
milestones
milestones
ahead,
but
also
going
from
like
sort
of
milestone
to
milestone
being
quite
tactical,
not
enough
iteration
or
incremental
iteration,
and
also
sort
of
relatively
poor
communication
and
understanding
between
the
different
disciplines
in
the
team.
A
So
we
really
wanted
to
to
address
this,
and
I
really
wanted
to
try
and
address
this
in
my
time
that
I
I
was
acting
pm.
A
So
when
I,
when
I
was
told
that
I
would
be
bm
by
by
jeremy,
I
was
a
little
bit
surprised,
but
I
sort
of
had
a
number
of
first
very
glaringly
obvious.
First
impressions-
and
the
first
thing
that
happened
to
me
was
my
calendar
sort
of
filled
up
exponentially
and
I
moved
from
maker
time
to
manager
time,
and
that
was
a
big
shock
to
the
system,
especially
being
gitlab
and
working.
A
The
way
that
we
do
so
yeah,
having
maybe
an
hour
or
two
of
meetings
a
day
to
four
or
five
hours
of
meetings
a
day
was,
was
yeah
big
shock
to
the
system.
A
I
was
being
asked
to
participate
a
lot
more
in
meetings,
so
I
had
to
sort
of
bring
my
a-game
to
those
five
hours
of
meetings
as
well,
so
that
was
a
again
another
challenge,
and
I
also
needed
to
be
a
lot
more
mindful
and
aware
of
all
the
issues
which
were
coming
through
the
the
pipeline,
all
the
stuff
within
the
value
stream,
beyond
just
the
scope
of
of
ux
and
front-end.
A
So
again,
this
required
me
to
to
learn
quite
a
bit
more
about
what
was
happening
on
the
back-end
side
of
things,
as
well
as
get
a
broader
understanding
for
sort
of
what
was
happening
higher
up
and
further
down
the
the
track
and
as
well
as
that,
I
felt
like
pms
wear
just
so
many
more
hats,
they're
they're,
constantly
context,
switching
and
and
and
doing
different
things.
One
time
in
one
call
they'll
be
speaking
with
customers
pitching
a
vision.
A
Another
call
maybe
like
working
with
the
team
understanding
what
some
technical
constraints
are
another
baby
planning.
So
it's
constantly
context.
Switching
based
on
like
the
the
mode.
The
content
is,
it
was
really
quite
quite
challenging
to
to
get
a
get,
a
grip
of
which
made
me
realize
that
pms
are
truly
like
the
kings
and
queens
of
of
context.
Switching
so
yeah
there's
a
lot
of
respect
that
I
have
from
there.
A
So
I
wanted
to
sort
of
talk
about
some
of
my
experience
with
these
different
hats
that
I
was
trying
on
as
a
pm,
and
the
first
hat
that
I
tried
on
was
the
the
the
prioritizer
and
I
I
never
realized
how
many
different
variables
you
that
pm's
needed
to
consider
in
order
to
prioritize
what
goes
into
a
milestone
and
whatnot,
and
when
things
should
be
shipped
there's
a
lot
of
dependencies.
A
There's
a
lot
of
input
from
customers,
there's
a
lot
of
technical
constraints.
So
basically
it
seems
like
pms.
Have
this
tremendous
juggling
act
act
with
all
the
different
variables
going
on
for
the
the
features
and
issues
that
they're
looking
at,
and
it
really
is
quite
an
art
form
to
to
prioritize
the
right
things
at
the
right
time,
because
I
don't
think
there's
like
a
specific
equation
that
you
can
put
to
it.
I
think
it
just
requires
experience
and
and
know-how
and
knowledge
of
the
the
content
itself.
A
A
So
the
the
storyteller
so
another
big
thing
that
I
found
another
sort
of
architect
archetype
that
I
found
that
I
was
sort
of
embodying
as
I
was
in.
A
number
of
the
meetings,
is
sort
of
talking
about
how
we
got
to
now
with
regards
to
the
features
and
functionality
that
we've
included
within
the
product,
so
sort
of
summarizing
the
history
and
timeline
of
the
steps
that
we've
taken
and
where
we
are
currently
as
well
as
like
like
looking
forward
and
thinking.
Where
do
we
actually
need
to
go?
A
And
I
found
myself
both
to
customers
and
to
to
different
team
members
regularly
summarizing
where,
where
we
come
from
and
where
we're
gonna
go
and
getting
their
input
on
that
story
as
well,
and
using
that
as
a
tool
to
sort
of
drive
the
team
forward
and
also
garner
feedback
as
well.
A
Another
hat
that
I
wore
as
a
pm
was
the
the
planner.
So
I
put
this
this
term
here.
I
think
it's
like
a
chinese
proverb
crossing
the
river
by
by
feeling
the
stones
so
having
a
good
understanding
of
where
you
need
to
go
as
a
team
in
the
next
quarter
and
the
next
year
in
the
next
three
years,
whatever
it
is,
but
also
being
aware
of
the
of
the
pitfalls
and
challenges
that
we
have
along
the
way.
A
So
we're
sort
of
understanding
where
we
we
need
to
go,
but
we're
also
being
mindful
of
of
the
of
the
actual
path
that
we
need
to
take.
So
the
planner
is
as
a
pm
really
mindful
of
of
what
are
the
obstructions
that
we
currently
have
in
the
way.
A
But
where
do
we
need
to
go
and
how
do
we
balance
that,
in
order
to
get
to
the
or
achieve
the
goal
that
we
we
were
trying
to
achieve
the
scientists
understanding
the
the
key
metrics
that
we're
trying
to
that
we're
trying
to
drive
that
we're
trying
to
move
the
needle
on
and
figuring
out
ways
to
experiment
with
the
features
and
functionality
that
we're
shipping
and
order
to
learn
more
about
what
we're
doing
so
moving
those
metrics
building
the
features
that
we
think
will
help
to
shift
those
metrics
measuring
the
outcomes
and
then
learning
about
what
we
did
along
the
way.
A
So
a
scientist
hat
is
another
one,
and
then
the
networker
is
speaking
with
a
bunch
of
different
customers,
but
also
speaking
with
a
bunch
of
different
groups
and
teams
as
well,
who
we
are
interacting
with
and
who,
who
we
currently
sort
of
share
a
number
of
areas
of
the
product
with
making
sure
that
we're
aligned
on
some
of
the
product
decisions
and
also
getting
input
from
customers.
A
And
I
find
I
found
that
I
I
previously.
I
assumed
that
customer
interviews
were
actually
very
similar
to
user
interviews.
But
upon
sort
of
doing
more
and
more
of
them,
I
I
kept.
I
realized
that
the
the
scope
of
it
was
quite
different.
It's
how
I'd
sort
of
define
more
as
like
a
stakeholder
interview
rather
than
a
user
interview
and
the
the
the
type
of
conversations
you
have
are
different
within
customer
interviews.
A
Tv
show
called
bob
the
builder,
and
this
was
models
on
him,
but
it's
all
about
just
basically
seeing
seeing
what's
currently
blocking
the
pipeline
and
and
getting
it
out
the
way
so
that
the
the
engineering
team
can
can
ship
features
as
quickly
as
possible
and
increase
the
throughput.
A
So
really
product
managers
are
are
jacksonville,
trade
and
potentially
masters
of
all
trade
as
well,
and
it's
really
admirable
because
I
I
was,
I
was
barely
hanging
on
so
some
of
the
takeaways
that
that
I
had
from
this
experience
and
trying
all
these
different
hats
on.
A
I
found
that
the
the
sway
that
I
had
on
the
user
experience
as
a
pm.
A
Well,
I
had
much
more
influence
on
on
the
end
user
experience
as
a
pm
than
I
did
as
a
designer,
and
that
just
made
me
me
as
a
designer
and
how
I
and
and
how
I
collaborated
with
my
previous
pms,
but
I
found
that
yeah.
I
had
a
lot
more
influence
on
on
what
the
experience
was
like,
and
there
is
also
a
lot
of
potential
overlap
between
the
responsibilities
of
pm
and
ux,
and
I
don't
see
this
as
a
stealing
each
other's
tasks
or
stealing
each
other's
activities.
A
So
we
might
as
well
understand
what
it's
like
to
walk
in
pm
shoes
a
little
bit
more,
and
I
know
I'm
mixing
metaphors
here,
but
yeah,
seeing
how
pms
think
and
work
and
trying
on
those
different
hands
from
the
perspective
of
a
of
a
designer,
I
think,
would
be
super
useful
for
people
in
the
team,
and
I
think
it's
going
to
be
super
useful
for
me
as
well
going
forward,
and
this
will
enable
better
collaboration
with
the
pms
through
better
understanding
which
will
enable
better
results
and
overall
it'll
give
our
pm
some
time
to
relax
as
well.
A
So
based
on
all
this
sort
of
stuff
I
talked
about.
I
thought
I
was
thinking
of
some
just
generally
actionable
steps
that
we
could
take
away
from
this
number.
One
is,
I
think,
jumping
on
customer
calls,
if
you're
not
doing
so
already
would
be,
would
be
really
valuable.
A
A
Try
goal
setting
see
whether
for
a
milestone,
you
can
individually
do
some
goal
setting
and
then
compare
notes
with
a
with
a
pm
and
see
what
what
happens
like.
Who
knows.
Could
something
interesting
could
happen?
Read
the
book
inspired!
That's
the
first
first
book
that
I
I
read
as
a
pm
and
it
it
really
provided
a
lot
of
insight
into
into
why
we
do
things
the
way
we
do
within
gitlab.
So
that's
a
great
book.
A
It's
probably
like
silicon
valley,
something
and
then,
as
I
said
before,
there's
a
lot
of
shared
responsibilities
and
activities
that
pms
and
designers
can
have,
and
I
invite
you
to
try
on
the
different
hats
that
I
sort
of
talked
about
that
pms.
Typically,
try
on
and
think
about
how
you
can
use
your
design,
skills
and
different
approach
to
clarify
and
build
on
on
whatever
the
the
pm
is
doing
or
how
they're
communicating
to
see
whether
you
can
get
to
a
like
a
a
better
place
in
general.
A
So
that's
like
a
little
whistle
stop
tour
of
my
experience
as
a
pm.
I
appreciate
you
listening.
I
want
to
leave
everyone
on
this.
This
little
quote
which
comes
from
valerie.
A
I
didn't
draw
try
drawing
valerie,
because
I
don't
want
to
draw
the
ux
director
and
get
myself
in
trouble,
so
every
designer
no
matter
what
level
has
the
opportunity
to
collaborate
with
pm's
and
ends
to
influence
prioritization.
A
The
goal
is
to
get
two
to
three
months
ahead,
and
this
will
open
opportunities
for
longer
term,
more
strategic
thinking.
So
I
thought
that
sort
of
summarized
up
what
I'm
trying
to
get
at
here
and
there's
the
issue
down
here
that
you
can
look
into
and
potentially
comment
on
as
well
and
yeah.
Thank
you
very
much
for
listening.