►
From YouTube: The GitLab Journey & GitOps Use Case
Description
William with Product Marketing discusses what is GitOps, who are the user / buyer personas, and what are some assets to look at today and coming soon.
https://about.gitlab.com/handbook/marketing/product-marketing/usecase-gtm/gitops/#what-is-gitops
A
A
The
general
notion
here
is
that
git
ops
is
one
of
our
eight
go
to
market
use
cases.
So
when
we
say
go
to
market
use
case,
we're
talking
about
a
reason.
Why
organization
why
a
business
or
an
organization
would
buy
gitlab?
This
is
usually
something
that
attracts
a
budget
is
something
the
customer,
a
problem
the
customer
needs
to
solve
for,
and
we
try
to
articulate
that
in
the
terms
of
the
customer.
So
as
an
example,
customers
tend
to
need
version
control,
so
one
of
our
use
cases
is
version
control.
A
Customers
tend
to
need
ci
cd,
so
one
of
our
use
cases
is
ci
cd,
and
in
this
case
one
of
our
customers
needs
is
git
ops.
Now,
because
it's
a
new
term,
the
the
customer
may
or
may
not
use
that
language,
but
it
is
a
problem
that
they
need
to
solve
for
so
let
me
dive
in
to
share
some
of
our
resources,
and
hopefully
it
will
become
a
little
bit
more
clear.
What
git
ops
is
so
the
first.
A
The
first
thing
I
just
want
to
point
to
is
the
the
single
source
of
truth
that
you
need
is
the
use
case
go
to
market
page.
This
page
is
your
sales
resource.
That
is
the
lending
off
point
for
all
of
the
other
resources.
So
everything
else
I'm
showing
today
is
linked
on
this
page,
and
this
is
your
one-stop
shop.
So
if
you
only
go,
have
one
url,
this
is
the
one
to
go
to
and
it's
linked
in
our
notes
today.
A
A
So
really,
one
of
the
images
I
like
to
show
is
this
is
an
image
of
the
git
lab
flow.
For
example,
if
you're
doing
application
development,
you
create
an
issue,
you
create
a
merge
request.
You
commit
your
changes,
you
run
ci
etc.
Well,
this
is
the
same
flow
that
can
be
done
for
your
infrastructure
and
your
environment.
So
these
are
things
like
you
know:
provisioning
virtual
machines
or
deploying
containers
on
your
cluster
or
it
could
I
like
to
make
this
broader
than
even
just
infrastructure.
A
This
I
like
to
talk
about
environments
generally,
because
this
could
be
provisioning.
Your
access
policies.
Your
policy
is
code,
not
just
infrastructure's
code.
This
could
be
provisioning
network
configuration
right.
So,
if
you
think
of
a
tool
like
a
terraform
or
aws
cloud
formation,
these
types
of
provisioning
tools
that
provision
entire
environments-
things
like
the
firewalls,
in
addition
to
the
virtual
machines
that
entire
environment
as
code-
that's
what
we're
talking
about
when
we're
talking
about
git
ops,
so
your
customers
and
your
prospects
they
may
or
may
not
use
the
term.
A
Git
ops,
like
I
said,
get
out,
is
very,
very
new,
so
the
likelihood
of
them
actually
using
that
term
is
actually
pretty
small.
Today,
they're
far
more
likely
to
talk
about
terms
such
as
infrastructure
as
code
they'll
likely
say,
we
want
to
do
infrastructure,
as
code
is
probably
the
biggest
one.
They
will
probably
also
talk
about
using
tools
like
terraform
or
ansible
chef
or
puppet.
A
So
similarly,
if
you've
heard
me
talk
about
cloud
native
application,
development,
which
is
another
gitlab
use
case-
and
I
say
your
customers
may
or
may
not
actually
use
the
term
cloud
data
they
may
they
may
not
come
to
you
and
say,
like
I
have
a
cloud
native
application
development
problem.
Can
you
help
me
solve
it,
but
they
are
likely
to
say
I
want
to
do
things
like
adopt
kubernetes
right,
so
kubrick
I
want
to
adopt
kubernetes
or
I
want
to
adopt
microservices
or
I
want
to
containerize
my
workloads.
A
All
of
those
things
are
code
words
for
the
dev
side
of
the
house
that
they
want
to.
They
want
to
adopt
cloud
native
application
development
and
they
may
in
fact
use
the
word
cloud
native.
Similarly,
if
they
say
we
want
to
do
infrastructures
code
or
you
know,
we
want
to
use
git
lab
together
with
ansible
or
terraform
those
the
that's.
What
they're
really
talking
about
doing
git
ops,
it's
kind
of
at
the
high
level.
A
One
thing
I'll
say
about
how
we
at
get
lab
view
getups
we
have
our
our
own
unique
take
and
because
it
is
a
new
term,
it's
kind
of
like
devops
right.
If
you
ask
10
devops
practitioners
to
define
devops
you're
going
to
get
10
different
definitions.
So
a
lot
many
tech
terms
are
like
that.
Git
ops
is
no
exclusion
to
that.
So
everyone
in
the
industry
is
defining
a
little
bit
differently.
The
the
phrase
was
coined.
A
But
we
look
at
it
brought
more
broadly,
we
just
say
like
any
type
of
infrastructure
provisioning,
whether
you're
doing
microservices
or
not,
whether
you're
doing
kubernetes
or
not,
if
you're
doing
infrastructure
as
code,
you
know-
and
you
want
to
automate
that
that's
really
get
up.
So
we
kind
of
take
a
broader
view
and
one
of
the
focuses
obviously
as
gitlab
our
take
on
it,
is
that
the
merge
request
is
a
really
core
component.
A
So
if
you
talk
to
you
know
a
company
like
so,
for
example,
yesterday
we
had
a
really
amazing
panel
brendan
o'leary,
and
I
together
did
a
panel
webinar
with
the
cto
of
weworks.
The
cto
of
hashicorp
and
the
principal
product
manager
for
ansible
had
a
really
great
discussion
about
git
ops,
about
the
market,
about
infrastructure,
automation
and
so
everybody
kind
of
had
their
own
take.
So
you
know
weave
works.
They
they
focus
a
lot
on
cd,
their
main
tool.
A
Flux
is
a
cd
tool,
so
when
they
talk
about
git
ops,
it's
90
of
what
they're
talking
about
is
is
continuous
delivery
and
what
they
call
continuous
operations.
That's
their
big
focus,
that's
what
their
tool
does,
and
they
talk
a
little
bit
about
git,
it's
a
part
of
it,
but
they
talk
more
about
those
components
for
us,
obviously,
as
a
single
application,
a
complete
devops
platform
in
a
single
application,
we
take
them
more
broadly.
Yes,
we
talk
about
the
infrastructure.
A
Yes,
we
talk
about
the
cicd,
but
we
also
talk
about
the
merge
request,
because
our
version,
control
and
collaboration
tool
is
so
powerful
and
that
this
is
the
core
of
our
product.
That
is
really
a
beautiful
product,
and
so
the
idea
here
is
when
you're
using
merge
requests
to
initiate
changes
into
your
production
environment.
A
A
A
A
You
want
to
have
a
you
know,
a
small
group
of
of
codified
and
certified
release
engineers
that
can
that
can
push
that
button,
but
you
don't
want
to
lock
down
your
contribution
right
increasingly,
as
not
only
applications
become
distributed,
like
let's
say,
you're
doing
microservices,
instead
of
just
a
monolithic
application.
Now
you
have
a
distributed
application.
A
Similarly,
our
teams
are
becoming
distributed,
especially
in
the
current
age,
where
everyone
is
working
remote
now,
just
like
gitlab
and
now
teams
are
distributed.
So
more
than
ever,
software
development
teams
are
working
on
distributed
applications
where
they
themselves
are
in
different
locations
and
are
distributed
so
in
that
environment.
If
you
want
to
do
collaboration
moving
your
your
policy
and
your
infrastructure,
your
network
configuration
these
things,
moving
them
into
code
and
using
gitlab.
A
Now,
all
of
a
sudden,
you
can
collaborate
with
with
people
all
over
the
globe
asynchronously,
and
so,
with
this
kind
of
merge
request
model
you
can
have
anybody
can
propose
a
change
to
let's
say
this
algorithm
for
the
stock
market.
Anybody
can
propose
a
change,
so
you
have
broad
collaboration,
but
few
people
actually
have
the
ability
to
merge
that
change,
and
that's
where
you
get
your
compliance.
A
So
there's
a
lot
of
benefits.
I
don't
have.
I
could
talk
about
this
all
day,
long.
Anybody
who
wants
to
talk
more
about
get
ops,
I'm
happy
to
talk
more,
but
hopefully
it
gives
you
kind
of
like
a
view
of
like
what
git
ups
is
some
of
the
reasons
why
it
it
is
emerging
as
a
powerful
practice
and
some
of
the
benefits
of
it.
So
there's
there's
more
benefits
here.
We
also
have
this
git
ops,
topic
page,
which
is
really
nice.
A
This
is
like
our
internal
handbook
page
that
has
all
the
notes,
I'll
touch
briefly
on
the
personas
that
you
would
encounter
so
similarly
on
the
application
side
of
the
house,
if
you
were
doing
a
sale,
you'd
be
looking
at
like
the
vp
of
app
dev
or
or
some
type
of
engineering
manager,
engineering
director
on
the
application
side,
the
folks
that
are
responsible
for
infrastructure
and
operations.
Those
are
going
to
be
your
git
ops
folks.
A
They
have
an
operations
person,
they
have
somebody
who's
responsible
for
the
uptime
and
operations
of
that
service.
But
they're
not
solely
responsible
for
themselves.
We
call
that
person
the
embedded
sre
so
rather
than
being
off
on
a
separate
team.
They
tend
to
be
embedded
together
with
the
developers
that
own
that
service
and
what
I've
seen
really
good
is
there's
this.
A
We,
you
know
pareto
principle,
80
20,
split
where
the
devs
don't
just
only
write
code,
they're
also
responsible
for
operating
the
service,
but
maybe
an
80
80
20
split,
where
the
sres
still
write
some
code,
maybe
20
20
and
are
80
responsible
for
the
operation
of
that
service,
and
that's
within
that
layer
of
the
the
dev
team.
But
then
those
dev
teams
they
don't
they
shouldn't-
have
to
worry
about
things
like
kubernetes
clusters.
A
A
Where
these
these
teams
are
building
essentially
internal
platform
as
a
service
services
that
they
serve
out
to
their
dev
teams.
These
are,
you
know,
often
built
on
top
of
kubernetes.
This
idea
is
that
the
platform
ops
team
they
own
the
clusters,
they're
responsible
for
the
upkeep
and
the
maintenance
of
those
clusters
and
then
the
developer
teams.
They
offer
that
that
platform
to
them
as
a
service,
usually
with
some
pipelines
that
allow
them
to
deploy
into
kubernetes.
I'm
sure
you
can
already
see
where
gitlab
is
a
very
powerful
tool
for
this.
A
This
use
case,
because
we
have
such
great
version
control,
because
we
have
such
great
ci
cd
and
then
optionally,
sometimes
there's
even
a
separate
infrastructure
team.
So
this
is
where
you
might
have
like
a
database
administrator
and
the
infrastructure
team,
or
this
is
where
the
people
who
are
responsible
for
the
the
actual
virtual
machines
and
the
nodes
or
the
actual
physical
infrastructure
is
sometimes
a
separate
team.
Sometimes
the
platform
operations
team
owns
not
only
the
cluster
but
also
the
infrastructure
as
well.
A
So
that's
kind
of
the
user
personas
in
terms
of
the
buyer,
personas
we're
looking
at
all
of
your
your
ino
infrastructure
and
operations,
personas
folks
like
the
cio
or
vp
of
I.t.
If
anybody
who's
a
who's,
a
director
vp
that
has
infrastructure
in
their
title,
this
is
some
some
one
where
we
can
tell
them
about
the
benefits
of
our
infrastructures,
code
and
github's,
powerful
parts
of
gitlab,
and
especially
this
one
right
here.
A
Things
like
our
terraform
integration,
we're
building
up
more
and
more
features
that
integrate
with
terraform
we
partner
with
all
of
these
other
tools,
and
so
that's
a
really
strong
part
of
our
story
where,
with
other
use
cases
like,
let's
say,
ci
cd,
the
story
might
be
well.
Git
lab
is
the
one
thing
and
you
do
it
all
with
git
ops.
Our
partner
story
is
a
really
powerful
part
of
that
story.
A
If
everything
is
is
in
a
container,
maybe
you
don't
even
need
that
tool
right.
You
just
have
your
cluster
connected
to
gitlab
and
gitlab?
Has
your
gitlab
has
your
cluster
connection?
Gitlab?
Has
your
container
registry
gitlab?
Has
your
ci
cd,
it's
all
in
gitlab,
but
if
you're
using
a
tool
like
terraform
gitlab's
not
going
to
replace
terraform
if
using
tool
like
ansible
gitlab's,
not
gonna,
replace
ansible,
so
instead
we're
gonna
partner
with
those
companies.
We're
gonna,
build
strong
integrations,
and
we
already
have
some,
for
example,
for
tools
like
like
careful
like
terraform.
A
A
These
are
some
of
the
market
requirements,
so
you
may
be
familiar
from
other
use
cases
where
we
say:
what's
your
customer,
what's
the
problems
that
they're
gonna
have
that
we're
gonna
help
them
solve
right?
One
of
the
problems
is
they're
gonna
need
that
foster
collaboration,
and
this
is
a
really
good
way.
I
I
should
have
brought
this
in
earlier,
but
a
great
way
to
think
about
the
benefits
that
git
lab
offers
for
git
ops.
A
Is
it's
a
it's?
A
combination
of
the
benefits
of
our
version
control
and
collaboration
and
the
benefits
of
our
ci,
the
benefits
of
our
cd
and
the
benefits
of
our
partner
integrations,
which
I've
just
talked
about
right.
So
all
of
those
together
are
the
git
ops
benefits
because,
for
example,
if
their
use
case
is
version
control
for
application
code,
we
have
all
these
version
control
benefits
things
like
our
amazing.
You
know,
code
review
process
and
the
ability
you
can
comment
on
each
line.
A
You
can
apply
suggestions
and
these
really
nice
workflows
for
doing
code
review.
Well
all
the
same
code
review
for
your
application.
Development
teams
is
the
same
type
of
collaboration,
benefits
that
your
infrastructure
and
operations
teams
are
going
to
benefit
from
the
the
modern
types
of
I
know
so
so
traditional
itops
is,
this
is,
is
not
going
to
be
using
these
tools
right.
Traditional
traditional
I.t
ops
is
a
different
story,
but
the
modern.
What
would
it
call
modern
ino?
These
are
folks
like
site,
reliability,
engineers,
devops
engineers,
platform
platform
operations,
engineers.
A
They
want
to
collaborate
in
code.
We
have
great
code
collaboration
tools
right
same
thing
for
like,
for
example,
test
automation.
You
want
to
do
test
automation
for
your
application
code.
We've
got
great
ci.
You
want
to
do
test
automation
for
your
infrastructure
or
your
environments.
We've
got
great
ci
right
so
as
you're
thinking
about
selling
this
use
case
into
folks
that
have
infrastructure
in
their
title
and
helping
to
share
with
them
why
this
is
beneficial
for
them
or
how
we
can
help
them
out,
make
them
successful.
A
It's
it's
a
lot
of
the
same
benefits
and
a
lot
of
same
language.
We
would
share
with
the
app
dev
folks
right,
so
all
the
benefits
of
reversion
control.
We
share
the
app
dev
folks
for
the
I
know,
folks
we
would
say
hey
if
you're
doing
infrastructure's
code,
we
have
all
these
version,
control,
benefits,
etc.
A
There
are
a
lot
of
a
lot
of
customers
already
doing
this,
even
though,
like
I
said,
git
ops
is
a
pretty
new
thing
infrastructure,
as
code
has
been
around
for
at
least
a
decade,
and
so
we
have
folks
that
are
already
doing
this
folks,
like
kiwi
folks
like
this,
is
a
cool
video
from
vmware
who's,
another
one
of
our
partners.
They
did
this
talk
at
gitlab
commit
about
how
to
do.
A
You
know
infrastructure's
code,
there's
one
that
I'm
looking
for
northwestern
mutual
here's,
a
really
cool
video
about
how
northwestern
mutual
is
using
get
lab
together
with
terraform
right.
So
customers
like
northwest
mutual
wag
labs.
We
have
another
list
of
them
here.
These
are.
These
are
folks
that
are
doing
this
today,
they're
any
of
our
customers
that
are
using
terraform
together
with
gitlab.
That's
that's!
A
For
the
most
part,
they're
doing
git
ops
and
we
have
many
of
them
and
you
can
share
their
stories
of
how
they've
been
successful
using
gitlab
last
thing,
this
resources
section
here
on
the
go
to
market
page.
This
is
where
the
slide
deck
and
the
video
that
I
you
can
actually
see
this
slide
deck.
I
did.
I
did
a
video
where
I
present
the
whole
thing.
So
it's
about
40
minutes.
If
you
want
to
kind
of
in
depth
like
see
this
entire
deck
presented,
that
video
is
linked
here.
A
The
pages
are
linked
here.
We
have
a
lot
of
other
great
videos,
what's
really
cool.
What
makes
me
excited
about
git
ops
is
that
within
our
company
we
have
a
lot
of
smes,
which
I
forget
what
that
stands
for.
Subject
matter
expert,
so
we
have
many
subject
matter:
experts
a
lot
of
folks
in
our
solution,
architect
or
tams.
A
Even
brad
downey
is
a
you
know
in
the
sales
org
and
holding
his
own
as
a
technical
expert
as
well.
So
some
of
these
blogs
and
videos
are
from
him
myonk
who's,
one
of
our
alliances
folks.
So
we
have
a
lot
of
folks
that
are
are
really
subject
matter.
Experts
on
this
and
they're
all
contributing
content.
A
We
have
a
lot
of
content
already,
even
though
we've
just
started
this
go
to
market
motion,
we've
just
started:
we've
just
launched
a
campaign
around
get
ops
where
we're
doing
you
know
these
webinars,
like
we
did
yesterday
and
and
ads
and
landing
pages,
and
these
kinds
of
things
to
generate
leads.
We
already
have
a
good
bit
of
content
that
I'm
excited
about.
So
with
that
it
looks
like
we
have
nine
or
ten
minutes
left.
C
D
C
Share
we
do
have
the
project
and
the
blog
it's
great.
Now
it's
you
know
with
a
handbook
with
more
information,
the
use
cases,
but
especially
with
banks.
The
moment
we
go
into
I
I
see
infrastruc
infrastructure
as
a
call
because
they
can
manage
through
merge,
requests
all
that
stuff
and
the
automation.
Then
they
say
it's
a
configuration
as
a
code
as
well,
so
we
have
to
show
terror
form
provider.
C
So
is
this
effort
include
configuration
as
call
or
stay
in
the
scope
of
infrastructure
portion?
I
know
our
demo
project,
it's
great
jeff
built
the
whole
infrastructure
as
a
code
and
the
configuration
as
a
code.
So
I'm
using
that
as
a
reference
point
right
now,
just
curious
the
scope
of
working
through
that
as
well.
This
bank
specifically
asked
for
that
because
they
want
to
provide
audit
trail,
it's
a
compliant
environment,
so
everything
has
to
be
tracked
and
versioned.
A
A
So
what
I
like
to
talk
about
is
sometimes
I'll
say:
x:
excess
code,
because
infrastructure
configuration
policy
operations
as
code
security
is
code,
any
any
of
those
infrastructure
and
operations
concerns
we're
calling
that
git
ops
right.
So,
yes,
absolute
configuration
is
code.
Absolutely
policy
is
code.
All
of
those
things
that
are
the
concern
of
the
site,
reliability,
engineer
or
the
platform
engineer
the
devops
engineer,
all
of
those
tools
that
they
would
work
on
that
are
not
necessarily
the
concern
of
the
software
developer.
A
The
feature
development
right,
so
this
is
the
these
are
two
different
parts
of
the
organization,
but
they
can
both
benefit
from
git
lab
and
what
you
have
just
nailed.
There
is
like
what
they're
looking
for
is
these
security
and
compliance
benefits,
and
this
is
the
one
that
I
hear
over
and
over
and
over
again
that
you
know
if
you're
trying
to
do
your
auditing
and
your
infrastructure
and
configuration
and
network,
and
all
of
that
is
provisioned
via
clicking
on
these
manual
buttons.
Well,
then,
you
have
to
document
it
somewhere.
A
You
then
have
to
read
that
documentation.
What
state
is
it
in?
We
don't
know,
and
when
I
go
to
audit,
I
now
have
to
go
and
pull
data
out
of
these
multiple
places
to
try
to
figure
out
what's
going
on
and
am
I
compliant,
but
if
every
change
to
your
policy
and
every
change
to
your
infrastructure
and
every
if
all
of
these
changes
are
all
tracked
in
one
git
log
and
all
I
can
do-
is
just
look
at
the
git
history
and
there's
my
audit
log,
it's
very
very
powerful.
A
C
A
A
I
do
know,
for
example,
that
some
of
the
features
in
gitlab,
for
example,
we
have
released
the
ability
to
store
terraform
state
within
gitlab
as
your
storage
mechanism.
So
without
this
feature,
if
you're
using
gitlab
and
using
terraform,
then
that
terraform
state
file
that
needs
you
need
to
store
that
somewhere.
A
So
now,
all
of
a
sudden,
you
need
a
separate
place
to
go
and
store
that
so
so
gitlab
has
a
nice
tightly
integrated
feature
where
you
can
just
store
that
state
file
and
it'll
even
show
up
in
your
merge
request
and
be
able
to
parse
it
that
kind
of
feature,
and
we
have
more
capabilities
coming.
That
will
be
more
tightly
integrated
with
terraform,
and
I
will
need
to
follow
up
on
unless
anyone
on
the
call
is
more
up
to
speed
on
that
on
the
state
of
the
terraform
provider.
C
A
Yeah-
and
I
will
mention
here
the
call
to
action
that
john
and
I
discussed
what
do
everyone
on
this
call?
What
are
we
asking
of
you
so
mostly
I'm
just
sharing
with
you
and
hopefully
sharing
information,
that's
helpful
to
you,
but
I
do
have
an
ask
of
you,
and
that
is
if
you
are
doing
discovery
with
any
customers,
if
you're
doing
discovery
with
folks
like
this,
on
the
infrastructure
and
operations,
side
and
you're
doing
a
discovery
call
with
gitops.
I
personally
would
love
to
join.
That
call.
A
A
B
D
Actually,
thanks
john,
I
was
looking
at
the
the
the
page
for
get
ops
william.
It
looks
like
you've
started
down
underneath
the
gitlab
solution
where
you've
got
discovery,
questions,
competitive
comparison,
etc.
The
message
house
bit
there
so
no
need
to
no
need
to
tackle
this
one
now,
but
I
think
in
terms
of
the
use
cases,
it
might
be
good
to
follow
the
command
of
the
message
framework
as
in
hey,
what's
your
status
now,
what
are
the
negative
consequences?
What
happens
if
you
don't
do
anything?
D
A
One
is
it's
part
of
our
gitlab
culture
right,
everything's,
always
in
draft,
so
I'm
not
gonna,
it's
never
ever
gonna
be
fully
baked.
So
I
wanted
to
share
with
you
what
I
had.
I
felt
there
was
something
meaningful
there
today,
even
though
there's
a
lot
more
coming
and
also
we've
already
started
to,
we've
already
started
our
marketing
campaigns.
So
with
other
use
cases,
we've
developed
the
entire
use
case,
and
then
we
run
a
marketing
campaign
on
it
with
git
ops.
We
said
we
really
didn't
want
to
wait.
A
We
felt
like
there's
a
market
need
to
go
and
address
and
we
already
started
the
campaign
so
we're
already
in
the
middle
of
this.
So
you
can
kind
of
see
some
of
the
planning
work
is
the
the
carts
before
the
horse
on
that
one.
So
you'll
even
see
parts
of
this
page
are
not
yet
filled
out,
so
there's
more
work
coming
and
that's
a
phenomenal
suggestion
to
to
mesh
those
things
with
the
command
of
the
message,
and
I
I
totally
agree.
D
E
A
That
yeah,
that's
a
really
good
point.
That's
why
I
say:
yeah
your
customers
they're
almost
certainly
not
going
to
use
a
term
like
git
ops,
if
they're
very,
very
up
on
the
latest
cloud
native
kubernetes,
you
know
they're
very,
very
sophisticated,
they
probably
will
say:
hey
we're
doing
git
ops,
and
can
you
talk
to
us
about
get
ops,
everybody
else,
they're
they're
going
to
be
using
terms
like
infrastructure
as
code
they're
going
to
be
talking
about
terraform
if
they
say
terraform
or
cloud
formation.
A
Those
are
key
words
to
key
you
into
this,
and
it
looks
like
we're
just
up
on
time.
If
there
are
other
questions,
I'll
address
them,
async
in
the
sales
channel
or
wherever
john
tells
me
is
a
good
place
to
go.
Put
those
and
would
certainly
love
to
continue
this
conversation.
Please
I'd
love
to
join
your
your
calls
and
ask
any
other
further
questions.
We
can
keep
the
conversation
going.