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 GoalDeliver 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 DisambiguationTrying 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 AssertionThe 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 PerspectiveThis 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 PerspectiveWho’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 PersonasFinancial 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

ANDProduct (Traditional)

Platform

DevOps

Short-Term (Optional)

Others (potentially)

Socialware Radical Roadmaps

Product

DevOps

Platform

Example - Q1 ‘15 Ranked Goals1. 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

ImplementationProduct 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

SynchronizationSynchronization 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 AdaptUpdate 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 RulesUsers, 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 RoadmapsShort-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 H8My 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 PerspectiveRadical 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 PerspectiveRadical 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 AssertionThe 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 ToolsPowerpoint 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 WorkContinuous 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