A Feature-Based Roadmap Is Not Evil

Read on my website / Read time: 5 minutes

​

I stopped worrying about whether I or my teams were in a feature factory years ago.

My reasoning was simple:

If those features are delivering value to customers and growing the business, keep on keeping on.

If they’re not, then move to delivering things that do.

I get the concern - that we may be prioritizing quantity of features over quality, outputs over outcomes, short-term delivery over long-term value. That we risk becoming mindless task-doers instead of "strategic value drivers" or "product thinkers" (whatever those buzzwords mean).

I don't believe any product manager sets out to simply crank out features mindlessly.

But I also never lectured my product managers to "stop being a feature factory".

The connective tissue that's needed is how those features are moving the needle for customers and the business.

That connective tissue is built from two directions. One is from product leadership who has the responsibility to ensure every product manager understands not only the overall product strategy and the business priorities, but also how their work ties back to those.

Product leaders who don't do this and then lament how their PMs "don't understand the business" are failing in their duty.

The other side of that connective tissue comes from the product managers themselves. The best product managers don't solely rely on management to provide business context - they take the onus themselves to understand the commercial value of their products. And simply surveying users on their pains and pleasures isn't good enough.

So, the issue isn't the quantity of features we're releasing or whether our roadmap is feature-heavy or showing "market problems". What we need to be concerned with is ensuring the work we are doing is delivering outcomes for our customers and our business, and that our roadmap presentation communicates that effectively.

A feature factory story

During the height of the pandemic, when competitors threatened to steal $$millions in business from us, our team delivered over 60 enhancements to some of the largest US health systems while releasing an upgraded UI and launching 4 new products.

The result?

We didn’t lose a single customer account, improved our NPS score, and helped our customers impact thousands of patient’s lives.

Were we focused on pumping out a bunch of features - outputs - in a short amount of time?

Yes.

Were our roadmap presentations feature-heavy?

Yes.

Did they produce outcomes for our customers and the business?

You bet.

Was all that work aligned with our strategy?

Absolutely.

Maybe that's a feature factory. Maybe not. Honestly, I don't care. What I do care about is that heads down execution-focused work produced valuable outcomes for our customers and our business.

Mindset shift

Many product teams go through an evolution in terms of where their center of gravity lies.

At one company I worked at years ago, we had to move all our enterprise customers from the legacy platform to the new one we were building. We had over 300 features to migrate.

So, I made shipping features the center of gravity of the team.

Of course, there was a bigger picture: it was about moving millions in revenue from one platform to another while also winning new customers to hit our bookings goal for the year. And it was my responsibility to ensure my PMs understood that.

I had a very small and rather inexperienced product management team. Given these conditions, heads down execution was the priority of the day.

The mindset was:

As products, product teams, and product managers mature, the mindset shifts to where the center of gravity is around solving customer problems.

Product managers become better at customer discovery, tracking local metrics, and connecting the dots to the broader strategy.

The philosophy is: if we deliver value to customers, positive business results will automatically follow.

The mindset is:

There's still a gap, though. The gap is in truly understanding the commercial side and business model of products.

Mature product teams are outcome driven. The center of gravity is on driving business results.

The mindset is:

This is not as common. Most of the advice to product managers out there is about being customer-driven (and about technical skills). There's much less talk about the importance of being business and outcome-driven. (Hence, much of the angst from those outside of product management that PMs "don't understand the business".)

It takes commercially savvy product managers led by strong mentorship from product leadership for a product management team to be truly business outcome driven.

This gets us to roadmaps.

A feature based roadmap can work fine...

As long as it's clear how it's delivering outcomes.

There's lots of advice out there against feature-based roadmaps - they're not strategic, they're just a list of tasks, they're all about outputs, they communicate no value, etc.

The result is I work with so many product managers who work themselves in knots trying to craft roadmaps that look and feel "strategic" - only to then struggle and chafe against the demand for roadmap views that show timelines for features.

​
​Real World Example 1

Here's what the roadmap looked like for that migration effort I talked about earlier (confidential info replaced):

Yup. It was a Google Sheet. Our CTO loved it. Our co-founders and executives loved it. And our go-to-market teams loved it.

Sure, it was a list of targeted features per release. But they knew that, outside of the current release, it was subject to change. And sometimes we did have to change it, and, when we did, we communicated those changes. We had a biweekly meeting with them to review the roadmap and ensure alignment.

It worked because it showed very clearly:

• The use cases being targeted at each step and when we'd be able to fully support those use cases. (Outcomes.)
• When new customers would be fully supported on the new platform. (Read: new $bookings - outcomes.)
• When existing customers would be fully supported on the new platform and our progress toward having our customer base 100% upgrade ready. (Read: recognizing revenue on the new platform - outcomes.)
• What R&D was working on at any given time.

Prior to this, the strategy and goals had been made clear to everyone: build the new platform, transition our entire customer base to it, then sunset the old platform. Why? Because:

• More competitive product offering.
• Quicker customer implementations.
• Lower support and maintenance costs.
• Higher customer satisfaction.
• Improved product margins.

The feature-based roadmap above was simply the manifestation of the plan to deliver on this strategy.

​
​Real World Example 2

Here's a snapshot of a roadmap I presented every quarter to the executive committee at one company I worked at (confidential info replaced):

The ex-com loved it.

• They understood the value being delivered from these initiatives because of previous conversations we had had about these. We also had a set of slides before this one reinforcing those goals.
• This view was one they specifically requested. And executives will do that. Given the millions they were investing in this product, they wanted to know when they could expect our customers and partners to get the things we were working on.
• They understood the timelines were merely directional, because we - both PM and Eng - had done a good job communicating expectations and reinforcing them. We gave them transparent access to the detailed project plans behind each of these initiatives that had more specific dates, in case they were interested in that level of detail.

Here's a variation I presented that showed the type of revenue each feature contributed toward and how we were thinking of delivering them. This also generally aligned with how we were allocating capacity across our development execution efforts.

Other types of views

Here's a roadmap view we developed at one of my former companies that showed our plans for targeting different clinical use cases:

Here's one that laid out the go-to-market strategy for a new product we were launching:

Here's one that showed how key product initiatives were aligned to strategic goals. I like how go-to-market items like the turnkey sales demo and the new pricing plan are called out:

Here's one that presented a more operational view to the COO and CFO, who wanted to understand resourcing plans against major initiatives. This was important for annual budgeting discussions.

I don't know if these roadmaps would be considered "strategic" or "tactical". And I don't care. The fact is, all of these did the job for the products they represented, for the business they were in, and for the audiences they catered to.

My point here isn't to say you should copy-paste these approaches. (There is no one right way. Be wary of anyone who says so.) Nor am I saying it's fine to just blindly print out your Jira sprint plan or GANTT charts (shudder) with no context toward the broader strategy and goals. Roadmapping always begins with strategy.

My point is you need to know your audience and your organizational context, figure out what can work within that, and be pragmatic in how you represent your roadmap plans.

We need to start with an understanding of our product strategy and the business goals that matter. Then, as long as our roadmap is showing how we plan to make progress toward those goals in a way that our audience can consume, we're in good shape.

Takeaway

It's not important if some external coach or consultant or some expert on LinkedIn (including me) is convinced whether your roadmap is outcome-driven or whether they think you're in a feature factory. What matters is whether the folks in YOUR organization understand your plans to deliver the outcomes that are important for your business.

Create the roadmap view that communicates what you want to say about your product plans in a way that makes sense for your audience.

Sometimes that's Now > Next > Later.

Sometimes it's use cases and market opportunities.

Sometimes it's highlighting key customers or customer segments.

Sometimes it's a list of initiatives with time bars.

Sometimes it's a list of features planned across releases.

So, whether you’re cranking out 1 feature or 1000, the key is to communicate impact.

• Are those features driving purchase behavior?
• Are they encouraging loyalty and renewal?
• Do they boost growth and profitability?
• Do they deliver results that matter to customers and the business?

If yes, keep cranking out those features.

Focus on value and viability. Do that and the rest will sort itself out.

Keep to the basics.

If you want to get really serious about how to craft a roadmap that aligns company goals, stakeholders, and customer asks, consider joining the interest list for my upcoming cohort class, One Week Product Roadmap. You'll join me live to learn how I was able to transform a messy backlog of product asks into a coherent, actionable, outcome-driven product roadmap, and how you can use the same methods for your own product.

Right now, I'm looking to see if a group might be interested in a beta cohort so I can perfect the material. If you're interested, apply here to get on the waitlist and be the first to hear when enrollment opens.

That's all for this week.

Have a joyful week, and, if you can, make it joyful for someone else too.

cheers,
shardul

Shardul Mehta

I ❤️ product managers.

​Follow me on LinkedIn
​​Book a 1:1 Call​

Help out a colleague by forwarding this article to them.

​

Whenever you're ready, there are 3 ways I can help you:

1. One Week Product Roadmap: Join the rapidly growing interest list for my upcoming cohort course on product roadmapping. This comprehensive course will teach you the playbook I've used to create a product roadmap and bring key stakeholders along in just 7 days. Practical, real-world tested, and immediately applicable, with resources to help, live roadmap creation, and hands on exercises.

2. Customer Discovery Toolkit: Use the customer discovery tactics I've used to grow my products to $100M+. Get a complete playbook of practical and immediately-implementable strategies to help you get a running start on your customer conversations, including templates and scripts, and questions for different types of interviews, to develop your own game plan to extract maximum customer insights.

3. Promote​ ​your product to 3,600+ decision makers and influencers by sponsoring my newsletter.