How we built a zero-waste product roadmap in a Logistics SaaS Company

If you are a Product Manager (PM), it is highly likely that you dread the month before a new quarter begins. You, my friend, have to decide what your tech team will spend 25% of their year building.

Your customer success team wants you to build that long-pending feature request raised by the customer, while your sales team wants you to build that one feature every prospect is asking for, but you don’t have. Your lead engineers are constantly reminding you about that piece of code they need to go back and improve, while the leadership nudges you towards the most electrifying innovation that will have the pundits sit up and take notice of you. You wish you could snap your fingers like Thanos and get a shiny new product roadmap that ticks all the boxes.

At Locus, PMs want to make sure that we always include features in our product roadmap which give us the best returns with the least waste. While “returns” is easy to understand, “waste” is not often emphasized upon. So, what does “waste” really mean?

PMs should not include a feature in the product roadmap which may eventually get discarded or completely descoped during the quarter. Even bigger, the feature gets built and users no longer need it. When any of that happens, you have created a “waste”.

Why is roadmap waste important for a PM?

A PM performs many activities before a feature is made ready for launch. Once the PM sets her eye on a feature, she performs in-depth research on various competitors and similar use case products to get inspirations on the way the feature can be designed. She identifies feature touchpoints and builds a hypothesis around its usage. PM explores different flowcharts and user journeys to identify the best workflow for the feature. Once the flow is clear in the mind, the PM goes on to document the solution in different business cases, PRDs, and functional specifications. Each of these goes through multiple reviews with the design and engineering team before making numerous readjustments and getting the precious final sign-off. Each feature then gets broken down into multiple stories, tasks, and subtasks and the feature finally arrives into its “Ready for Development” status.

It is a massive disappointment if a feature gets discarded during the quarter when new information unfolds and the feature is no longer needed. It is even more painful if the information unfolds after the feature is built because now it is not just you but the entire team whose efforts have gone wasted.

Therefore, it’s extremely important that the PM does the additional due diligence to ensure there is minimal or no waste.

The road to road mapping

The unfortunate aspect of waste is that it can be measured only in retrospect. However, waste can be significantly reduced or even eliminated if roadmaps are done the right way. Here’s what we do

We take the zero-waste product roadmap through multiple steps:

1. Establish product vision by segmentation
2. Ideate and identify a laundry list of features
3. Evaluate features to build themes
4. Design multiple flexible roadmaps
5. Last call for adjustments

Let’s look at each of these steps in detail.

Establish product vision by segmentation

We operate across multiple geographies, use cases, and industries and segment our product by each of them

1. Use cases (Single Pick Multi Drop, Last Mile, Single Day Deliveries, etc)
2. Industries (E-commerce, FMCG, Courier, Services, etc)
3. Geographies (APAC, NA, EU, etc)

We perform secondary research by going through sources like research reports, whitepapers, industry blogs, competitor resources, and regional domain news to build an understanding of the direction the product should take. This is a high-level direction that the product should move towards.

As an analogy, a possible high-level direction for a B2C chat messenger platform may be to evolve into a voice and video chat platform for businesses, which then supports B2C transactions and then enables digital payments on it.

For each use case, we learned what are the existing workflows in each region for an industry. Doing this research over multiple segments started showing up similar patterns in typical workflows. We were also able to map each of these different pain points with the strengths of the competitors. This exercise gave us an “aha” moment as to where we are doing well and which areas need improvement.

Ideate and identify a laundry list of features

The high-level direction is then broken down into multiple smaller milestones which act as sequential building blocks for the overall product vision.

For example, different high-level milestones for an online edTech SaaS company would be “video streaming platform -> student and faculty onboarding-> payments integration solution-> user profiling -> course recommendation engine -> multi-sided ratings and feedback system”

The next step is to identify features that will contribute to the completion of each milestone. There are various sources that can provide insights into the features that will constitute part of your laundry list. Let’s look at some of the sources we rely on.

Stakeholder Sync-ups: This is where cross-team collaboration is extremely important. We sync up with our sales, engagement, and customer success teams to understand what are the on-ground realities. These are teams that have their ears on the ground and tell us what customers are asking for, what they like, and what they don’t like in our product. They provide us another perspective on the competitor positioning and act as idea boards to build a hypothesis. Some of these requests are already reported on issue and project tracking tool Jira, which we keep in our backlog.

Tip: A really good way of getting such feature insights on a regular basis is to model your Jira workflow accordingly. In addition to the regular Jira issue types like Epic, Story, Task, and Subtask, we also created another issue type called “Idea”. All employees of Locus are encouraged to create product “Ideas” on Jira which the relevant PM reviews within a limited timeframe and marks “accepted” or “rejected” with reasons. On acceptance, the PM immediately creates a corresponding Story and adds it to the backlog with the reporter as a watcher.

Customer Issue Reporting: We integrated an issue reporting tool in our product which allows users to raise a feature request or submit feedback. These requests are vetted by the Locus POC and passed to the Product team with additional information. Locus POC also helps to bridge the gap between the user and the PM to clarify any doubts or run an experiment to address the problem.

RFPs: We review the old Request for Proposals (RFPs) to check what were the features commonly asked by prospective customers which we ended up saying no to. As a PM, we are keen to convert most of these “nos” to “yeses”. We increase the initial priority of the feature if it gets repeatedly asked by new prospects.

Note: We also check for the alignment of these features in RFPs with our broader goals. Including non-aligned features will deviate you from your goals.

Analytics Data: We want data to guide us through product improvements as well as feature ideas. Many times, the data tells us what is churning users out of a funnel or which usage has a bottleneck. Diving deeper into this data ocean helps us find key bottlenecks.

Studying analytics data helped us identify inefficiencies in a heavily used workflow a few quarters back. We reduced the steps in the flow to improve the flow completion by 14%.

Primary Research: While all the above is necessary, nothing replaces   primary research. We visit the warehouses, accompany the delivery partners to understand the delivery process, conduct in-person and remote interviews with the buyers, influencers, and users and conduct in-app surveys to identify their as-is workflow and how our product can further make their lives better.

All of the above allows us to identify the pain points faced by users to achieve these milestones. We take the help of competitor research and similar products from other industries to gauge how the same pain point was addressed. This guides us to ideate and identify a set of features needed for a pain point.

Doing the above exercise across all the pain points enables us to create a laundry list of features needed to achieve milestones.

Evaluate features to build themes

We did this in further two more steps. In the first step, we took the huge laundry list of features and tagged it across different parameters like Hygiene, Stability, Aspirational, MSP, and USP. This helped us quickly prioritize Hygiene, Stability, and MSP while cherry-picking the features from the other buckets. This was a one-time exercise with frequent rationalization at larger intervals. Other stakeholders like engineering, sales, customer success, and marketing were involved to get inputs on it.

In the second step, we explored the requirements further and prepared a short sentence business case on each. While features could belong to multiple categories, we prepared a central feature theme around the set of features. These themes could indicate meaningful goals like localization, self-serve, or notifications, or could fall under the specific screen or workflows like app login, settings, or user profile.

This is helpful to reverse associate it with the milestones prepared earlier. Pick themes that make the most sense to the core workflow. However, do keep in mind the improvement in user engagement when delight features are also included.

For example, while feeds, stories, and reels are core features to Instagram, a delight feature like dark mode not only improves the battery performance but also makes the overall viewing experience much better while giving users a sense of choice.  Increase in user engagement thereby increases the number of posts on Instagram.

Design multiple flexible roadmaps

We have a practice of having multiple roadmaps ranging from short duration (3, 6 months) to longer duration (24, 36 months). Naturally, the longer duration roadmaps are subject to constant evaluation and are flexible to modifications. The purpose is to have a high degree of confidence in upcoming roadmaps while having one eye on the long-term product roadmap.

Feature level themes are discussed with PMs of other products. This step is important as they account for cross-team dependencies which could alter the priority of the features. Once dependencies are accounted for, features categorized in themes are put on the floor for the prioritization process (another blog, another day) involving all internal key stakeholders. Each stakeholder provides its own assessment and priority on the features. We get data on features across useful parameters like revenue guesstimates, effort sizing, market effectiveness, and feature differentiation. Each quarter further gets some time allocation for each of the following optional categories

1. Tech Debt
2. Customer Asks
3. Roadmap: Growth
4. Roadmap: Future
5. Experiments

Growth features are aimed towards enhancing the experience for existing customers in order to improve the growth metrics.

Features under “Roadmap: Future” are intended to build and grow the business to a bigger customer-base.

“Experiments” is a fairly new exercise to try out initiatives in the market to test the hypothesis.

While the time allocation changes as per situation, we almost always give higher time allocation to Roadmap items. As an unofficial rule, it is safe to consider around 60% time allocation to building features for future roadmap. Keeping a higher allocation for the roadmap ensures the team always builds for horizontal and vertical expansion while keeping some time allocation for tech debts and the customer asks helps us improve the tech stack and keep our customers happy. Experiments are a great way to test out hypothesis when you don’t have enough data points on its eventual adoption.

Once prioritization is complete, roadmaps are taken through an estimation cycle driven by the Engineering team. The outcome is a solid 3-month roadmap planned on a tentative time-scale. The roadmap itself gets a central theme. Each of the past few quarters had a central theme like the following:

1. Q1: Efficiency
2. Q2: Scale
3. Q3: Stability

Other themes could be Visibility, Flexibility, Usability, Innovation, etc. Building themes allowed us to assemble features that belonged to meaningful buckets and also arguably helped the engineering team improve focus.

Last call for adjustments

Roadmaps are published to all the stakeholders for their review. Stakeholders can come back with requests for tweaks to the roadmap. All such tweaks are incorporated and a final zero-waste product roadmap is signed-off.

Results

We observed significant improvements in the roadmap adherence and feature adoption levels. There was a time when some features were spec’d out but never saw the light of the day, thereby wasting a lot of valuable time. Some other features were built but saw very low activation by users. Since the new road mapping technique is in place, there is higher confidence in the time-value of the efforts put into building features as well as a steep increase in the adoption of those features.

Source: This Zero-Waste Product Roadmap blog was earlier published on medium by Rohit Nadgouda.