Product Roadmap Amnesia

Ankita Parihar
Credit Saison (India)
4 min readApr 29, 2022

In growth stage companies/products — often even if the roadmap is agreed across by Makers & Sellers, the end users or the product sellers have their requirements under-met by product makers.

During early stages of a start-up, the overall product strategy & roadmap is very closely knit within few stakeholders, as the focus is on preliminary versions of product launch. To have a strong foundation for quick growth, companies keep a tight control on the preliminary product definition-to-launch lifecycle by involving few stakeholders such as the co-founders, CEO, initial product and tech team.

At this stage, more iterations can be made, launch hiccups are tolerable — Product & Tech teams are accountable, but are anchors of product roadmap.

The product strategy in a fast growing organization requires a dynamic and fast evolving product roadmap & approach, across different stakeholders within the organisation. The product vision needs to expand to include additional and updated products to fulfil a larger vision.

As organisation’s teams grow, a key skill in product management is to arrive at a balanced product roadmap between the Product Maker team — “people who build & define the product roadmap” and Product Seller team — “people who sell & take product to market”.

In this scenario, product manager needs to rise above the excel sheet prioritization between Tech and product to avoid a very common “roadmap amnesia” issue.

Roadmap amnesia occurs due to typical one-time alignment at start of quarter: long meetings & long excel sheet-based prioritization between different stakeholders in the company. This prioritisation should follow frameworks to evaluate best value creation for the product and not just a feature overload on the product. However, it is common for stakeholders not directly get involved in product development or get caught up in their own priorities and rightly so. Unfortunately, this often results in alignment challenges between all stakeholders between the quarters.

While there are plenty precise tools & processes available to get most mind-blowing prioritisation sessions backed with analytical thinking: naming few Pareto principle, RICE, Eisenhower or even multi-column creative & colourful models in trackers.

Even though in the beginning of the development cycle, prioritisation of a long list of features with all stakeholders is a good start — but it does not solve the problem of “roadmap amnesia”.

This leads to frequent disconnect between expectations vs current in-development work. In my experience, I often hear comments — “this is not covering most of our requirements”, “competitor are bringing features faster”, “we have to do more, why don’t we hire more”.

Product should always ensure there is value creation on features launched than more features. Less is more, beauty of products lies in simplicity and not overcrowding.

I recently read an interesting way of putting this together — this is usually outcome of the gap between two key stakeholders: Team Maker and Team Seller.

The Seller team has exposure to many products in market, competitive features and growth potential in the field, while the Maker team ping pongs between the new requirements & the upkeep of quickly built minimum viable level features.

This leads to an expectation & timeline disconnect between the Seller & Maker team leading to

“everyone in market has this feature, we cannot launch with this feature”

vs other side of the story

“Team is working on overcommitted roadmap & halfway down the development. We had agreed on the list of features”. “lets decide which feature should we deprioritize to pick this new requirement”.

While both teams come from the “right” side & aligned with organizational goals, but end up becoming problem for the other side, leading to mid-development crisis and frustration.

These are mostly deja-vu events for experienced product & sales professionals, and few methods which can help solve the gap are:

Do not focus on New Features only: If in the beginning of the development cycle, entire Technology development bandwidth is factored for new developments, it does not leave any room to improve the older features (which are often bare minimum) or provide any support. So, the quarter or 6 month effort should be factored across these:

  • New Feature development
  • Improving older features
  • Proof of Concepts & Tech Improvements
  • Support & fixes for issues in older features

The weightage on each of these can vary based on the stage of the product & priorities agreed between team. Ignoring any of these sections, often leads to reprioritization or mid-development cycle ad-hoc requests.

Aligning product development roadmap with the Business team targets: While this is the most basic & given step in product goal setting, getting an understanding of Business/Revenue Targets set out by Sales team will enable product to prioritize those features which can help the business grow faster. For example, the must have features can be revenue generating features — like subscription for customers and other good to have features like “Repeat purchase from Older Orders” can be pushed later in roadmap.

Frequent sync ups such as on a bi-monthly basis rather than quarter start & end sync ups: A more frequent walkthrough of the product features developed, in-progress and how they piece well with the quarter, or 6-month goal helps with more practical use case & alignment with Business & Sales stakeholders. These frequent sync ups help in any re-alignment required to do market moving news, customer demand raised to sales team, competitors’ news or feedback on already developed & released features

These methods can help the expectation vs readiness gap between different teams, and help the product build a product/feature set that meets the requirements of other stakeholders “Just in time” rather than fatigued product launch.

--

--

Ankita Parihar
Credit Saison (India)

Building Products @Credit Saison; curious about everything and keeping up with the pace of technology.