Product Roadmaps: for Consumer Businesses

Dissecting the two types of product roadmaps by example

Hey You,

On to another Sunday and another month. I’m super stoked to say that I'm now taking my newsletter international, outside India too. So you’ll soon start seeing topics and examples that are relevant for a wider audience, across the world. Best practices in products and my experience of working with high-growth consumer businesses & venture funds, in India & US.

Before we dive into today’s topic, if any of you are interested in co-investing in DTC startups along with me, drop me a hi on my LinkedIn.

Also, do check out my latest video on ‘the most important metric for DTC brands’ that crossed 5K video views on LinkedIn (which means more than 5000 people watched it for over 3 seconds).

Today, we’re on to 2300+ subscribers and it’s growing steadily. So if you’ve been added by a well-wisher or you’ve signed up yourself, it’s going to be a fun journey from here on. You are part of 2300 avid readers of experiential (read: tactical) content on product, design & technology. No ads I assure.

Subscribe

Today I’m busting a HUGE myth, across product teams. It’s a lash out on the way most product teams work, but perhaps worth hearing this side of the story.

Today is a contrarian view to what we usually work on, across product teams. We usually end up working on project based roadmaps whereas we’ll dive into what an alternate version: outcomes based roadmap could look like,

Project Based Roadmap: Based on the vision of the product, a few features would be lined up for design & development across product & engineering teams. These timelines for these roll-outs will be set in advance (say for the next 6 months) and the teams will work on building the best version of customer experiences across each of the features.

The Challenge: 

Markets evolve faster than you’d imagine. And even though things change in the process, teams are set on their course to deliver new features (that were planned a few months ago) onto the product.

Even bigger challenge is: once these features are rolled out, no one’s measuring the value they provide to customers. The teams are on to their next set of features and busy ‘building stuff’ and no one bothers to check with customers if the previous features had any value / impact.

Rarely would teams be working on another sprint to improve the first set of features rolled out. That’s because they have the next set of features to attack, coz the Product Head somewhere has committed to a series of these features to be rolled out, by end of the quarter / year.

At Lights Out too, we’re often working on ‘project or feature based roadmaps’ on high-growth products. Seldom do we get a chance to convince our way through a different way of improving products: outcome based roadmaps.

Outcome Based Roadmap: An outcome-based roadmap describes the path to a successful product in terms of the problems to be solved to achieve the desired results. This approach provides context to product decisions and allows you to plan further out than you can actually see in terms of features and dates.

The pros of this approach is that it allows you to weigh in the discovery & research you need to do, before committing to a particular feature. It allows for a flexible approach as well as timelines, before you roll out new features.

Also, since it’s purely outcome based, the possibility of the desired outcome changing in a short span of time is limited, even if the market dynamics change.

So today, I will help you understand the difference between the 2 roadmaps, based on a consulting project I concluded last week: for an upcoming e-commerce aggregator platform: to build a thesis for their next round of investment. For ease of reference, let's call this platform: FUN

Some background: FUN is an e-commerce aggregator platform across all categories like apparel, lifestyle, beauty, fashion, etc. They have products of multiple other brands as well as their own in-house label.

Let's start with the overall objective that a product head would usually be entrusted with:

Build a product that creates customer delight, in unique and profitable ways.

Now, for an e-commerce aggregator platform, the one metric that would become almost like a North Star Metric would be: RETENTION

Retention basically means a Higher LTV per customer  (via repeat purchase). But this alone is quite a broad metric to measure. So we break retention down into multiple smaller metrics (called proxy metrics), that can be moved faster. Over time, the aim of the product team would be to move these proxy metrics.

Lets analyse these proxy metrics, through an SMT (Strategy/Metrics/ Tactics) framework, for both Project Based Roadmaps as well as Outcome Based Roadmaps.

S/M/T Framework: Project Based Roadmap

Now since it’s a project based roadmap, the features / projects are literally divided across a few months / quarters for them to be implemented.

While all of these correlate to improved customer retention, the time it takes to implement some of these tactics is pre-determined based on future roadmap rather than customer feedback. 

S/M/T Framework: Outcome Based Roadmap

Now let's look at the same strategy of improving retention through the lens of an outcome based roadmap.

Difference between Project-based vs Outcome based Roadmaps:

• Product based roadmaps (PBR) focus on the features and lay them across a specific timeline. Outcome based roadmaps (OBR) consider the most meaningful metric to be attacked first.
• PBR’s allow for little to no flexibility on customer feedback in between, since you are on a tight timeline. OBR’s consider feedback after the most important feature is rolled out and allows for iteration instartegy, since you aren't married to a timeline but an outcome.
• PBR’s look at problem-solving as a quarter-on-quarter exercise whereas OBR’s focus on a personalised approach from a customer’s perspective and then arrive at some leading indicators that make the most sense.

The result reinforces the importance of moving the “leading indicators,” irrespective of the timing or exact composition of each project. Most importantly, there’s no implied commitment to a timeline.

I could go on, but based on the above tables, you’ve figured the difference. Here’s to note that the above table is only a very high-level snapshot of what I worked on for FUN. We went into a lot more depth in the actual presentation, to dig deeper into the why’s & how’s of each indicator, metric & feature.

Lastly, some points to keep in mind:

• Roadmaps are the last thing that comes in the product journey. There’s a whole lot of vision, PMF and things like competitor analysis to work on before arriving at the roadmap.
• Use roadmaps as just a story-telling tool since they build for a great narrative across the organisation.
• Simplify and make your roadmaps jargon-free (friction-less) for them to become documents that different departments can use; exactly as you’d like your product to become one too.
• You could choose to merge both the roadmap styles and come up with your own version of roadmaps, as long as you take merits of each of them into consideration.

Well, I hope there was something new to learn for each of you. Coming back with another exciting topic in my next edition. Until then, have a good one.

With Gratitude,
Sak.