After 10 years of using roadmaps, I decided to ditch the standard way and build a valuemap. The result? Everybody loves it and we can happily deliver value to customers instead of organizing boxes. You can also read the blog posts or watch our recorded webinar https://payhawk.com/blogs/dont-build-a-roadmap-for-a-saas-product-build-a-valuemap-instead/

2. 17 April 2020 payhawk.com 2

3. 17 April 2020 payhawk.com 3

4. 17 April 2020 payhawk.com 4

5. 17 April 2020 payhawk.com 5

6. 6
• Can be too technical for
customers and wider to
understand
• No guarantee that delivery of
a feature will meet customer
expectations
• No guarantee that delivery of
the roadmap will achieve the
business objectives
• It’s often not bound to
something measurable
results.
payhawk.com

7. 7
• You see the results, but you
don’t really understand why
and how you it was built.
• The customer conversations,
team discussions, strategy
considerations and all other
inputs for a roadmap remain
hidden.
• This often leads to a lot of
friction between PMs and
engineers.
payhawk.com

8. 8
• Once you build the roadmap,
dealing with change is hard.
It means a lot of
communication both
internally and externally.
• Constant choice between
loosely define items with
room for innovation, or
tightly define items and
focus on efficiency.
• The reality is that innovation
happens when you are
building a product, not a
roadmap.
payhawk.com

9. 17 April 2020 payhawk.com 9

10. 17 April 2020 payhawk.com 10

11. 17 April 2020 payhawk.com 11

12. 17 April 2020 payhawk.com 12

13. 13
1. Excited about your technology
than the practical implications
of it.
2. Customers buying despite lack
of many success stories and
proven ROI
3. Customers are actively buying
and referring your product with
many big logo customers.
4. Growth is slowing and you are
mostly driven by renewals
5. Customers refuse to buy
anything else until you are not
out of businesspayhawk.com
1 2 3 4 5

14. 14
• You don’t really need a
roadmap. You simply have a
prioritized list.
• Work is organized around
hypothesis, iterations and
quick learning from your
initial customers. It would be
good to decide on Speed vs.
Quality for each feature
from your list.
payhawk.com
1 2 3 4 5

15. • Always make the tradeoff on
speed vs. quality. Here is a
quick framework we used
early on to decide how much
to invest in every feature.
• How certain are we for the
definition of a specific
feature?
• How critical is this feature
for our MVP?
Critical
Confident
Yes No
Yes 4 or 5 3
No 2 1

16. 16
• Build a value map instead of
a roadmap.
• You use Objectives and Key
Results to group your
features
• It’s great to keep you
focused and aligned with
your strategy.
• It’s great for early product
validation and is more agile
than roadmaps.
• At Payhawk we uncovered
two types of customer
segments and created
editions for each.payhawk.com
1 2 3 4 5

17. 17
• Organized around OKRs
rather than Group features
• Clear objective
• Measurable key results
• Timebound
Benefits
• Easy to explain to customer
• Easy to explain internally
• Easy to measure
• Keeps you focused

18. 18
• Build a roadmap and OKRs
at the same time.
• No need to align all roadmap
items to the OKRs
• Use OKRs only for the
features that you widely
want to communicate
• Plenty of small and
fragmented features that
will be needed to perform
“business as usual” and
keep renewals steady
payhawk.com
1 2 3 4 5

19. 19
• Blend of features and
initiatives tied to OKRs, and
loosely defined features
Benefits
• Focus and easy
prioritization, because
everybody knows what’s
important
• Alignment with the rest of
the organization
• Tracking and clear key
results for each initiative
payhawk.com
+

20. 17 April 2020 payhawk.com 20

21. 21
payhawk.com/blog
17 April 2020