►
From YouTube: Pipeline authoring - PM/UX - March(21) vision
Description
Pipeline authoring - PM/UX - March(21) vision
A
Hi
everyone-
this
is
doug
joshkovitz,
the
senior
product
manager
from
the
pipeline
authoring
team,
I'm
here
joined
by
nadia
sutnikova,
our
product
designer,
and
I'm
here
to
give
you
a
brief
walkthrough
about
our
our
team
roadmap
for
the
I
would
say,
two
to
three
iterations
and
but
before
we'll
dive
into
the
actual
roadmap.
I
want
to
first
talk
a
little
bit
briefly
about
the
pipeline
authoring
team.
As
you
all
know,
the
pipeline
authoring
is
a
fairly
new
team.
A
It
was
formed
late
this
year
it
emerged
from
a
split
between
ci
and
when
I
talk
about
the
pipeline
authoring
thing
and
explain
the
responsibility
I
like
to
show
this
this
illustration.
If
you
look
at
the
ci
life
cycle,
we
know
that
whenever
you
want
to
run
on
a
pipeline,
first
user
need
to
define
a
pipeline.
A
So
everything
about
authoring
writing
the
pipeline
configuration
thinking
about
the
different
requirement.
This
is
where
the
pipeline
authoring
team
responsibility
comes
into
play
and
then,
when
you
run
a
pipeline
and
you
analyze
the
pipeline
and
analyze
the
the
performance
data
of
the
pipeline,
this
is
where
the
responsibility
of
the
ci,
the
ci
team,
comes
into
play.
But
then
users
don't
stop
there,
because
it's
a
continuous
effort
to
improve
and
iterate
making
sure
that
the
pipeline
is
working
and
running
efficiently
efficiently
and
doing
what
needs
to
be
done
so
using
normal
users.
A
Normally
after
they'll
analyze
their
performance
that
data
of
the
ci
pipeline,
they
will
optimize
the
pipeline
and
by
optimizing
they
will
do
some
editing
we'll
do
some
fine
tuning
and
more,
and
this
is
also
where
the
pipeline
authoring
comes
into
play.
So
if
you
want
to
roughly
understand
what
is
the
distinction
between
the
team,
you
can
think
about
everything
that
is
related
for
writing,
starting
from
starting
from
scratch
or
updating
or
editing
your
pipeline.
This
is
pipeline
authoring,
responsibility
and
everything
that
is
related
for
running
and
analyzing
your
pipeline
as
it
runs.
A
This
is
more
the
responsibility
of
the
cit
and,
of
course,
there
are
some
overlaps
on
the
handovers.
But
this
is
something
that
we
know
how
to
manage
now
going
back
to
to
our
roadmap
and
again
before
that,
as
we
formed
the
team,
we
set
up
a
goal
and
the
goal
is
straight
from
our
direction.
Page
of
our
from
our
handbook.
B
B
B
They
all
have
to
go
through
that
experience,
and
we've
been
mainly
focusing
on
this
job
to
be
done.
You
can
see
we
have
more
granular
job
statements
here,
though,
we'll
later
talk
a
bit
more
about
the
specific
workflows
that
have
to
do
with
this
job
to
be
done,
but
I
would
like
to
talk
a
little
bit
where
these
job
to
be
done
came
from,
so
we've
done
lots
of
research
that
informed
this
job
to
be
done.
Specifically,
you
can
see
here,
we've
done
some
problem
validation.
B
I
feel
like
sometimes
our
most
interesting
insights
come
from
customer
interviews.
So
a
lot
of
those
also
tie
into
those
jobs
to
be
done,
and
there
are
some
solution,
validation,
efforts
that
we're
running
as
well.
That
also
may
be
indirectly,
but
they
inform
everything
that
we
do
regarding
the
jobs
to
be
done.
So
this
is
still
like
a
living
breathing
organism.
We
keep
adding
more
and
more
jobs
to
be
done.
B
A
Sorry,
I
wasn't
mute.
I
was
just
thanking
you
so
yeah.
So
as
as
nadia
explained,
we
looked
at
the
job
to
be
done,
we've
done
our
research
and
we
understand
what
is
the
user
journey?
The
user
need
to
do.
What
are
the
steps
users
need
to
do?
It
doesn't
matter
if
you
are
like
a
small
to
medium
enterprise,
a
small
to
medium
business
or
an
enterprise
solution,
and-
and
we
all
know
that
to
start
with,
we
want
to
make
sure
that
users
the
minute
they
create
a
new
new
project.
A
This
is
super
important
because
we
want
to
make
sure
that
this
experience
is,
is
a
whole
and
support
and
will
support
those
those
new
users
and,
like
obviously,
once
they
created
the
the
pipeline
configuration.
We
want
them
quickly
to
start
to
try
out
to
start
author,
the
pipeline
or
maybe
adjust
their
configuration,
and
this
is
where
we
have
this
whole
epic
about.
It
is
actually
the
second
iteration
of
the
pipeline
editor.
A
The
first
iteration
of
the
pipeline
editor
was
just
to
create
or
create
the
actual
textual
editor,
but
now
we
are
more
into
making
sure
that
the
actual
experience
within
the
editor
is
well
suited
for
those
for
those
users.
So
we
identify
a
few
areas
where
the
users
need
to
move
away
from
the
pipeline
editor
and
we
want
to
make
sure
we
keep
them
within
the
experience.
A
So
the
first
thing
is
getting
getting
getting
the
users
in
the
pipeline
editor
and
then
improving
the
experience
within
the
pipeline
editor
and,
as
you
can
see,
we
have
a
lot
of
a
lot
of
issues
that
we
still
need
to.
We
still
need
to
work
on
and
also
to
better
support
our
users
as
they
ride
their
their
pipeline.
We
also
have
the
visual
builder,
which
we
believe
will
support
our
users
when
they
create
the
first,
the
first
pipeline.
A
So
it's
some
sort
of
a
guided,
a
visual
aid
to
allow
our
users
and
to
build
their
pipelining
like
the
first
mvc
that
we
want
to
that.
We
want
to
do
is
to
implement
some
sort
of
a
drawer
on
the
pipeline
editor,
so
they
can
open
the
door
and
can
see
some
sort
of
an
image
of
some
sort
of
an
illustration
on
how
the
the
first
pipeline
will
look
like.
A
A
We
realized
that,
although
some
of
our
users
are
using
github
ui,
a
lot
of
them
are
using
their
own
editor
and
we
don't
want
to
neglect
them,
and
this
is
why,
every
time
we
have
a
chance
to
help
and
support
those
users
as
well,
we'll
do
that,
and
this
is
where
a
those
two
epics
come
into
play
and
to
support
those
users.
So
one
of
them
is
the
ci
linter
on
improve
api.
So
we
know
that
a
lot
of
our
users
are
embedding
linting
as
a
part
of
their
workflow
and
they
do
it
to
api.
A
So
we
want
to
enhance
and
improve
that
experience
and
the
actual
linkedin
of
the
piper
the
python
editor.
So
you
know
when
you
go
to
the
to
any
editor,
you
start
typing
like
the
first
letter
and
it
will
auto
complete
and
it
will
give
you
some
tooltips
and
some
guided
help.
So
this
is
where
this
epic
is
coming
from,
and
one
of
the
suggestions
that
we
are
exploring
is
that
if
we
will
indeed
be
able
to
generate
a
json
scheme,
why
won't
we
contribute
it
upstream
for
all
of
our
users?
A
A
A
Now
this
is
the
the
user
flow
and
I
want
to
pay
attention
to
the
issues
here
on
the
right,
because,
as
I
mentioned,
we
have
a
large
and
growing
customer
base
and
we
want
to
make
sure
we
will
will
not
forget
about
them.
So
this
is
where,
every
time
when
we
plan
the
next
iteration
or
we
plan
our
output,
we
will
always
have
a
mixture
between
issues
that
will
support.
A
B
Well,
I
think,
maybe
to
one
thing
to
add,
is
that
you
know
as
the
next
step
so
now
we're
we're
focusing
on
this
for
the
next.
You
mentioned
two
three
iterations
and
as
the
next
step,
where
we'll
we
will
start
looking
at
that
other
job
to
be
done.
That
has
more
to
do
with
enforcing
some
kind
of
csd
guidelines
on
the
team,
and
we
do
have
some
problem
validation
efforts
planned
to
start
focusing
on
that
so
but
yeah.
This
is
yeah.