Article by Sherry Heise, Product Manager and User Experience Enthusiast at Intent HQ in London, UK. Sherry strongly focuses on delivering efficient solutions in the field of AI and Big Data and has a secret passion for forward-thinking institutional change.
Roadmaps. And those problems that we seem to face again and again when creating them. I haven’t met a single product manager - including myself - who have not gotten a paw stuck in the countless traps that are lurking just around the corner when setting out as a visionary. Luckily, there are ways to avoid those traps, if we keep aware of the forces - time pressure, expectations and investors - that will influence our decision making.
At one point or another we have all created roadmaps that include some of the weaknesses outlined below. And if you don’t recognise yourself in at least one of the below, then I very much envy you and your visionary skills!
1. The ‘Invisible Roadmap’ that says nothing
An invisible roadmap is - at best - an internal justification for the endless time of non-relevant releases to your customers. This roadmap contains the usual suspects such as upsell implementations (“Pay XYZ more to get access to this feature!”), or life savers (“we better update that code before things break”) or that big, long stretch of time before launching a new infrastructure.
Why would we call this roadmap inefficient? It is relevant work, or not? The invisible roadmap is usually not a piece you can present to your customers. Either because it has no direct relevance and/or value or it contains items you are actively avoiding to show to the public. Nobody wants to speak about a shaky infrastructure, scaling or beta features running in production that need some flesh on the bone that once was called a skeleton. Digital transformation and scaling of your infrastructure are natural processes that your client needs to understand and expect. If you feel what you are working on is not relevant for your customer, then it most likely is not relevant for your product either.
2. The lost-in-translation Feature Roadmap
I admit it, this one is my personal favorite. More than once I’ve struggled with dividing feature and value. As a result, I’ve ended up with a roadmap that did not only list features (e.g. “Single Sign On”, “Drag & Drop”) but sometimes even cryptic technical or internal acronyms.
This type of roadmap can be presented to a client, you are, however, not doing yourself a favour. You are promising full-fleshed production ready features, one after the other, smoothly delivered within a year. In my experience, this leads to two main problems.
First, clients are getting entirely detached from the problem you are trying to solve for them and are making assumptions of their own. You are most likely going to disappoint them. Second, your roadmap presentations are going to transform into a santa’s wish list session, due to the fact that as soon as you mention features, your client will mention more. Justifying time for technical debt and needed UX enhancements that do not directly speak to the feature you are building is almost impossible in this approach.
3. The Visionary Roadmap
While you certainly don’t want to hand timelines and features to your customers, you also do not want to be too vague. Our customers have lost interest through the overuse of terms such as real time, digital revolution and ‘the next... “(Insert big company name that already dominates the market)”.
So, how grounded is your roadmap?
A little bit of agile methodology makes all the difference
While there are benefits and disadvantages in agile development, there are indeed some aspects we as product managers can utilise when thinking of our roadmap. The agile development cycle aims to offer Flexibility, Opportunity, Discover and Retrospective. All of these would be more than welcome in our roadmap and will more naturally translate into the structure of engineering. I recommend to strongly stand behind these as values:
1. Flexibility
Your Roadmap is not an SOW (Statement of Work), it may change at any time.
Consistently validate with the business and your customers whether your roadmap content is still valid.
2. Opportunity
Development rather than Delivery.
Discovering more features to implement in the future while doing the work right now is good and expected.
3. Discovery
Include non-features in your roadmap, no company has ever developed groundbreaking tech without taking time to explore with no aim for profitable outcome
Partner with your customers, rather than establishing a client delivery relationship, unless you cater to as a (fixed project) third party supplier and work in a project scheme one can only benefit in partnering with your client during design, specs and delivery
4. Retrospective
Constantly challenge your roadmap through user testing and reversing the vision. A reverse vision test is done by showing the roadmap to a test user and asking them to guess the product’s vision based on your roadmap. If they get what you are trying to do for the product, they understand your vision.
Building the ideal Roadmap
In my humble opinion, there is no such thing as a perfect roadmap. But you can get close, if you put in the effort.
1. Get real - Identify Business Problems and Value
A great exercise to get started with is to identify the market and user problems your product is currently solving. Some questions to ask:
Do they solve them well? If not, why not?
How complete is the problem-solving? Do you offer an end-to-end experience?
Are there areas to expand? If you can list new or existing problems, identify the value of the items in your backlog.
Why have people bought, not bought or churned?
What does your competitor do really well?
How good is your product market fit?
2. Split and Plan
I found that planning exact work to be done further than 3 months increases the change of your plans being inaccurate.
Themes: Which isolated areas exist within your product that need addressing? Where would you like expand/enhance these areas in the next 3, 12 or 26 months?
Objectives: Objectives are problem solving approaches (and yes, mostly done through enhancements and features). Within your themes identify all objectives and find the most important ones within each theme. For prioritisation I can only recommend another agile method Weighted Shortest Job First (WSJF) that helps you to challenge your assumptions on what’s truly important.
If you’d like to protect yourself from feature commitment, only commit to concrete features for the first 3 months, as things will change after, but keep your objectives focused on existing problems. If those consist to exist throughout your roadmap you can later on identifying features that fit your product when the time is right.
3. Roadmap buy-in is not just ‘a product thing’
Ideally your roadmap should be the manifesto that all departments heavily rely on. Only by having access and direction to the product vision in a concrete time and resource verified manner, different people can help the product thrive. Whether it is the sales department telling the right story of vision, a customer success manager avoiding churn through excitement about upcoming features or your executives justifying funding for staff expansions.
A roadmap can be a powerful tool when done well, and is therefore an important - if not the most important - task a product manager can take on
4. Know, and I mean really know, your Users
When have you last spoken to your hand on users? Not just about how they think your new UI looks like, but have you shadowed them for a day understanding how they do other tasks during their day? Which apps they use professionally? Personally?
We have a lot to learn from our personas, if we engage consistently and responsibly. Creating a good relationship with your users can not only drive customer satisfaction, but also give you a genuine (and often new) understanding of the problems the user is looking to solve and that they are unexpectedly looking to your product for help.
Final Thoughts?
When it comes to perfect roadmapping, i do not think there is a definite handbook. No one methodology. As product leaders we will always be challenged to combine the business interests, your clients requests and the technical needs and find the perfect balance to chase what we hope to be our Product Vision. Is it that easy? Of course not.
Throwing timelines, customer contracts, lack of resources and a variety of interests within your organisation into the pot, we have a soup that can very easily turn out salty. And as the pain that comes with the roles, there is little to do about it.
However, I sincerely hope that some of the content of this article will help you question and improve your current roadmap and if not, I hope that it comforts to know: you’re not alone in the madness.
Continue the conversation about roadmaps
Feel free to leave a comment below, if you have different perspective, or if you share some of my views on these challenges that we face when roadmapping.
You can also join one of our product management peer groups in Europe and the US.