►
From YouTube: Non-K8 Deployments at Scale Opportunity Canvas
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
so
as
a
project
manager,
I
try
to
I,
don't
know
what
else
I
would
be
doing
at
gate
lab.
There
seems
like
a
redundant
statement,
but
one
of
my
job
duties
is
to
do
a
problem.
Validation
and
I.
Try
to
do
an
opportunity,
canvass
one
or
cubic
order,
so
this
quarter
I
would
like
to
focus
on
an
opportunity,
canvass
around
validating
the
jobs
to
be
done
with
the
environments,
dashboard
and
the
operations
dashboard.
A
So
the
problem
or
the
question
that
I'm
trying
to
solve
is
how
our
customers
managing
deployments
in
get
lab
at
scale
to
non
kubernetes
environments
or
targets.
Just
let's,
let's
take
the
environment
word
out
of
here,
and
it's
call
our
target
when
we
started
asking
questions
to
our
customer
base
around.
How
are
they
using
get
lab
to
plan
and
deploy
their
software
products
to
their
customers?
A
We
found
about
three,
or
four
of
them
were
actually
going
outside,
of
get
lab
and
the
environments
list,
as
well
as
the
environments
dashboard
and
going
to
the
actual
cloud
client.
So
what
I
want
to
accomplish
in
this
meeting
is
walk
through
the
left
hand,
side
and
the
the
problem
in
the
business
case,
section
here
and
flush
out
what
we
want
to
tackle
as
the
investigation
narrow
our
focus
from
both
the
user
flow
experience
and
a
market
problem
experience
and
how
that
inform
what
our
discussion
guide
will
be.
A
So,
in
this
issue
right
here,
this
is
the
issue
that
Kenny
created
five
months
ago.
It
is
a
really
great
overview
on
what
are
the
things
that
are
currently
happening
between
an
Operations
dashboard
in
an
environment,
dashboard
and
the
end
of
user
experience
that
we're
expecting
out
of
that
I'm
using
this
as
like
the
landing
point
to
organize
our
research
and
then,
of
course,
we'll
use
the
dovetail
application
to
link
our
customer
calls
and
all
of
that
stuff,
because
that's
now
the
process
we
use
rather
than
DM
the
UX,
our
insights.
A
If
we
can
get
an
Operations
team
perspective
in
one
of
the
interviews,
that
could
be
a
good
counterbalance
as
to
how
do
we
create
a
better
division
between
the
operations
dashboard
in
the
environments
dashboard
inside
of
gala
diving
right
into
the
problem
consistently,
when
we
interviewed
users
about
how
they're
orchestrating
deployments
today,
they
said
well,
either
machines
doing
it
and
it's
all
automated
or
it's
a
manual
process
where
they're
going
to
their
cloud
client
to
manage
it.
So
the
ability
to
manage
non
Cabrini's
deployments
at
scale
is
not
friendly
and
get
a
lot
today.
C
A
A
A
A
Then,
when
we
look
at
like
our
actual
personas
and
if
we
tap
to
be
up
like
if
there's
like
security
operations,
I
think
that
there's
an
open
mr
right
now,
it's
like
add
more
ops
but
Allison
ops
is
accessibility
and
performance.
So
when
we
look
at
a
production
release,
this
team
is
going
to
be
monitoring
that
release
to
see
how
it's
impacting
that
the
customer
experience
and
the
performance
of
the
application.
A
A
And
you
see
a
little
alert
indicator,
it's
less
about
the
pipeline.
You
have
exactly
what
was
updated
and
last
commit
here.
So
there's
like
small
nuances
that
are
tailoring
to
what
these
people
care
about.
So
I,
don't
really
want
to
spend
a
bunch
of
time
validating
this
dashboard
I
would
rather
spend
time
confirming
that
operations
teams
aren't
looking
at
this
dashboard,
because,
if
they're
looking
at
this
dashboard,
then
we
need
to
capture
with
the.
A
A
Okay,
because
I
agree
with
you,
I
really
don't
know
how
customers,
who
have
a
single
tenant
application
and
hundreds
of
customers
where
they're
deploying
you
know
taught
to
a
target
server.
I,
don't
know
how
they're
managing
versions
across
those
target
servers
and
get
lab
I,
don't
know
how
they're
managing
roll
ups
or
bump
version
bumps,
like
other
tools,
allow
you
to
say:
hey
I
have
a
customer
in
New,
Jersey
and
they're
going
to
get
my
geographically
approved
version
for
New
Jersey.
A
I
was
more
like
giving
a
summary
of
the
customer
and
the
problem
so
like
we're
joking,
just
these
two
boxes.
We've
just
covered
these
two.
So
diving,
you
like
the
actual
problem
statement
and
I'll,
read
what
I
have
written
here
and
then
we
can
tie
it
back
to
the
goals
that
we
have
for
this
opportunity.
Canvas
which
will
be
this
box
here
so
as
a
release,
manager
or
development
team
lead,
I
have
to
work
across
many
projects,
environments
deployments
and
get
lab.
A
This
is
very
challenging
to
do
since
there's
not
a
single
place
to
go
to
see
a
snapshot
of
production
applications,
not
just
environments.
I
want
to
be
able
to
see
the
health
of
how
my
end-users
need
the
production
environments
across
many
projects
and
teams
and
I
kind
of
want
to
say
something
about
without
having
to
use
kubernetes
or
with
more
flexibility
than
just
kid
where
these
deployments,
because
if
you
use
deploy
boards,
there's
a
lot
of
flexibility
there,
where
you
can
see
your
canary
roll
out,
you
can,
like
you,
have
more
high
touch
experience.
A
So
what
I
really
want
to
tap
into
to
unlock
here
with
this
opportunity?
Canvas
and
solving
this
problem
is
identifying
where
we
can
separate
the
operations
and
environments
dashboard,
folks,
technically
and
from
the
user
flow
experience,
and
how
to
how
we
can
create
conduits
to
the
environments
dashboard.
A
So,
as
a
user,
how
can
I
be
presented
to
the
environments,
dashboard
and
a
low-friction
way
to
triage
to
action
across
multiple
groups
and
projects,
then
the
second
perspective
that
I
want
to
leverage
this
experiment
for,
or
this
research
for
is
to
identify
how
users
are
managing
environments
and
deployments
at
scale
and
I
really
do
want
to
see
even
Carre's
deployments
at
scale.
So
maybe
my
third
goal
here
is
going
to
be
unpack.
The
non
kaid
experience
and
get
luck.
B
A
Sure
that
the
current
jobs
to
be
done,
we
have
a
release.
Orchestration
will
chip
away
at
what
we
discover
here
so
we'll
get
insights
that
relate
to
specific
jobs.
We've
done
that
we
already
have
to
find,
but
from
my
perspective,
I'm
going
into
this
without
a
particular
job
to
be
done,
because
I
want
to
know
what
they're
actually
trying
to
accomplish
when
they
go
to
get
lab
to
manage
a
deployment
at
scale
after
we
walk
through
that
experience,
we
may
create
related
jobs
to
be
done
with
jobs,
be
done
that
we
already
have.
A
So
we
have
like
a
release
management
job
that
we
don't
know,
but
I
want
to
deploy
production
changes
so
that
my
customers
have
a
really
positive
user
experience
with
my
application.
That's
the
entire,
like
motivating
force
for
release
orchestration,
so
I
could
see
a
related
sub
to
manage
a
non
kubernetes
deployment.
But
again
that's
getting
very
solution
specific.
So
really
it's
more
like
a
user
story
rather
than
a
job
freedom.
D
A
So
I
would
love
your
love,
your
thoughts
on
the
problem
statement
and
if
you
feel
like
this
overlaps
too
much
with
the
CI
CD
dashboard,
what
I'm
trying
to
zero
in
on
here?
It's
not
talking
about
releases
or
pipelines
or
CI
CD
I'm,
getting
like
hyper
hyper
focused
about
deployments
and
environments
and
well
I,
wanted
to
hear.
If
you
feel
like
this
was
duplicative
of
any
of
the
CI
CD
dashboard
work
that
we're
doing
I.
Think.
C
My
only
concern
because,
let's
start
with
there
with
the
concerns,
it
is
introducing
like
a
different
view
for
for
singular
personas,
because
when
we
talk
about
the
CIC
dashboards,
video
and
group
level
and
I
think
we
briefly
discussed
this,
and
this
one
is
that
the
instance
levels
and
I
wonder
if,
after
our
discovery
after
this
this
investigation,
we
could
find
ways
to
I.
Don't
know,
maybe
play
around
with
the
how
users
navigate
to
our
filter
these
informations,
but
that
we
can
build,
for
example,
these
at
the
instance
level.
C
Like
you
have
the
deployments:
okay,
it's
not
necessarily
for
the
release
or
the
things
that
you
want
to
show
for
their
release
status
on
the
CI
Steve
dashboard.
What's
to
you,
it's
a
similar
overview
and
a
similar
entry
point.
That's
I
think
that's
that
it
makes
more
sense
to
the
yeah.
It's
the
common
data
and
I
wonder
how
people
will
find
having
two
dashboards.
C
A
And
remember
whenever
you
and
I
were
talking
about,
maybe
these
all
get
combined
in
the
end
from
like
a
solution
so
yeah.
What
I
want
to
do
is
like
I
put
those
as
risks
like
well,
we
do
have
another
effort
that
we're
planning
right
now
and
what
we
don't
want
to
do
is
cause
a
user
disruption.
So
I
think
that's
a
risk
from
a.
How
do
we
not
cannibalize
existing
efforts
with
this
new
solution,
but
to
like
take
a
step
back
from
the
problem?
Do
we
feel
like
the
problem?
C
Sure
it
keeps
complementary.
Unless
then,
you
have
another
key
focus
in
the
in
the
different,
let's
say
flavor
of
the
problem,
especially
that
with
releases
in
the
CI
CD.
We
don't
really
go
in
that
they
need
a
non-carbonated
appointment
and
if
we
want
to
spend
yeah
our
offering
that
direction,
that's
it's
valid
to
do
for
this
dashboard
and
also
just
salsa
to
to
do
highlight
that
we
know
that
the
end
of
it
takes
and
I
think
I
got
so
many
things
by
you
sooner.
A
A
Okay,
that's
really
very
insightful
from
a
business
case
perspective
for
me
because
of
wine
like
when
we
look
at
our
target
market,
these
will
likely
be
the
same
personas
but
a
different
level.
So,
like
the
CIC
video
director
dashboard,
the
audience
is
an
executive
persona,
so
we're
looking
at
quality
analytics
about
releases,
your
team,
your
pipelines
globally
and
in
my
mind
this
is
about
tackling
the
day
to
day
release
manager,
job
and
the
development
team
lead.
Who
was
a
step
below
be
the
director?
A
So
they're
not
really
talk,
they're,
not
really
caring
about
analytics
intro,
they
could
care
about
analyzing
trends
over
time,
but
this
is
more
about
like
what
is
my
current
state,
what
is
on
fire
and
how
do
I
get
it
fixed
as
fast
as
possible?
So
maybe
maybe
that
can
be
part
of
the
pain
that
we
try
to.
A
Right
I
think
we
feel
pretty
I
feel
pretty
good
about
the
problem
about
what
we're
trying
to
unpack
here.
I
did
note
in
the
confident
section,
but
the
points
that
you
did
say
Iona
around
making
sure
that
we
don't
introduce
another
view
to
cause
friction
for
users,
reconciling
this
against
the
goals
for
the
CICE
director,
dashboard
and
then
working
across
teams.
Is
that
accurate
from
what
you
were
saying?
A
So
today
they're
having
to
go
into
a
failed
pipeline
notification,
drill
into
the
job
blog
and
then
send
that
screen
to
somebody
to
fix
either
in
an
issue
or
a
slack
message.
So
that's
typically
like
a
triage
flow
from
a
failed
deployment.
But
when
you
go
to
the
environments
dashboard
today,
what
does
this
tell
you
today
that
of
the
things
I
have
selected,
which
is
across
seven
projects
and
three
environments
per
project?
This
is
where
they're
at
it
doesn't.
A
I
will
have
to
go
in
this
and
add
and
remove
projects
to
view
all
of
the
projects
in
my
in
my
group
and
only
identify
the
production
environments
instead
of
like
a
natural
hierarchy
where
this
page
is
like
responsive
like,
for
example,
if
we
were
to
have
an
automatic
filtering
of
like
production
environments
that
are
failed,
so
that
they
can
triage
it
at
the
top,
because
that's
what
they
want
to
do
and
I'm
getting
into
solutioning
a
little
bit.
But
my
point
being
there
isn't
a
way
today
to
see
where
are
all?
A
A
So
the
two
panes
that
transpire
out
of
the
inability
to
see
across
all
of
my
projects
and
my
deployments
are
that
I'm
spending
an
immense
amount
of
time
sifting
through
problems
to
then
assign
to
some
fields
rather
than
efficiently
being
able
to
click
on
like
this
production,
environment
button
and
then
send.
You
know
this
particular
production
that
could
be
shared
by
multiple
projects
and
groups
is
down
because
of
this
job.
C
C
Like
the
features
could
be
smarter,
I
as
a
user
of
course,
I'm
super
biased,
but
I
would
rather,
for
example,
lending
invest.
What
you're
saying
with
things
that
were
pre-selected
and
then
I
can
remove
my
project
and
Nathan
talked
about
it's
like
a
lot
of
times
on
the
way,
also
how
we
configure
it
is
in
the
CI
file.
That's
we
don't
really
like
these
there's.
No
at
a
glance,
that's
the
cupcakes
can
be
added
or
it
can
be
configured.
So
I
wonder
is
like
what
you're
saying,
but
a
dashboard
is
something
that
should
work.
C
A
A
I
think,
like
you
framed
up
the
the
user
experience
problem
beautifully
and
then
I
just
put
a
result
on
that.
So
is
that
fair?
Do
you
feel
like
we're?
Not
quite
accurate,
okay,
you're
the
best
putting
words
in
your
mouth?
Okay,
you
said
it
as
well
in
the
workaround
that
customers
aren't
using
these
tools
and
get
them
they're
having
to
go
somewhere
else.
I
also
slated
that
they're
leaving
get
lab
to
view
their
production
environment
in
AWS,
GCP
or
IBM
tools
or
their
server
client.
A
So
some
people
are
using
likes
themes
or
just
bare
metal
servers
and
they're
going
and
watching
performance
or
metrics
from
those
clients
and
not
using
Prometheus
and
get
lab,
because
they
can't
really
see
the
relationship
between
a
shared
production
environment
like
when
we
think
about
a
mobile
application
and
a
web
application.
Sometimes
customers
want
to
view
those
as
a
single
customer
experience,
but
we
don't
have
the
ability
to
like
link
those
production
environments
like
especially
if
the
web
app
is
not
a
native
application.
It's
a
responsive
web
app.
A
So
it
really
is
like
the
same
application
just
on
different
devices.
Additionally,
like
a
production
environment
from
a
micro-services
perspective
can
be
several
different
services
feeding
into
that
production.
But
today,
in
get
lab
you'll
have
several
different
projects
all
with
the
same
URL,
but
the
environments
dashboard
will
populate
seven
different
environments.
So
there
isn't
a
great
way
to
say
that
this
environment
shared
which
we'll
be
fixing
in
the
next
couple
of
milestones
from
the
ability
to
share
a
target
environment
but.
A
Managing
that,
across
hundreds
of
projects,
where
really
it's
only
like
six
or
seven
customer,
experienced
productions
right,
it
makes
it
virtually
impossible
for
people
to
click.
Okay.
What
is
the
health
of
my
production
environment?
Not
just
the
health
of
this
one
service,
that's
contributing
to
the
production
environment,
any
of
the
things
that
you
could
think
of
in
the
work
around.
A
Alright,
let's
dive
into
some
some
learnings
I
left
this
one
blank,
because
I
think
that
your
assumptions
having
be
having
been
in
both
verified
and
release
as
a
designer
might
be
a
little
bit
different
than
what
mine
are
going
to
be
so
I'm
really
interested
in
hearing
like
how
you
perceive
people
working
across
environments
at
scale.
So,
for
example,
one
of
my
assumptions
will
be
people
are
hesitant
to
use
gitlab.
A
D
D
A
C
C
A
Some
yes
yeah,
we
had
a
survey
and
people
are
like
yeah
I,
don't
really
know
what
environments
are,
and
that
was
like.
The
most
eye-opening
thing
is
that
these
people
have
hundreds
of
environments
and
they're
actively
deploying
to
them,
but
they
said
I,
don't
know
what
environments
are
and
it's
like.
A
Like
I've,
never
I've
actually
never
seen
my
environments
less
screen
because
I'm
going
to
a
different
tool,
the
worst
thing
to
hear
as
a
project
manager
I'm,
actually
not
using
that
no
I
am
but
I.
Don't
know,
I
am
yeah
okay,
so
some
bullet
points
that
I'll
put
from
a
what
we
thought
for
the
solution.
A
C
A
A
So
this
is
like
an
application
model
where
you
have
like
a
site,
and
then
you
have
the
database
here
and
then
you
have
an
external
integration
and
then
a
backup
system.
And
then
this
is
like
an
API
that
goes
to
a
partner
site,
and
these
are
the
actions
that
people
are
expecting
to
interact
with
your
application.
A
A
context
diagram
and
like
this
one's,
probably
a
little
bit
better
because
you
have
the
client
and
all
the
sub
services
I
mean
you
can
see
like
it
indicates
access,
meaning
they
cause
it
needs
to
authenticate.
So,
like
that's
an
authentication
service,
we
don't
offer
anything
like
this
thing
get
web
right,
and
this
is
a
very
legacy
way
of
viewing
applications.
A
C
Do
you
remember,
like
anything
because
I
think
it's
almost
two
years
old?
It
was
maybe
the
first
big
thing
that
I
inherited
from
you
I
asked
you
actually
say
sink
before,
but
do
you
have
any
memories
of
the
reservation
ship
between
these
two
dashboards
and
the
influence
that
he
had
in
the
user?
Experience
that
we
have
today.
D
B
It
hard
to
answer
because
as
far
as
I
remember
for
the
first
at
least
like
six
months
or
so
it
gotten
zero
use
as
far
as
I
know,
so
there
wasn't
much
to
care
or
influence
at
all
and
then
at
some
point
people
began
to
use
it,
but
I
am
not
sure.
Where
widen
exactly
happened.
I
think
it
was
them
already.
C
D
C
B
I
still
remember
that,
like
part
of
the
reason
we
in
in
a
way
that
we
did
it,
which
was
on
the
user
level,
not
on
the
group
instance
or
project
level,
was
based
on
engineering
scope,
it
was
just
easier
to
do
that,
so
there
was
always
less
influence.
I
like
what
does
that
means
for
to
use
experience?
No,
no!
This
is
easy.
Let's,
let's
go
for
that,
which
I
think
it
isn't
in
here
inherent
wrong
approach.
But
again
this
wasn't
rushed
kind
of
like
a
rush
thing
as
well,
so
it
was
like
alright.
A
I'm,
just
adding
some
impact
notes,
given
that
we'd
be
expanding
our
persona
here,
part
of
our
assumption
of
users,
not
feeling
empowered
to
use
our
tools
at
scale
once
we
unlock
this
assumption
and
we
allow
them
to
effectively
do
that,
we
can
be
opening
up
that
persona
and
to
get
lab,
and
that
would
mean
companies
would
want
to
expand
their
seats.
We
know
today
that
around
40%
of
the
CI
accounts
aren't
deploying
or
aren't
releasing
with
get
lab,
they're
not
orchestrating
the
releases
out
of
get
lab.
A
They
may
be
packaging,
a
binary
and
then
shipping
that
to
artifactory
and
then
deploying
it
to
production,
so
they're
building
but
they're,
not
deploying
straight
out
of
get
lab
so
part
about
limitation
is
around
being
able
to
see
things
and
control
and
manage
at
scale.
So
from
look
for
a
solution
perspective
I
think
that
we
have
probably
two
main
options
around
empowering
users.
One
of
them
is
around
powerful
documentation
on
how
to
plan
and
track
the
deployments
and
get
lab
and
I
also
think
that
the
other
piece
is
providing
of
you
into
that
anything
else.
A
C
Well,
that's
what
I'm
fighting
a
single
new
yeah!
You
know
I
think
in
general,
not
only
the
documentation
but
helping
guide
users
so
that
there's
more
discoverability
when,
for
example,
they
don't
necessarily
need
to
use
the
environment
sub
dashboard.
Let's
eat
environments
with
you,
you
know
you
can
learn
about
this
other
feature.
I
love.
B
B
On
sorry,
do
we
have
an
emphasis
on
like
showing
users
like,
for
example,
the
the
tools
that
we
offer
like
I,
like
the
beginning,
like
out-of-the-box
experience
and
I
guide
the
users,
but
we
actually
have
an
emphasis
on
show
Muse
like
hey.
If
you
use
this
correctly
or
you
know,
as
we
indicated,
we
have
this
in
line
when
you're
using
it.
It
will
deliver
you
this
this.
This.
A
C
C
Just
want
to
admire
my
thumbs
up
to
the
documentation,
know
how
to
plan
not
necessarily
just
here's
environment
dashboard.
But
how
do
you
plan
your
deployments?
We
need
Levin
tell
the
whole
story,
that's
where
we
can
connect
also
with
the
progressive
deliver
functionalities
I
personally,
when
I
have
to
learn
something
about
the
product.
That's
what
I
mean.
What
can
I
do
with
this,
and
where
can
this
take
me
and
yeah
focus
a
little
bit
more
in
the
user
flow
zone,
perfect.
A
Yeah
I
I
felt
we
got
so
much
more
engagement
after
I
released
that
blog
post
on
how
to
automatically
release
with
get
lab
around
our
gamal
generation.
We
had
people
testing
the
alpha
version
and
I
want
it.
I
want
to
inspire
people
to
give
that
feedback
on
contributions
and
I
feel
like
the
more
content
that
we
can
create
and
empower
users
to
feel
like
they
can.
They
have
a
voice
like
this
is
work
in
progress
versus
just
shipping,
something
that's
full
I
think
will
be
really
powerful
and
compelling
for
users.
A
Okay.
So
if
you
think
of
any
other
assumptions,
I'm
high
ona
the
stock,
you
better
access
in
here
so
feel
free
to,
like
add
a
bullet
point
and
comment
on
me
and
then
comment
on
me
comment
to
me
and
it
all
respondent,
except
we
have
about
five
minutes,
left,
let's
dive
into
the
business
case.
So
from
our
reach
perspective,
I
did
a
couple
number
crunching
inside
of
Salesforce
and
we
have
like
75%
of
our
base
with
greater
than
a
hundred
users
deploying
several
times
a
day.
A
So
we
know
customers
are
deploying
at
scale,
but
we
know
that
they're
not
actively
using
the
environments
dashboard,
or
we
also
have
been
confirmed
with
several
interviews
that
they
are
using
other
tools
outside
of
get
lab
to
manage
production
deployments,
and
this
is
where,
like
ori
and
progressive
delivery,
is
building
out
these
templates
for
a
better
target
experience
and
get
lab
to
reduce
that
friction.
So
this
is
a
common
understanding
across
the
release.
Release
team
from
a
reach
perspective,
I
think
worst
case
is.
A
We
won't
get
an
immediate
adoption
of
the
environments
dashboard
because
we
will
need
to
compete
with
the
existing
workflow
of
the
users
leveraging
their
existing
tools,
which
are
the
clients
unless,
if
our
solution
ends
up
being
like
integrating
with
the
client,
so
this
is
something
that
we'll
need
to
consider
in
the
solution.
I'm
not
going
to
say
that
integration
with
an
AWS
client
is
out
of
out
of
reach
for
us.
A
Of
course,
it
wouldn't
be
in
the
scope
of
the
environments
and
operations
dashboard
redesign,
but
it
would
be
something
for
us
to
like
how
do
we
provide
linking
into
those
clients
easily
from
the
dashboard?
So,
for
example,
how
do
we
add
a
URL
to
the
client
so
that
they
can
click
on
it
and
then
it
authenticates
with
gitlab
as
a
user,
and
they
can
then
view
their
deployment
from
AWS.
So,
like
that's
a
flow
that
we
could
consider
linking
from
the
dashboard
so
worst
case,.
D
A
A
I'm
going
to
say
that
we
have
a
fairly
medium
confidence
as
it
ranks
now
in
being
able
to
deliver
some
sort
of
solution
to
this
problem,
like
I
think
that
we
can
chip
away
at
users
being
able
to
effectively
manage
deployments
at
scale
and
get
lab
I.
Don't
think
this
is
an
unsolvable
problem,
I
think
when
it
comes
to
the
solution
section.
That's
when
we'll
have
to
like
think
through
what
is
our
next
iteration
for
this
and
how
much
are
the
problem
will
be
solved
with
that
iteration.
A
For
me,
from
a
urgency
priority
perspective,
I
think
that
we
need
to
ship
the
remainder
of
our
deploy
freeze
in
the
UI
experience.
We
need
to
support
group
environments
and
support
group
releases,
and
then
this
is
third
in
line
so
I
would
say:
13.5
would
be
our
expectation
of
shipping
designs
or
mocks
for
whatever
new
experience
for
implementation
in
like
13.7,
and
my
goal
would
be
that
we
could,
you
know,
look
at
13.8,
13.7
being
the
iterations
that
we
improve.
A
C
A
In
my
mind,
like
that,
it's
absolutely
something
that
we
need
a
before.
We
can
work
on
this
because
it
would
be
pretty
useless
being
able
to
to
not
share
a
production
environment
like
that's.
A
part
of
the
problem
is
that
you
see
seven
production
environments,
even
though
it's
really
just
one
production
environment.
It's
just
shared
right.