Are roadmaps ever useful? - Marty Cagan
Вставка
- Опубліковано 12 тра 2024
- 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
Awesome as always. Thanks for the insightful conversation.
Would it be possible to add some visual examples?
Visual examples of roadmaps? If so we have a bunch of visual guides in the works so that sort of thing is coming.
No, I just use nav on my phone. I had an "road atlas" once, with lots of road maps (/sarc)
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 ;)
I just hear him talking "be credible" "make sure there is evidence..." but not a single time how to actually achieve this. And that is the hard part. Of course a roadmap is only valuable when there is enough confidence that the thing is not utter bullshit. With some things that were mentioned, like prototyping, feasability analysis, they can make some projects take twice the time.
So is getting started early and learn on the journey more important or research and analyze before to make more accurate roadmaps?
If you do the right thing and it takes longed (it should not take anywhere near 2x!) but you don't waste your time doing the wrong things you will end up making more progress in less time. The urge to just build it is seductive. Often a feasibility prototype is hours (or at most days) of work. It's just a form of discovery. That allows you to take out risk and drive up confidence quickly and cheaply.
You phrase it as an either or, do a lot of up front work or get started. We'd argue it is both. Get started. Write down what you think is the right direction of travel, include the uncertainty and discovery in the roadmap. Then do the discovery and refine. After a few short iterations that initial uncertainty is driven down in the short term stuff and you are showing the areas you are understanding further out.
Hint: if you put the customer problems on the roadmap they also tend to be pretty stable - the discovery tends to just help you better understand them and through that refine the solution you will deliver to address them.
@@TalkingRoadmaps That's surely an explanation that makes sense on paper or for some teams. I'm working for a company where we develop one huge product with almost 20 teams. There is so many dependencies (yes we are also in the process of untangling them) that every discovery/prototype won't show very clear results quickly.
You could argue that this is our fault with having still many remains of a big monolyth but probably the truth for many other "older" companies out there. So there is no way we can proof the concept good enough in a few days to give a seemingly accurate roadmap for a year or two year long project :(
@@highopay you somewhat answer your own questions. The only real way to scale product work is to descale the work, striving to minimise the dependencies. But you also hint at a key point at the end, a roadmap is not a project plan. It's job is not to provide delivery certainty in a proJEct context. Its job is to communicate and align direction of travel in a proDUct context. By asking a roadmap to do too many jobs we make it do them all badly. In a product context our goal is to ship little and often. But that said we also have to consider the domain. In some domains they are complex - which means that the only sensible way to have certainty is to use methods like agile and lean (aka discovery) - most software fits in this. On the other hand some domains are complicated - which means that planning and analysis are the best approach to take - most physical products fall here. The hard part comes when you have a mixture. Neither mean you can't do discovery to rerisk and increase certainty - the question is how far you want to go with that. You likely can't eliminate risk in a couple of days but you can probably take 50+% of it out. I work with old and new companies alike helping them with this sort of thing.
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?
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".
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?
@@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.