Driving Platform-as-Product Using Lean Hypothesis by Karina Villaneuva at SpringOne Tour 2019

1. © Copyright 2019 Pivotal Software, Inc. All rights Reserved. Version 1.0
Karina Villanueva, Product Labs Lead
February 2019
Driving Platform-as-Product using
Lean Hypotheses

2. Goals for this talk
Broad and shallow:
To discuss why it is important to treat your Platform-as-Product.
Specific and in depth:
To learn how might you leverage Lean Product Management with
your new Platform-as-Product approach

3. Design the product (your platform)
around the needs of our customers,
rather than seeking to change the
user's behaviors around how a
product (Pivotal Cloud Foundry)
works.
Platform as a
Product

4. They want to...
Deliver value fast, forever
business outcomes
and user benefits
through working
features
quickly and often an ongoing basis without
burning out the team
App development team: Goals

5. Platform Product Team Objective
To allow an app development team to have an idea in the morning
which is running in production by the afternoon

6. App product team: Pains
“We handed off the
requirements to IT,
but then 6 months later
we got a product that
didn’t meet our
expectations.”
“It takes forever to
release new features.
We see opportunities to
sell to new customers,
but we can’t respond
to change fast enough.”

7. Product
Management
Will this help the
business?
Balanced Platform Teams
Desirable
“What pains exist today for the
user? How might we solve those
pains? Are they able to use the
system effectively? Will they adopt
this product? Is their path to
production optimal?
Viable
“By solving these specific user
problems with these specific
solutions, are we creating valuable
business outcomes? How might we
measure those outcomes?
Feasible
“What are the technical
complexities necessary to satisfy
the project and product goals best?
How can we build a system that
will respond well to change?
Design
Will users like this? Can
they get to production?
Platform
Reliability
Engineering
Can we build this
and run it reliably?
Product

8. Lean Product Management Practices
Lean is a product methodology
designed to decrease risk and reduce
waste through constant validated
learning.
Product
Management

9. LEAN, a product methodology
designed to decrease risk and
reduce waste through constant
validated learnings.
Lean Product
Management

10. LEAN, a product methodology
designed to decrease risk and
reduce waste through constant
validated learnings.
Lean Product
Management

11. Story telling time

12. The product portfolio needs to standardize and support application
interoperability. Given business needs, rest points are not enough, data
was too dynamic.
Eliminate as much waste as possible without building software

13. Identify what we don’t know
Assumptions

14. Select your riskiest risk
2x2 - Likely to kill the product VS
how much is know about the risk.
Prioritize
assumptions

15. Lean Hypotheses
We believe that ...
We will do ...
We will know we are right when ...
Cost: ...

16. Do messaging queues solve the portfolio objectives?
We believe that the product teams could successfully share data using a messaging
queues (as opposed to more robust solutions like event sourcing) while achieving portfolio
objectives.
We believe that the client developers will have enough experience with messaging
queues.
We will conduct exploratory user interviews with the developers, product managers and
stakeholders to understand business needs and developer skills.
We will know we are right if we find that messaging queue solve the portfolio
objectives as good as even sourcing does and more than 50% of developers have
experience with them.
Cost: total of 15 hours of interviews and 5 hours of synthesis.

17. Do messaging queues solve the portfolio objectives?
We believe that the product teams could successfully share data using a messaging
queues (as opposed to more robust solutions like event sourcing) while achieving portfolio
objectives.
We believe that the client developers will have enough experience with messaging
queues.
We will conduct exploratory user interviews with the developers, product managers and
stakeholders to understand business needs and developer skills.
We will know we are right if we find that messaging queue solve the portfolio
objectives as good as even sourcing does and more than 50% of developers have
experience with them.
Cost: total of 15 hours of interviews and 5 hours of synthesis.

18. Considered Solutions
© 2017 PIVOTAL SOFTWARE, INC. All Rights Reserved. Confidential—Do Not Distribute
Solution Standardization Application Interoperability Does it meet the portfolio
objectives?
Other reasons
Rest Endpoints No guarantee, each
team rolls their own
No guarantee due to each
point to point being controlled
by different teams
Concerns about validity of data
given changes in the battle
space and dissemination
timeliness
Not recommended due to
synchronous nature of rest
endpoints
Messaging No guarantee, needs a
common abstraction
over the transport.
No guarantee due to each
point to point being controlled
by different teams
Concerns about providing
complete operations data
Messaging is normally a
recommended solution,
however, given the ops branch
objectives messaging alone is
insufficient
Integration
Database
Yes, enforced by a
database
Sidesteps the issue by creating
a common link via a database
Concerns about data
production and dissemination
timeliness
Not a good solution due to a
single point of contention due
to the distributed work that is
being done
Event Sourcing Yes, the event source
should have common
methods to access
Single interface that
applications are communicating
through
Yes No standard way of
implementing
Immutability is hard

19. Developer Persona
Goals:
Get code to compile: focus
entirely in writing code that
delivers user value.
Doing the bare minimum to get
the app into the cloud.
Manage app in development
and get this app ready for
production
Robust testing: diagnose odd
behavior and short term
monitoring

20. Cool, Event Sourcing it is. How do we know we will abstract technology
enough to make integrations easier?
If you must build, build as lean as possible and test

21. You need to implement an event sourcing
We believe that the portfolio applications need an event sourcing way to communicate
in order to standardize communications between applications and abstract complexity away
from the product teams.
We will create a not production ready lean MVP, the app receives events via an API,
stores it in mysql and puts it on rabbitmq for consumption. We are not going to worry about
contract testing, failure queues, health monitoring….
We well know the platform solved the client problem if we can successfully integrate
with two application in our sandbox environment and walk through a happy path scenario.
The integrations must take less than a couple of days.
Cost: 1 .5 months, 1 developer pair and 1 product manager

24. Integration Tests? System Reliability? Health Monitoring? Expanding
offering?
What is next for this team?

25. What are your assumptions?
How can you create validated
learnings?
What is next for you?

26. Any Questions?
THANK YOU!

27. Transforming How The World Builds Software
© Copyright 2017 Pivotal Software, Inc. All rights Reserved.