#HowIPM · 2026-02-17 · 1 min
Key moments - from our scoring
Substance score
23 / 100
Five dimensions, 20 points each
Michael, a VP of Product, challenges the common practice of loading roadmaps with feature lists. Instead, he advocates for a goals-and-outcomes-driven approach where roadmaps articulate the business and product objectives you want to achieve, while the backlog houses the specific features that ladder up to those goals. This separation creates clarity with stakeholders - management can align on desired outcomes and success metrics upfront, then trust the team to execute the right features to hit those targets. The approach keeps processes lean by preventing roadmap bloat from feature requests and maintains team focus on problem-solving rather than feature factories. This is particularly useful for product leaders managing multiple stakeholders with competing feature demands.
Goals and outcomes you want to achieve with your product, along with agreed-upon metrics to improve, should be on your roadmap rather than individual features.
Feature requests belong in your backlog, where they can be prioritized and executed in service of the goals and outcomes outlined on your roadmap.
It keeps the team focused on solving problems and outcomes rather than becoming a feature factory, while also making it easier to manage stakeholder expectations and keep processes lean.
Our reviewer’s read on each dimension, with quotes from the episode.
The episode contains a single, commonly-discussed product management principle (goals over features on roadmaps) with minimal expansion, evidence, or novel angles. The advice is straightforward and familiar to most experienced PMs, and no concrete examples or deeper exploration of implementation challenges are provided.
Instead of putting features on your roadmap those are in your backlog, you should put on your roadmap, um, goals and outcomes that you want to achieve
you should think about, uh, what goals and what achievements you want to achieve with your product and put that in there
The goals-over-features framework is a well-established best practice in product management (widely taught via INSPIRED, OKRs, and countless PM blogs). No contrarian perspective, first-principles reasoning, or counterintuitive insight is offered; this is textbook conventional wisdom presented without fresh angle.
Instead of putting features on your roadmap those are in your backlog, you should put on your roadmap, um, goals and outcomes that you want to achieve
The speaker holds a VP of Product title, which suggests relevant seniority, but the episode is so brief and surface-level that it's unclear whether this person has actually shipped major products or led scaled teams through outcome-driven planning. The lack of specific case studies or concrete wins leaves caliber ambiguous.
I'm a VP of product
I'm also a general manager of R and D
The episode contains no named examples, metrics, timelines, dollar figures, or concrete case studies. All advice is generic and abstracted (e.g., 'hundreds and hundreds of feature requests', 'goals and outcomes'). No specific product, company, or measurable outcome is cited.
So instead of having hundreds and hundreds of feature requests in there, you should think about, uh, what goals and what achievements you want to achieve
This is a monologue with no host-guest interaction, follow-ups, or dialogue. There are no sharp questions, pushback, or exploration of trade-offs. The format is a one-way declaration of advice with no conversational craft evident.
Instead of putting features on your roadmap those are in your backlog, you should put on your roadmap, um, goals and outcomes that you want to achieve
Computed from the transcript - who did the talking, and the words that came up most.
Your roadmap is not a feature list. If it is, you are solving the wrong problem. In this How I PM episode, Michael Ionita - CEO of LFG Solutions, VP of Product, and General Manager of R&D - shares a simple shift that changes how your entire team thinks about what they are building and why. Michael explains why features belong in the backlog and what should replace them on the roadmap. The distinction sounds small. The impact on team focus, stakeholder alignment, and execution speed is not. "You can keep your team focused on solving problems and not just implementing features." - Michael Ionita The full collection of 50 real-world strategies from practicing product leaders is available exclusively to members of The Product Way.
Transcribed and scored by The B2B Podcast Index.
Speaker A: Hey, I'm Michael. I'm a VP of product. I'm a Cuban salsa dancer. I'm m a general manager of R and D. I'm also a developer, technology lover, a guitar player, and I also play golf in order to get away from the computer. And this is how I pm. Instead of putting features on your roadmap those are in your backlog, you should put on your roadmap, um, goals and outcomes that you want to achieve. So instead of having hundreds and hundreds of feature requests in there, you should think about, uh, what goals and what achievements you want to achieve with your product and put that in there. Uh, talk to your management about it with your stakeholders, agree on goals, agree on metrics to improve, agree on outcomes, put that in your roadmap, prioritize that with your management, and then go to your backlog and put features that will account for those goals to make them happen. And this way you can keep, uh, your process, uh, lean and you can keep your team focused on solving problems and not just implementing features.
Other episodes covering the same guests and topics, from across The B2B Podcast Index.