This session will discuss why a company would create and maintain three major artifacts - Innovation Roadmap, Infrastructure/ Platform Roadmap, and Operations/DevOps Roadmap - as well as the process to do so. Further, it will cover how to synchronize them in order to move away from making "OR" decisions to making "AND" decisions that will please all stakeholders. It will also discuss key cultural changes that must be present in order to achieve maximum benefit from this approach and challenges experienced along the way to making this a reality at Socialware, a SaaS product company. Finally, this session will include real world examples of the evolution of these roadmaps over 18 months that participants can take away and use as guidelines for their own situations. This was presented at the Keep Austin Agile 2016 conference, the #AgileAustin Product SIG and Product Camp Austin 2016 (#PCATX17)

1. Radical Roadmapping: Creating
Synchronized Agile Product and Technology
Roadmaps
Product Camp Austin 17
6 August 2016
Matt Roberts , VP Product Engineering
@ContinuumAnalytics
matt@matt-roberts.com | @MulticastMatt
linkedin.com/in/cpgmattr
multicastmatt.blogspot.com

3. Abstract:
This session will discuss why a company would create and maintain
three major artifacts - Innovation Roadmap, Infrastructure/
Platform Roadmap, and Operations/DevOps Roadmap - as well as the
process to do so. Further, it will cover how to synchronize them in
order to move away from making "OR" decisions to making "AND"
decisions that will please all stakeholders. It will also discuss key
cultural changes that must be present in order to achieve maximum
benefit from this approach and challenges experienced along the way
to making this a reality at Socialware, a SaaS product company.
Finally, this session will include real world examples of the evolution
of these roadmaps over 18 months that participants can take away
and use as guidelines for their own situations.
This concept is RADICAL as it is innovative in both its novel approach
and ability to drive enormously positive organizational agility.

4. Bio:
Matt Roberts is an Agile pragmatist continuing his lifelong learning
journey, currently serving customers and innovators throughout the
complete value chain as VP of Product Engineering for Continuum
Analytics. His experience is wide-ranging as he has developed
software and led efforts to create systems for product development
teams to deliver innovative solutions in companies ranging from
early-stage start-up to publicly-traded companies in both consulting
and full-time roles. He has had the privilege of serving the Austin
software development community as Agile Austin President for four
consecutive years and as Secretary for the IEEE Computer Society
for two years.
Among others, Matt holds certifications as a Certified Scrum
Practitioner (CSP), Certified Scrum Master (CSM), Certified Scrum
Product Owner (CSPO), Innovation Games, and Pragmatic Marketing.

5. My Goal
Deliver the highest quality
value to the customer while
maintaining worker
safety. This is
accomplished by
harnessing ongoing
change through
continuous:
Learning
Planning
Alignment
Risk Reduction /
Options

6. “Business people and
developers must work
together daily throughout the
project.”
“Continuous attention to
technical excellence
and good design enhances
agility.”
“Responding to change over
following a plan”
“Simplicity--the art of
maximizing the amount
of work not done--is
essential.”

7. Naming Disambiguation
Trying to make this applicable to various teams in
product development (deployed and SaaS) and IT, and
reduce the use of “strokes,” here’s what will be the
standard for this presentation
Product = “Business” “The Business” “Innovation”
Platform = “Technology” “Infrastructure” “Debt”
DevOps = “CI” “CD” “CM” “Security” “Ops” “IT”

8. “What Problem Are You Trying to Solve?
Ability to communicate to stakeholders the near-term and long-term
goals of the entire product organization as things CHANGE
Continuous alignment of customers, business, and development /
technology teams from a medium to longer-term planning perspective
Building trust across Product, Platform, and DevOps and maybe, just
maybe into customers
Ability to make tradeoffs and understand the full impact across all
fronts
A great deal of work is not represented in traditional roadmaps
How much do we invest in infrastructure and why should we?

9. Matt’s Assertion
The process of creating and continuously
updating product roadmaps can be applied
to underlying and related technology and
operational changes that require
investment for fun and profit

10. Roadmaps - Biz Perspective
This is the future and we’re
excited!
These are all our !TOP SEKRET!
master plans - don’t show it to
anyone!
We don’t have time for
infrastructure work - we’re
already late
We don’t want to be held
hostage by our customers to old
roadmaps
Note - I watched ST TOS in the 80s - TNG metaphor didn’t apply

11. Roadmaps - Dev Perspective
Who’s going to do all this work?
Thanks for a free lunch, now
please let me get back to what’s
important
No one talked to me…
How are we going to get all of this
done without infrastructure
improvements?
What about DevOps?
When was the last time this thing
was updated?
Note - I watched ST TOS in the 80s - TNG metaphor didn’t apply

12. Whatcha Gonna Git Today?
A general model of a product roadmap
A model set of synchronized roadmaps that span Product,
Platform, and DevOps, with an specific focus on Platform and
DevOps
An example of a process to ensure that the roadmaps are
continuously updated and made visible across organizational
boundaries
“Fun” stories about what’s worked and didn’t work
A few laughs (hopefully), some snarkiness
A chance to provide feedback

13. What this presentation isn’t
about
Product management tools and tooling
Product capability prioritization techniques
Product marketing and
positioning techniques
Estimating (bonus at the end)
Product strategy
Kittens (but here’s a cat)

14. What is a Traditional
Roadmap?
Bucket of product features
over time
Hopes, dreams, wishes
Infrequently updated
Pretty
Top SekreT

15. When is a roadmap generally
used?
Funding (Start-up, New Line of Business, etc.)
Annual planning
Quarterly meetings
Critical customer presentations
Product Portfolio Strategy
Build vs. buy
Acquisition

16. Roadmap
Examples

17. Hardware Roadmap

18. Big Enterprise Software Example

19. Enterprise Software Product Roadmap

20. Enterprise SaaS Roadmap

21. “Like” - Variable Time Horizons
Closer is Wider and Longer Term Narrower
- Allows for more detail in the short-term
- More strategic / high-level in the long-term

22. “Like” - Customer Personas
Financial Services Firms’
Compliance Officers, Financial Advisors,
Information Security Team, Corporate
Marketers, Brand Marketing and Legal

23. “Like” Customer Personas
Swim lanes are specifically targeted at
customer user personas that are
appropriate for the product or service

24. “Like” Fuzzy & Friendly
Roadmap items are primary written in terms that the
customer persona / users will understand easily
Themes on the top, detail expanded with epics
Just the right amount of detail allows flexibility /
interpretation as we learn

25. “Like” Fuzzy & Friendly
Boundaries of boxes are “fuzzy” allowing change
Epics are prioritized so stakeholders can understand
what comes first
Continuous Themes are OK with prioritized epics

26. General Roadmap Benefits
Long-Term Planning
User Value-Based
Visible
Explicit
Holistic / High-Level
Trade-Offs
Risk

27. What if we could apply the same roadmap
techniques to Platform and DevOps?
What if we could apply the same techniques to
Platform and DevOps long-term planning?

28. Radical RoadmapS
AND
Product (Traditional)
Platform
DevOps
Short-Term (Optional)
Others (potentially)

29. Socialware Radical Roadmaps

30. Product

31. DevOps

32. Platform

33. Example - Q1 ‘15 Ranked Goals
1. Ship Social Content Recommendation
2. Support Facebook API changes
3. Fix broken search technology
4. Scalable archive
5. “The Rest”

34. Product
Platform
DevOps

35. Goal Alignment - Product

36. Goal Alignment - DevOps

37. Goal Alignment-Platform

38. Agile Planning Flame
Radical Roadmapping

39. Implementation
Product Roadmap usually exists - if not, start there
Platform Roadmap is challenging, but it usually is easy to set
once there is a good Product Roadmap - It should be very much
in sync!
DevOps Roadmap is the most challenging, although with SaaS it
can be much easier with a Product and Platform Roadmap.
Again - keep it in sync
Short-term roadmap can help connect short- and long-term
efforts
The first set of roadmaps will have wide variances in accuracy.
With more time, practice, visibility, and adaptation they will be
extremely useful
Continuously update

40. Synchronization
Synchronization means that business drivers are
connecting all of the technical decisions
Business drivers include things like customer
value, risk, ROI, company strategy, option
theory/MVP
These are absolutely the most important
conversations to have as they allow value to
pull all work through the system
Eliminating waste is a key aspect of this effort

41. Inspect and Adapt
Update continuously
Scrum: At the end of every sprint
Kanban: Periodically—once a month max
Items multiple quarters out generally don’t change
much as they are more strategic and high-level in
nature (hint: write them that way)
Keep pushing at making them more visible

42. Radical Roadmap Rules
Users, users, users, users (personas better), especially for non-
product items - who cares and why?
Not all roadmap items will link together, but the organizations’
goals must
Planning horizon is important
Think product features AND platform AND DevOps
Think capacity
Continuously update, be explicit, and be real
Share as much as possible

43. Other Roadmaps
Short-Term
Partner-Delivered Functionality
Capacity Allocation
Fun story there about 12-month team member
allocation for customer insight (ducking for
cover in a room full of agilists)
ANYTHING to help get visibility into value, risk, and
tradeoffs over the medium- to long-term

44. Haters Gonna H8
My tool doesn’t support this / don’t have time to work
with the API
That’s a TON of work to do manually
Three roadmaps—that’s way too much
Actually, I had 7 at one point
We can’t share our confidential plans with the team
Technical roadmaps are not valuable - we need to ship
features and focus all our efforts there

45. NOT responding to change
Planning in silos
Updating less than once a quarter
Ignoring cross-cutting concerns
Highly secretive environment
Violation of Agile Principles and Values
Radical Roadmapping
#Fail

46. Dev & Ops Perspective
Radical Roadvmapping is considered RAD by Developers
because:
There is more visibility across the organization of
the real current state.
The underlying technology work is made visible, is
prioritized, and stands with features
Their work is a first-class citizen
They can start to think long-term and extend their
stewardship

47. Business Perspective
Radical Roadvmapping is considered RAD by the
Business because:
Long-term planning is a relatively easy exercise
and the team isn’t afraid of engaging in what-if
scenarios.
The full costs/risks can be discussed
Developers start communicating in ways they
understand

48. Breaking “Rad”
Real visibility and quick
tradeoffs possible across an
entire product development and
operational environment
Continuous learning
organization where the business,
the developers, and customers
can work honestly and together
on long-term planning as things
change
Culture embraces Agile principles
and values

49. Fact Check - Matt’s Assertion
The process of creating and continuously
updating product roadmaps can be applied
to underlying and related technology and
operational changes that require
investment for fun and profit

50. Powerful Prioritization
Techniques
Kano Model - Categorization of product
capabilities by customer satisfaction over time
Buy-A-Feature - Innovation game that allows
groups to form consensus over value
Can be applied to Platform and DevOps efforts
too!
All of the Innovation Games!
Product Canvas - Achieve Fast Alignment

51. Product Roadmap Tools
Powerpoint and Excel/Sheets :)
Stickies and a wall
Aha!
Portfolio for Jira
Trello
So many more…

52. - Dwight D. Eisenhower
“Plans are useless, but planning is indispensable”

53. - Kert Peterson
“Agile is the Art of the Possible”
- Kert Peterson
“Agile is the Art of the Possible”

54. Related Work
Continuous Agile Planning That the Biz and Dev
Folk can "Like Like” by Matt Roberts
bit.ly/252w4nk

56. Matt Roberts
VP Product Engineering @Continuum Analytics
matt@matt-roberts.com | @MulticastMatt
linkedin.com/in/cpgmattr
multicastmatt.blogspot.com
Feedback is appreciated!
Rad! >> bit.ly/pcatx17