►
From YouTube: Testing PM/UX Sync - 1:1:1 - 2021-08-03
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).
B
Yeah,
so
this
is
the
101
on
one.
This
is
transition
transitioning,
my
normal
one-on-one,
with
hayanna
who's
been
acting
substitute,
can't
be
ever
replaced
designer
for
testing
and
runner,
but
we're
really
really
really
happy
to
have
gina
as
part
of
our
team,
so
swapping
gina
in
for
hayana.
So
this
is
just
the
transition,
one
we'll
go
through
the
transition
issues,
but
otherwise
it's
a
pretty
normal
one-on-one
for
hayanna,
and
I
I
think-
and
so
I'm
just
gonna
jump
in
like
it
would
be
a
normal
thing.
B
Some
follow-up
stuff.
I
figured
we'll
probably
cover
this
as
part
of
new
business,
but
following
up
on
the
okrs,
just
where
we're
at
with
that,
and
then
I
linked
to
the
existing
usability
jobs
to
be
done.
Issue
usability
category
jobs
to
be
an
issue
gina,
as
we
start
looking
at
that,
I
wouldn't
be
shocked
if
that
evolves
into
hey.
Let's
actually
look
at
review
apps
as
well
with
it
being
a
new
category,
but
we
can
focus
on
usability
for
now.
B
That's
a
very
immature
category,
so
understanding
what,
besides
just
the
visual
review
tools,
users
are
expecting
out
of
that
and
they
need
to
do
as
part
of
usability,
testing
or
user
acceptance.
Testing
is
probably
the
focus
there,
but
we'll
deep
dive
on
that.
At
some
point,
I
just
wanted
to
make
sure
the
link
was
here
so
that
you
had
it
as
part
of
your
the
next
steps
in
that
when
you
get
to
it
cool
and
then
how
do
you
want
to
start
with
the
transition
issue?.
C
A
A
A
I
already
asked
you
to
to
have
a
look,
but
maybe
we
can
triple
check
to
see
if
everything
is
here
relevant
to
research
initiatives,
if
there's
anything
else
that
might
be
helpful
and
useful
to
gina
during
this
transition
and,
of
course,
the
team
meetings
and
rituals
for
testing.
Maybe
it's
good
to
for
context.
Gina
for
testing
vitica
has
been
doing
the
research
right
for
dashboards
recently.
A
So
in
the
previous
milestone,
and
before
that,
I
think
my
main
efforts
were
really
related
to
the
merge
request,
widgets
and
we
did
work
right
a
couple
of
months
ago
on
some
ui
usability
improvements.
But
there
is
nothing
on
my
plate
today.
That
needs
to
be
transitioned
to
you
in
terms
of
yeah
deliverables.
B
B
A
Yeah,
I
think
you
already
depend
on
your
planning
james,
so
I
added
here
the
the
kr
write,
disability,
improvements
to
the
merger
class
widgets,
but
not
sure.
Based
on
my
comment
right
from
yesterday,
I
would
rather
not
assign
anything
that
is
technical
to
gina
now
so
that
she
can
focus
on.
You
know
getting
up
to
speed
and
on
border
with
the
everything
else,
but
then
again
yeah.
If,
depending
on
the
scope
of
this
kr,
we
will
contribute.
A
So
I
have
a
plan
also
to
at
least
do
the
improvements
of
one
widget.
This
quarter
so
I'll
take
a
task
myself,
but
then
it's
really
up
to
you
on
how
you
want
to
prioritize.
Did
the
jobs
to
be
done
ar
versus
the
usability
and
in
14304,
I
would
say,
since
in
143,
gina
is
going
to
be
doing
the
kr
for
for
runner,
which
is
the
scorecard,
I
would
suggest
keeping
the
the
jobs
to
be
done.
B
Fine,
I
was
just
calling
out
that
it
looked
like
it
for
14
2,
your
bullets
in
your
timeline
for
a
transaction
transition,
section
of
the
issue
and
the
bullet
points
in
the
current
and
upcoming
initiative
seemed
to
match,
and
then
they
got
a
skew
in
14,
3
and
14
4,
so
just
making
sure
that
we're
aligned
with
there
there's
some
overlap
but
they're,
not
mutual
they're,
not
the
same
list
just
spilled
that
differently.
That
was
all
cool.
B
A
Then
I'll
jump
to
the
next
one,
which
is
the
merger
quest
widget,
so
I'm
not
gonna
really
dive
into
that,
but
here's
here's
the
kr
and
I'm
looking
for
the
issue,
the
hives
issue:
let's
see
this
one,
so
we
had
a
discussion
yesterday,
james
with
with
scott
there,
you
go
so
here's
the
link
yeah.
I
can
already
touch
on
this
one,
so
we
still
don't
know
what
the
scope
for
this
would
look
like
in
terms
of
how
technical
these
improvements
would
be.
A
So
that's
why
I
say:
okay,
let's
make
sure
that
this
is
in
under
the
spots
raider
I
mention
to
to
darren
james
in
or
last
101
that
since
gina
will
be
doing
now,
the
scorecard
for
runner
up
milestone.
So
we
could
potentially
look
into
miguel
as
a
support
for
testing.
But
then
again,
that's
a
conversation
needs
to
happen
with
the
engineering
managers
and
to
talk
about
allocation
there.
But
I
know
that,
looking
at
the
plans
for
runner
for
ux,
there
is
not
a
lot
of
front-end
work
that
will
be
delivered.
B
So
I'm
confused,
then,
is
the
working
group
going
to
deliver
kind
of
a
framework
or
updates
to
pajamas
about
here's.
What
our
widget
should
look
like
to
where
there
should
be
consistency
and
usability
around
merge,
request
reports
on
the
page
and
then
we'll
go
and
implement
that
or
is
working
group,
and
this
kr
completely
separate
initiatives,
in
which
case
they
seem
very
duplicative
and
we're
going
to
end
up
with
two
different
results.
So
I'm
if
they're,
not
the
same
and
rkr,
is
tied
to
the
working
group.
A
Yeah
exactly
so,
that's
why
the
working
group
is
still
it's
your
proposal
right.
So
we
have
the
folks
that
have
been
from
foundations
some
folks
in
front-end
department,
ux
apartment
that
are
coming
together
to
say
this
is
how
we're
going
to
implement
and
then
based
on
the
guidelines
right
the
framework
we
each
stage
group
that
it
owns
that
widget
will
implement
the
the
enhancements.
A
So
what
what
we
need
to
understand
is.
Are
we
going
to
be
required
to
change?
For
example,
only
the
css
of
some
widgets
do
we
have
to
you
know,
redesign
the
the
the
view
components
do
we
have
to
so
how
technical
is
that
activity?
Is
that
task?
That's
why
I
said
yesterday:
let's
not
assign
that
to
gina
or
to
myself
just
yet,
because
if
it's
something
that
really
requires
it's
a
very
front-end
heavy
task,
we
will
probably
be
able
to
do
it,
but
you
know
we're
better.
A
We
better
spend
our
time
in
the
meantime
in
different
different
parts
of
the
product,
especially
for
during
gina's
onboarding
period.
So
that's
why
we
might
still
have
to
do
it,
but
we
don't
know
yet
exactly
so.
That's
what
the
working
group
is
figuring
out:
it's
not
a
replicated
as
a
duplicate
test
or
anything
they're
they're,
providing
really
the
framework
and
the
step
by
step
so
that
each
stage
group
can
implement
the
changes
this
quarter.
Does
that
kind
of
answer
your
question?
It
does.
B
I'm
I
mean
I
don't
know
how
we're
gonna
achieve
this
kr.
If
the
working
group
is
just
now
kicking
off
or
is
still
in
a
proposal
state
and
that's
going
to
be
where
the
suggestions
for
this
come
from,
versus
the
teams
themselves
being
the
dri
and
what
that
widget
should
be,
at
least
as
far
as
like
content,
potentially
and
obviously
we'd
work
with
our.
B
You
know
designer
to
understand
the
usability
of
the
feature,
but
if
the
working
group
is
going
to
propose
that
to
us,
then
the
working
group
should
be
the
ones
making
those
changes
as
well.
I
would
think
that's
personal
opinion
aside,
but
then
how
does
this
fit
into
the
all
the
work
that
pedro
and
kai
did
last
quarter
and
the
quarter
before
around
all
of
the
content?
On
the
merge
request,
page
itself,
we
got
a
lot
of
suggestions
and
made
a
lot
of
changes
already
to
which
it's
based
on
that
feedback.
B
A
Yeah,
I
totally
get
that,
and
it's
also
one
of
my
concerns
as
in
yeah.
It's
a
plan
for
the
quarter,
but
the
quarters
already
started
right.
So
part
one
is
figuring
out.
How
do
we
want
to
implement
this
and
then
part
two?
I
think
it's
it's
good
to
clarify
that
the
effort
right
that
that
our
team's
already
put
into
improving
usability
of
the
merge
requests.
It's
not
gonna,
we're
not
gonna,
lose
it
right.
A
A
So
that's
why
I'm
opening
a
sidebar
here
and
I'm
saying
looking
at
what
I
redesigned
in
figma
and
looking
at
our
team's
like
the
availability
of
a
front
end,
I
think
once
we
know
how
we're
going
to
implement
these
changes
that
we
should
focus
only
on
the
look
and
feel
of
this
widget.
It's
not
really!
Here's
a
full
redesign,
like
some
of
proposals
that
I
had
changing
where
things
are,
you
know
changing
how
we're
displaying
content.
Maybe
we
do
there's
a
face
lifting
of
some
of
the
widgets.
A
B
Yeah
and
totally
acknowledged,
let's
keep
the
buffer
there
for
ux.
We
just
want
to
be
clear
that
we
probably
only
have
one
in
front
an
engineer
for
all
of
q3
until
we
get
it
back,
fill
in
some
way
or
another,
so
our
availability
to
work
on
anything
beyond
one
widget
change,
a
milestone
for
the
two
remaining
milestones
is
going
to
be
limited,
especially
with
the
emphasis
on
com
availability
performance.
A
C
A
A
B
Because
we're
focused
on
the
performance
work
and
the
other,
what
not
we're
not
going
to
start
on
the
test
execution
end
point
until
14
5,
which
means
we
won't
implement
a
ui
until
14
6..
So
we
can
push
that
back
into
14,
5
and
then
gina
and
darren,
and
I
can
figure
out
how
that
fits
into
her
work
that
takes
that
off
of
viticus
plate.
So
she
can
refocus
back
on
pipeline
execution.
C
B
A
C
B
So
hopefully
I
can
do
this
in
10
seconds
we
write
release
post
entries
for
all
of
the
direction
items
or
other
major
changes
that
we're
shipping
that
go
out
as
part
of
a
marketing
blog,
although
it's
starting
to
change
a
little
bit
and
make
sure
that,
especially
for
the
ux
items
that,
on
all
of
the
release
posts,
we
tag
the
designer
as
well
as
em
and
tech
writer.
So
I'll
start
tagging
you
on
that
issue
and
you
can
see
a
status
very
similar
to
this.
B
I
look
at
it
every
monday,
I'm
like
oh.
I
should
really
go
change
this
out.
I
don't
know
if
I
need
to
check
I'll
go
look
at
the
transition
issue
and
then
I'm
12
issues
deep
into
triaging
bugs
and
I'm
like
wait.
What
was
I
going
to
do
again
every
time
all
right
yeah?
If
you
send
that
to
me
I'll,
go
take
care
of
it.
My
stuff
is
pretty
quick
and
easy.
B
I
am
going
to
be
what
am
I
doing
this
week,
supporting
our
internship
for
learning
for
scott
who's
coming
on
board
and
do
some
problem
validation
with
us,
so
he
will
be
picking
an
opportunity
scoring
it
and
then
moving
forward
with
all
of
the
recruiting
and
other
whatnot.
For
that
writing
the
discussion
guide
the
whole
kit
and
caboodle
upped
through
presenting
an
opportunity
canvas.
B
So
I'm
excited
about
having
another
chunk
of
research
done
in
the
backlog
going
from
problem
to
potentially
solution
validation.
So
then
we
can
have
a
clean
handoff
to
gina
and
myself
and
move
it
on
from
there.
If
we
find
that
there's
a
big
opportunity,
I'm
going
to
start
working
on
a
deck
for
a
sales
enablement,
webinar
that'll
be
happening
later
this
month.
B
For
me,
wrapping
up
some
partnership
discussions
with
a
company
that
reached
out
about
a
potential
partnership-
and
the
thing
I
forgot
to
add
to
my
actual
list-
was
I'm
going
to
go
back
and
re-watch
all
of
jackie's
videos
around
why
users
aren't
scm
users
aren't
using
ci?
I
want
to
dig
into
the
artifact
related
bits
there
now
that
we
have
build
artifacts
as
a
category
and
understand
what
is
preventing
them
from
using
artifacts
in
general,
because
that
drives
so
much
of
the
testing
functionality.
B
A
C
A
C
B
C
B
C
B
A
B
A
A
Awesome
all
right
dinner
address
anything.
So
james
will
resume
to
our
well
now
regular
wanna
ones.
Maybe
we
can
meet
once
every
two
three
weeks
and
then
yeah
I'll
create
a
new
new
invite
for
us
with
a
new
agenda,
also
so
that
you
have
your
your
agenda,
doc
with
the
regina
and
yeah
everything
set
up
for
you.
B
So
your
and
I
this
one
was
kind
of
a
one-off,
where
I
included
gina
and
I's
one-on-one
doc
as
the
agenda.
Your
and
I
agenda
doc
is
still
the
normal
doc
in
our
meeting
that
will
occur
in
two
weeks.
So
if
you
want
to
switch
that
change
the
one
on
the
17th
to
be
on
the
24th
and
then
every
three
weeks
after
that,
that
will
work
for
me.
B
Gina
you
and
I
have
our
normal
thursday
morning.
Yes,
that
will
happen
this
thursday.
I
need
to
move
next
week's
because
I'll
be
out
of
office
on
the
12th,
but
we'll
do
a
weekly
one-on-one
and
we
can
keep
that
cadence
as
long
as
you
want.
If
you
feel
like
we
can
go
back
to
bi-weekly,
that's
fine
too,
but
I
would
say
at
least
every
two
weeks
we
should
touch
base.