What's a Featureless Roadmap?
What is a featureless roadmap? What purpose does that serve, when & how do you build one of those?
Talking of the PLC (Product Life Cycle) this underlying graph so often becomes the reference point for many. It starts with LAUNCH and then ends at DECLINE after seeing a rise over the GROWTH & MATURITY phases in between.
But, there’s such a huge cycle of time that goes into the STRATEGIZING bits prior to the LAUNCH phase which comprises of the GOALS, STRATEGY, ROADMAP & BACKLOG overarching into the BUILD phase of the product.
“No pain no gain & so also NO BUILD NO LAUNCH”!
The Strategic phase is so crucial for any product that it would dictate the accentuation angle of the slope over the GROWTH phase and the width of the MATURITY phase which simply means a product that sees a widespread adoption and for a prolonged period of time, so much so that the DECLINE doesn’t even come into sight.
In case you are wondering if there’s ever a product that would fit into such a category you don’t need to look too far away from your regular lives. Some stapled products like Colgate / Pepsodent Toothpaste wherever you are in the world or Amul Butter if you are in India do fit in perfectly into this sample space.
When longevity of a product / prolonged & continuous adoption with metrics pointing upwards & above average do seem like a myth for many in today’s world of SaaS products, it is down to a few important factors:
Problem it is solving
Percentage of the target market who associate with the problem
Manner in which the problem is solved
How the solution (product) is rendered
Cadence at which the product evolves & its relevance to market’s needs
“If your product doesn’t have enough onus on the strategic bit upfront, it would soon turn into a feature factory & may eventually face zero adoption, a painful death nobody wants”
When Strategy happens to be something of a high-level plan defining the value the product would add to its target audience & how it would set out to achieve those key goals, the Roadmap accentuates the strategy by defining the key initiatives / routes / opportunities that one ought to explore & undertake so as to realize the goals & take a step closer to the vision.
The Strategy anchors the vision setting the most necessary direction when the roadmap underlines the way & means of getting there via fluid plans.
The Debate…
But here’s a debate that’s been on for quite some time now!
Do roadmaps ought to have TIMELINES on them?
When some PMs & product leaders advocate the use of roadmap as an internal communication tool that focuses on providing clarity to stakeholders / teams by simply limiting the use to accentuate the STRATEGY, some agree that they have been putting timelines on them.
Firstly, one ought to understand that roadmaps come in various shapes & forms serving various purposes ranging from acting as a guideline to internal, external teams whilst clearly underlining their strategic initiatives. As is evident in example (refer image above) there are various EPICs carrying 3 different colors serving those very purposes:
Now take a good look at those individual EPICs in the roadmap. Mobile Mock Up or Ticketing System happen to be detailed tasks / initiatives spelled out clearly for the respective teams to understand what’s important and to hit them one by one collaborating & coordinating as needed ensuring that they reach the outcomes so desired.
Could they be termed features by any stretch of the imagination? For sure.
Ticketing system could point to better issue reporting, routing and resolution which is internal to the organization & to do with XFN collaboration
Mobile Mock Up simply underlines that the task is important and could also serve to communicate the exigence to the design team
But can a roadmap get envisioned & built sans these initiatives / features listed on them? Would that serve any purpose in the first place? Turns out that is essential at times & one of them fitting the bill is a “FEATURELESS ROADMAP”.
Featureless Roadmaps
“If a roadmap can’t have EPICS on them that vaguely correlate to features then what else can it have there?”
If you happen to be in the zone with that very question lingering in your head at this point of the article, you may have to shift your perspective from tactical product work to the strategy and way beyond, overarching into the vision.
And as it turns out there could be a requirement where something like a roadmap is needed so as to serve as a bridge for communication aligning product leaders / the C-suite, whose major point of reference & agenda is bent towards the vision & leading one-step further into the goals.
Definition:
“A feature-less roadmap is usually meant to serve as a high-level artifact and is often used when one is looking to communicate product vision and goals, rather than listing out detailed features & define the order in which the teams ought to build them”
Mostly when one is talking of Agile teams their roadmaps are so often built around epics making it feasible to convert them into something tangible like arriving at the user stories over a backlog. There could be many roadmaps used by various teams meant to serve specific purposes, some common ones are:
Development roadmap – For Tech / Dev teams (Front-end, Back-end)
Marketing roadmap – For underlining all marketing initiatives
Sales roadmap – Meant to direct sales teams spelling out the area to focus on so as to reach the sales goals
Product roadmap – Used to align all internal (at times external) stakeholders over the initiatives that matter RIGHT NOW whilst clearly communicating the strategy
But when it comes to going featureless, one could use a stretch of their imagination to curtail the EPICS in the roadmap to align to the goals in question.
Let’s take a look at a few variations of these featureless roadmaps, the stage & order in which they are built alongside their immediate purpose.
1. Business Roadmap
Think of a business roadmap as an artifact that focuses on strategy & strategic goals whilst also covering a bit of organization structure for one ought to focus on planning hiring & building teams so as to lead the successful deployment of the strategy.
The EPICs here in this roadmap aren’t initiatives but represent the goals & the direction the leadership plans and a prioritized route they would want the teams to take.
For ex: Here’s a roadmap that’s used to depict the strategic initiatives lined-up over the 4 quarters
The business roadmap post discussions & buy-in often overarches into a business plan which is more of a detailed document accentuating those epics and underlining challenges / detailed plans to overcome them.
2. OKR Roadmap
An OKR Roadmap gets built a little later in the PLC, ideally after the product has seen a cycle of growth, however minimal that may have been.
For ex: Here’s an OKR roadmap depicting the objectives & respective key results
After taking the product through the build stage & releasing it to the market the onus naturally tilts towards the growth of the product when it essentially turns into this number game and that’s when having something like OKRs so as to drive growth ahead becomes crucial.
NOTE 1: The OKR based roadmap could be easily turned into an Outcomes Roadmap by focusing and listing the Outcomes that matter in place of the Objectives, when the Key Results could get replaced by opportunities / initiatives.
NOTE 2: When it is usually the product leaders who build these artifacts over a normal scenario, it is quite possible that these may be built by product managers over an early / growth stage startup.
When should you go FEATURELESS?
There could be 2 main factors that dictate and influence the type of roadmaps one ought to be building for their teams:
1. Clarity (the Leadership & the Teams possess)
What are the EPICs on a roadmap & what do they represent? Do they spell out the features to be built & in detail (or) do they just list out the opportunities that seem to be lucrative overarching into the routes to be explored?
I am sure you agree that the latter fits in better for a description here. Then if it is still an opportunity that’s yet to be addressed, yet to be explored then how can it even fit the description of a FEATURE?
But it still is important you list them there so as to get that word out, make it clear as to what’s important NOW, NEXT & LATER which is why building the artifact does make perfect sense.
2. MATURITY (the Teams & the members carry)
Think about this, of all the teams you have worked alongside over the years of experience you have garnered thus far can you vouch for all of them being at the same pedestal of strength / maturity?
The maturity of the individual teams does play a large role here and when one talks of product organizations there are Startups with less than 15 members and large MNCs with 1000+ members in there fitting the bill. So that makes it way tougher to generalize exactly how an artifact ought to be built, employed & used.
If the teams are mature enough to grab opportunities by the scruff of the neck, ideate over them and methodically move forward towards detailing the feature list thereof, there could be a strong case to build these featureless roadmaps given how the leadership team would want to hand over more autonomy to the teams themselves entrusting them to do a great job with it, time and again. Otherwise one could simply fall back upon roadmaps with detailed features listed & also use timelines if need be.