2. Scope
of
the
document
• High-‐level
view
fundamental
processes
require
in
order
to
build
a
Roadmap
• This
model
has
been
primarily
used
in
PlaOorm
SoPware
Go-‐To-‐Market
experiences
• As
usual,
simplicity
is
the
drive
Disclaimer
and
assumpTons
• This
document
is
based
on
my
experience
of
plaOorms.
As
a
result,
the
model
presented
may
have
holes,
gaps
or
wrong
prioriTes
• Products
and
Markets
Strategy
is
assumed
to
have
been
determined
• Some
level
of
compeTTve
posiToning
has
been
developed
• The
Roadmap
format
is
designed
to
accommodate
“SEC
regulaTons”
constraints
in
terms
of
revenue
recogniTon
(Heisenberg
principle
applied
to
Feature/Time
variables)
Dimitri
Volkmann
dimiexter@mac.com
+1
925
271
2081
3. Roadmap
Format
Priori%zed
Feature/Capability
List
Fixed
Schedule
Con%nuous
Delivery
(frequency:
f)
Vx.y,
ddmmyy
Vx.y,
ddmmyy
Vx.y,
ddmmyy
OR
Releases
Feature
Priority
ClassificaTon
DescripTon
…
4. Roadmap
Format:
ClassificaTon
Example
Code
Descrip%on
Alloca%on
(%)
Core
New,
next
generaTon
of
capabiliTes
that
creates
differenTaTon,
and
supports
Products
and
Markets
Strategy/Vision
Highest
Customer
Specific
capabiliTes
that
supports
Customer
Requests
or
SaTsfacTon,
assuming
they
fit
into
Products
and
Markets
Strategy/Vision
Medium/High
(depending
on
maturity)
Ecosystem
CapabiliTes
that
enables
3rd
ParTes
to
augment
the
Product
and
support
a
growing
eco-‐system
High/Medium
(depending
on
maturity)
EBF
Emergency
Bugs
Fix
High
Context
Everything
else
Lowest
5. Roadmap
Building:
Sources
&
Filtering
ROADMAP
Version:
v
Industry
Trends
Vision
Customers
• Analysts
• Influencers
&
Visionnaries
• Experts
Filter
• Use
AllocaTon
%
to
do
trade
off
(example:
core,
customer,
ecosystem,
EBF,
context)
• Consider
in-‐house/partnering/acquisiTon
strategies
• Customer
Council
(PM
process)
• Tech
Support
• Field
Sales
feedback
• Pro
Serv
feedback
• What?
• Why?
• How?
• How?
• Engineering
&
R&D
innovaTon
