►
From YouTube: Collabject Convergence Session – 2021 05 06
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
All
right:
well
we
this
edition
of
convergence
session.
I
think
we've
been
seeking,
I
think,
more
specific
action
items
to
start
to
execute
some
design
ideas
around,
and
I
I
was
talking
with
kristen
yesterday
and
I
kind
of
five
wise
a
bit
with
her
and
and
that's
what
I
put
at
the
top
of
the
agenda
and
then
gabe
actually
iterated
on
that
further,
and
I
was
wondering
gabe
if
you
could
walk
us
through
what
what
you
came
up
with.
B
Yeah,
I'm
happy
to
I
sort
of
laid
out
a
possible
iterative
approach.
You
know
our
values
and
all
for
thinking
about
breaking
this
into
different,
smaller
problems
to
solve,
so
it's
easier
to
grow
and
solution
on
and
holly
asking
the
question
last
night.
What's
the
single
most
important
outcome
we
want
to
have
from
this
and
it's
hard
for
me
to
put
that
into
one
sentence.
B
But
what
I
can
do
is
say:
if
we
take
this
approach
each
two
week
iteration,
I
think
I
think
we
as
a
team
can
clearly
define
what
success
looks
like
and
that's
finding
a
solution
that
works
for
the
particular
problems.
We're
are
working
on
that
iteration,
where
the
solution
is
valuable
to
customers
and
users,
that's
both
ux
and
product.
B
Determining
that
it's
usable,
it's
all
on
ux,
to
determine
that
it's
technically
feasible,
which
is
something
that
engineering
is
responsible
for
and
then
business
viable
like
does
it
work
for
our
business
and
that's
what
product
does
and
I
think
if
we
look
at
just
a
couple
problems
each
week,
limited
to
a
very
defined
scope
that
it
will
be
easier
to
basically
achieve
all
the
opportunities
that
are
listed
up
top
in
a
more
like
sane
way,
and
so
what
I
sort
of
did
is
looking.
If
we're
gonna
have
we
breaks
into
four
iterations?
B
What's
like
sort
of
the
the
order
to
do
it,
but
also
the
context
for
each,
and
so
I
put
together
a
suggestion
for
the
first
iteration,
which
is
exploring
the
foundational
object
structure
and
some
basic
data
that
we
can
look
at
in
terms
of
what
people
are
doing
on
issues
now
and
what's
used,
the
most
are
interacted
with
most
frequently
across
the
most
amount
of
users,
which
is
you
think
about.
This
is
like
impact.
It's
creating
an
issue,
commenting
on
an
issue,
updating
the
description,
updating,
an
issue,
title
and
editing
a
comment.
B
Those
are
the
the
most
popular
things
from
a
unique
user
standpoint
and
you
can
imagine
it's
not
the
total
count.
But
how
many
comments
do
you
leave
on
an
issue
a
day?
You
can
probably
extrapolate
that
out.
It's
it's
very,
very
high,
and
so
I
was
thinking
if
we
scoped
the
first
kind
of
iteration
to
look
assuming
like
we're,
starting
with
a
blank
canvas,
and
we
look
at
just
a
title,
a
description
and
discussions.
B
Just
just
solving
these,
like
when
I
mean
like
a
blank
slate,
assume,
there's
nothing
in
the
view,
except
for
a
title
of
description
and
discussions,
because
I
think
that's
gonna
form
the
basis
of
like
what
I
believe
is
the
most
important
aspect
of
a
cloud
object,
because
the
purpose
is
to
facilitate
collaboration
as
efficiently
as
possible.
There's
not
many
competitors
that
do
it.
B
Then,
like
you
know,
we
can
get
to
it.
Customizing
the
cloud
objects
to
better
reflect
our
customers
business
domains,
but
really,
if
we
get
these
first
three
like
buckets
of
problem
solved
within
each
of
these
iterations,
it
will
help
us
take
what
we
currently
have
and
achieve
our
product
goals
of,
like
basically
migrating
fx2
types
of
issues
and
all
that
other
stuff,
while
also
improving
usability.
So
that's
sort
of
how
I
looked
at
it
and
I'm
curious
to
get
feedback.
B
A
A
So
I,
if
I
might
direct
your
attention
to
the
opportunity
statement
instead,
does
that
help
to
stand
out
amongst
our
competitors.
Collaboration
across
the
team
is
not
treated
as
a
critical
component
in
software
lifecycle.
Life
cycle
tools,
so
the
the
objective
or
the
opportunity
is
to
make
cool
objects
like
issues
and
epics
more
conducive
to
collaboration.
D
B
A
D
This
is
helpful
because
it
does
help
to
create
a
bit
of
a
constraint
which
is
kind
of
what
I
was
looking
for
in
having
that
problem
statement.
But
I
was
thinking
that
we
had
talked
about
not
focusing
on
discussions
as
part
of
mvp.
So
does
that
mean
that
we
can
incorporate
discussions
as
part
of
this
exploratory
work?.
B
I
I
think,
as
I
was
thinking
about
it,
if,
if
out
of
all
of
our
work,
this
is
the
most
frequented
action
by
our
users
is
collaborating.
It's
the
right
place
to
start,
because
everything
else
that
we
want
to
iterate
and
improve
on
from
usability
and
product
capability
standpoint
should
should
be
designed
around
this
experience.
B
The
experience
of
collaborating
right-
and
so
that's
where,
like
we
have
to
tech,
we
have
to
refactor
it
from
a
code
level
standpoint
already
so
that's
gonna
happen
and
we
we
might
not
even
have
to
make
huge
changes
to
like
what
the
what
a
thread
looks
like
right.
We
can,
but
it's
more
like
how
can
we
in
getting
into
specific
problem
statements
if
we're,
starting
with
the
collaboration
experience
as
a
core
pillar
of
what?
B
B
Another
one
was
like:
how
can
we
take
the
outcomes
of
the
threaded
discussions
and
officially
capture
them
in
the
description
right
with
in
a
usable
way,
without
having
to
scroll
back
and
forth
open,
multiple
tabs
or
windows?
To
like
look
at
my
my
discussion
and
then
look
at
my
description
and
edit
at
the
same
time,
so
I
can
like
have
both
those
contacts
would
do
that
like?
How
can
we
reduce
the
amount
of
context?
B
Switching
between
discussions,
descriptions,
objective
object,
for
example,
like
I
don't
know
how
many
tabs
I
ended
up
with
open,
because
I,
like
right,
click,
open
a
comment
to
go.
Look
at
that
comment.
It
was
referenced
in
one
comment.
That's
in
another
issue
like
this
is
the
core
of
the
usability
problem
from
a
collaboration,
efficiency
standpoint
for
the
individual
users
like
from
the
way
I
see
it,
and
so
I
I
think
like.
If
we
start
with
solving
this
problem,
then
it
makes
layering
on
things
like.
How
do
we
associate
metadata?
B
How
do
we
like
relate
objects
to
one
another
like
if
it
all
flows
from
the
ability
and
the
pillar
of
improving
collaboration
and
making
that
experience?
Lovable,
does
that
make
sense?
That's
my
hypothesis.
I
could
be
wrong,
but
I
think
it's
backed
up
by
a
lot
of
good
research
that
you
all
have
done
so.
D
D
A
C
A
C
A
B
All
right,
I
do
think,
there's
a
viable.
Some
of
the
questions
you
asked
alexis
are
also
like
really
relevant
and
the
agenda,
and
I
think
point
three
holly.
If
you
want
to
vocalize
that
question
too,
I
think
it
also
ties
into
personas
and
by
stepping
outside
of
parker
is
sort
of
important
right.
Now,
too,.
D
We're
at
so
for
number
three:
who
specifically,
are
we
targeting
so
this
was,
and
alexis
probably
got
some
of
this
in
her
research
as
well.
We
were
targeting
parker
for
our
jobs
research.
However.
Obviously
parker
is
not
the
only
persona
that
uses
issues
regularly
and
we
could
say
all
the
personas,
but
I
think
it's
best
for
us
to
narrow
it
down
to
sort
of
the
ones
that
are
most
most
involved
with
the
collaboration
aspect.
D
My
thought
on
that
would
be
that
it
would
be
parker
and
maybe
delaney,
I
think,
and
maybe
sasha,
I
believe,
that's
the
dev
lead
and
the
engineer
as
a
starting
point,
or
maybe
even
just
the
pm
and
the
engineer-
and
I
kind
of
bundle,
the
engineer
and
designers
into
the
same
bucket
when
I
think
about
how
they
collaborate
within
our
product,
which
may
or
may
not
be
good.
But
I
know
we
have
a
designer
presented
out
to
you
so
that
that
would
that
would
make
sense.
D
C
Of
different,
too,
because
I
had
also
quality
management
so
but
like
thinking
at
a
higher
level,
I
was
just
kind
of
asking
questions
more
around
like
what
are
you
trying
to
do?
How
are
you
collaborating
with
the
team
and
all
so
maybe
I
could
surface
some
of
that
research
more,
but
it
was
really
everyone
right
who
works
on
a
project
and
then
it's
like.
Are
you
working
on
a
project?
C
That's
you
know
a
large
project,
a
program.
Are
you
working
on
one
task?
Are
you
working
on
multiple
tasks
is
what
kind
of
tasks
you
know?
Is
it
like
a
test
kit,
like
so
different
granularity?
I
think,
but
not
not
really
tied
to
one
person
I
would
say
especially
like,
as
we
define
the
personas.
I
don't
think
it
would
fit
into
one
or
two
of
those
people,
but
we
could
think
of
like
maybe
how
to
like
prioritize
them.
I
don't
know
if
that
would
make
sense.
What
do
y'all
think.
B
I
link
to
in
my
comment
under
point
three:
basically,
this
gets
into
the
next
iteration,
but
talking
about
how
the
different
personas
like
intersect
on
a
club
object,
but
basically
presley
wants
to
get
feedback
on
designs
right
between
product
and
engineering,
sasha,
devon
and
delaney,
for
letting
mrs
commits
to
an
issue
playing
work,
sydney
and
alex
for
relating
incidents
and
alerts
to
issues
and
mrs
resolved
them.
Sam
for
relating
security,
vulnerabilities
to
the
issue
resolved
and
like
the
the
the
this
like
cloud
object
is
like
the
intersection
of
all
the
roles.
B
I
think
there
are
specific
tasks
that
they
will
take
within
it,
but
at
the
end
of
the
day,
almost
all
of
them
will
do
in
in
this
first,
like
thing
that
we're
talking
about
the
foundation
object,
all
of
them
will
leave
comments.
All
of
them
will
want
to
understand
the
description
and
the
information's
there
and
how
that
like
basically
guides
actions
and
then
the
title
gives
them
context.
B
A
Appreciate
about
this
iteration
steps
is
a
lot
of
the
a
lot
of
the
upcoming
questions
like
what
about
hierarchy.
What
about
watch
versus
notifications
we're
going
to
defer
those
to
future
iterations?
The
first
iteration
is
only
about
these
critical
paths
for
a
collaboration
on
a
object.
So
that
way,
when
we,
when
we
come
together-
and
we
we
talk
about
ideas,
we're
not
talking
about
everything-
we're
only
talking
about
the
things
that
are
the
focus
right
now,
so
those
things
are
important,
they're,
just
not
important
right
now.
A
B
B
So
one
of
the
things
that
we
were
asked
to
do
by
the
board
is
figure
out.
If
we
were
given
more
investment,
how
do
we
invest
that
money
to
reach
one
billion
dollars
in
aar
by
2025
right
so
right
now,
the
product
leadership
is
working
across
all
the
product
teams
to
identify
like
different
opportunities,
and
so
what
I'm
doing
to
contribute
to
that
within
plan
and
working
with
kristin
and
mark
is
looking
at
the
general
markets.
B
So
tying
back
like
our
original
bhag
as
a
company
which
is
usually
a
30-year
time
horizon,
it
is
to
become
the
most
popular
collaboration
tool
for
knowledge
workers
in
any
industry.
So
this
is
super
vague
and
generic,
but,
like
that's
the
b
hack
and
I
get
it,
I
get
why
it
is
and
we're
starting.
We
just
happen
to
be
starting
with
devops
lifecycle
first,
because
that's
where
the
biggest
market
opportunity
was,
but
it's
really
to
become
a
collaboration
tool
for
knowledge.
B
Workers
like
and
I
think,
we're
doing
a
great
job
of
making
devops
lifecycle
more
user
friendly,
but
we're
not
doing
a
good
job
of
making
gitlab
user
friendly
or
even
useful
for
non-developers
or
domain
experts
that
aren't
engineers.
That's
the
way
that
mark
or
mike
framed
it
earlier
so
like
looking
at
the
opportunity,
there's
basically
by
2023,
there's
gonna
be
27
million
developers.
B
Customer
support
is
a
12.1
billion
dollar
market.
The
broader
ppm
market,
which
is
when
you
get
into
like
funding
resource
allocations,
true
portfolio
management
like
there's,
an
additional
over
four
billion
dollars
in
market
opportunity
there,
but
collaboration
software,
I'm
gonna
reorder
these
it's
31.5
billion
dollars.
That's
how
big
the
market
is
it's
huge
and
so,
as
I
as
a
product
manager,
think
about
how
can
we
set
ourselves
up
to
be
successfully
like
reach
into
these
adjacent
markets
and
start
capturing
some
of
that
market
share
across
all
these
things?
B
There
pretty
much
is
like
one
constant
and
that's
collaboration.
Right
like
this
is
listed
as
a
market,
but
you
collaborate
in
devops
playing
you
collaborate
in
itsm,
you
like
use
business
process,
automation
to
make
collaboration
more
efficient
and
so
kind
of
where
you
can
look
at
this
issue.
I'm
not
going
to
go
through
all
these,
but
there's
all
these
opportunities
in
these
adjacent
markets.
B
I'm
thinking
about
how
can
we
leverage
the
smallest
technical
footprint
possible,
which
means
we
don't
have
to
build
as
much,
because
basically,
every
line
of
code
costs
a
lot
of
money
over
its
lifetime
to
maintain
not
just
to
create.
But
how
can
we
leverage
everything
that
we're
building
to
allow
to
power
solutions
across
all
these
different
sec,
like
market
segments
and
and
real
like
opportunities,
and
so
that's
kind
of
going
back
to
why?
B
A
A
C
It
looks
like
we're
starting
smaller,
I
suppose,
and
if
we're
basing
it
on
usability
issues
that
are
already
documented
things
like
that,
starting
really
small
there.
I
think
it.
You
know
it's
just
a
smaller
version,
validating
some
of
it.
I
think
that
could
be
that's
already
scoped
out
correct,
or
are
we
including
that.
A
C
A
Throw
it
all
out,
no
I'm
kidding
yeah.
I
think
you
know
if
an
iteration
gitlab
is
currently
two
weeks.
This
is
a
lot
it's
a
lot
of
crit,
so
the
critical
pass
at
the
bottom
I
mean
yeah,
like
you
know,
we
could
it'd
be
feasible
to
make
prototypes
for
these
things
within
two
weeks.
They'd
be
really
quick
and
dirty,
and
I
don't
know
if
they
would
be
at
the
fidelity
where
we
could
get
really
good
feedback
from
end
users.
A
A
A
C
So
I
feel
like
we
would
need
to
look
like
get
on
the
same
page
there,
because
all
I've
been
hearing
is
that
in
a
milestone
and
a
half
now
we're
going
to
start
refactoring
and
the
engineering
or
development
team
needs
a
plan.
We
need
road
and
map
out
how
to
you
know
like
how
they're
going
to
work
on
this
refactoring
and
like
what
they're
going
to
be
refactoring.
C
A
A
Yeah,
okay,
that's
a
really
good
question.
So
how
does
how
does
this
activity
impact?
You
know
the
wider
team,
the
people
outside
of
this
meeting.
I
think
we're
gonna
riff
on
some
really
bad
ideas
together
and
then
the
good
ideas
become
a
plan,
but
I
think
it
would
be
it'd
be
kind
of
odd
to
take
our
first
ideas
and
start
to
make
a
plan
from
them.
A
A
A
C
It's
not
me,
and
that
was
I
thought,
the
constraint
that
we
you
know
like
a
week
ago
or
whenever
we
first
started
talking
about
it.
It
was
okay
in
two
milestones:
we're
going
to
start
building
or
like
refactoring
issues
and
and
epics,
and
you
know
everything
else
we
need
to
know.
What
does
this
thing
look
like?
How
do
we
like,
simplify?
You
know
one
code
base
like
things
like
that,
so
that's.
D
C
A
A
A
We
get
closer
to
something
that
you
know
reflects
the
outcome
that
we
want,
that
we
have
a
a
basic
structure
for
a
collaboration
object
and
if
we're
open
and
transparent
about
that
work
and
the
engineers
are
aware
of
it
and
and
involved
in
some
way,
then
there
will
be
an
understanding
of
like
work
that
we
need
to
do
in
the
software.
That
would
support
these
ideas
so.
A
Is
not
a
it's,
not
a
project?
I
think
I
think
what
we've
done
in
the
past
is
we
treated
pretty
significant
things
as
projects
with
like
short
timelines,
and
we
don't
get
the
outcomes
that
we
want.
We
did
that
with
simplifying
groups
and
projects.
The
simplifying
groups
and
project
initiative
was
sort
of
treated
like
a
a
project
in
it
it
was
one
it
was
kind
of
treated
like
a
side
project
and
then
because
it
sort
of
had
a
deadline
when
the
deadline
passed,
people
were
like
well
now.
A
This
side
project
is
definitely
not
on
the
radar
because
the
deadline
is
over
and
I've
got
these
other
things
to
do.
This
is
going
to
be
an
ongoing
thing
where
we
have
a
discovery
and
vision
track,
and
we
have
a
delivery
track
and
there's
going
to
be
things
in
the
delivery
track,
which
is
writing
code
and
pushing
it
out
to
production.
That'll
support
the
foundation
for
for
where
we're
going
with
this.
A
A
People
people
hope
that
something
like
this
takes
weeks.
This
is
continuous
and
we've
already
been
doing
it
continuously,
but
without
these
sort
of
constraints
and
and
sort
of
a
a
more
deeply
thought
through
kind
of
vision
of
where
it
goes,
it's
been
a
lot
of
incremental
tweaks
like
make
the
labels
you
can
remove
a
label
by
clicking
an
x
right.
That's
a
that's
a
tiny,
incremental
tweak,
and
this
is
a
bigger,
longer
term
kind
of
thing.
A
But
the
most
important
thing
is
that
every
twice
a
week
we
come
together,
we
share
the
direction
that
we're
going,
those
ideas
pollinate
and
it
evolves
the
next
time
we
come
together
and
that
it's
constrained
to
these.
You
know
critical
paths
so
to
speak,
that
we
that
we've
decided
on
iteration
to
iteration.
C
C
A
C
A
It
if
it
works,
it
might
be
a
new
thing
for
a
plan.
I
don't
know
yet
the
things
that
you're
talking
about
with
kristin.
Those
are
those
are
understood
to
be
important.
Those
aren't
until
iteration,
three
relating
collab
jacks
to
each
other.
That's
where
you're
getting
the
scenarios
with
epics
and
roadmaps
right.
Oh.
C
A
A
A
A
A
C
And
then
like,
what
is
that
you
know?
How
do
we
prioritize
things
that
we
kind
of
want
to
swarm
on
too?
Right
might
be
an
interesting
thing
to
think
about,
because
if
we
want
to
swarm
on
everything,
then
that's
not
we're,
probably
not
going
to
I
don't
know
I
mean
that's
a
different
way
of
working.
I
guess
that's
not
really.
A
C
A
A
Yeah
so-
and
you
know,
holly
holly
identified
that
the
start
of
this
is
going
to
be
a
little
messy.
It's
not
going
to
be
like
a
straight
straight
line,
but
I
think,
as
long
as
we're
reconnecting
at
a
high
frequency,
we'll
we'll
see
a
lot
of
really
interesting
ideas
merge
together
and
then
the
more
of
those
ideas
merge
together
and
the
better
we
feel
about
them,
the
more
we're
willing
to
commit
to
okay.
We
need
to
make
this
back
end
change
and
maybe,
like
there's
gonna,
be
a
milestone
where
it's
just
back-end
changes.
A
That's
not
gonna
go
in
the
release
post.
That's
okay,
like
only
valuable
thing,
should
go
in
the
release
post.
This
is
the
part
where
gabe's
gonna
watch
and
go
no.
No,
no,
but
well
that's
his
fault
for
dropping
out
early,
I'm
just
kidding,
but
yeah.
I
think
you
know,
there's
gonna
be
things
that
we
find
that
we
could
put
in
the
product
release
milestone
milestone
as
an
improvement,
but
it's
not
going
to
be.
D
I
don't
have
anything
else
that
I
I
need
to
do
in
terms
of
meetings
right
now,
but
as
far
as
next
steps,
it
sounds
to
me
like
what
would
be
beneficial
is
to
go
ahead
and
start
working
on
some
ideas:
visually
some
prototypes,
some
sketches
and
rough
ideas
to
support.
Those
four
points
is
that
accurate
is
that
kind
of
your
expectation
as
well
mike.
A
Yeah,
I
think
this
would
be
you
know.
Each
of
these
could
be
a
prototype
informed
by
the.
How
might
we
use
anchored
by
the
definitions
with
the
bigger
opportunity
in
mind,
so
I
think,
what's
what's
going
to
change
iteration
to
iteration
will
probably
be
what
the
deliverable
is
for
these,
like,
I
think,
initially,
would
be
prototypes
and
then
and
then
after
that
it'll
be
like
solution
validation.
A
A
A
A
Good,
you
know,
I,
I
don't
think
in
in
eight
weeks
we're
going
to
pull
the
plug
on
this
initiative.
This
I
mean
that
that
the
use
cases
and
the
objects
that
we're
talking
about
that's
already
our
daily
reality
anyway
like
why.
Why
would
this
stop
at
eight
weeks
and
if
we're
really
transparent
about
what
we're
doing
the
idea
is
that
from
engineering
will
will
come
to
them.
If
they're
aware
of
what
we're
up
to
you
know,
I
think,
if
they're
not
aware
of
what
they're
up
to
then
it
will
be
this
kind
of
hey.
A
D
D
So
would
it
open
a
can
of
worms
in
the
spirit
of
transparency
for
us
to
start
tagging
folks,
like
pedro
who's,
going
to
be
obviously
focused
on
a
potential
object
of
merge,
requests
eventually
and
amelia
who's
working
on
incidents,
or
should
we
focus
on
just
this
core
idea
initially
and
then,
once
we've
got
a
little
bit
more
definition
surrounding
it
pull
other
folks
in
what
I'm
trying
to
avoid.
Obviously,
is
the
analysis,
paralysis
and
kind
of.
C
A
Yeah,
I
think
it's
important
to
have
our
own
opinions
first
and
that
way
when
people
do
give
feedback
or
not
it's
not
like
this,
oh
so-and-so
said
it
should
be
this
way,
and
then
that
becomes
the
the
opinion.
I
think,
as
a
team
that's
focused
on
you
know:
cross-collaboration
cross-functional
collaboration
around
planning
and
the
progress
of
work.
A
We
have
to
have
our
own
opinions
about
about
what
how
that's
embodied
in
a
solution
and
then
I
think,
with
with
other
teams,
you
know
across
other
stages.
It's
just
about
awareness
and
maybe
more
of
the
perspective
of
like
they
might
be
inspired
by
what
we're
doing,
rather
than
having
to
approve
what
we're
doing.