►
From YouTube: Continuous Product Oriented Practices
Description
CDF Ambassador presents the concept of Continuous Product Oriented Practice! In this webinar, guest, Garima Bajpai will cover:
- Continuous Product Oriented Practice focus on integrating “Value” in product
management from product inception to retirement in the devOps way
- Breaking Each step is in its own silo including planning
- Product Canvas, DevOps way!
A
Welcome
everyone
to
the
CDF
member
webinar
series.
Today
we
have
our
ambassador
Garima,
presenting
the
continuous
product
oriented
practice
and
she
also
has
two
of
her
colleagues
from
carbon
capital
joining
her.
Today.
It's
Steve
and
then
I'm
sorry
I
in
William,
Steven,
William.
So
welcome
and
I
hope
you
enjoy
our
webinar
today.
So
kick
it
off.
Karema
yeah.
B
Thank
you
very
much.
First
of
all
for
inviting
us,
it
has
been
a
pleasure
associate
being
associated
with
slavery
foundation.
You
guys
are
doing
a
great
job
so
kudos
to
you
before
we
start
this
webinar
I
think
I
would
like
to
introduce
myself
and
the
team
so
understood
of
canada,
ottawa
and
talking
about
myself,
Grima
bajpai
and
one
of
the
cofounders
for
the
devops
summit,
which
happens
in
Canada.
I
am
also
co-founder
for
the
DevOps
meetup,
which
happens
in
Canada.
B
The
community
of
practice
for
DevOps
I
am
DevOps
ambassador
with
Clinton
still
Foundation,
as
well
as
DevOps
Institute.
Also,
my
professional
associations
I
belong
to
two
different
boards
of
two
different
companies:
their
startup
companies.
One
is
a
moment
of
startup
capital,
Carbon
consulting,
which
is
heavily
invested
in
DevOps
and
I
sit
on
the
board
of
this
company
I'm
also
associated
with
health,
food
Auto,
Leadership
Institute,
which
is
an
early-stage
startup
and
there.
This
is
where
my
experience
comes
from.
B
Building
up,
startup
small
medium
enterprises
I've
also
been
part
of
big
mature
businesses
for
20
odd
years.
So
I
also
kind
of
understand
where
IT
and
IT
solutions
and
digital
solutions
are
taking
us.
So
that's
that's
a
really
bad
myself.
Now
I
give
the
stage
to
Steve
Steve.
Would
you
like
to
introduce
yourself
sure.
C
Could
could
no
everyone?
My
name
is
Steve
I
worked
with
haptic
have
been
consulting
with
garima
and
William,
so
talking
about
myself,
I
have
been
working.
The
IT
industry
for
20
years
and
I
have
my
own
penis
e-commerce
business
in
China
for
five
years.
So
that
is
my
my
fourth
quarter
journey
and
we
we
grow
from
five
five
Emily's
at
the
beginning
and
then,
after
only
two
years,
we
grow
to
1,600
employees
so
that
huge
change
to
to
to
mice
startups.
C
D
Yeah,
my
name
is
William
Satoshi,
originally
electrical
engineer,
I
became
interested
in
IT
and
got
into
programming
development
and
then
moved
or
into
project
management
working
in
a
few
different
industries
and
financial
services
in
an
HR
and
in
healthcare
areas,
I
really
became
interested
in
the
diversity
and
the
development
and
in
the
operation
side.
So
DevOps
is
a
natural
for
me
and
meeting
with
Steve
and
garena
in
the
last
year
became
interested
in
the
C
pop
concept
and
am
enjoying
the
journey
with
them.
So
looking
forward
to.
B
Thank
you
very
much.
So,
let's
quickly
get
on
to
the
topic,
today's
topic
is
continuous
product
oriented
practice,
and
what
we
are
trying
to
do
here
is
to
introduce
the
audience
with
the
playbook
before
we
actually
get
going.
I
also
wanted
to
talk
a
few
words
about
capita
carbon
consulting.
So
this
company,
as
I
said,
is
a
movement
of
startup
company.
We
are
heavily
invested
in
DevOps,
DevOps
certifications.
We
also
do
sorry
certification,
accredited
by
DevOps
Institute.
We
have
created
continuous
product
oriented
practice
which
we
will
talk
about
today.
B
B
Having
said
that,
what
makes
us
unique
is
what
we
are
doing
in
Canada
is
we
have
been
associated
with
a
large
set
of
startups
and
we
are
helping
these
startups
to
gain
momentum
when
you
interact
with
a
wide
range
of
startups
which
are
doing
digital
solutions
and
they
are
diverse
in
nature,
we
come
across
a
lot
of
different
problems,
but
what
essentially?
We
actually
come
across
is
some
common
threads,
and
that
is
where
the
continuous
product
oriented
practice
was
originated
from.
So
we
will
talk
about.
B
B
Lastly,
we
are
also
in
a
huge
promoter
of
open
source,
open
communities
and
I
do
belong
to
the
Ambassador,
we're
you
know,
open
source,
open
communities,
open
projects
are
being
you
know,
made
up,
so
that's
where
our
passion
belongs.
Now,
let's
talk
about
containers,
product
oriented
practice,
as
I
said
that
we
actually
meet
a
lot
of
startups,
and
the
common
thread
actually
which
we
have
got
from
these
startups-
is
that
they're
introducing
a
lot
of
products.
Now
we
will
talk
about
like
our
key
learnings
in
this
journey
and
how
we
initiated
this
practice.
B
B
You
know
products,
they
can
develop
products
and
they
can
speak
to
the
operations
team
and
do
operations,
so
they
are
bridging
the
gap
between
development
and
operations.
Now,
as
DevOps
has
gained
momentum,
people
have
understood,
and
actually
at
least,
if
not
close,
the
gap
at
they
have
been
discussing
how
to
close
the
gap
between
development
and
operations.
But
what
we
have
seen
working
with
these
startups
and
small
businesses
that
there's
a
larger
gap
in
strategy
planning
and
inception
stages-
and
this
is
where
continuous
product
oriented
practice
comes
in.
B
This
is
a
case
of
exponential
change
and
why
I
am
saying
that
is
that
we
have
been
incremental
improving
the
collaboration
between
development
and
operations
organization,
but
now
it's
our
time
to
take
an
exponential
leap
into
improvement,
how
we
vary
products
now,
taking
a
step
back
from
where
we
started
that
when
me
and
Steve
one
day,
I
think
it
was
somewhere
in
December
before
the
Christmas
holidays.
We
were
discussing
a
lot
of
things
about,
you
know,
Chinese
startups,
and
you
know
startups
in
India
and
how
we
see
startups
happening
in
North
America.
B
So
if
one
function
was
imagining
a
value
in
the
system
of
products
or
features,
it
was
not
translated
in
a
good
way
to
the
development
organization
to
the
operations
organization
and
the
feedback
journey
was
not
there,
so
we
actually
found
out.
That
was
one
of
the
primary
reasons
why
product
failed.
B
Also,
there
was
no
way
where
we
actually
can
assess
why
the
return
of
investments
was
delayed,
especially
for
these,
like
small
medium
enterprises,
which
are
continuously
working
on
MVPs,
so
they
and
they
were
not
able
to
find
solid
reasons
around
it
like
why
they
they
are
not
able
to
realize.
There
are
why
the
business
was
changing
faster
than
the
features
were
developed
and
I
am
not
the
only
one
saying
that,
but
the
fact
of
what
we
actually
discussed
was
why
that
was
happening.
B
That
was
happening
because
the
linear
shift
towards
lifestyle
had
is
no
longer
there,
so
people
have
started
to
shift
their
lifestyles
exponentially.
The
trajectory
is
exponential,
so
as
the
need
of
actually
digital
solutions.
So
when
you
think
about
that,
you
automatically
get
to
a
point
that
you
know
there
is
a
level
of
uncertainty
in.
B
You
know
how
products
and
features
will
be
used,
and
the
time
span
of
these
digital
solutions
are
being
reduced
so
that
that's
one
other
area
and
lastly,
we
also
actually
this
was
like
a
common
understanding
that
we
had
found
in
different
parts
of
the
world.
These
companies
actually
discussed
that
you
know
we
have
implemented
agile
and
devolves.
You
know
last
year,
but
how
to
generate
revenue
out
of
an
MVP
is
not
known
on.
B
And
we
created
this
continuous
product
oriented
practice
now,
to
give
you
a
brief
background
about
this
practice,
is
this
practice
advocates,
transforming
the
qualitative
way
how
we
will
products
to
quantitatively
and
you
will
ask
what
it
means.
So
basically,
what
we
are
doing
is
identifying
and
measuring
a
value
in
in
this
practice,
so
we
give
score
to
each
value
and
drag
them
in
this
practice
from
inception
to
operations
and
eliminate
the
silos
by
integrating
strategy.
Inception
planning,
designing
development
and
operations
through
a
uniform
value
radar.
Now
this
becomes
a
very
academic
definition.
B
The
journey
of
building
products
is
very
interesting,
and
it's
not
an
easy
one,
so
we
will
need
a
lot
of
tools
and
lot
of
techniques,
and
these
tools
and
techniques
have
to
be
integrated
in
one
way.
So
now,
I
give
the
forum
to
Steve
to
discuss
about
the
product,
canvas
and
the
practices
and
the
core
behind
this
whole
continuous
product
oriented
practice
so
Steve
over
to
you.
C
Son
son,
thank
you
karema,
so
I
I
see,
as
you
can
see,
this
picture
described
described
a
line.
So
behind
this
picture
is
a
lot
of
suffering
him
day
and
night.
So,
let's
back
to
twelve
twelve
years
before,
as
I
said,
I
have
my
own
e-commerce
business
in
China
for
five
years,
and
that
is
twelve
couriers.
C
When
we
have
only
20
employees
and
I
got
new
requirements
are
every
two
weeks
and
but
when
we
grow
to
100
employees,
they
they
gave
me
new
requirements.
I
were
weak,
not
every.
Two
weeks.
Every
week
I
we
have
the
my
my
department,
all
the
developers
have
the
requirements
and
after
we
have
300
employees,
my
department,
the
the
R&D
department,
got
a
new
requirement
every
single
day.
So
I
read
a.
We
got
a
lot
of
requirements
from
different
the
different
department.
At
that
time.
C
I
only
have
30
developers
and
everyone
worked
15
hours
a
day,
but
we
still
have
a
long
waiting
list
there.
So
that's
suffering
one
day
after
work,
a
developer,
one
developer
told
me
that
he
want
to
quit
and
he
is
a
very
good
developer
and
he
he
he
was
my
friends
and
I,
couldn't
persuade
him
to
to
today.
That
make
makes
me
very,
very
sad
and
that
night
I
told
myself
today
you
can
take
a
hotel
requirement.
Your
team
will
crash
and
you'd
only
need
to
work
on
the
valuable
requirements.
C
So
that
was
the
first
time
I
thought
about
the
poor,
not
value,
and
that
was
the
first
time
I
take
the
product
into
product
and
so
that
that
that
this
story
is
about
12
years
before
and
after
I
sold,
my
I
sold
my
company
for
five
years.
I
work
as
a
consultant
for
another
10
years,
so
we
regionally
do
it
in
10
years.
I
am
a
consultant
of
agile
and
DevOps.
C
So
I
have
some
some
some
clients
from
the
big
companies
and
some
from
the
sidorov's,
some
of
them
in
China,
and
some
of
them
in
in
Canada,
and
also
I,
noticed
that,
no
matter
how
big
is
a
company
and
no
matter
how
many
developer
they
have
no
clan
told
me
he
has
enough
developers
and
I
told
them
it.
It
is
not
about
the
resources
that,
because
people
have
too
many
ideas,
the
penis
people
have
too
many
ideas
every
second,
that
they
will
have
a
new
idea
and
they
want
older
ideas
develop
it.
C
So
that
is
a
major
region.
That
is
a
major
reason
that
developers
always
feel
he
is
all
said,
and
the
company
always
feel
they
have
not
enough
developers.
So
what
is
behind
this
picture?
I
want
to
share
some
some
of
my
my
salt,
so
when
we
think
about
what
is
a
product
after
so
so
many
day-and-night,
such
as
severing
the
product
to
me,
is
like
a
line:
the
July,
the
blue
line,
produced
values
and
the
materials,
people's
ideas,
so
ideas
in
and
the
potential
values
out
all
the
developers
and
the
team
are
the
line
workers.
C
That
is
the
concept.
I
I
got
those
10
10
years,
so
the
goal
for
the
company
is
to
keep
the
line
efficient.
There
are
three
golden
rules.
The
first
rule
is
identify
the
correct
ideas,
not
like
the
non
valuable
ideas
in
the
product
line,
because
we,
when
a
bad
idea,
goes
to
the
line,
everyone
will
work
on
the
bad
idea
without
any
value
produced.
That
is
a
first
rule
and
the
second
release
the
product
as
quick
as
possible.
C
That
is
only
passed
to
win
the
longer
the
product
in
the
line,
the
more
rate
when
the
product
needs
published,
because
we
know
the
marketing
changes
every
day
every
second,
we
can't
wait
for
half
a
year
for
a
feature
to
be
popped
to
be
released,
and
the
third
rule
is
about
collective
feedback.
Mitred
potential
values
then
generate
your
new
ideas
based
on
the
feedback,
so
only
with
this
blue
line
in
your
mind,
you
can
develop
a
sustainable
product.
C
C
B
You
Steve
and
when
I
bring
up
these
ideas
for
Capricorn
concerting
when
Steve
says
I'll
think
about
it.
That
means
he
is
assessing
the
product
line,
so
he
often
does
that
to
me
as
well,
so
we
are
applying
this
in
our
own
business
so
now,
coming
back
to
you
know
what
seed
has
described.
This
is
a
product
canvas
which
we
have
created
in
this
practice
in
this
product.
Canvas.
B
If
you
see,
on
the
right
hand,
side
they,
there
are
certain
tools
and
techniques
which
we
will
explain
some
of
these
key
tools
and
techniques
which
will
be.
We
will
try
to
explain
in
the
upcoming
slides.
So
when
we
are
evaluating
the
ideas,
we
have
created
tools
and
techniques
and
of
course,
some
of
these
tools
and
techniques
are
already
available,
which
we
have
integrated
from
you
know
outside.
So
we
create
a
the
product
vision
with
the
help
of
the
team
which
we
are
working
with.
We
also
help
create
the
value
radar
for
the
the
product.
B
We
also
do
some
product
box
design,
so
these
are
the
early
practices
which
we
you
know,
help
our
customers
evaluating
these
ideas.
When
it
comes
to,
you
know
how
fast
you
can
develop
these
ideas,
we
have
a
couple
of
practices,
and
this
is
like
both
in
design
and
development
phases.
So
from
a
design
perspective,
product
value
design
is
an
extremely
important
activity
which
you
need
to
perform
when
you
are
assessing
any
of
the
products
or
features
in
the
pipeline.
B
So
all
the
feature
design
the
concepts
which
we
have
from
a
technology
perspective,
our
CI
CD
pipeline,
the
architecture
of
our
feature
and
applications
which
we
are
producing.
It
becomes
extremely
important
because
we
need
to
loosely
couple
our
features
to
introduce
it
in
increments
right
and,
having
said
that,
we
also
have
produced
like
morph
charts,
which
will
help
you
speed
up
the
process
of
development
and
operations
and
introduce
some
of
the
tools
which
you
will
need
in
order
to
integrate
data
box
practices
into
your
product
line
and,
lastly,
feature
release
strategy.
B
It's
extremely
important
to
assess
what
your
release
strategy
for
these
products.
You
know
if
you
want
to
do
some
kind
of
feature,
toggles
or
some
kind
of
you
know,
use
a
segment
mapping
around
features.
All
this
is
very
context
to
then,
but
it's
important
as
well.
When
you
come
to
operations
it
it
becomes.
You
know
important
that
whatever
data
you
have
you,
your
data
has
to
tell
a
story
right,
so
you
have
to
bring
that
data-driven
approach
to
everything.
What
you
are
assessing
and
evaluating.
B
You
should
be
having
empirical
data
to
back
you
up
in
decision
making
process
and,
lastly,
a
value-based
pricing,
so
we
will
be
able
to
assess
and
gauge
where
the
value
of
the
product
is
belonging.
How
what
kind
of
features
are
more
valuable
to
the
user
and
that
will
set
the
stage
of
you
know,
moving
away
from
cost
base
to
a
value
based
structure,
and
this
all
together
creates
a
product
canvas.
B
Is
it
a
good
idea
and
when
we
are
assessing
that
product
value,
we
are
actually
measuring
five
dimensions
to
balance
this
value
through
the
scan
bus
and
this
five
values
are
put
on
the
right-hand
side
of
the
slide,
which
is
primarily
like
stability
and
security,
being
one
of
them
cost
speed,
scalability
and
learning
curve.
Now,
if
you
think
about
it,
if
you're
working
with
a
start-up
or
a
small
business,
what
is
more
important
for
those
businesses
is
the
pilot
process
right
stability
and
scalability
are
not
their
top
priorities,
and
but
cost
and
liquidity
are
right.
B
So
you
need
to
have
a
value
radar
which
can
balance
priority
of
a
business
from
there.
They
are,
you
know,
a
context,
driven
mapping
when
we
come
to
a
mature
business
or
mature
enterprise,
as
opposed
to
startups
we.
What
we
have
seen
is
that
stable
cap
capacity
and
balancing
the
learning
curve
is
there
high
high
priorities,
so
we
need
to
kind
of
ensure
that
whatever
product
value,
we
are
designing,
we
keep
in
consideration
the
context.
So
that's
some
of
the
key.
You
know
consideration
when
we
are
doing
our.
B
You
know
designing
the
product
value,
the
product
value
composition.
Now
it
doesn't
become
an
academic
exercise.
That's
why
I'm
also
mentioning
that
we
have
a
value
value,
design,
matrices
which
are
part
of
this
product
canvas
and
continious
product
oriented
practice.
So
what
these
value
design
matrices
would
do
for
the
product
team,
it
provides
them
with
a
value
measurement
toolbox
and
help
them
answer.
The
second
question
that
how
fast
you
can
deliver.
B
So
you
will
have
to
assess
that
as
well,
and
we
have.
These
matrices
will
provide
you
support
in
that
decision-making
process.
Lastly,
but
how
to
assess
slowly
decreasing
the
cost
of
each
value
point.
So
the
idea
is
that
we
have
to
be
more
efficient
and
build
a
system
where
our
return
of
investment
is
faster
and
quicker.
So
these
matrices
will
support
you,
this
decision-making
process.
B
We
have
workshops,
and
we
have
done
like
hands-on
session
with
like
enterprises,
where
we
have
helped
people
delivering
these
value.
Design
matrices
for
them.
Moving
on
I
would
also
try
and
like
to
introduce
the
investment
strategy
board,
which
we
have
created,
and
this
investment
strategy
board
is
comprising
of
you
know,
account
it's
a
complementary
technique
which
provides
tangible
way
to
steer
investments
towards
value.
Now.
Let
me
explain
this
to
you,
because
what
investment
means
here
is
that
when
you
are
developing
a
feature
or
a
product,
you
not
only
are
investment
investing
in
capex.
B
You
are
also
investing
in
OPEX,
so
you
need
to
consider
four
dimensions
whenever
you
are
building
a
product
or
a
future
features,
of
course,
because
features
are
something
which
bring
value
to
the
target
user,
then
you
will
have
risk
associated
with
those
features
right.
You
will
have
defects
which
are
bugs
primarily
or
features
that
do
not
false
acceptance,
testing
and
then.
Lastly,
you
will
have
depth
steps
on
temporary
workarounds
or
creating
a
quick
product
decision
where
you
know
you
are
trying
to
solve
all
the
potential
issue.
B
So
these
four
aspects-
and
we
have
named
it
as
Fred
now
in
this
context
only
feature
is
valuable
and
everything
else
does
not
add
value
but
cause
longer
lead
time.
So
what
it
means
is
that
we
are
investing
in
not
only
features
but
risk
defects
and
depths.
So
we
need
to
understand
that
one
feature:
how
many
risk
are
we
introducing
how
many
defects
we
have?
B
So
that's
extremely
important
from
a
product
perspective
now
moving
on,
there
are
product
value
of
feedback
loops,
and
this
is
basically
there
because
it
helps
you
answer
the
third
question
in
the
product
canvas.
Is
it
really
a
good
idea?
That
means
what
it
babyzane
is
in
cycle
data
towards
the
decision
making
process.
So
if
you
want
to
steer
an
organization
to
a
data-driven
organization,
I
think
it's
it's
a
very
valuable
technique
which
we
are
introducing.
It
talks
about
three
things
actually
creating
stories
around
data,
which
is
basically
translating
your
whatever
data.
B
You
are
gathering
from
a
customer
point
of
view
and
to
easily
understandable
insights
to
influence
action
and
business
decisions.
The
second
part
is
evaluating
and
building
a
value,
driven
pricing
strategy
for
features,
utilizing
customer
data
break
down
offering
later
value
of
different
features
and,
of
course,
your
investment
towards
one
feature,
so
that
plays
an
important
role
in
that
as
well
and,
lastly,
developing
your
continuous
product
canvas.
B
So
it's
important
that
you
have
continuous
flow
features
in
the
pipeline,
the
innovative
features
which
should
continuously
be
quantifiable
and
have
a
value
to
it,
approach
towards
you
know,
whatever
you
are
introducing
as
features.
So
these
are
the
three
things
and
when
you
build
a
connection
between
devops
and
product
continuous
product
oriented
practice,
I
would
suggest
that
we
we
discuss
it
from
two
perspectives.
One
is
the
cultural
basics.
B
When
we
talk
about
continuous
product
oriented
practice,
we
are
also
talking
about
and
advocating
upscaling
individuals,
teams
and
leaders
to
adopt
basic
techniques
for
maximizing
outcome
and
these
techniques
comprised
of
DevOps
practices.
These
techniques
comprise
agile
practices.
These
techniques,
you
know,
advocate
for
bringing
smaller
increments,
to
use
a
disability.
So
that's
that's
where
the
connection
is
from
a
cultural
standpoint.
Now,
when
you
talk
about
you
know,
DevOps
practices
in
C
pop
context,
we
we
will
also
try
to
introduce
you
to
morph
charts.
B
Basically,
what
we
have
done
is
we
have
created
mouth
charts
which
are
supporting
your
decisions,
decision-making
around
tools
and
capabilities
which
are
needed
to
be
brought
in
from
DevOps
perspective,
to
ensure
that
a
particular
feature
is
well
designed,
delivered
and
operated,
and
we
have
enough
insight
about
that
feature.
So
we
would
need
some
specific
tools,
some
specific
applications
and
these
tools
and
applications
can
be
integrated
as
out
of
box
integration,
or
we
can
also
have
capabilities
produced
in-house
right.
B
Not
much
has
been
done
in
order
to
close
the
gap
between
strategy
and
planning
and
what
we
are
trying
to
do
with
c-pop
is
taking
one
step
further
and
trying
to
integrate
strategy,
planning
and
design
decision
into
one
context
and
make
them
work
hand-in-hand
with
DevOps
teams.
So
that
is
what
you
know.
The
vision
for
co-op
is,
and,
of
course,
this
slide
also
depicts
that
what
kind
of
practices
and
tools
are
applicable
to
pitch
rolls
into
so
I
think
we're
coming
to
the
end
of
the
presentation.
B
But
I
would
like
to
also
emphasize
that
what
we
are
doing
here
with
c-pop
is
they
are
creating
like
a
certification,
or
course
we
are
actually
helping
organization
by
making
them
learn
by
doing
right.
So
we
have
created
use
cases
and
we
have
done
workshops
around
startups
within
healthcare.
You
know
sector
with
FinTech,
and
we
are
also
building
up
use
cases
for
sports
tech,
industry,
Agrotech,
AI
products
and
customized
cases.
The
beauty
of
c-pop
is
that
it
can
be,
it
can
be
implemented
or
integrated
with
any
kind
of
industry
segment.
B
B
Management
and
data-driven
structured
approach,
tools
and
techniques
to
support
the
process
and
the
team,
and
how
would
we
do
that
is
to
adopt
tools
and
techniques
for
everyone
in
the
team
where
everybody
in
the
team
needs
to
learn
by
doing
right?
And
what
can
be
our
the
next
steps
with
us
is
you
can
get
in
touch
with
us
for
workshop?
We
have
continuous
oriented
product,
oriented
basic
workshops
which
you,
which
will
get
you
introduced
to
all
these
techniques
and
concepts.
And
of
course
we
do
simulation
cases.
B
You,
the
tools
and
techniques
we
are
advocating
for
to
make
how
you
can
actually
make
them.
In
your
context.
We
also
offer
virtual
CIO
and
virtual
product
owner
capabilities
because
we
do
understand.
This
is
a
large
learning
curve
for
some
of
the
organizations
and
they
might
need
support
in
the
journey
of
the
learning
process.
Sepa
platform
is
readily
integrated
with
the
concepts
and
techniques,
and
we
are
actually
heavily
invested
in
building
this
platform,
as
we
speak.
So
having
said
that,
some
words
from
our
customers,
it's
always
good
to
get
acknowledgement
from
our
customers
and
I.
B
B
B
We
have
a
DevOps
community
of
practice,
meetup
group,
where
you
can
join
in
and
get
more
insights
into
what
continuous
product
oriented
practices
and
how
is
it
connected
with
DevOps?
We
also
have
DevOps
continuous
product
oriented
practice
workshop,
which
is
coming
up
27th
of
June.
We
are
taking
a
financial
application
as
one
of
the
simulation
cases
and
we'll
run
end
to
end
to
you
know,
build
value,
driven
products
and
lastly,
I
would
say
that
I
invite
you
all
to
the
DevOps
summit
2020
or
whatever
order.