4. Agile Roadmap is:
• An Agile Roadmap is a living document designed to answer
key strategic questions:
• Who are my desirable markets/market segments?
What do they care about?
• When, how, and how often should I serve them?
• What technologies can I leverage?
How must my current product change to deal with the answers to
these questions?
• What are the internal or external factors that I must address to deal
with these issues?
5. Typical Roadmap Failures
•No visible logic
•Created unilaterally
• Lack of buy-in
• Poor technical and market
inputs
•No plan for internal or
external sharing
6. What do effective roadmaps contain?
• Generally roadmaps should contain answers to:
• Who, What, When, How, How often, and Why (at least)
• Market Map (Who)
• Who do we serve? Who do we want to serve?
• Market Events/Rhythms Map (When/How Often)
• What happens to THEM? Now and then? Regularly?
• What happens to us?
• Feature/Benefit Map (What)
• What do THEY care about? ($$)
• Technical Architecture (How)
• How do we deliver the features to THEM?
7. More on the Roadmap Content layers
• Market Map
• How do you segment your market?
• Create a visual representation of the market(s) you’re targeting.
• Market Events/Market Rhythms
• What is the right frame of reference for time in your problem domain?
• Identify the events and rhythms of your market/market segments.
• Feature/Benefit Map
• How do you ensure that the right features and benefits are being created for
your target market(s)?
• Create a map of the proposed features and their benefits. Tie these to the
market(s) you’re targeting.
• Tarchitecture Roadmap
• How do you manage the evolution of your technical architecture?
• Create a roadmap of known technology trends. Include specific and well-known
changes you want to make to your architecture so that everyone can plan for
them.
8. Agile Roadmapping
- A working definition
Collaboratively creating, managing, and
communicating strategic product intent.
9. Successful Roadmaps Creation…
• Active participation of key constituents
• Engineering (architects), Marketing, Support, next-level product
strategists, Fulfillment, etc.
• Extended in-person meetings
• Time to research issues
• Quarterly reviews
• Clear (written) distribution plan
• Easy to say, hard to do
10. Low-Tech Speeds Collaboration
Fast and messy,
But ultimately…
Very effective
Formal results
can be transcribed
in various tools
(Excel/Visio/PPT)
11. Use a Simple Template - Build iteratively
Q1 Q2 Q3 Q4 Q1
Customer Groups
(Mkt Segments)
Features and
Benefits
Architecture and
Systems
Events and
Rhythms
Scheduling
12. Clarify the “Who” in your market
• Personas, Goals, and Problems
• Often it is helpful to clarify who the product is being built for
• Buyer Personas (who buys our product not necessarily uses)
• User Personas (who we build products for)
• Technocal Personas (implements and/or manages the product
or the IT architecture it will be installed into)
• (insert slides on Personas etc.)
13. Major Features & Benefits
• Features
• Our delivery of features drive (hopefully) the customer benefit
• List ONLY the major features (those that “move the needle”)
• These features would likely have many User Stories
• Remember that a feature may have multiple benefits or serve multiple
segments
• Benefits
• Describe in business terms what benefits each feature will deliver to
the customer.
• General is OK. Specific is MUCH better!
• Reduce Costs (How? How much?)
• Avoid Costs (How?)
• Increase Revenue by…
• Avoid human error by…
• Reduce manpower by…
14. Events and Rhythms
• Things that occur one-time are events
• IPO of competitor (or of your company)
• New IRS / Govt. mandate or regulation in effect
• Company launches new website
• Opening of new store or site
• Hurricane/Flood (part of Disaster Recovery Planning)
• Things that occur regularly are rhythms
• Industry conferences
• Holidays
• Regulatory issues
• Gartner Quadrant or other Analyst activity
• US Presidential Election
• Things that are knowable but out of your direct control.
• But you might have indirect influence
15. A word on Rhythms
• Rhythms effect everything we do;
• Life rhythms
• Firsts – single events
• Life Rhythms – recurring events
• Business events follow the same patterns
17. How are you going to deliver?
• Mapping in the Technical Architecture and Capabilities
(Tarchitecture) required
18. Technical Architecture (Tarchitecture)
• Typically just the large pieces
• Required Technologies
• Known updates to embedded technologies
• New technologies to improve stability, performance,
flexibility, etc.
• You may want to break out development phases such
as exploration, POC, development, beta as they span
over quarters.
19. Tarchitecture Roadmap Activity
• Forces
• No matter how well an application has been architected, changes in technology
can invalidate prior assumptions. Technologies usually appear on the horizon
with enough time to accommodate them if they’re planned for.
• Developers like to understand where they are headed.
• Developers like to learn new things.
• Developers want a way to manage the tarchitectural evolution of poorly
implemented features. The want a way to make both the poor feature known to
others and register their desire to change it.
• Technology can enable new features that marketing may want.
• Marketing may demand features that can be supported only by adopting a new
technology.
• Competitors’ adoption of a new technology may put you in a disadvantageous,
reactive state. Technical people will argue over emerging technologies.
Sometimes the arguments are a way of learning more about the issues. Most of
the time the only way to reach consensus is to give them plenty of time to
discuss the issues.
24. Variations
• Do you need other swimlanes?
• Services?
• Operations?
• Legal?
• Manufacturing?
• Integration (Scrum of Scrums)?
• Partners?
• ???
• You will need whatever gives your team(s) better
visibility and clarity for the timeframe
• Keep it simple and at the right level