TL;TR
- Use roadmaps to discuss scope as objectives and outcomes you’d like to achieve.
- Don’t use roadmaps to write down features or track output.
- Work with themes: problems, needs and objectives.
- Don’t use dates in roadmaps.
- Use features and experiements as possible customer solutions and only track them in a plan, if really needed.
- Empower your people and teams to maximize your outcome, not your output.
Due to my latest experiences at work, I’d like to write down and share some notes about roadmaps, expectations and empowerment. Roadmaps are part of a daily business in a software product world, especially when exchanging with stakeholders.
Where is the problem with roadmaps?
As in the product world, product managers and owners are forced to discuss the planned upcoming scope and potential timeframes with the stakeholders. This sometimes goes hand in hand with poor understanding in dependencies like the project management triangle which is very old:
Original source: https://en.wikipedia.org/wiki/Project_management_triangle#/media/File:Project-triangle-en.svg
The obvious challenge: you can’t have all by one. This might lead into disappointments and bad outcomes due to different expectations which are hard to be met in the product delivery. Scope is the only dimension which should stay flexible. Once you are working within sprints, time is fix for the sprint length. In general budget and costs are constant at least within a year. Try to keep teams stable over time if possible. The biggest challenge is quality, as everybody often agree on this as “given” or non-negotionable as this will affect and influence customers immediately. If quality is treated as non-negotionable, it would mean to focus on fixing bugs first before writing new code.
David Cancel, CEO of Drift, brought the challenge in the right direction:
“Either I’m going to disappoint you by giving you exactly what we thought six months ahead of time was the best solution when it’s not, or by changing course and having lied to you.”
Another easy way to understand and acknowledge the usual problem of roadmaps:
I highly recommend to read this article “Why David Cancel Hates Roadmaps (But Uses Them With Customers); April 3, 2018 by Bruce McCarthy” as you will find more great statements about roadmaps.
So, what is a roadmap?
Starting first with exclusions of a roadmap:
- A roadmap is not a project or release plan
- A roadmap is not a list with dates and features.
I found some definitions worth sharing, because it resonates with the long history of my product understanding:
- A roadmap is a strategic communication tool.
- A product roadmap is a prototype of your product strategy.
- A roadmap is a state of intend and direction.
- A roadmap is how you will realize your product vision.
Differences between roadmaps and project or release plans
A roadmap manages outcomes. Your project and release plan manage outputs.
Original source: https://speakerdeck.com/iamctodd/roadmaps-are-dead-long-live-roadmaps-mtpcon-2018?slide=55
Easy said: Your roadmap is about priorities. Your release plan is about execution.
- Roadmap = Priorities
- Sprint or Release Plan = Execution
Work with themes & remove dates
Wait, what are themes? Themes are not a list or grouping of features.
Themes are problems, needs and objectives.
Themes are the constant once you translate your goals into solutions.
- Objectives = Outcomes
- Features = Output
Finally this is the best visualization I ever saw so far to explain the differences between a roadmap and a release plan.
Original source: https://speakerdeck.com/iamctodd/roadmaps-are-dead-long-live-roadmaps-mtpcon-2018?slide=115
Experiment, prototype and hypothesize
Most of the time you don’t know exactly what and how to solve a problem hypothesis. But this is a good starting point, because you usually have various ways to build the product and work towards your objectives. It might depend the stage your in. Design thinking might also be a good fit.
Original source from Jeff Patton: https://jpattonassociates.com/handouts/
Try also also to experiment with user research like the Kano model to gain further insights especially for solution validation.
Four possible steps to your roadmap
- Gather inputs from all your various sources
- Organize and prioritize your themes
- Place them into timeframes on your roadmap in three categories:
- Now
- Next
- Future
- Map to sprint or release plan
That’s it.
Are roadmaps really needed, how is leading tech dealing with it?
Finally, a lot of people referencing about GAFA should also have a look around their way of innovation and collaboration. I’ve read some inspiring thoughts by Marty Cagan and like also to highlight the way how Apple or other leading software companies work with roadmaps:
Empower your people
Don’t be fooled by “green table decisions” where others might think and know better what and how to build for customers. This is the work of the team which actually works and builds the product. They should and must be empowered. But this won’t come naturally and depends on various dimensions. Power dynamics and organizational structure might not be in your control. I highly recommend to accept and embrace reality as it is and work with it.
“We need to co-create with our stakeholders, getting their feedback early and often, long before we draw our final conclusions.”
— Teresa Torres
At least to practical ideas come into my mind to facilitate co-creation with other stakeholders:
- POEM – Product Owner Evolotion Model
- Delegation poker and board
What are your thoughts? What is missing? Would love to hear from you.
Thanks,
Patrick
___
Further reads and sources of this post
Product Roadmaps Relaunched: How to Set Direction while Embracing Uncertainty
by C. Todd Lombardo et al.; http://a.co/d/4stJd7k
Themes: A Small Change to Product Roadmaps with Large Effects; https://articles.uie.com/themes/
How To Build A Product Roadmap Everyone Understands
June 10, 2017; https://www.prodpad.com/blog/how-to-build-a-product-roadmap-everyone-understands/
Stop Setting Up Product Roadmaps To Fail; https://medium.com/@johnpcutler/stop-setting-up-product-roadmaps-to-fail-3189452360a3
Product Roadmap Failure: Stop Setting Them Up To Fail; https://age-of-product.com/product-roadmap-failure/
Why Most Product Roadmaps are a Train-wreck (and how to fix this); https://medium.com/techstars/why-most-product-roadmaps-are-a-train-wreck-and-how-to-fix-this-12617e3adabc
What is an agile roadmap? Product development tips, May 10, 2018; https://www.justinmind.com/blog/free-template-agile-product-roadmap-for-product-owners/
VersionOne 12th Annual State of Agile Report; https://explore.versionone.com/state-of-agile/versionone-12th-annual-state-of-agile-report
The Joel Test: 12 Steps to Better Code https://www.joelonsoftware.com/2000/08/09/the-joel-test-12-steps-to-better-code/
Stop Managing Bugs, Start Focusing on Quality! https://blog.crisp.se/2018/02/05/yassalsundman/stop-managing-bugs-start-focusing-on-quality
Patrick Sauerwein | @virtual_patrick 
2 thoughts on “Roadmaps, Expectations and Empowerment”