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
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.
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.
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
“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.”
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”
“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?
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
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
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
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
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)
What is a Traditional
Roadmap?
Bucket of product features
over time
Hopes, dreams, wishes
Infrequently updated
Pretty
Top SekreT
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
Roadmap
Examples
Hardware Roadmap
Big Enterprise Software Example
Enterprise Software Product Roadmap
Enterprise SaaS Roadmap
“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
“Like” - Customer Personas
Financial Services Firms’
Compliance Officers, Financial Advisors,
Information Security Team, Corporate
Marketers, Brand Marketing and Legal
“Like” Customer Personas
Swim lanes are specifically targeted at
customer user personas that are
appropriate for the product or service
“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
“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
General Roadmap Benefits
Long-Term Planning
User Value-Based
Visible
Explicit
Holistic / High-Level
Trade-Offs
Risk
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?
Radical RoadmapS
AND
Product (Traditional)
Platform
DevOps
Short-Term (Optional)
Others (potentially)
Socialware Radical Roadmaps
Product
DevOps
Platform
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”
Product
Platform
DevOps
Goal Alignment - Product
Goal Alignment - DevOps
Goal Alignment-Platform
Agile Planning Flame
Radical Roadmapping
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
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
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
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
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
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
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
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
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
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
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
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
Product Roadmap Tools
Powerpoint and Excel/Sheets :)
Stickies and a wall
Aha!
Portfolio for Jira
Trello
So many more…
- Dwight D. Eisenhower
“Plans are useless, but planning is indispensable”
- Kert Peterson
“Agile is the Art of the Possible”
- Kert Peterson
“Agile is the Art of the Possible”
Related Work
Continuous Agile Planning That the Biz and Dev
Folk can "Like Like” by Matt Roberts
bit.ly/252w4nk
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

Radical Roadmapping - Creating Synchronized Agile Product and Technology Roadmaps PCA17

  • 1.
    Radical Roadmapping: Creating SynchronizedAgile 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 willdiscuss 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 isan 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 thehighest 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 developersmust 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 tomake 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 AreYou 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 processof 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 - BizPerspective 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 - DevPerspective 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 GitToday? 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 presentationisn’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 aTraditional Roadmap? Bucket of product features over time Hopes, dreams, wishes Infrequently updated Pretty Top SekreT
  • 15.
    When is aroadmap 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.
  • 17.
  • 18.
  • 19.
  • 20.
  • 21.
    “Like” - VariableTime 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” - CustomerPersonas Financial Services Firms’ Compliance Officers, Financial Advisors, Information Security Team, Corporate Marketers, Brand Marketing and Legal
  • 23.
    “Like” Customer Personas Swimlanes 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-TermPlanning User Value-Based Visible Explicit Holistic / High-Level Trade-Offs Risk
  • 27.
    What if wecould 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.
  • 29.
  • 30.
  • 31.
  • 32.
  • 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.
  • 35.
  • 36.
  • 37.
  • 38.
  • 39.
    Implementation Product Roadmap usuallyexists - 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 thatbusiness 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 Updatecontinuously 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 CapacityAllocation 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 Mytool 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 tochange 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 & OpsPerspective 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 Roadvmappingis 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 visibilityand 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 Powerpointand 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 “Agileis the Art of the Possible” - Kert Peterson “Agile is the Art of the Possible”
  • 54.
    Related Work Continuous AgilePlanning That the Biz and Dev Folk can "Like Like” by Matt Roberts bit.ly/252w4nk
  • 56.
    Matt Roberts VP ProductEngineering @Continuum Analytics matt@matt-roberts.com | @MulticastMatt linkedin.com/in/cpgmattr multicastmatt.blogspot.com Feedback is appreciated! Rad! >> bit.ly/pcatx17