Are roadmaps ever useful? - Marty Cagan

Season 1 - Episode 26 - Marty Cagan
Before founding the Silicon Valley Product Group to pursue his interests in helping others create successful products through his writing, speaking, advising and coaching, Marty Cagan served as an executive responsible for defining and building products for some of the most successful companies in the world, including Hewlett-Packard, Netscape Communications, and eBay.
Marty began his career with a decade as a software developer at Hewlett-Packard Laboratories conducting research on software technology, and building several software products for other software developers.
After HP, Marty joined a then young Netscape Communications Corporation, where he had the opportunity to participate in the birth of the Internet industry. Marty worked directly for co-founder Marc Andreessen, where he was vice-president for Netscape’s platform and tools, and later e-commerce applications, and worked to help Internet start-ups and Fortune 500 companies alike to understand and utilize the newly emerging technology.
Marty was most recently senior vice-president of product and design for eBay, where he was responsible for defining products and services for the company’s global e-commerce trading site.
During his career, Marty has personally performed and managed most of the roles of a modern software product organization, including product management, software development, product marketing, user experience design, software testing, engineering management, and general management.
As part of his work with SVPG, Marty is an invited speaker at major conferences and top companies across the globe.
He is also the author of the books INSPIRED: How to Create Products Customers Love and EMPOWERED: Ordinary People, Extraordinary Products.
Marty is a graduate of the University of California at Santa Cruz with B.A. degrees in Computer Science and Applied Economics (1981), and of the Stanford University Executive Institute (1994).
"Used properly roadmaps are a helpful tool, the problem is almost no-one uses them that way" - Marty Cagan
Timestamps:
00:00 Introduction
01:11 What is the purpose of a roadmap?
08:06 What is the relationship between the roadmap and other artifacts?
12:13 What about roadmapping your discovery efforts?
14:22 If not a roadmap in discovery, what are we using?
15:30 Why are roadmaps so popular in product?
21:50 When is a roadmap useful and how is it useful?
23:21 What do you consider to be best practices on a roadmap?
24:32 What are the biggest mistakes or anti-patterns you see on a roadmap?
28:23 Can you put your pledge to customers from product teams into the context of roadmapping?
30:52 If you had to distill your philosophy of roadmapping into one or two sentences what would it be?
31:32 What should I have asked you about roadmapping that I haven’t?
33:06 What is SVPG, how people can get in touch and how you can help them?
Thanks for watching 👍
Be sure to check out Marty's links...
- www.svpg.com/
- / cagan
- / cagan
- Inspired book www.amazon.com/INSPIRED-Creat...
- Empowered book www.amazon.com/EMPOWERED-Ordi...
- Loved book www.amazon.com/Loved-Rethink-...
Subscribe to stay up to date on all the latest roadmapping tips!
/ talkingroadmaps
Phil Hornby and Justin Woods, Co-hosts and Co-creators of Talking Roadmaps
www.talkingroadmaps.com/
#roadmaps #expert #educator

[@saroshmawani6801]

Awesome as always. Thanks for the insightful conversation.

[@DaurenKurkenov]

Would it be possible to add some visual examples?

[@TalkingRoadmaps]

Visual examples of roadmaps? If so we have a bunch of visual guides in the works so that sort of thing is coming.

[@angstrom1058]

No, I just use nav on my phone. I had an "road atlas" once, with lots of road maps (/sarc)

[@TalkingRoadmaps]

Satnav is just a digital roadmap with guidance. The risk is you end up on auto-pilot and paying attention so you take the wrong term. The same thing can happen if you treat your product roadmap that way ;)

[@dankelly]

Just say "never give a date".
What company has enough people or enough time to do feasibility prototypes for every new thing they work on?

[@TalkingRoadmaps]

I don't think it is that simple. It's all about risk. There are times (business reality) that you need to give a date, so you invest in feasibility discovery there. Similalry if feasibility is the biggest risk you should invest in that. Like everything in product "it depends".

[@richardarussell]

What company has enough people or enough time NOT to do feasibility prototypes for every new thing they work on?
I mean, unless you're working on things for which feasibility isn't a risk at all - but then you wouldn't really have a problem to solve, because you'd be able to predict dates reliably in the first place.
Are predicted dates reliable? If so, you don't have feasibility risks, so probably won't get much value from feasibility prototypes.
If the predicted dates are unreliable, do the dates matter? If not, your feasibility risks aren't material and so it's not worth having dates or feasibility prototypes - just go ahead and start working and finish when you're done. I hope your business and customers are OK with that!
If the predicted dates are unreliable, and this matters, then .... invest in the feasibility prototypes, because you can't afford not to.
Which is it?

[@dankelly]

@@TalkingRoadmaps I'll take "it depends". Just like, "when will that new feature be done?" It depends on how many other things I have to work on at the same time and how many quality, experienced people I have to work on them.