I was talking to a Head of Product last month who described their backlog as “a graveyard with a search bar.” Over 400 items, accumulated over two years, all tagged as “ideas.” Some were multi-quarter platform bets. Some were CSS tweaks. A few were vague sentences pasted from a Slack thread. Every sprint planning session started with the same ritual: scroll through the list, argue about what matters, pick things based on whoever made the strongest case that week, and move on feeling slightly defeated. The backlog had become a performance of prioritization without any of the substance.

The root problem was structural. Every item sat at the same altitude, so every conversation about priority had to start from scratch. There was no hierarchy telling anyone whether they were comparing apples to oranges, or oranges to aircraft carriers.

The Flat Backlog Trap

Most Product teams inherit a flat backlog. It starts innocently enough: someone sets up a board or a spreadsheet, people add items, and the list grows. At 20 items, it works fine. By 200, it becomes unmanageable. Push past 500 and it’s a liability.

The structural failure here is subtle. A flat backlog implies that every item is the same type of thing, deserving the same type of evaluation. But “migrate to a new authentication provider” and “change the color of the onboarding button” are fundamentally different decisions. They operate at different altitudes. They require different stakeholders, different time horizons, different risk assessments, and different evidence thresholds. Putting them in the same list and asking a team to rank them against each other is like asking someone to choose between buying a house and buying lunch. Both are purchases. Both cost money. The comparison is still absurd.

What a flat backlog does to prioritization

When everything sits at the same level, teams default to one of three dysfunctional patterns.

Volume-based prioritization. The items with the most votes, the most customer requests, or the loudest internal advocates win. This rewards frequency of complaint over strategic importance. A minor UI friction that ten customers mention will outrank a foundational architecture decision that nobody outside Engineering even understands. Teams end up prioritizing at the idea level instead of the problem level, and the result is a roadmap that optimizes for noise.

Recency bias. Whatever was discussed most recently feels most important. The backlog becomes a queue, not a strategy tool. Items that were added six months ago decay in perceived relevance, regardless of their actual value. Teams lose track of strategic bets that need longer gestation periods, and the backlog slowly tilts toward quick fixes and reactive work.

False equivalence in scoring. Teams apply RICE or Impact vs. Effort scoring to every item equally, as though a “Reach” score for a platform migration means the same thing as “Reach” for a tooltip improvement. The math produces a number. The number creates an illusion of rigor. But the inputs are incommensurable, so the output is fiction dressed up as analysis. The Product Manager’s Guide to prioritization frameworks exists precisely because most frameworks fail when applied at the wrong altitude.

Flight Levels: A Thinking Model for Backlog Structure

The concept of “flight levels,” developed by Klaus Leopold as a thinking model for organizational improvement, offers a useful lens here. Leopold describes three altitudes at which work is managed: the strategic level (portfolio decisions about where to invest), the coordination level (how work flows across teams to deliver value), and the operational level (how individual teams execute). Each level has its own cadence, its own decision-makers, and its own definition of “done.”

What makes the flight levels model relevant to backlog structure is the core insight that different altitudes require different types of decisions and different feedback loops. When an organization tries to manage everything at a single altitude, strategic decisions get dragged into operational conversations, and tactical improvements get treated with the same ceremony as platform bets. The result is that nothing moves at the appropriate speed.

How this maps to backlogs

Most Product teams are already making decisions at multiple altitudes. They just lack the structure to formalize it. The Head of Product is thinking about which market segments to pursue next quarter. The Product Manager is thinking about which customer problem to tackle within a given initiative. The Engineering lead is thinking about which technical approach to take for a specific feature. All three of those decisions are valid and necessary. The problem arises when they all land in the same backlog column.

A backlog that operates at a single altitude forces everyone to context-switch constantly. One moment you’re debating whether to invest in a new pricing model; the next, someone’s asking about the relative priority of a button placement change. The strategic conversation gets interrupted by operational detail. The operational detail gets inflated into a strategic debate because someone in the room has strong feelings about buttons. And the coordination layer, the part where cross-team dependencies and initiative-level trade-offs actually live, gets skipped entirely.

The Initiative Layer Most Teams Are Missing

The fix is straightforward in concept: stop treating all backlog items as peers, and introduce a hierarchy that separates strategic bets from tactical experiments from operational improvements.

In practice, this means adding an initiative layer between objectives and ideas. An initiative represents a problem to solve or an outcome to pursue. It sits at the coordination altitude. It connects upward to a company objective or strategic theme, and downward to a collection of ideas, experiments, and user stories that represent possible ways to achieve it.

What changes when initiatives exist

When a team has an explicit initiative layer, three things shift.

Prioritization happens at the right altitude

Instead of comparing “replace the payment system” against “add a button to this page,” the team first prioritizes at the initiative level. “Reduce payment friction” competes against “Improve first-run onboarding” competes against “Support enterprise SSO requirements.” These are comparable decisions. They operate at similar altitudes, involve similar investment horizons, and can be evaluated against the same strategic objectives.Individual ideas then get prioritized within the context of their parent initiative. “Add a button to this page” competes against other ideas that might solve the same onboarding problem, not against a payment infrastructure overhaul. The comparison is meaningful because the items share a common frame of reference. This is the approach outlined in product roadmap best practices that emphasize working with high-level initiatives first and layering ideas in as solutions.

Context travels with the idea

When an idea is linked to an initiative, anyone evaluating it can immediately see why it exists. The initiative carries the problem statement, the strategic connection, the target outcome. A new team member looking at “add CSV export to the reports page” can trace it back to “Improve data accessibility for enterprise customers” and understand the context without a 30-minute onboarding conversation. The idea becomes self-documenting because the hierarchy provides the frame.

Saying “no” gets easier

One of the hardest parts of Product Management is saying no to a reasonable idea. When every idea exists in isolation, rejecting one feels personal or arbitrary. When ideas sit inside initiatives, and initiatives connect to objectives, the “no” has structural support. “This is a good idea, but it doesn’t serve any of our current initiatives” is a fundamentally different conversation than “I don’t think this is important.” The hierarchy absorbs the conflict that would otherwise land on the Product Manager’s judgment alone.

Why Delivery Tools Make This Worse

A significant contributor to the flat backlog problem is the tooling itself. Most teams manage their product thinking inside delivery tools like Jira, Trello, or Azure DevOps. These tools are excellent at tracking execution: tickets, sprints, story points, velocity. They are structurally terrible at managing the upstream decisions that determine what should be built in the first place.

A Jira backlog is, by design, a flat list of work items. You can add labels. Epics are available too. Stories nest under those epics.

But the tool’s fundamental model is oriented around delivery, and its hierarchy reflects that. Epics in Jira are containers for stories, grouped by scope of work. They are not strategic constructs. They don’t carry objectives, outcomes, or evidence. They’re buckets.

When teams try to use delivery tools for strategic product decisions, the tool’s structure pulls the conversation downward. Everything becomes a ticket. Everything needs a story point estimate. Strategic thinking gets compressed into ticket descriptions that nobody reads because the tool rewards moving cards across columns, not thinking deeply about whether those cards should exist at all. Rich Mironov has written extensively about how the tools teams use shape the decisions they make, and delivery tools consistently push teams toward output thinking rather than outcome thinking.

The two-backlog principle

The fix is to maintain two separate backlogs with a clear handoff between them. The product backlog (or opportunity backlog, as Marty Cagan calls it) is the space for ideas, experiments, hypotheses, and strategic possibilities. It lives upstream of delivery and is organized around problems to solve. The delivery backlog (sprint backlog, development backlog) is the space for committed work, organized around stories and tasks that are ready for Engineering to pick up.

ProdPad was designed around this exact separation. Ideas live in the idea management system, organized under initiatives that connect to roadmap objectives. When an idea is validated, scoped, and ready for development, it gets pushed to Jira or Azure DevOps as a fully spec’d ticket. The product backlog stays clean and strategic. The delivery backlog stays focused and actionable. Nobody is scrolling through 400 mixed-altitude items trying to figure out what matters.

The Scoring Trap

It’s worth lingering on why scoring frameworks fail in flat backlogs, because the failure mode is instructive.

Most prioritization frameworks assume that the items being scored are comparable. RICE scoring asks you to estimate Reach, Impact, Confidence, and Effort for each item. Those are reasonable dimensions. But “Reach” for a platform migration and “Reach” for a button change are measuring fundamentally different things. The platform migration affects every user who interacts with the payment flow over the next three years. The button change affects a subset of users on a single page for the next quarter. Both produce a number. The numbers are not comparable.

Teams that rely on scoring without hierarchy end up in one of two failure modes. Either they score everything with false precision and generate misleading rankings, or they abandon scoring entirely because the results never match their intuition. Both outcomes point to the same root cause: the items being scored operate at different altitudes, and no single scoring rubric can meaningfully span that range.

The better approach is to score within a level. Compare initiatives against other initiatives using strategic criteria (alignment to objectives, expected business impact, customer evidence). Compare ideas against other ideas within the same initiative using tactical criteria (feasibility, speed to learn, scope of change). The scoring becomes meaningful because the comparison is like-for-like.

What a Healthy Product Backlog Hierarchy Looks Like

A well-structured product backlog has three clearly separated levels, each with its own purpose and cadence.

The objective level

Objectives represent the strategic direction of the product. They answer “where are we going and why.” Cadence is quarterly or slower. Ownership sits with Product leadership, and they connect to company-wide business goals. In ProdPad, objectives sit at the top of the hierarchy and cascade into the roadmap.

The initiative level

Initiatives represent problems to solve or outcomes to achieve. They answer “what are we working on and what does success look like.” They sit on the Now-Next-Later roadmap as cards that communicate strategic intent without false delivery commitments. Each initiative connects upward to an objective and downward to a set of ideas.

The idea level

Ideas represent possible solutions, experiments, or features that could address the problem described by an initiative. They answer “how might we solve this.” They are the most granular layer, and they are the layer where most teams spend the majority of their time. The key structural principle is that ideas are never evaluated in isolation. They are always evaluated in the context of their parent initiative.

This three-level structure mirrors the flight levels concept: strategy at the top, coordination in the middle, operations at the bottom. Each level has its own prioritization criteria, its own decision-makers, and its own review cadence. When a stakeholder asks “why are we working on this,” the hierarchy provides the answer without anyone having to reconstruct the reasoning from memory.

The Backlog as a Decision System

The deeper point here is that a backlog is not a to-do list. A to-do list is a flat sequence of actions. A backlog is a decision system: a structured environment in which trade-offs are surfaced, evidence is weighed, and commitments are made at the appropriate altitude.

When the backlog lacks hierarchy, it degrades into a wishlist. Items accumulate without structure. Prioritization becomes a political exercise. Teams feel busy but strategically adrift. The common symptom is the sprint planning meeting where everyone argues about priority but nobody can articulate why any given item connects to the company’s strategic direction. The items are all at the same altitude, so the only available argument is personal conviction.

When the backlog has hierarchy, conversations change. Strategic debates happen at the initiative level, where they belong. Tactical debates happen at the idea level, scoped to a specific problem. The Product Manager stops being a human router, translating between altitudes in real-time, and starts being a decision-maker working within a system that supports structured trade-offs.The product backlog examples that actually work in practice all share this structural characteristic. They separate the “what problems are we solving” conversation from the “how are we solving them” conversation, and they give each conversation the right altitude, the right evidence, and the right decision-makers.

Hierarchy Is the Precondition for Good Prioritization

Every prioritization method, every scoring framework, every roadmapping process assumes that the items being evaluated are comparable. A flat backlog violates that assumption at a structural level. Teams can spend months debating which prioritization framework to use, when the actual problem is that their backlog lacks the hierarchy that would make any framework effective.

The fix is not a new scoring model. The fix is structure. Separate objectives from initiatives from ideas. Prioritize at each level using criteria appropriate to that altitude. Let the hierarchy do the work of creating meaningful comparisons instead of forcing Product Managers to mentally sort through mixed-altitude items in real-time.

Product teams that make this shift describe the same experience: prioritization stops feeling like a negotiation and starts feeling like a decision. The backlog becomes something the team trusts instead of something they dread. And the sprint planning meeting, finally, becomes a conversation about how to solve the problems the team has already agreed matter, rather than a rehash of which problems matter in the first place.

The post Your Backlog Has a Hierarchy Problem appeared first on ProdPad.

The problem is not execution. The problem is that any roadmap structured around time turns strategic intent into implicit promises, and the entire organization then optimizes around keeping those promises, rather than around building the right things. The 2026 State of B2B Product Management survey found that 41% of teams use quarterly time-based roadmaps, another 9% use sprint or monthly timelines, and 8% use specific date-driven delivery charts. Add those up: roughly 58% of the industry is still organizing product work around calendar slots. Only 27% have moved to Now-Next-Later. That means the vast majority of Product teams use formats that structurally produce broken commitments.

We invented the Now-Next-Later roadmap because Simon and I watched smart, capable Product teams get crushed by formats that reward false precision over strategic clarity. The argument here is simple: honesty scales better than certainty. Organizations that communicate what they know (and what they don’t) make better decisions, build more trust, and ship better products than organizations that perform confidence they do not have.

Why Time-Based Roadmaps Feel Comforting but Mislead

Time-based roadmaps are popular because they answer the question every executive wants answered: “When?” A Gantt chart with features slotted into Q2 and Q3 gives the illusion of control. A quarterly roadmap with big friendly columns gives the illusion of flexibility. Both look like a plan. Both feel like a commitment. And that is precisely the problem.

The quarterly roadmap: the friendliest trap

Gantt charts get a lot of criticism, and they deserve it. But the quarterly roadmap is the format that actually catches the most teams, because it looks so reasonable. Three or four columns. Big, open spaces. No exact dates. Just “Q1,” “Q2,” “Q3.” It even looks a bit like a Now-Next-Later if you squint.

The difference is structural and it matters enormously. A quarterly roadmap organizes work by when. A Now-Next-Later roadmap organizes work by priority order of problems to solve, sequenced by confidence level.A quarterly roadmap says “we plan to do this in Q2.” A Now-Next-Later roadmap says “this is the next most important problem, and we are currently exploring solutions.” One is a time commitment dressed in casual clothes. The other is a strategic statement about what matters and how certain we are about the path forward.

The moment an item sits in the Q2 column, every department reads it as “shipping in Q2.” It does not matter that the Product leader meant “we hope to start exploring this in Q2” or “this is roughly Q2-ish.” The column is a timebox, and timeboxes are read as deadlines. The quarterly roadmap inherits every pathology of the Gantt chart while looking modern enough to escape criticism.

The comfort of false precision

Any time-based roadmap provides the psychological comfort of certainty in an environment that is fundamentally uncertain. Nobody knows what they will learn three months from now. Nobody knows which customer need will suddenly become urgent, which technical assumption will collapse, or which market shift will change the calculus entirely.

Marty Cagan has written extensively about how roadmaps become de facto commitments the moment they are shared, regardless of the caveats stapled to the front page. It does not matter how many disclaimers you add. The moment a feature appears on a Q3 column (or a “Q3” section, or a “H2 2026” bucket), every department treats that time period as a ship date. Sales starts promising it. Marketing starts planning campaigns around it. Customer success starts telling unhappy customers to hold on. The disclaimer evaporates; the expectation remains.

Certainty theater erodes trust faster than honesty

The cruel irony of time-based roadmaps is that they should build trust, but they systematically destroy it. A Product leader who presents a quarterly roadmap in January and then revises it in April looks like they failed to deliver. A Product leader who communicates honestly about confidence levels and problem priorities from the start never creates the expectation that needs to be walked back.

This is a pattern that compounds over time. Each missed “deadline” (which was never a deadline, but the format made it look like one) erodes a little more credibility. After a few quarters, the rest of the organization stops trusting the roadmap entirely, and starts treating Product as a team that can’t keep promises. The problem was never the team. The problem was a format that manufactured promises nobody should have been making.

How Timeboxing Distorts Prioritization

The damage caused by time-based roadmaps runs deeper than missed expectations. When every item on a roadmap carries an implied delivery window (whether that window is a specific date or a quarter), the entire system of prioritization warps around protecting those windows, rather than around maximizing outcomes.

The vicious cycle of buffers and Parkinson’s Law

Every Product Manager who has worked with a time-based roadmap knows the buffer game. Estimates include padding because nobody wants to be the one who misses a quarterly target. That padding becomes the new baseline. And then Parkinson’s Law kicks in: work expands to fill the time given for its completion. Teams that receive generous estimates use all of them. The buffer disappears. Bigger buffers get added next time. And so the cycle spirals.

ProdPad’s own analysis of the vicious cycle of timeline roadmaps describes this pattern in detail: the added pressure of stacked delivery dates results in a cycle that makes it progressively harder to work in a lean way. Scope creeps in to fill allocated time. Procrastination sets in for anything with a far-off due date. And the teams that should be running fast, small experiments are instead locked into large, time-committed feature builds with no room for course correction.

Quarterly roadmaps are especially vulnerable to this. The quarter itself becomes the timebox. Teams fill the quarter. Work that could have shipped in six weeks stretches to twelve because the column said Q2, and Q2 runs until June.

Timeboxing kills discovery

The most insidious effect of time-based organization is that it crowds out discovery entirely. When a team has committed (even implicitly) to shipping Feature X by the end of Q2, there is no time or incentive to discover that Feature X might be the wrong solution to the problem. The timebox creates a gravitational pull toward output. Ship the thing. Hit the quarter. Move on.

This is how feature factories are born. Teams stop asking whether the work is the right work and start asking whether the work will be done on time. The roadmap becomes a to-do list, and the to-do list becomes the strategy. The original intent behind the feature (a customer problem, a business outcome) gets buried under the urgency of the calendar.

Backlog gravity distorts what gets built

There is another, quieter distortion that time-based roadmaps create. Items that have been on the roadmap the longest accumulate organizational weight. Stakeholders have been told about them. Customers have been promised them. They start rising through the backlog not because they are the highest-impact work, but because they have been there the longest. I call this “backlog gravity,” and it is one of the most reliable ways to ensure that a Product team is building yesterday’s priorities instead of today’s.

A quarterly roadmap makes this worse because items that slip from Q1 to Q2 feel like they are “overdue.” They acquire urgency from their failure to ship on schedule, not from any fresh assessment of their strategic value. The team spends the next quarter paying down roadmap debt rather than working on the highest-impact problems.A lean, outcome-based roadmap disrupts this pattern because items are framed as problems to solve and strategic bets to make, rather than as features owed to someone on a schedule. When an item on a Now-Next-Later roadmap no longer serves an active OKR, it gets deprioritized or dropped, regardless of how long it has been on the list. The roadmap serves the strategy, rather than the other way around.

Priority Order of Problems, Not Calendar Slots

The core distinction between Now-Next-Later and every time-based format (Gantt, quarterly, monthly, sprint-aligned) is the organizing principle. Time-based roadmaps organize work by when it will happen. Now-Next-Later organizes work by which problems matter most, sequenced by how much we know about them. That difference sounds subtle. It changes everything.

What the columns actually mean

Now-Next-Later columns are not disguised quarters. They are confidence horizons.

Now contains the problems the team is actively solving. These initiatives are validated, scoped, and in progress. The team has done enough discovery to be confident they are working on the right problem with a viable approach. If there are genuine external deadlines (a regulatory window, a contractual obligation), they attach here, to specific initiatives, because this is where certainty lives.

Next contains the problems the team is preparing to solve. The problem is well-defined. The team is exploring solutions, running discovery, and testing assumptions. They are not yet ready to commit to a specific approach, which is exactly why these items should not carry a delivery date.

Later contains the strategic bets the team believes will matter, but that need significantly more discovery before they are ready to move forward. These are the problems on the horizon. They might shift. They might get dropped entirely if the team learns something that changes the calculus. Putting these in a Q3 or Q4 column would be dishonest, because nobody has enough information to make that call yet.

The organizing question is never “what quarter does this fall in?” The organizing question is “how important is this problem, and how much do we know about solving it?” That question produces a fundamentally different roadmap, one that invites conversation about confidence and evidence rather than conversation about dates.

Why this matters for how teams work

When the roadmap is organized by problem priority rather than time, the team’s daily work changes. There is no “Q2 crunch” because there is no Q2 column creating an artificial deadline. Items move from Later to Next to Now as discovery progresses and confidence increases, not because a calendar date is approaching. The pace of the work is determined by learning, not by the quarter boundary.

This also changes how teams handle surprises. When a new, urgent customer problem surfaces, a time-based roadmap creates a crisis: something in the current quarter has to get bumped, and that bump cascades into the next quarter, and the quarter after that. The entire schedule unravels. On a Now-Next-Later roadmap, the team re-evaluates priorities, moves the new problem into Now if it warrants it, and adjusts Next accordingly. No cascading schedule changes. No apologetic email to stakeholders explaining why Q2 is “slipping.” The roadmap reflects reality because it was always designed to.

Using Dates as Constraints, Not Commitments

The argument against time-based roadmaps is sometimes misread as an argument against all dates, everywhere, in all contexts. That is not the point. Dates are valuable when they represent genuine external constraints. They become destructive when they are the structural backbone of the entire roadmap.

Where dates belong

Some dates are real. A regulatory deadline is real. A compliance window is real. A contractual obligation tied to a customer renewal is real. An annual conference where a product capability needs to be demonstrated is real. These are compelling constraints, and they deserve to be tracked explicitly.

The difference between a roadmap and a release plan is critical here. The roadmap is a strategic communication tool. It describes the problems you are solving, in what order, and why. The release plan is a tactical delivery schedule. It tracks the dates, dependencies, and resources for work that has been scoped, validated, and committed to. The two documents serve different audiences, answer different questions, and should live in different places.

When teams conflate these two documents (as every time-based roadmap format does, whether by design or by implication), every strategic intent inherits a delivery window, and every delivery window inherits strategic significance. The result is a document that is too rigid to be a good strategy and too vague to be a good plan.

How Now-Next-Later handles real deadlines

In a Now-Next-Later roadmap, genuine time constraints attach to the OKR or the initiative, not to the format itself. If a regulatory deadline requires a capability by a specific date, that deadline lives on the objective. The initiative linked to it sits in the Now column because it is validated, scoped, and actively in progress. The date is visible. The constraint is respected. And the rest of the roadmap remains free to flex as learning unfolds.This is the structure Marty Cagan calls high-integrity commitments: commitments made only after the team has done enough discovery to understand what they are actually committing to. In ProdPad, this works through the OKR-to-roadmap connection, where every initiative traces back to a business objective, and the objective carries the commitment. The roadmap shows the plan. The OKR carries the accountability. The horizon shows honest certainty.

The dual-direction view for commercial stakeholders

One of the most common objections to dropping time-based roadmaps comes from commercial teams. Sales leaders, business development managers, and account executives want to know when features will ship because they have made promises of their own. This is a legitimate concern, and ignoring it is how Product teams end up isolated from the rest of the business.

The answer is a dual-direction view. Looking at any initiative on the roadmap, a commercial stakeholder can see which business outcomes it contributes to. Looking at any OKR, they can see every initiative that is meant to move the needle, and where each one sits on the horizon. If all the initiatives supporting a year-end revenue target are sitting in Later, that is a visible, actionable signal to course-correct. No status meeting required.

This is a fundamentally different conversation than “When will Feature X ship?” The question becomes “Are we on track to hit our target?” That is a better question with a more useful answer.

What Leaders Should Ask Instead of “When”

The question “When will this ship?” feels natural. It feels like good governance. It feels like holding the team accountable. In practice, it is a question that optimizes for the wrong thing. It optimizes for delivery windows rather than business outcomes. And it trains Product teams to communicate in a language of certainty they do not possess.

From “when” to “what outcome”

The most effective Product leaders I have worked with have retrained themselves (and their stakeholders) to ask different questions. Instead of “When will we have the new onboarding flow?”, they ask “What are we doing to reduce churn in the first 30 days?” The first question drives toward a date. The second drives toward a goal with multiple possible paths.

This shift has structural consequences. When the goal is a date (or a quarter), the team optimizes for shipping the thing as specified. When the goal is an outcome, the team has permission to experiment, learn, and change direction if the first approach does not work. They might discover that a simpler change to the existing onboarding flow moves the metric more than a ground-up rebuild. They might learn that the churn problem is actually a pricing problem, not a UX problem. None of these discoveries are possible if the team is locked into a feature in a quarterly column.

Five questions that replace “when”

Product leaders and executives who want to govern effectively without creating a culture of false precision can start with five replacement questions.

“Which business outcome does this serve?”

Every initiative on the roadmap should connect to an OKR or strategic objective. If it does not, it probably should not be on the roadmap. This question forces specificity: not “we’re building search improvements” but “we’re improving time-to-value for new enterprise users, measured by a reduction in support tickets in the first 14 days.”

“Where does this sit on the horizon, and why?”

The Now-Next-Later horizon communicates confidence level and problem priority, not delivery date. An item in Now is validated, scoped, and in active development. A Next item has a clear problem definition and the team is exploring solutions. A Later item is a strategic bet that needs more discovery. Asking where something sits (and why) gives leaders a realistic picture of certainty without forcing false precision.

“What have we learned so far?”

This question centers the conversation on discovery and evidence. It invites the team to share what customer research, experiments, or data have informed the current plan. It also creates a natural opening to change direction: if what the team has learned suggests a different approach, the conversation supports that pivot rather than punishing it.

“What would need to be true for this to move to Now?”

This is a forward-looking question that surfaces blockers, dependencies, and risks without demanding a date. It might reveal that a Later initiative needs a technical spike, or that a Next initiative is blocked on a decision from leadership. It makes the path forward visible without creating a time-based promise.

“Are we on track for the objective, even if the plan has changed?”

This is the question that replaces quarterly roadmap reviews. Instead of checking whether the features were shipped on schedule, it checks whether the business outcomes are on track. The features are a means to an end. If a team has changed its plan three times but is hitting the Key Results, that is a success. If a team has shipped everything on the original plan and the Key Results have not moved, that is a failure, regardless of how punctual they were.

The System Dynamics Behind Honest Roadmaps

Understanding why time-based roadmaps persist requires looking at the system, not the people. Nobody is trying to mislead anyone. The format itself creates incentives that drive behavior in predictable, damaging directions.

How the format shapes the conversation

A time-based roadmap assumes a level of certainty that decreases the further out you look. But the visual format does not degrade. A feature in Q4 looks just as solid on the quarterly roadmap as a feature in the current sprint. There is no visual cue that says “we are 80% confident about this one and 15% confident about that one.” The format treats all items as equally certain. Gantt charts inherited this from manufacturing and construction, where scope is fixed and unknowns are small. Quarterly roadmaps inherited it from Gantt charts, swapping months for quarters but preserving the same structural assumption. Product development is the opposite environment: scope is flexible, and unknowns are large.

Now-Next-Later encodes uncertainty directly into the structure. Items move from Later (fuzzy, exploratory) to Next (problem defined, solution being explored) to Now (validated, in active development). Stakeholders can read the confidence level from the column position. There is no ambiguity about which items are commitments and which are bets. And because the columns represent problem priority rather than time, the question the roadmap answers shifts from “what ships when” to “what matters most and what are we doing about it.”

Why organizations resist the switch

The shift away from time-based roadmaps requires more than a new template. It requires a change in how the organization talks about product work. Commercial teams need to learn to sell around outcomes rather than features. Executives need to learn to evaluate progress by Key Results rather than ship dates. Customer-facing teams need to learn to set expectations around problems being solved rather than specific functionality arriving in a specific quarter.

This is cultural change, and cultural change is hard. The time-based roadmap persists not because it is good, but because everyone in the organization has adapted their workflows around it. Sales pipelines are built on feature promises. Board decks are structured around quarterly delivery milestones. Compensation plans are tied to shipping dates. Unwinding all of that takes deliberate effort and sustained leadership.

The organizations that do make the shift consistently report two things: they deliver faster (because teams are not wasting time on buffer games and estimate theater) and they build better products (because teams have the flexibility to follow evidence rather than follow the plan).

Honesty as Competitive Advantage

There is a reason why more product organizations are moving toward outcome-based roadmapping formats like Now-Next-Later, and it is not because it is trendy. It is because the organizations that communicate honestly about uncertainty make better decisions.

An honest roadmap does not mean a vague roadmap. Now-Next-Later is extremely specific about what is being worked on now, what is being explored next, and what is on the strategic horizon for later. It is specific about the outcomes each initiative targets, the evidence supporting the approach, and the confidence level of the team. It just refuses to attach false precision (or false quarterly boundaries) where they do not belong.

Teresa Torres has publicly stated she is “a fan of Janna Bastow’s Now-Next-Later roadmaps.” The reason is straightforward: continuous discovery requires a roadmap format that supports changing direction when you learn something new. A time-based roadmap punishes learning. An outcome-based roadmap rewards it.

The Product leaders who build the most trust with their organizations are the ones who say “here is what we know, here is what we are exploring, and here is what we are not yet certain about” rather than “here is what we will ship in Q3.” That honesty, communicated well and backed by a clear strategic framework, earns more credibility than a hundred perfectly formatted Gantt charts or quarterly grids.

Product teams exist to solve problems in priority order, driven by evidence and connected to strategic outcomes. They do not exist to fulfill a delivery schedule written before anyone understood the problem. The roadmap should reflect that reality. When it does, everything downstream gets better: prioritization, discovery, stakeholder trust, team morale, and the quality of the product itself.

The best roadmap is the one that tells the truth about what matters, how much you know, and what you are doing about it. The truth scales better than any calendar ever will.

The post Honesty Scales Better Than Certainty: Why Time-Based Roadmaps Are Promises You Can’t Keep appeared first on ProdPad.

This matters because voting portals are everywhere. Tools like Canny, UserVoice, and Productboard have made it trivially easy to spin up a board and start collecting votes. The appeal is obvious, especially for teams drowning in Slack messages, support tickets, and sales call notes. A voting portal promises to cut through the noise. The problem is that it introduces a different kind of noise, one that’s harder to detect because it comes wrapped in numbers.

The Visibility Trap: Position Bias in Feedback Portals

Every voting portal has a default sort order. Usually that’s “most popular” or “most votes.” The items at the top of the list get more eyeballs, and more eyeballs produce more votes. Items lower on the list get fewer views and therefore fewer votes, regardless of how important they are. This is a classic position bias effect, and it compounds over time.

Early movers accumulate disproportionate support

An idea submitted in the first month of a portal’s existence has a structural advantage over one submitted six months later. The early idea has been accruing votes passively while newer, potentially better ideas never get the same exposure. Voting portals reward persistence of visibility, not quality of insight. We wrote about this problem on the ProdPad blog years ago, calling it the Pareto principle outcome that no Product Manager wants: ideas at the top get more votes simply because they’re more visible, while potentially great ideas at the bottom get pushed further down.

Existing framing constrains new thinking

When customers arrive at a voting board, they scan what’s already there. If someone has already articulated a feature request, other customers tend to pile onto that request rather than articulate their own version of the underlying problem. The board becomes a collection of specific solution proposals rather than a map of customer pain. This is a well-documented phenomenon in group decision-making research, and it’s exactly the kind of anchoring effect that good Product discovery is designed to counteract.

Who Actually Votes (And Who Doesn’t)

The composition of your voter pool is skewed from day one. Understanding who self-selects into voting, and who never participates, is essential to interpreting any signal the portal produces.

Power users dominate the conversation

The customers most likely to visit a feedback portal regularly are power users: people deeply embedded in your product who have strong opinions about what should change. These users are valuable, but they represent a specific segment with specific needs. When their voices dominate the board, the resulting data skews toward the needs of users who have already figured out your product, at the expense of users who are struggling with it.

This is a version of survivorship bias applied to Product feedback. You’re hearing from the survivors (people who stuck around long enough to become power users) and missing the people who churned, downgraded, or never activated in the first place. The customers who found your product confusing, who couldn’t get past onboarding, who quietly left after a trial period: they’re not logging into your feedback portal to vote. Their absence from the data is a signal, but a voting board can’t capture it.

The vocal minority shapes perception

Research on online feedback systems consistently shows that the people most motivated to participate hold extreme opinions, either very positive or very negative. The moderately satisfied majority tends to stay quiet. In a voting portal, this means the ideas that surface don’t represent what most of your customers care about; they represent what your most vocal segment cares about. That distinction matters enormously when you’re deciding where to invest Engineering time.

Revenue weighting is absent by default

A vote from a free-tier user and a vote from your largest enterprise account look identical on a voting board. Most portals don’t attach any business context to votes. So a feature request from 200 free users can outweigh a request from 5 enterprise customers who collectively represent 40% of your ARR. The numbers say one thing; the business reality says another.

Anchoring to Solutions Instead of Problems

The deepest flaw in feedback voting is structural, not statistical. Voting portals are built to collect and rank solution proposals (“add a dark mode,” “support CSV export,” “build a Salesforce integration”). Customers describe what they want built. The portal counts how many people agree with that description. And the Product team uses those counts to decide what to build.

The problem underneath the request stays hidden

Teresa Torres, the product discovery coach and author of Continuous Discovery Habits, has written extensively about the importance of separating the opportunity space from the solution space. When a customer says “I need a CSV export,” there’s an underlying job they’re trying to do: maybe they need to share data with a stakeholder who doesn’t have access to the product, or they need to combine data from multiple sources in a spreadsheet. Five different customers might vote for “CSV export” for five different reasons, and a different solution might serve all five of those reasons better.

A voting board collapses all of that context into a single number. Twenty votes for CSV export. Those twenty people might have the same problem, or they might have five different problems that all led them to the same proposed solution. The voting portal can’t tell you the difference. And the moment you treat “most votes” as a prioritization input, you’ve optimized for the wrong level of abstraction.

Problem-level prioritization produces better outcomes

I’ve written before about why the best Product teams prioritize at the problem level, not the idea level. Idea-level prioritization (which is what voting portals produce) is inherently bottom-up. It starts from a pool of proposed solutions and tries to figure out which solution to build next. Problem-level prioritization starts from strategic objectives and works down to which problems, when solved, would move the needle on those objectives. The right ideas and experiments to work on then fall into place within each problem space.

This is a fundamentally different approach, and it requires a fundamentally different relationship with customer feedback. Instead of asking “which feature do the most people want?” you’re asking “which customer problem, if solved, creates the most value for the business?” Those two questions produce very different roadmaps.

The Bandwagon Effect and Social Proof Distortion

When vote counts are publicly visible (as they are on most portals by default), the numbers themselves influence future voting behavior. An idea with 500 votes looks important. A new visitor to the board sees that number and thinks, “Other people clearly want this, so it must matter.” They add their vote. The rich get richer.

Visible vote counts create momentum, not insight

This is a well-documented bandwagon effect. In political polling, researchers have long understood that publishing poll results influences subsequent voter behavior. The same dynamic plays out in feature voting. The number beside an item becomes a social signal, and customers respond to that signal rather than making an independent judgment about what they personally need.

Some tools have started offering options to hide vote counts or randomize the display order of items. These are steps in the right direction, but on most portals they’re optional settings layered on top of a system that was designed around public ranking. The underlying architecture still encourages customers to browse, compare, and pile on. Unless the entire portal experience is rebuilt around removing those dynamics (randomized display, limited item sets, hidden votes and comments), the biases persist in subtler forms.

Competitive intelligence is a free bonus for rivals

There’s also an underappreciated external risk. Public voting portals are a gift to your competitors. Jason Evanish has pointed out that user forums and voting boards are fertile ground for competitive intelligence. Your competitors can see exactly what your customers are unhappy about, what they’re requesting, and how many of them care about each gap. You’re effectively publishing a prioritized list of your product’s shortcomings for anyone to read.

The “But When?” Trap: Voting Boards Create Implicit Promises

When you publish a voting board, you’re sending a message to customers: “We want to hear what you think we should build.” Customers take that message seriously. They invest time articulating requests, they upvote things they care about, and then they wait. When the most-voted item doesn’t appear on the roadmap, customers feel ignored, and they’re right to feel that way. The portal set an implicit expectation that votes would influence decisions.

The expectation gap erodes trust

Product leaders end up in an impossible position. If they follow the votes, they’re building a product shaped by the biases described above. If they don’t follow the votes, customers who participated feel betrayed. Rich Mironov, product management coach and author of The Art of Product Management, has written at length about how product teams need to maintain strategic autonomy while staying responsive to customer input. A voting portal makes that balance harder, not easier, because it creates a public ledger of expectations that the Product team now has to manage.

Public comments turn portals into pressure campaigns

When customers can see each other’s votes, comments, and frustrations, a feedback portal stops functioning as an input channel and starts functioning as a public forum. Pile-ons happen. A frustrated customer writes a long comment about a missing feature, other customers add “+1” replies, and suddenly the Product team is managing a visible thread of public dissatisfaction.

That pressure, however understandable from the customer’s perspective, introduces a political bias into prioritization. The team feels compelled to respond to whatever is generating the most noise on the portal, even when the noise doesn’t reflect the most valuable use of their time. Sometimes there are very good reasons not to build what customers are asking for, whether because of technical constraints, strategic direction, or because the proposed solution wouldn’t actually solve the underlying problem. Public pressure makes it harder to hold that line.

The related tension shows up in roadmap communication, too. I invented the Now-Next-Later roadmap specifically to move away from date-based commitments and toward strategic time horizons. A voting board pulls in the opposite direction. It says: “Here’s what people want, ranked by demand. When are you going to deliver it?” That framing is the exact kind of commitment-trap that outcome-driven Product teams are trying to escape.

What Good Feedback Systems Actually Do

Listing the biases inherent in voting doesn’t mean customer feedback should be ignored. The opposite is true. Customer feedback is one of the most valuable inputs a Product team has. The question is how to collect, organize, and interpret it in ways that minimize distortion and maximize strategic value.

Capture context, not just requests

Every piece of feedback is more useful when it comes with context: who said it, what they were trying to do, what segment they belong to, how much revenue they represent, and what problem they’re actually experiencing. When feedback flows in from support tickets, sales calls, Slack messages, NPS responses, and direct conversations, each piece carries some of that context naturally. A good feedback system preserves and surfaces that context rather than stripping it away.

ProdPad’s approach to customer feedback management is designed around this principle. Feedback from any channel, including Intercom, Slack, Salesforce, email, and branded feedback portals, gets linked to the idea or initiative it relates to, tagged with customer and segment data, and connected to the strategic objectives it maps against. The point is to turn qualitative signals into evidence that can inform prioritization, not to reduce feedback to a single number.

Design the portal to remove bias, not add it

ProdPad’s Customer Feedback Portal was built specifically to avoid every bias described in this article. The design choices are deliberate.

Ideas are hidden from the portal by default. The Product team selects which ideas to promote to the portal when they’re ready for customer input. This means customers aren’t browsing the entire backlog and piling onto whatever catches their eye first. The team controls what gets tested.

When a customer visits the portal, they see a random selection of up to nine ideas from the promoted pool. The selection changes, so no single idea sits at the top of the list accumulating votes through position bias. And because each visitor sees a different set, the system produces an unbiased aggregate signal over time rather than a popularity ranking distorted by display order. The goal is not to get every customer to evaluate the entire backlog. It’s to get an honest, unbiased sense check from the customers who show up.

Customers can upvote ideas and leave comments (which get captured in ProdPad as feedback), but those votes and comments are not visible to other customers. This eliminates the bandwagon effect entirely. No customer can see how many other people voted for an idea, so every response is independent. And because comments stay private, the portal never becomes a public discussion forum where customers air grievances or coordinate pressure campaigns about what they think is wrong with the product.

This design reflects a specific philosophy: feedback portals should help the Product team gather signal, not create a public popularity contest that constrains their decision-making.

Link feedback to problems, not solutions

When feedback is connected to ideas (which are themselves connected to roadmap initiatives and OKRs), the Product team can see patterns across customers and segments. Ten customers might each articulate a different feature request that all trace back to the same underlying problem. A voting board would show ten separate items with one vote each. A well-structured feedback system would show one problem area with ten supporting data points, a much more useful signal for prioritization.

Use feedback volume as one input among many

The number of customers mentioning a particular problem is useful context. So is the revenue those customers represent, the strategic importance of the segment they belong to, and the degree to which solving their problem advances the company’s objectives. Impact-versus-effort prioritization keeps the conversation grounded in business value rather than raw demand. The final decision is still a judgment call, made by humans in the context of strategy and evidence. Itamar Gilad, creator of the GIST framework and author of Evidence-Guided, has advocated for treating product decisions as bets that should be tested, not as commitments to be delivered. That framing is much harder to maintain when a voting board is telling you exactly what to build.

The Organizational Dynamics That Make Voting Boards Stick

Knowing that voting boards introduce bias doesn’t automatically make them easy to remove. They persist because they serve organizational needs that go beyond product prioritization.

They give non-Product stakeholders a sense of control

Sales teams love voting boards because they can point to vote counts to justify feature requests. Executives love them because they provide a simple narrative: “Customers want X, so we should build X.” The simplicity is the appeal. A nuanced approach to feedback interpretation requires more trust in the Product team and more patience with ambiguity. Voting boards reduce that ambiguity to a number, and numbers feel safe.

The 2026 State of B2B Product Management report found that 40% of respondents ranked poor prioritization and decision-making discipline as a serious problem, with one respondent noting that leadership routinely overrides structured frameworks in favor of reactive decision-making. Voting boards feed directly into that pattern. They give anyone in the organization ammunition to challenge Product decisions by pointing to “what customers want,” even when the underlying data is distorted.

Removing a voting board requires replacing the function it serves

You can’t just turn off a voting portal and tell stakeholders to trust the Product team. You need to replace the visibility and accountability that the portal provided. That means giving stakeholders access to a transparent prioritization process, a roadmap they can understand, and a feedback system they can see working. When stakeholders can observe feedback flowing into ideas, ideas being evaluated against objectives, and initiatives appearing on a Now-Next-Later roadmap connected to business goals, the voting board becomes redundant. The system itself provides the transparency that the portal was supposed to deliver.

Voting Boards Measure Demand, Not Value

The most important distinction in all of this is between demand and value. A voting board measures demand: how many people asked for a thing. Value is a different calculation entirely. Value accounts for which customers are asking, what strategic objective the request maps to, how much effort the solution requires, what the opportunity cost of building it is, and whether the proposed solution actually addresses the underlying problem.

Product teams that build decision confidence based on evidence and strategy don’t need a popularity ranking to tell them what to build. They need a system that captures customer pain, preserves context, connects it to business goals, and supports the kind of judgment calls that good Product leadership requires. Scoring models like RICE have their uses as conversation starters, but the best teams use scoring to create a stake in the ground and judgment to make the final call.

The uncomfortable truth about feedback voting is that it optimizes for a metric (vote count) that has a weak relationship to the outcome most teams care about (building the right product for the right customers). The biases aren’t bugs in the system. They are the system. Position bias, survivorship bias, the bandwagon effect, and the conflation of solutions with problems are all predictable consequences of asking customers to vote on features. The alternative is harder. It requires capturing feedback from diverse channels, preserving the context around each piece, connecting that feedback to strategic objectives, and making prioritization decisions that balance customer input with business judgment. That’s more work than sorting a list by vote count. It’s also how products get built that customers actually need.

The post Why Feedback Voting Introduces Bias Into Your Product Decisions appeared first on ProdPad.

Bottom-up roadmaps are seductive because they feel grounded. They come from real inputs: customer feedback, engineering constraints, sales requests. They avoid the hand-wavy aspirationalism of top-down strategy decks that never survive contact with reality. And they ship. Teams running bottom-up roadmaps can point to velocity, throughput, and a satisfying cadence of releases. The problem is that none of those metrics tell you whether the product is heading in the right direction.

Why Teams Fall Into Bottom-Up Planning

Bottom-up planning rarely starts as a conscious choice. It’s what happens when the conditions for top-down planning aren’t in place. The company hasn’t articulated a product strategy. The OKRs are vague or disconnected from product work. Leadership changes direction every quarter. Or the Product team is so deep in delivery that stepping back to reframe feels like a luxury they can’t afford.

The strategy vacuum

When product strategy is absent, unclear, or changes too frequently to be useful, teams default to what they can control: the backlog. They focus on the queue of known work because it provides structure and predictability. Melissa Perri described this dynamic thoroughly in her exploration of the build trap, where organizations measure success by features shipped rather than problems solved. The backlog becomes the de facto strategy, and “what should we build next” gets answered by “what’s at the top of the list” rather than “what will move us closer to our objectives.”

The tooling trap

The tools teams use shape how they think. When the primary planning surface is a delivery tool like Jira, the unit of work becomes the ticket. Tickets are concrete: they have descriptions, acceptance criteria, story points. They feel real in a way that strategic initiatives don’t. But tickets don’t carry strategic context. They don’t explain why something matters, what objective it serves, or what outcome it should produce. Over time, the team starts planning in ticket-shaped chunks, and the roadmap becomes a prioritized list of things to build rather than a plan for outcomes to achieve. John Cutler has written extensively about how teams can get stuck optimizing for output velocity instead of value creation velocity, building a well-oiled feature factory that ships efficiently without knowing whether any of it matters.

The comfort of consensus

Bottom-up planning is also politically easier. When the roadmap is assembled from things people have already agreed to, there’s less conflict. Nobody has to make the hard call about what to deprioritize. Nobody has to tell a stakeholder that their pet project doesn’t align with the strategy, because there is no strategy to point to. The backlog provides cover: “We’re working through the prioritized list.” It avoids the difficult conversations that real strategic planning demands.

How Backlog Gravity Replaces Decision-Making

Once a team settles into bottom-up planning, a specific pattern emerges that’s worth naming: backlog gravity. This is the tendency for items that have been in the backlog longest, or that have accumulated the most votes, requests, or internal advocacy, to rise to the top simply by virtue of their persistence. Backlog gravity replaces intentional decision-making with inertia.

The accumulation effect

In any active product, the backlog grows faster than the team can process it. Customer requests pile up. Internal stakeholders add ideas. Engineers flag technical improvements. Each item individually makes sense, and many are genuinely useful. But without a strategic filter, the backlog becomes an undifferentiated mass where the loudest signal wins. Rich Mironov has pointed out the absurdity of trying to do ROI analysis on hundreds or thousands of backlog items, noting that it makes no sense unless anchored in a clear business model and strategy. The exercise itself becomes a time sink that masquerades as rigor.

Momentum masquerading as direction

Teams caught in backlog gravity often feel productive. They’re shipping regularly, closing tickets, and responding to customer requests. But strip away the velocity metrics and ask a harder question: if you removed the backlog entirely and started fresh, knowing only your company’s strategic objectives, would you rebuild the same list? Most teams would not. That gap between “what we’re building” and “what we should be building” is the cost of bottom-up planning, and it compounds over time.

The slow erosion of intent

The most dangerous aspect of backlog gravity is how gradually it erodes strategic intent. A team doesn’t wake up one morning and decide to abandon their product strategy. They just stop referencing it. Sprint planning becomes a conversation about what’s next in the queue, not about which objective needs attention. Roadmap reviews become status updates on delivery, not discussions about direction. The roadmap stops being a strategy artifact and starts being a project plan, and nobody notices because the cadence of work never slows down.

The Difference Between Initiative-Led and Feature-Led Planning

The structural difference between a bottom-up roadmap and a strategy-aligned roadmap comes down to the unit of planning. Bottom-up roadmaps plan in features. Strategy-aligned roadmaps plan in initiatives.

Features describe solutions; initiatives describe problems

A feature is a specific piece of functionality: “Add SSO support,” “Build a CSV export,” “Redesign the onboarding flow.” A feature assumes the solution is known. An initiative describes the problem or opportunity the team is pursuing: “Reduce friction for enterprise buyers,” “Make it easier for teams to extract insights from their data,” “Accelerate time-to-value for new users.” Initiatives leave room for the team to explore different solutions, test hypotheses, and iterate toward the best outcome.

This distinction matters enormously for how the roadmap functions. A theme-based roadmap built around initiatives communicates what the team is trying to achieve and why. A feature-based roadmap communicates what the team is going to build, with the “why” implied (or missing entirely). Stakeholders looking at a feature roadmap will judge it on whether their favorite feature is included. Stakeholders looking at an initiative roadmap will engage with whether the right problems are being prioritized.

Initiative-led planning creates strategic flexibility

When the roadmap is built around initiatives, the team retains the ability to change course as they learn. If the first approach to “reduce enterprise onboarding friction” doesn’t work, the initiative persists on the roadmap while the specific solution changes. The strategic commitment remains stable even as the tactical execution evolves. This is the core principle behind outcome-based roadmapping, where the roadmap declares the outcomes the team is pursuing, and the specific features become hypotheses to be validated, not promises to be delivered.

Feature-led planning locks teams into commitments prematurely

A feature-based roadmap, by contrast, locks the team into specific solutions before they’ve been validated. Changing direction means removing items from the roadmap, which triggers stakeholder anxiety (“You said you were building SSO this quarter”). The team ends up defending the plan rather than adapting it, and the sunk cost of having communicated the feature makes it harder to pivot even when evidence suggests a different approach would be more valuable.

Reintroducing Objectives Without Boiling the Ocean

For teams that have been running bottom-up for a while, the prospect of “adding strategy” can feel paralyzing. The backlog is enormous. There are commitments in flight. Stakeholders have expectations. Stopping everything to define a product strategy and build a new roadmap from scratch isn’t realistic. The good news: it doesn’t have to happen all at once.

Start with the work already in progress

The simplest entry point is to look at what’s currently on the roadmap and ask: what objective does this serve? In many cases, the answer exists but has never been made explicit. The team is working on improving search performance because they know activation rates are too low. They’re building an integration because enterprise customers keep churning without it. These are strategic motivations, just unspoken ones. Making them visible is the first step.

Take the current roadmap items and group them under the objectives they support. Some items will cluster naturally around clear themes. Others will sit awkwardly, belonging to no particular objective, which is useful information in itself. Items without a clear strategic home deserve scrutiny: they may be perfectly valid work, or they may be backlog gravity in action.

Use objectives as a filter, not a straitjacket

The goal is to use objectives to evaluate the work the team is already doing, not to impose a rigid framework overnight. If the team can articulate three to five product objectives and map their current work against them, they’ve already made a significant shift. They can now see where effort is concentrated, where objectives are underserved, and where work is happening that doesn’t align with any stated goal.

ProdPad’s approach to OKR alignment was designed specifically for this kind of incremental adoption. Linking roadmap initiatives to objectives creates visibility into which objectives have active work supporting them and which are effectively orphaned, without requiring teams to rebuild their entire planning process from scratch.

Elevate the planning conversation

Once objectives are visible on the roadmap, the planning conversation changes. Instead of “What should we build next?” the question becomes “Which objective needs the most attention right now?” Instead of debating whether Feature A or Feature B is more important (a conversation that usually devolves into opinion and politics), the team debates which strategic problem is most urgent. The features become potential solutions to that problem, and the team has permission to explore alternatives.

This is where the shift from feature-led to initiative-led planning becomes tangible. An initiative like “Reduce time-to-value for new users” might contain three or four different ideas the team could pursue. The roadmap declares the initiative as a priority, and the team runs discovery to determine which approach will have the greatest impact. The roadmap stays stable while the execution stays flexible. Itamar Gilad has advocated for a similar approach through the GIST framework, which separates goals, ideas, steps, and tasks to prevent premature commitment to specific solutions.

Making the Roadmap a Strategy Artifact Again

The roadmap is one of the most scrutinized artifacts in any product organization. Executives review it. Sales references it. Engineering plans around it. Customers ask about it. Given that level of attention, the roadmap is either reinforcing strategic thinking every time someone looks at it, or it’s undermining it. A bottom-up roadmap, no matter how well-maintained, does the latter. It tells people what’s being built without explaining why, and it invites feature-level negotiations instead of strategic conversations.

The roadmap should declare intent

A strategy-aligned roadmap does something a feature list never can: it declares what the organization is trying to achieve and in what order. It answers the question “where are we going” before it answers “what are we building.” When someone opens the roadmap, they should be able to understand the Product team’s priorities, the problems being solved, and the objectives being pursued, without needing a separate strategy deck to provide context.

This is the principle behind the Now-Next-Later roadmap format, which organizes work into time horizons based on confidence rather than calendar dates. Items in “Now” are committed, well-understood, and actively being worked on. “Next” holds what’s being prepared and validated. “Later” represents strategic direction that hasn’t yet been fully explored. The format itself communicates that certainty diminishes over time, which is both honest and strategically useful.

Connect the layers

A roadmap that functions as a strategy artifact needs visible connections between the layers of planning: objectives at the top, initiatives that serve those objectives in the middle, and specific ideas or experiments at the bottom. When someone asks “why are we building this,” the answer should be traceable directly from the feature up through the initiative to the objective. That chain of reasoning is what makes a roadmap strategic. Without it, the roadmap is just a prettified backlog.

The feedback-to-idea-to-roadmap connectivity that ProdPad users consistently describe as a breakthrough moment is exactly this kind of visible connection. Customer feedback links to ideas. Ideas link to initiatives on the roadmap. Initiatives link to objectives. Every level of the chain is visible, which means every decision is auditable and every priority is explainable.

Strategy is a living practice, not a launch event

The biggest mistake teams make when trying to move from bottom-up to strategy-led roadmapping is treating it as a transformation project. They plan an offsite, build a comprehensive strategy framework, define 12 objectives, and try to rewire everything at once. Two months later, the framework is gathering dust and the team is back to working from the backlog because that’s where the muscle memory is.

The shift works better as a gradual practice. Start with one roadmap review where you ask “which objective does this serve” for every item. Tag initiatives with the objectives they support. Notice when an item can’t be connected to any strategic goal and have a conversation about it instead of ignoring it.Over a few cycles, the roadmap will naturally evolve from a feature list into something that looks, sounds, and functions like a strategy.

Rich Mironov captures this well with his framing that the goal isn’t to have a roadmap, but to have a good product strategy where hard choices have been made, and the roadmap simply reflects those choices. The roadmap is the output of strategic thinking, not a substitute for it. When teams work bottom-up, they’re doing it backwards: building the roadmap and hoping strategy emerges from the collection of features. It almost never does.

When the Roadmap Carries the Strategy, Everything Else Gets Easier

Product teams that operate from bottom-up roadmaps spend an enormous amount of energy on activities that strategy-led teams barely think about. These teams spend hours in prioritization debates because there’s no shared framework for what matters most. Decks get built to justify decisions because the roadmap doesn’t communicate the reasoning on its own. Stakeholders constantly ask “why are we building X instead of Y” because the strategic logic isn’t visible. Every shift in priorities looks like indecision rather than learning, so the team ends up defending the plan instead of adapting it.

A roadmap that carries the strategy eliminates most of this overhead. When objectives are visible, prioritization becomes a discussion about which problems matter most, not which features are loudest. Framing initiatives as problems to solve gets stakeholders engaging with direction rather than debating specific solutions. And once the chain from objective to initiative to idea is visible, changes in execution don’t look like changes in strategy, because the strategic layer hasn’t moved.

The teams that get this right describe a fundamental shift in how they spend their time. Less time explaining and defending. More time on discovery, experimentation, and learning. Less time managing the backlog. More time shaping the direction of the product. The product roadmap stops being a source of anxiety and starts being a tool for alignment, which is what it was always supposed to be.

Bottom-up roadmaps feel safe because they come from real inputs and produce real outputs. But safety and progress are different things. A team that ships features without strategic intent is moving fast in no particular direction. The roadmap is the one artifact with enough organizational gravity to change that, if it’s built to carry strategy instead of just features.

The post The Danger of Bottom-Up Roadmaps appeared first on ProdPad.

I had a conversation with David Pereira recently that crystallized something I’ve been circling for months. David, whose book Untrapping Product Teams is one of the sharpest diagnoses of product dysfunction out there, put it bluntly: the teams that were already building the wrong things are now building the wrong things faster. AI has become a force multiplier for motion, and motion is getting mistaken for progress at every level of the organization.

This is a problem that sits squarely on the shoulders of senior Product leaders and founders. Teams didn’t choose to skip problem framing. The systems they operate in did.

The Return of Capability-Led Thinking

Product organizations have been fighting capability-led thinking for more than a decade. The idea that “we can build it, therefore we should build it” has been called out by Melissa Perri in Escaping the Build Trap, by Marty Cagan in Empowered, and by every credible Product thinker writing today. And yet the pattern keeps returning. It keeps returning because the conditions that produce it never fully change.

Why the Pattern Persists

Capability-led thinking thrives wherever there’s a mismatch between what an organization can produce and what it has permission (or patience) to learn. When new technology arrives, that mismatch widens. AI has widened it dramatically.

Consider what’s happened. Before AI tooling became common, there was a natural friction in the product process. Writing a spec took time. Synthesizing feedback took time. Scoping a solution took time. That friction was often annoying, but it also created space for thinking. It forced teams to sit with ambiguity a little longer, to ask whether the problem was understood well enough to justify the effort of writing the solution down.

AI has collapsed that friction. A PM can go from a vague customer complaint to a fully-formed spec in under an hour. The feature factory dynamic that John Cutler diagnosed years ago now operates at a speed that makes the old version look quaint.

The issue isn’t that AI generates bad outputs. Often the outputs are well-structured and thorough. The issue is that the inputs were never interrogated. The problem was never framed. The customer need was assumed, not validated. And so the beautifully formatted spec describes a solution to a problem that may not exist, or may not be the problem that matters most.

Speed Without Direction Compounds Waste

Itamar Gilad, creator of the GIST framework and author of Evidence-Guided, has been writing for years about how opinion-based decision-making dominates product organizations, even ones that claim to be data-driven. His Confidence Meter makes visible something most teams would rather not acknowledge: the gap between how certain they feel about an idea and how much actual evidence supports it.

AI widens that gap. When a tool produces a polished artifact, the artifact itself generates confidence. A well-written spec looks like a well-researched spec. A cleanly summarized set of customer insights looks like deep understanding. Leadership sees the output and assumes the thinking happened. The team ships, measures nothing meaningful, and moves on.The compounding effect is significant. Every cycle that skips problem framing adds more features to a product without adding clarity about what the product is for. Over time, the product becomes harder to reason about, harder to maintain, and harder to sell. Technical debt accumulates alongside strategic debt, and neither shows up on a dashboard until it’s expensive to fix.

The Cost of Skipping Problem Understanding

There’s a phrase that circulates in product leadership circles: “fall in love with the problem, not the solution.” It has become so common that it risks losing its meaning. But the underlying principle is structural, not sentimental. Organizations that skip problem understanding don’t just build the wrong features. They build the wrong operating model.

What Gets Lost When Problem Framing Disappears

Problem framing is the work of defining what you’re actually trying to change for customers and the business, and understanding it well enough to recognize a good solution when you find one. It includes research, yes. But it also includes the harder work of building shared understanding across Product, Design, and Engineering about what “done” looks like and how you’ll know if you got there.

When AI tools generate solutions quickly, the temptation is to skip that shared understanding work entirely. After all, the spec is already written. The user stories are drafted. Engineering can start. And this is where the real cost appears: not in the quality of any single feature, but in the erosion of the decision-making muscle across the team.

Teresa Torres’ continuous discovery habits model is built on the idea that product teams need to be making frequent, small bets informed by direct customer contact. When AI-generated outputs replace that direct contact, teams lose the context that makes those bets meaningful. They stop asking “why this problem?” and start asking “how fast can we ship this solution?”

David Pereira talks about this in terms of traps. Teams get trapped in coordinative workflows where the PM hands off a spec, Engineering builds it, and nobody owns the outcome. AI accelerates the handoff without addressing the workflow’s fundamental weakness: nobody paused to ask whether the thing being handed off was the right thing.

The Incentive Problem Underneath

The deeper issue is that most product organizations still reward speed and volume. Quarterly planning cycles favor teams that can show a full backlog of scoped work. Roadmap reviews favor teams that can demonstrate throughput. Annual performance reviews favor PMs who shipped a lot.

None of these incentives reward the team that spent three weeks in discovery and came back with the insight that the highest-value opportunity was something nobody had considered. None of them reward the PM who killed a project early because the evidence didn’t support continuing.The result is a system that penalizes depth and rewards surface area. AI plugs directly into that system, making the surface area even easier to expand. Teams that already struggled to protect time for product discovery now have even less organizational patience for it, because leadership can see how fast specs and prototypes appear and reasonably asks: “why can’t we just go faster?”

Delayed Gratification as a Competitive Advantage

Speed has become the default metric for evaluating product capability. The faster a team moves from idea to shipped feature, the more effective it’s considered. AI has accelerated this further, making it possible to collapse what used to take weeks into days. And yet the organizations producing the best outcomes are the ones that deliberately slow down at the front of the process.

Why Slowing Down at the Front Creates Speed at the Back

There’s a paradox in product development that’s worth naming explicitly. Teams that invest more time in problem understanding before committing to a solution tend to ship fewer things, but the things they ship are more likely to move the metrics that matter. The total cycle time from “we identified an opportunity” to “we produced a measurable outcome” is often shorter for these teams, because they spend less time building things that don’t work, less time reworking solutions that missed the mark, and less time in post-launch firefighting.

This is the principle behind the Now-Next-Later roadmap. The format exists because it forces teams to separate what they’re confident enough to work on now from what still requires learning. Items in “Later” are deliberately vague, because pretending to know the answer before you’ve done the research is dishonest and wasteful. Items move forward only when the evidence justifies commitment.

AI fits beautifully into this model when it’s deployed in the right place. Using AI to accelerate research synthesis, to surface patterns in feedback data, to generate hypotheses for testing: all of this amplifies good product practice. The problem arises when AI is used to skip the stages where learning happens and jump directly to specifying and shipping.

The Organizational Courage Problem

Delayed gratification requires organizational courage. A Product leader who tells the executive team “we’re spending this quarter deepening our understanding of the problem before we commit to a solution” needs a level of trust and credibility that takes time to build. In organizations where PMs arealready struggling with decision confidence, AI offers an easier path: generate outputs fast, show progress on the roadmap, and deal with the consequences later.

The organizations that treat problem understanding as a competitive advantage tend to share certain characteristics. Product teams are funded as long-lived value streams, not project-based delivery squads. OKRs describe customer outcomes, not feature delivery. PMs get explicit permission (and time) to run experiments that might not produce a shippable result. And critically, their leadership has learned to read a roadmap that shows learning in progress, not just features in motion.

What Leaders Must Change in Incentives and Expectations

The operating model shift this requires isn’t about tools. It’s about what leadership asks for, what leadership measures, and what leadership rewards. Product teams will optimize for whatever the system incentivizes, and right now most systems incentivize exactly the wrong things for an AI-augmented world.

Stop Rewarding Throughput

The single most damaging incentive in modern product organizations is rewarding throughput. When PMs are evaluated on how many features they ship, how many specs they write, or how many items move across the board in a quarter, the message is clear: motion matters more than direction.

In an AI world, this incentive becomes actively destructive. A PM can generate a quarter’s worth of specs in a week. They can populate a roadmap that looks ambitious and well-planned. Leadership reviews it, sees volume, and gives a thumbs up. But nothing on that roadmap was validated. Nothing was tested. Nothing connects to a measurable customer outcome. The roadmap has become what Rich Mironov would call a political document rather than a strategic one.

Changing this requires leadership to redefine what good looks like. A strong quarter for a Product team might include shipping two things instead of ten, if those two things produced measurable impact. It might include killing three initiatives that didn’t survive validation, because the team learned something valuable and redirected resources to higher-value work. Or it might include a research insight that changes the company’s understanding of its market.

Measure Learning Velocity, Not Delivery Velocity

The shift from delivery velocity to learning velocity is one of the most important transitions a product organization can make. Delivery velocity asks: “how fast are we turning ideas into shipped features?” Learning velocity asks: “how fast are we generating validated insights about our customers and market?”

Both matter. But in an organization that has AI accelerating delivery, learning velocity becomes the bottleneck and the differentiator. Two companies with the same AI tooling and the same delivery speed will produce very different results if one of them is learning faster.

Measuring learning velocity means tracking things like: how many experiments ran this quarter, how many hypotheses were validated or invalidated, how quickly the team moved from a new customer insight to a testable bet, and how many times a roadmap initiative was refined based on new evidence before being committed to delivery.ProdPad was designed around this principle. Every idea carries its hypothesis. Every initiative connects to an objective. The workflow tracks progress from discovery through delivery and into outcome measurement. The tool makes it structurally difficult to ship something without articulating why you believe it will work and how you’ll know if it did.

Redefine the PM Role for an AI-Augmented World

There’s a temptation to treat AI as a productivity multiplier for PMs, letting them do the same job in less time. The better frame is to treat AI as a capability that changes what the PM job is.

If AI can write specs, synthesize feedback, and draft user stories, then the PM’s value shifts decisively toward the work AI cannot do: framing problems well, building organizational alignment around which problems matter most, designing experiments that generate genuine learning, and making judgment calls about when to continue investing in an initiative and when to stop.

This reframing has implications for hiring, performance evaluation, and career development. The PM who can generate the most output is no longer the most valuable PM. The PM who can frame the most insightful problem, design the most effective experiment, and make the most courageous prioritization call is.

Product leaders who understand this will restructure their teams accordingly. Investment in research capability comes first. Discovery time gets protected. Killing work that produces no evidence of value becomes normal. And AI gets deployed exactly where it’s most powerful: accelerating the parts of the process that benefit from speed, while protecting the parts that benefit from depth.

The Competitive Moat Is Judgment, Not Speed

Every product organization now has access to roughly the same AI capabilities. The tooling is broadly available. The productivity gains from generating specs, summaries, and prototypes are accessible to anyone willing to adopt the tools. Speed, in other words, is no longer a differentiator. Everyone is fast.

What differentiates organizations in this environment is the quality of their judgment. The ability to identify the right problems. The discipline to validate before committing. The courage to invest in learning even when it delays visible output. The structural commitment to connecting feedback to ideas to roadmap to outcomes in a way that creates institutional learning, not just institutional motion.

David Pereira’s framing of this is useful: the question isn’t whether to use AI, but whether your organization is capable of directing AI toward problems that matter. If problem framing is weak, AI accelerates waste. If problem framing is strong, AI accelerates impact. The tool is neutral. The operating model determines the result.

For senior Product leaders and founders reading this, the implication is concrete. Audit your incentives. Look at what your organization actually rewards, celebrates, and promotes. If the answer is volume of output, you’re building a system that will use AI to produce more of the wrong things, faster. If you can shift that answer toward validated learning and measurable customer outcomes, AI becomes genuinely transformative.

The teams that win the next five years won’t be the ones that shipped the most features. They’ll be the ones that understood the most problems and solved the ones that mattered.

The post AI Made Your Product Team Faster. It Didn’t Make Them Better appeared first on ProdPad.

But that reasoning has a compounding cost. And at some point, the cost of avoidance becomes the single biggest drag on a team’s ability to do anything strategic at all. Fixing what’s broken isn’t a detour from product strategy. For most teams, at some point in the product lifecycle, it is the strategy.

The Hidden Cost of “We’ll Deal With It Later”

Every deferred fix carries an interest rate. Roman Pichler describes this well in his writing on technical debt and product success: the messier the code and the less modular the architecture, the longer and more expensive every future change becomes. That’s true at the code level, and it’s equally true at the product level.

When teams accumulate unresolved bugs and instability, the cost shows up in places that are hard to see from a quarterly planning view. Cycle times get longer because engineers are working around fragile systems. Support ticket volume creeps up, pulling Engineering into reactive mode. Deployments become riskier, so teams batch more changes together, which makes each release slower and higher stakes. The Protiviti survey data on this is striking: nearly 70% of organizations say technical debt is significantly impacting their ability to innovate, and the average business spends 30% of its IT budget dealing with it.

The compounding dynamic is the critical part. A small bug left alone for six months doesn’t stay small. Other code gets built around it. Workarounds get baked into the product. New features have to account for the broken thing, adding complexity. What started as a quick fix becomes a structural problem, and now it’s genuinely expensive to address.

The planning trap

There’s a deeper systems-level problem too. When a team operates with significant instability, planning itself becomes unreliable. Estimates inflate because everyone knows that a certain percentage of every sprint will be eaten by unplanned work. Product Managers stop being able to forecast what can actually ship in a given time horizon, and so roadmap conversations devolve into hedging and caveats. John Cutler has written extensively about how product teams lose trust when engineers and designers can’t see the impact of their work, and chronic instability is one of the most common reasons that impact becomes invisible.

The “deal with it later” posture also creates a credibility gap with stakeholders. When the same bugs keep appearing in customer calls, and the roadmap keeps showing new features instead of fixes, Sales and Customer Success lose confidence in the product narrative. Leadership starts to question whether Product has a grip on the situation. And the Product team, ironically, ends up spending more time explaining and defending the roadmap than actually executing against it.

Cultural Damage Caused by Ignored Bugs

The technical costs of deferred stabilization are well understood. The cultural costs are less discussed, but they’re often more damaging and harder to reverse.

Engineers know

Engineering teams have a finely tuned sense of the state of their codebase. They know where the landmines are. They know which services are held together with duct tape. And when those problems get surfaced and then consistently deprioritized, it sends a clear signal: we don’t actually care about quality; we care about shipping features.

That signal erodes morale in a specific and predictable way. Engineers stop raising issues because they’ve learned that raising them doesn’t lead to resolution. They stop investing discretionary effort in code quality because the system doesn’t reward it. The best engineers, the ones with options, start looking elsewhere. Teams don’t usually describe this as a culture problem. They describe it as a retention problem, or a velocity problem, or a quality problem. But the root cause is the same: the operating model is telling people that stabilization work is second-class.

The trust erosion loop

There’s a cascading effect that’s worth tracing. When known bugs persist, customers complain. Support escalates those complaints to Product. Product acknowledges the issue but prioritizes something else. Support goes back to the customer with a non-answer. The customer loses trust. Support loses trust in Product. Product loses trust in Engineering’s estimates (because unplanned bug work keeps disrupting plans). Engineering loses trust in Product’s prioritization. Cutler’s product enablement principles put it simply: trust is nurtured through promises regularly kept. When a team consistently promises to address quality issues and consistently doesn’t, every relationship in the chain degrades.

The innovation theater problem

Paradoxically, teams that refuse to stabilize often end up producing less innovation, not more. The features they ship land on an unstable foundation. Adoption suffers because users are already frustrated. Usage data is polluted by bugs, making it harder to interpret whether a new feature is genuinely solving a problem or being avoided because the surrounding experience is broken. Teams end up doing more rework, more customer-appeasement shipping, and less genuine discovery. The pursuit of novelty without stability produces a kind of innovation theater: new things announced, but real user value stagnating.

The False Binary of Innovation vs. Maintenance

Most product organizations operate with an implicit assumption: time spent on stabilization is time not spent on innovation. The two are treated as competing priorities, and since innovation is what gets celebrated, funded, and promoted, stabilization consistently loses.

This framing is fundamentally wrong.

Stability is a prerequisite for speed

Keith Eich, VP of Product and Technology at Harbor Compliance, frames it well: technical debt is really just deferred decisions, and unmanaged debt eventually kills innovation. The real question isn’t whether to innovate or stabilize. It’s what level of stability your system needs in order to sustain the pace of learning you’re trying to achieve.

Consider the mechanics. A team doing continuous discovery needs to ship experiments quickly, measure results, and iterate. Every step in that cycle gets slower when the system is unstable. Experiments take longer to build because engineers are working around fragile code. Results are harder to interpret because noisy baselines obscure signal. Iteration is riskier because each change could trigger cascading failures in unrelated parts of the product. The team that refuses to stabilize isn’t choosing innovation over maintenance. It’s choosing slower, less reliable innovation.

Portfolio allocation, not binary choice

The most effective product organizations treat stabilization and new capability work as parts of a single portfolio, not as a binary trade-off. Some teams formalize this with capacity allocation: a declared percentage of engineering time dedicated to paying down technical debt, fixing bugs, and improving system health. Others use dedicated stabilization sprints at regular intervals. The specific mechanism matters less than the principle: stabilization work needs to be planned, visible, and protected from being the first thing cut when timelines get tight.

ProdPad’s own approach to managing technical debt in the product flow reflects this: the product team doesn’t own 100% of dev capacity, and that should be by design. A certain amount of slack needs to be built in to account for code quality work, and the more slack there is, the less likely you’re going to end up with rushed code, missed bugs, and the accumulation of new debt.

Where the language goes wrong

Part of the problem is linguistic. When organizations label stabilization work as “maintenance” or “keep the lights on,” they’re implicitly devaluing it. These labels frame the work as custodial rather than strategic. They make it harder to get executive buy-in, harder to attract strong engineers, and harder to celebrate when it’s done well.

A reframe helps. Stabilization work that enables faster cycle times is a strategic investment in delivery capability. Reducing support ticket volume through stabilization is a strategic investment in customer retention. And making the codebase more modular is a strategic investment in the team’s ability to respond to market changes. The work itself hasn’t changed. The framing has. And framing matters, because it determines whether stabilization gets the resources, visibility, and executive support it needs to actually happen.

How Stabilization Unlocks Better Discovery

The connection between a stable product and effective product discovery is direct, measurable, and consistently undervalued.

Cleaner signal, better decisions

Product teams make decisions based on data. Usage patterns, conversion funnels, experiment results, customer feedback. Every one of those data sources becomes less reliable when the product is unstable. Bugs create noise in behavioral data. Performance issues cause drop-offs that look like feature rejection. Workarounds change user behavior in ways that obscure actual preferences.

A team running a pricing experiment on a product with chronic checkout bugs can’t tell whether low conversion is a pricing problem or a reliability problem. A team measuring adoption of a new workflow can’t distinguish between genuine friction and intermittent errors. The discovery process depends on being able to trust the signal, and instability poisons the signal.

Faster experiment cycles

Teresa Torres popularized the idea that continuous discovery should be a sustained practice informing product decisions at every stage. That practice requires fast feedback loops: build something small, ship it, measure, learn, iterate. Every part of that loop gets slower on an unstable platform.

Risky deployments lead to lower deployment frequency. Fragile code forces teams to scope experiments more conservatively. And when QA is overwhelmed with regression issues, new features wait in the queue longer. The team that prioritizes stabilization isn’t taking time away from discovery. It’s removing friction from the discovery process itself.

Creating space for genuine learning

There’s a psychological dimension too. Teams mired in firefighting operate in a reactive mindset. They’re triaging, escalating, patching. There’s no cognitive space for the kind of open-ended exploration that discovery requires. Product Managers spend their time managing stakeholder frustration instead of talking to customers. Engineers spend their time on workarounds instead of building experiments. Designers are constrained by the limitations of a fragile system rather than imagining what the experience could be.

Stabilization creates breathing room. And breathing room is where the most valuable product insights tend to emerge, because teams finally have the headspace to notice things they’ve been too busy to see.

Turning Survival Work Into Strategic Leverage

The shift from treating stabilization as a necessary evil to treating it as a strategic lever requires changes at the operating model level. It requires different ways of planning, communicating, and measuring success.

Make stabilization work visible on the roadmap

The single most important step is getting stabilization initiatives onto the roadmap, with the same level of strategic framing as any new capability. That means tying them to objectives. Not just “fix the checkout bug” but “reduce friction in the purchase flow to improve conversion rate.” Not just “refactor the notification system” but “improve system reliability to support the scale of our Q3 growth target.”

When stabilization work is framed this way, it’s no longer in competition with feature work. It’s contributing to the same strategic objectives through a different mechanism. A Now-Next-Later roadmap is well suited to this because it organizes work around problems to solve, not features to ship. A stabilization initiative fits naturally as a “Now” item: a validated, high-priority problem that needs to be addressed before the team can confidently move forward.

Set OKRs that value stability

If your OKRs only measure new feature adoption and revenue from new capabilities, stabilization will always be the underdog. Consider what stability-focused key results could look like.

Reduce mean time to recovery by 40%. Decrease support ticket volume for top 5 reported issues by 60%. Improve deployment frequency from fortnightly to weekly. Cut average experiment cycle time from 6 weeks to 3. These are outcome-oriented, measurable, and directly tied to the team’s ability to deliver value faster. They’re the kind of key results that, when achieved, make everything else on the roadmap more achievable too.

Communicate stabilization as investment, not apology

When a Product leader presents stabilization work to the board or to stakeholders, the temptation is to frame it defensively: “We need to take some time to pay down debt before we can get back to building.” That framing invites the wrong response. It positions the team as having made mistakes that now need correcting, and it frames the stabilization period as dead time.

A better frame: “We’re investing in platform capability to accelerate our delivery pace for Q3 and Q4. The work we’re doing now will reduce cycle times by [X], free [Y] hours of engineering capacity per sprint, and give us more reliable data for our upcoming pricing experiments. This positions us to ship [Z initiative] faster than we could if we continued on the current trajectory.”

That’s the same work. Described in terms of what it enables rather than what it cleans up. And it’s more accurate, because the strategic benefit of stabilization isn’t retrospective. It’s forward-looking.

Build stabilization into the operating rhythm

The organizations that handle this best don’t treat stabilization as an event or a phase. They build it into the cadence. A consistent allocation of engineering capacity goes toward quality work every sprint. Stabilization objectives appear in every quarterly planning cycle. Metrics that track system health (deployment frequency, incident rate, mean time to recovery) sit alongside feature metrics in leadership dashboards.

This approach prevents the boom-bust cycle that most organizations fall into: ignoring quality until it becomes a crisis, then doing a panicked “stability sprint” that disrupts the roadmap, then going back to ignoring quality until the next crisis. The steady approach is less dramatic but far more effective, because it prevents debt from accumulating to the point where it requires a disruptive intervention.

Why the Best Product Teams Treat Stability as a Competitive Advantage

The distinction between product organizations that thrive and those that stagnate rarely comes down to how many features they ship. It comes down to how fast they can learn, adapt, and respond to what they discover. That speed is a function of system health.

A stable, well-maintained product is one where experiments ship in days instead of weeks. Customer feedback can be acted on quickly because the codebase is modular enough to change without cascading risk. Engineers spend their energy on creative problem-solving instead of firefighting. The roadmap reflects actual priorities instead of being held hostage by urgent but avoidable crises.

Nokia’s story is a cautionary one. The company dominated mobile phones for years, but years of deferred decisions around their Symbian operating system created an architecture so rigid that when the iPhone arrived, Nokia couldn’t respond fast enough. The debt wasn’t just a technical problem. It was a strategic one. The inability to move quickly meant the inability to compete.

Product leaders who understand this don’t treat stabilization as a detour. They treat it as the foundation that makes every other strategic initiative possible. They frame it, fund it, measure it, and celebrate it with the same seriousness as any new market-facing capability. Because a team that can move fast on a solid foundation will always outperform a team that moves fast on a shaky one. Speed on an unstable platform isn’t velocity. It’s vibration.

The post When Stabilization Becomes Strategy appeared first on ProdPad.

That’s where things fall apart.

The objectives are always oriented around subscriber growth, revenue, conversion rates, activation. Standard product metrics. And the platform lead is stuck trying to explain that improving core web vitals is, if you squint hard enough and do some napkin math, “one mathematical operation away” from something the exec team actually cares about. They know the work matters. Their exec team wants a number. And the framework they’ve been handed was never designed to produce one for this kind of work.

The OKR Framework Isn’t the Problem

OKRs are a genuinely useful tool for aligning teams around outcomes. The logic behind customer-centric OKRs is clean: set an objective that describes a future benefit, measure it through changes in customer behavior, and give teams the autonomy to figure out how to get there. Jeff Gothelf and Josh Seiden have been advocating for this approach for years, and they’re right. For product teams building features that end users interact with directly, that model works beautifully. You can observe the behavior change. The outcome is measurable. There’s a straight line between what you shipped and what moved.

The problem shows up when organizations take a framework optimized for one type of team and apply it uniformly across every team, regardless of what that team actually does. Platform teams, infrastructure teams, internal tools teams, developer experience teams, design systems teams. These groups exist to make other teams faster, more reliable, more capable. Their “customers” are internal. Their impact is indirect. And the OKR framework, as most companies implement it, has no native vocabulary for that.

What the Translation Tax Actually Looks Like

Every quarter, enabling teams go through a ritual that product teams rarely have to endure. They take work that has clear value (reducing deployment time, improving API reliability, consolidating authentication flows, paying down technical debt) and spend hours, sometimes days, translating it into the language of external customer outcomes.

The mathematical gymnastics

A platform lead improving CI/CD pipeline speed doesn’t get to say “we cut deploy time by 40%.” They have to construct a chain: faster deploys mean more frequent releases, which means faster iteration on features, which means features ship sooner, which means customers get value sooner, which theoretically improves retention. By the time you’ve built that chain, you’ve wandered so far from the actual work that the OKR reads like a creative writing exercise.

The borrowed metric problem

Because enabling teams can’t easily claim a customer-facing metric, they end up “borrowing” one from a product team. The platform team says their work will contribute to improving activation rates. But activation depends on dozens of variables, most of which the platform team has no control over. When the number doesn’t move (or moves for reasons unrelated to infrastructure), the platform team’s work looks like it failed, even though it delivered exactly what it was supposed to.

The output trap disguised as outcomes

Under pressure to show measurable results, enabling teams often retreat to output-based key results. “Ship the new service mesh.” “Complete the migration to the new auth provider.” These aren’t outcomes. They’re tasks. But they’re the only things the team can guarantee, because the actual outcomes of their work are felt downstream, in other teams’ numbers, on other teams’ timelines.

Product teams and enabling teams incur a “context-switching tax” every time they have to adapt to each other’s operating models. John Cutler has written extensively about this dynamic, and the same pattern applies to goal-setting. When enabling teams are forced to express their work in product team terms, the translation itself consumes energy and introduces distortion.

The Structural Incentives That Make This Worse

The translation tax would be annoying on its own. What makes it genuinely harmful is how organizations respond when enabling teams can’t produce clean OKRs.

Budget conversations become existential

In most companies, budget allocation is tied to demonstrated impact. If a team can’t show a measurable connection between their work and a business metric, they look like a cost center. Platform teams that can’t articulate their strategic value fall into an “expensive request taker” pattern: they fulfill whatever other teams ask for, lose the ability to prioritize strategically, and face constant pressure to shrink. The team that can’t write a compelling OKR gets a smaller budget next quarter. The smaller budget means less capacity, which means slower enabling work, which means product teams slow down too. But the budget cut happened to the platform team, not the product team, so the root cause stays invisible.

Performance reviews punish the wrong behavior

Individual contributors on enabling teams often find their own performance tied to OKR achievement. If the team’s OKRs are poorly suited to the work (and they almost always are), the people doing genuinely critical work get mediocre performance scores. Over time, this drives talent away from enabling roles. The best engineers and designers gravitate toward product teams where the impact is legible and the career trajectory is clearer.

Strategic misalignment compounds silently

When platform work gets chronically undervalued, companies accumulate a kind of organizational debt. Systems degrade. Developer velocity slows. Security vulnerabilities linger. None of this shows up in quarterly OKR reviews because nobody’s OKR is “maintain the foundations.” By the time the damage surfaces (an outage, a breach, a product team that suddenly can’t ship anything because the platform can’t support their needs) the cost is orders of magnitude higher than continuous investment would have been.

What Enabling Teams Actually Need From a Goal Framework

The solution isn’t to exempt enabling teams from goal-setting. Teams without clear objectives drift. They become service desks, reactive and unfocused, which is its own failure mode. The solution is to design goal-setting that fits the actual shape of the work.

Recognize internal customers as real customers

The framework for writing OKRs when your customers are internal starts with a deceptively simple insight: platform teams do have customers. They’re just internal. Jeff Gothelf and Josh Seiden have laid this out clearly. And those customers have behaviors that can be observed and measured. If your platform team supports product teams, you can measure how often those product teams deploy, how long they spend on boilerplate work, how frequently they encounter integration issues. These are legitimate outcomes. They’re just not the outcomes that show up in the company’s external metrics dashboard.

Separate the “what” from the “so that”

A useful pattern is to let enabling teams own objectives at their own level of abstraction, and then explicitly map the connection to downstream outcomes without collapsing the two into a single OKR. The platform team’s objective might be: “Reduce average deployment cycle time for product teams by 30%.” The documented rationale (not a key result, but an explanatory layer) connects that to the company’s broader goals. This preserves the integrity of the team’s actual work while maintaining strategic alignment.

Build roadmaps around the work, not the borrowed metric

This is where tooling matters. When your roadmap shows initiatives connected to objectives, and those objectives are explicit about what level of the organization they serve, the enabling team’s work becomes visible in its own right. The roadmap tells the story of what’s being done, why it matters, and how it connects to broader strategy, without forcing every initiative through a single, ill-fitting OKR lens.

In ProdPad, we’ve seen teams use portfolio-level and product-level objectives precisely for this kind of separation. Company-level OKRs capture the big external outcomes. Product-level OKRs capture what individual teams (including enabling teams) are driving toward. The connection between them is explicit but not forced. Each team’s roadmap is coherent on its own terms.

The Organizational Pattern Behind the Problem

There’s a deeper pattern worth naming. Organizations tend to design their operating models around their most visible teams. Product teams are visible because their output faces the customer. Sales teams are visible because they generate revenue. Enabling teams are invisible by design. Their whole job is to make other people’s work better. When the operating model rewards visibility, it structurally disadvantages the teams whose success looks like other teams’ success.

This isn’t a problem you can fix with better OKR coaching alone. It requires a decision at the leadership level to recognize that not all valuable work produces the same kind of signal, and that the absence of a clean metric is not the same as the absence of value.

The concept of organizations getting trapped in the “build trap” by measuring output over outcomes is well documented. Melissa Perri has made this case for product teams. The parallel for enabling teams is the “narrative trap”: being measured by someone else’s outcomes, and losing credibility when those outcomes don’t neatly correspond to the work being done.

What Senior Product Leaders Can Do

If you lead a product organization that includes platform, infrastructure, or enabling teams, this is your problem to solve. The people doing the enabling work already know it matters. What they need is an operating model that reflects that.

Audit your OKR structure for team-type blindness

Look at your current OKRs. Are they all framed in terms of external customer behavior? If so, you’ve implicitly told your enabling teams that their work doesn’t count unless it can be shoehorned into someone else’s metric. Add a layer of internal-facing objectives that enabling teams can own with integrity.

Make enabling work visible on the roadmap

If your company uses a single roadmap format that only shows customer-facing initiatives, enabling work becomes invisible. Create roadmap views that surface platform and infrastructure initiatives alongside product work, connected to their own objectives. When enabling work is visible to leadership, it stops being treated as overhead and starts being treated as investment.

Fund enabling work as a portfolio allocation, not a project justification

The worst version of this problem is when enabling teams have to write a business case for every quarter of their existence. Platform investment should be a standing portfolio allocation, reviewed for effectiveness, not a project that has to be rejustified against product team metrics every cycle.

Stop asking enabling teams to “tell the story” of their impact

This advice gets given constantly, and it’s well-intentioned, but it papers over the structural problem. Enabling teams shouldn’t have to become storytellers to survive. The operating model should make their contribution legible without requiring a narrative performance every quarter.

The Framework Isn’t Wrong. The Application Is.

OKRs work. They’re a powerful alignment tool. But alignment breaks down when the framework is applied as if every team operates the same way, faces the same measurement landscape, and produces the same kind of output. The moment you force a platform team to express their work as a derivative of someone else’s customer metric, you’ve introduced a distortion that makes the whole system less honest.

The best organizations I see in roadmap clinics have figured this out. They run OKRs at multiple levels. Enabling teams get objectives that match the actual shape of their work. The roadmap becomes the connective tissue that shows how platform investment supports product outcomes without collapsing the two into a single narrative. And enabling work is treated as an investment in capability, visible and valued on its own terms.

Bad OKRs don’t just produce bad goals. They force good teams into bad narratives. And when that happens often enough, the good people on those teams stop fighting the framework and start looking for somewhere that values what they do.

The system is the thing to fix. The teams are already doing the work.

The post When Good Teams Get Forced Into Bad Narratives appeared first on ProdPad.

That stung, because I’ve heard versions of it from hundreds of Product leaders over the years. And the painful part is that her team probably did create enormous value. They just had no system for making that value visible. The features shipped. The metrics moved (or didn’t). And nobody connected those two things in a way that the business could evaluate.

Proving the ROI of Product work is the single hardest communication challenge a Product leader faces. Sales has revenue attribution. Marketing has pipeline. Engineering has velocity and uptime. Product has a backlog of things that got done, a roadmap that was “mostly” delivered, and a vague sense that retention is better now than it was.

The problem runs deeper than dashboards and reporting. Most product organizations have inherited operating models that make it nearly impossible to draw a clear line from Product decisions to business outcomes. And until that changes, Product will keep fighting for budget, headcount, and credibility using anecdote instead of evidence.

Why Product Struggles to Show Its Value

Product Management occupies an unusual position in most companies. It sits at the intersection of customer needs, business goals, and technical possibility, which means its value is diffused across nearly every metric the company cares about. Revenue growth? Product contributed, alongside Sales and Marketing. Retention? Product helped, but so did Customer Success. Cost savings? Engineering shipped the code, even if Product defined the problem.

This diffusion makes it tempting to retreat into output metrics. Features shipped. Stories completed. Velocity maintained. These are easy to count and easy to report. They feel productive. But they tell the business absolutely nothing about whether the work mattered.

The output trap is a system design problem

The reason so many Product teams default to output measurement is that their tools and processes are designed around output. When your primary system of record is a delivery tool like Jira, every piece of work is defined as a ticket. Progress means tickets moving from “To Do” to “Done.” Success means the sprint was completed. The entire information architecture of the system pulls attention toward what was built, with no native concept of why it was built or whether it worked.

Marty Cagan has written extensively about the difference between empowered product teams and feature teams. The distinction matters here because it reveals a measurement problem hiding inside an organizational design problem. Feature teams, by Cagan’s definition, are given solutions to build and measured on whether they delivered those solutions on time. Empowered product teams are given problems to solve and measured on outcomes. You cannot prove ROI in a feature team model because ROI requires connecting work to results, and the feature team was never asked to produce results in the first place. They were asked to produce output.

This creates a vicious cycle. Product leaders who can’t demonstrate value get less trust. Less trust means less empowerment. Less empowerment means more prescribed solutions handed down from stakeholders. More prescribed solutions mean even less ability to demonstrate value, because the team is building what they were told to build rather than solving the problems that would actually move metrics.

The Missing Layer Between Strategy and Delivery

Most companies have a strategy (even if it lives in someone’s head) and a delivery system (Jira, Linear, Azure DevOps). What they lack is the layer in between: the place where strategic intent gets translated into measurable bets, where customer evidence informs prioritization, and where outcomes get tracked back to the initiatives that produced them.

This missing layer is where Product ROI actually lives. Without it, the best a Product leader can do is tell stories after the fact, trying to reconstruct a narrative of value from scattered data sources.

Explicit connections between objectives and initiatives

OKRs provide the structure for defining what the business is trying to achieve and how success will be measured. But OKRs alone are insufficient. The critical piece is the initiative layer that sits between an Objective and its Key Results: the specific product bets the team is making to influence those results. Without this connection, OKRs become a quarterly goal-setting exercise that runs in parallel to the actual work rather than driving it.

When an initiative on your product roadmap is explicitly linked to an Objective, you create the foundation for ROI measurement. The question becomes answerable: “We invested six weeks in this initiative. The Key Result it was targeting moved from X to Y. Here is the evidence that our work contributed to that movement.” That sentence is the atomic unit of Product ROI.

Evidence trails from customer to decision to outcome

The second requirement is traceability. A Product leader who can show that an initiative started with customer feedback, was validated through product discovery, was prioritized based on strategic alignment, and produced a measurable outcome has a fundamentally different conversation with the CFO than one who can only say “we built what was on the roadmap.”

This traceability requires that feedback, ideas, roadmap initiatives, and goals live in a connected system rather than scattered across spreadsheets, slide decks, Slack threads, and Jira tickets. John Cutler has written about the paradox that teams with the least situational awareness are the ones least likely to invest in improving it, because without seeing the value of better decision-making, the case for investing in better decision-making feels abstract.

Retrospective measurement as a habit, not a one-off

Product teams that prove their ROI do something most teams skip: they go back and check whether their bets paid off. This sounds obvious, but in practice it’s extraordinarily rare. Teams ship a feature, maybe celebrate, and immediately move on to the next sprint. The outcome measurement never happens because nobody built the system to prompt it. Jeff Gothelf, co-author of Lean UX, argues that treating product work as a series of experiments with explicit hypotheses and success criteria fundamentally changes how teams think about value. An experiment has a predicted outcome. You run it. You measure the result. You learn. The learning compounds. Over time, the Product team builds a track record of bets placed and results achieved, which is precisely the evidence base that proves ROI.

Three Levels of Product ROI

One of the reasons ROI conversations go wrong is that Product leaders and their stakeholders are often talking about different things. The CFO wants to know whether the Product org justifies its cost. The VP of Product wants to know which initiatives created the most value. A Product Manager wants to know whether a specific experiment moved a specific metric. These are all valid ROI questions, but they operate at different levels.

Level 1: Portfolio ROI

Portfolio ROI answers the question the CFO is asking: “Is our product investment generating returns for the business?” This requires connecting product-level metrics (retention, expansion revenue, activation rate, time-to-value) to business-level outcomes (revenue growth, margin improvement, market expansion).

Product leaders who succeed at this level tend to work backwards from the business metrics that the C-suite already cares about. If the board is focused on net revenue retention, the Product leader identifies which product initiatives are designed to influence retention and tracks them over time. If the business is in growth mode and cares about new customer acquisition, the Product leader connects product improvements to conversion rates in the trial or onboarding funnel.

Portfolio-level ROI is not about attributing 100% of a metric movement to Product. That’s neither possible nor necessary. The goal is demonstrating a consistent, evidence-backed connection between Product investments and business outcomes, quarter over quarter.

Level 2: Initiative ROI

Initiative ROI answers the strategy question: “Did this specific bet pay off?” This is where outcome-based roadmapping becomes essential. When a roadmap initiative is framed as a problem to solve with a measurable outcome rather than a feature to ship, you create the conditions for evaluating its ROI.

An initiative framed as “Build dashboard export feature” has no built-in success criteria beyond “did we build it?” An initiative framed as “Reduce time Product leaders spend creating stakeholder reports by 50%, measured by user research and usage data” has a clear outcome that can be evaluated after launch. The initiative either achieved its target or it didn’t. Either way, the team learned something, and the Product leader has evidence to share.

Level 3: Team ROI

Matt LeMay made a compelling argument in a ProdPad webinar on showing the ROI of Product work that thinking about ROI at the team level can actually be more liberating than thinking about it at the feature level. When a team has clear objectives and is measured on outcomes, they have the freedom to pursue whatever approaches will move the metric, including approaches that might not look like traditional “product work” at all. Maybe the biggest ROI comes from fixing an internal process, improving documentation, or running a training program for customer-facing staff.

Team ROI shifts the conversation from “did you ship the thing” to “did you achieve the result.” That shift is where real accountability, and real credibility, emerges.

The Systems That Make ROI Visible

Proving Product ROI is not a presentation problem. A Product leader who spends the last week of every quarter frantically assembling a narrative about the team’s impact is fighting a losing battle. The evidence needs to accumulate continuously, as a byproduct of how the team works, rather than as a separate reporting exercise layered on top.

Connected product management as an ROI engine

The companies that demonstrate Product ROI most effectively share a common trait: they use connected systems where customer feedback flows into ideas, ideas connect to roadmap initiatives, initiatives link to strategic objectives, and outcomes are measured and recorded in the same place. This end-to-end traceability is what transforms ROI from a storytelling exercise into a system output.

When a customer submits feedback that gets linked to an idea, and that idea gets developed into a roadmap initiative tied to an OKR, and the Key Result movement is tracked after launch, you’ve created an evidence chain that tells itself. The Product leader doesn’t need to reconstruct it from memory at quarter end. It’s already there.

This is one of the reasons why bolting strategy onto a delivery tool produces such poor ROI visibility. Jira is excellent at tracking what Engineering is building. It is not designed to answer the question of why something was built or whether it worked. The information architecture of a delivery tool optimizes for throughput. And learning, specifically learning whether your product bets are paying off, is the foundation of ROI measurement.

Building the habit of outcome retrospectives

Teresa Torres, in her work on continuous discovery habits, emphasizes the importance of regular touchpoints with customers and regular reflection on what’s been learned. The same principle applies to outcome measurement. Teams that build a habit of reviewing initiative outcomes, even informally, develop a much richer understanding of what creates value and what doesn’t.

A practical approach is to add an outcome review to existing retrospective cadences. Two or three months after an initiative launches, the team returns to the original hypothesis and evaluates whether the predicted outcome materialized. If it did, that’s ROI evidence. If it didn’t, that’s still valuable: it’s evidence of learning and adaptation, which builds credibility over time because it shows the team is honest, self-correcting, and improving its hit rate.

Christina Wodtke, author of Radical Focus and a leading voice on OKRs, has discussed with ProdPad how even simple rituals like weekly celebrations of progress and end-of-quarter reflections on whether objectives were met can dramatically shift how a team thinks about its own impact. The celebration part matters: teams that only measure ROI when they’re under threat never develop the muscle memory for ongoing value demonstration.

The Anti-Patterns That Destroy ROI Credibility

Some of the most common Product practices actively undermine a team’s ability to demonstrate its value. They’re worth naming explicitly, because many Product leaders don’t realize their operating model is working against them.

Measuring success by tickets closed

When the team’s primary success metric is velocity, throughput, or story points completed, the implicit message to the business is: “Our value is in how fast we move.” This invites the obvious follow-up from leadership: “Moving fast toward what?” And if the answer is “toward completing the things on the list we were given,” you’ve just described an order-taking function. Order-taking functions don’t command premium budgets or earn seats at the leadership table.

Roadmaps that promise features instead of outcomes

A timeline roadmap with specific features slotted into specific quarters creates a contract, and contracts are evaluated on whether they were fulfilled. If you delivered Q3’s features in Q3, you succeeded. If you didn’t, you failed. There’s no room in this model for the team to have learned something in Q2 that made Q3’s planned features irrelevant, or to have discovered a better solution to the underlying problem. The roadmap format itself prevents the ROI conversation from happening, because the success criteria is “did you build what you said you’d build” rather than “did you achieve the outcome you were targeting.”

This is one of the core reasons the Now-Next-Later roadmap format exists. By organizing work around problems to solve and outcomes to achieve, grouped by confidence level rather than calendar date, it creates the space for initiative-level ROI measurement. “We said we’d tackle onboarding conversion in the ‘Now’ column. We ran three experiments. Conversion improved by 12%.” That is a fundamentally more credible story than “we shipped the three features we promised.”

Disconnected strategy and feedback loops

When the product strategy lives in a slide deck, customer feedback lives in a spreadsheet (or worse, in people’s heads), and the roadmap lives in a different tool from the goals, there’s no connective tissue. The Product leader who tries to demonstrate ROI in this environment is essentially doing archaeology: digging through artifacts from different systems to reconstruct a narrative of value that was never designed to be captured.

The fix is systematic. It requires investing in how Product work gets structured before the work begins, rather than trying to measure value after the fact.

Practical Mechanisms for Proving Product ROI

The argument so far has been about systems and structures. Here’s how those ideas translate into specific practices that Product leaders can implement.

Frame every roadmap initiative as a hypothesis

Before any initiative enters the “Now” column of a Now-Next-Later roadmap, it should have a clearly stated hypothesis: “We believe that [doing this thing] will result in [this measurable outcome] because [this evidence supports the bet].” This takes thirty seconds to write and fundamentally changes the team’s relationship to the work. It becomes a bet to be evaluated, with a predicted outcome and a method for checking whether the prediction held.

The hypothesis format also gives Product leaders the language they need for ROI conversations. Instead of “we shipped a new onboarding flow,” the narrative becomes “we hypothesized that simplifying onboarding would improve activation rates. We ran the experiment. Activation improved by 15% within 60 days of launch. Based on our average customer lifetime value, that improvement represents approximately $X in additional annual revenue.”

Use OKRs as the ROI scaffolding

OKRs work best when they function as the scaffolding for ROI measurement rather than as an isolated goal-setting exercise. The Objective states what the business needs. The Key Results define how success is measured. The initiatives on the roadmap represent the team’s bets for influencing those Key Results.

When this structure is in place, the quarterly OKR review becomes a natural ROI reporting moment. The Product leader walks through each Objective, shows which initiatives were run, reports on Key Result movement, and discusses what was learned. This isn’t a separate “ROI presentation.” It’s the normal rhythm of how the team operates.

Bruce McCarthy, founder of Product Culture and co-author of Product Roadmaps Relaunched, made this connection explicit in an OKRs vs. Roadmaps discussion with ProdPad, arguing that OKRs and outcome-based roadmaps are complementary pieces of the same system. The OKR defines the destination. The roadmap shows the route. The retrospective confirms whether you arrived.

Track the “anti-portfolio” too

One of the most powerful ROI arguments a Product leader can make is about the work the team chose not to do. Every Product team has a graveyard of rejected ideas, deprioritized features, and stakeholder requests that were redirected. Most teams let these disappear without trace.

Product leaders who keep a visible record of ideas that were evaluated and deprioritized, along with the reasoning, build a different kind of credibility. When a stakeholder comes back six months later asking why their pet project wasn’t built, the Product leader can point to the evidence: “We evaluated it. The strategic alignment was low. We invested in [this initiative] instead, which contributed to [this outcome].” That’s a credibility-building conversation that most teams never get to have because the decision trail doesn’t exist.

Speaking the Language of Business Value

Even with the right systems in place, Product leaders need to translate their outcomes into language that resonates with the people who control budget. This means connecting product outcomes to the financial and strategic metrics that the C-suite actually uses to make decisions.

Map product metrics to business metrics

Every Product metric ladders up to a business metric, but the connection isn’t always obvious to non-Product stakeholders. Activation rate connects to customer acquisition cost. Retention connects to lifetime value. Feature adoption connects to expansion revenue. Time-to-value connects to churn risk.

The Product leader’s job is to make these connections explicit. When presenting initiative outcomes, lead with the business metric, then show the product metric that moved it. “Net revenue retention improved by 3 points this quarter. The primary driver was a 20% improvement in feature adoption for our core workflow, which was the focus of Initiatives A and B on our roadmap.”

Build a rolling evidence base

Instead of creating a quarterly ROI presentation from scratch each cycle, maintain a running log of initiative outcomes. Every time an experiment concludes or a Key Result is updated, capture the result. Over time, this creates a compounding evidence base that makes the ROI argument stronger with every quarter.

The Product leaders who do this most effectively treat their evidence base as one of their most strategic assets. It’s what they bring to budget conversations. It’s what they share with new executives during onboarding. It’s what gives them the confidence to push back on feature requests that lack strategic alignment, because they have the track record to prove their judgment delivers results.

Show the cost of not investing in Product

ROI has two sides: the return on what you invest, and the cost of what you don’t. Product leaders who can quantify the cost of the status quo have a powerful additional argument. How much revenue was lost to churn that could have been prevented by addressing known product gaps? How many support tickets were generated by usability issues that the team has flagged but hasn’t been resourced to fix? How much Engineering time was wasted on rework because requirements were based on assumptions rather than evidence?

These “cost of inaction” arguments are particularly effective with CFOs, who tend to be more motivated by avoiding losses than by chasing gains.

How Product Earns Its Seat at the Table

The ROI challenge facing Product leaders is ultimately a credibility challenge. And credibility compounds. The Product leader who demonstrates value consistently, quarter after quarter, using evidence rather than anecdote, gradually shifts the organization’s perception of Product from a cost center to a value driver.

This shift changes everything. Budget conversations become investment conversations. Feature requests become strategic discussions about trade-offs and priorities. The CEO stops asking “what did Product do last quarter” and starts asking “what’s Product’s recommendation for how we should grow next year.”

Getting there requires more than good storytelling. It requires an operating model that generates evidence of value as a natural byproduct of how the team works. Strategy connected to goals. Goals connected to initiatives. Initiatives connected to customer evidence. Outcomes measured and recorded. Learning accumulated and shared.

The tools a Product team chooses shape the behaviors of the team. A delivery tool shapes behavior around output. A connected product management system, one that links strategy to discovery to delivery to outcomes, shapes behavior around value creation. And value creation, made visible and measurable, is how Product proves its ROI.

There’s no shortcut. No single dashboard or quarterly presentation will solve the credibility gap. But a Product leader who builds the system for capturing and demonstrating value, who makes it part of how the team operates rather than something bolted on afterward, will find that the ROI question eventually stops being a threat and starts being a strength.

When every product decision is informed by customer needs, aligned to strategic objectives, and evaluated against measurable outcomes, the ROI conversation answers itself.

The post Proving Product ROI: How to Demonstrate the Value of Product Work appeared first on ProdPad.

The result is a set of OKRs that technically passes muster but describes work nobody actually recognizes. The team spends the quarter doing one thing and narrating another. Leadership reads objectives that feel vaguely correct but never quite explain what is happening or why it matters. And at the end of the cycle, the retrospective lands on a frustrating conclusion: the key results moved (or didn’t), but nobody learned anything useful about whether the platform got better.

This pattern is everywhere, and it is corrosive. Platform work shouldn’t have to masquerade as revenue work to be valued. When it does, the OKR system is broken. The fix requires understanding why the model fails, what the real cost is, and what a better set of objectives actually looks like for teams whose job is to make other teams faster, more capable, and more autonomous.

Why Platform Impact Is Systemic, Not Singular

Platform teams exist to create leverage. They build shared services, tooling, data infrastructure, and developer experiences that enable multiple product teams to move faster. Their value is multiplicative, distributed across every team that depends on them. That is fundamentally different from a product team working on a checkout flow or an onboarding experience, where the line from effort to user outcome is relatively short and direct.

The attribution problem

When a platform team rebuilds the CI/CD pipeline and deployment frequency across the organization doubles, that improvement shows up in every team’s velocity metrics. When a data platform team creates a self-serve analytics layer, the product teams using it discover insights faster and ship better experiments. The value is real, often enormous, but it doesn’t land in a single metric that the platform team can cleanly own. This is what John Cutler has called the problem of teams that connect to revenue through several hops: the work is essential, but the path between effort and business outcome is long and branching.

Systems value versus feature value

Most OKR frameworks are implicitly designed for feature teams. They assume a world where a team works on a discrete capability, ships it, and measures whether users adopt it. That model works beautifully for teams building customer-facing product. It falls apart for teams whose “product” is another team’s ability to do their job well. The value a platform team delivers is systemic: it shows up as reduced cycle times, fewer incidents, faster onboarding of new engineers, and the ability for product teams to experiment without waiting six weeks for infrastructure. These are organizational health metrics, and the best Product organizations already know how to track them. The problem is that the OKR review process often treats them as second-class outcomes.

A shared vocabulary gap

Part of the difficulty is linguistic. Revenue, conversion, and retention are universally understood as “real” outcomes. Deployment frequency, service reliability, and developer experience lack the same organizational status, even when they are upstream of every single revenue metric leadership cares about. Without a shared vocabulary for the value of enablement work, platform teams are left translating their impact into somebody else’s language. The translation always loses something.

The Cost of Forcing False Alignment

When the goal-setting model does not accommodate platform work on its own terms, teams adapt. They find ways to survive the system. Every one of those adaptations has a cost, and over time, the costs compound into serious organizational damage.

Narrative debt

The most immediate cost is what might be called narrative debt: the gap between what a team is actually doing and what their objectives claim they are doing. A platform team that frames a major infrastructure migration as “improve checkout conversion by 2%” has created a story that is technically defensible but functionally dishonest. Leadership reads the OKR and thinks the team is working on checkout. The team knows they are working on infrastructure. Neither side gets the clarity they need to make good decisions. Melissa Perri’s observation about strategy being a decision-making framework rather than a plan is directly relevant here: when the framing is wrong, the decisions it produces will be wrong too.

Misallocated attention

False alignment distorts leadership’s mental model of where effort is going. If three platform teams all write OKRs that reference revenue metrics, the executive team’s portfolio view shows heavy investment in growth, when in reality, most of that effort is going toward reliability and developer experience. This is exactly the kind of roadmap theater that erodes trust between teams and leadership. When executives eventually discover the gap between the narrative and the work, the default response is skepticism toward the teams, when the real problem is a system that made honest reporting feel unsafe.

Lost learning

Good OKRs create a feedback loop: you set a target, you work toward it, and the key results tell you whether your approach worked. When platform teams write OKRs anchored to metrics they don’t directly influence, that feedback loop breaks. The key result might move (checkout conversion might tick up for reasons entirely unrelated to the infrastructure migration), but the team learns nothing about whether their platform work was effective. Or the key result might not move, and the team gets dinged in a review despite doing excellent, high-impact work. Either way, the organization has lost the ability to learn from the cycle.

Talent attrition

Strong engineers and Product Managers gravitate toward platform roles because the work is technically challenging and the impact is broad. Those same people leave when they realize the organization does not actually value what they do on its own terms. If every quarterly review requires a contorted explanation of how their reliability work somehow maps to a revenue metric, the message is clear: the organization considers their work secondary. That is how you lose your most capable infrastructure and platform talent to companies that know how to value systems work.

Designing Objectives That Allow Enablement to Exist

The solution is straightforward in concept, though it requires real commitment from Product and Engineering leadership: design your OKR framework so that enablement objectives are legitimate, first-class outcomes. This means changing what counts as a valid objective, how key results are structured, and how platform work is reviewed.

Create an explicit category for enablement objectives

Most organizations run OKRs with implicit categories: growth, retention, monetization. Platform work does not fit neatly into any of these. Adding an explicit enablement category (with names like “Engineering Velocity,” “Platform Capability,” or “Operational Health”) signals that the organization values this class of work. The category needs executive sponsorship and parity with customer-facing objectives in reviews. Marty Cagan makes a useful distinction between experience teams and platform teams, noting that the purpose of a platform team is to enable experience teams to better solve problems for their customers. The OKR framework needs to reflect that topology.

Write key results the team can actually influence

The single most common failure in platform OKRs is selecting key results that the team cannot directly move. A platform team should not own “increase revenue by X%” as a key result. They might reasonably own “reduce mean time to deploy from 45 minutes to under 10 minutes,” or “enable 80% of product teams to provision a new service without filing a support ticket,” or “reduce P1 incident frequency by 50%.” These are measurable, outcome-oriented, and directly within the team’s sphere of influence. The team can learn from whether these results move. That learning is the whole point.

Use leading indicators, not lagging ones

Revenue is a lagging indicator of many things, including platform health. Platform teams should anchor their key results to leading indicators: deployment frequency, build times, time-to-first-commit for new hires, API latency, error rates, the number of teams able to run experiments independently. These metrics move on a timeline that matches the team’s work cadence and provides actionable feedback. When a team sees that their refactored authentication service cut integration time for downstream teams from two weeks to two days, that is a real, valuable, measurable result.

Frame platform objectives as problems to solve

This is where outcome-based roadmapping maps directly to platform work. Instead of writing a platform objective as “migrate to Kubernetes” (an output), frame it as “enable product teams to scale services independently without waiting for infrastructure support.” The first describes a task. The second describes a problem to solve, and it opens space for the team to discover the best approach. Maybe the answer involves Kubernetes. Maybe it involves something else entirely. The Now-Next-Later roadmap is particularly well-suited for platform teams for exactly this reason: it separates the problem from the solution and gives the team room to experiment.

Build a review cadence that respects different time horizons

Platform investments often pay off over longer time horizons than feature work. A design system takes months to build and years to generate compounding returns. A data platform migration might show minimal measurable improvement in the first quarter but transform organizational capability over the next three. Quarterly OKR cycles work best when they are treated as a cadence of introspection rather than organizational delivery sprints. For platform work, this means setting key results that reflect progress toward a longer arc, reviewed quarterly but understood as part of a multi-quarter investment. Leadership needs to evaluate platform OKRs with that context, asking “are we learning and making measurable progress?” rather than “did we hit the number this quarter?”

What “So What” Looks Like for Internal Products

One of the hardest questions for platform teams is articulating the “so what” of their work in a way that resonates with business leadership. Revenue teams have a built-in “so what”: more revenue. Platform teams need to construct their own, and that construction requires deliberate practice.

The enabling condition framing

The most effective way to communicate platform value is through enabling conditions: “Our work created the conditions that allowed X to happen.” This is different from claiming credit for X directly. A platform team that reduced deployment time from hours to minutes did not “increase feature velocity by 30%.” They created the conditions that made a 30% velocity increase possible across the teams that used the new deployment pipeline. This framing is honest, verifiable, and significantly more compelling than a forced attribution to revenue.

Adoption as a success metric

Internal products succeed when other teams voluntarily adopt them. Adoption rate is one of the most telling metrics for platform work: if product teams actively choose to use the platform’s tools, APIs, and services rather than building their own, the platform is delivering value. Conversely, if teams routinely build workarounds to avoid the platform, that is a signal that the platform is failing to serve its users, regardless of what the OKRs say. Framing platform success around adoption, satisfaction, and time-saved for consuming teams creates an honest accountability structure.

The capacity unlock narrative

Every product leader understands that capacity is finite and expensive. Platform teams can frame their impact in terms of capacity unlocked: “This quarter, our self-serve provisioning tool eliminated an estimated 200 engineering hours of support requests from product teams.” That is 200 hours those product teams could redirect toward customer-facing work. Translated into loaded engineering cost, that is a number any CFO understands. The key is to measure and report these capacity effects explicitly, rather than hoping leadership will infer them.

Treat internal consumers as users, not colleagues

The best platform teams operate with the same rigor they would apply to an external product. They run discovery with their internal users. They measure satisfaction. They maintain a roadmap that is visible and outcome-driven. They treat other engineering teams as customers whose problems they need to understand and solve, and they hold themselves accountable to outcomes that those customers care about. This mindset shift changes everything about how the team operates, and it gives leadership a much clearer lens for evaluating their impact.

Making the Organizational Shift

Recognizing the problem is the easy part. The harder work is changing the systems that created it. This requires coordinated effort from Heads of Product, CTOs, and platform leaders who are willing to redesign how their organizations set, review, and reward objectives.

Give platform teams a seat at the OKR table

In many organizations, company-level OKRs are set by business leadership and then cascaded downward. By the time they reach platform teams, the objectives have been filtered through revenue and growth lenses that don’t reflect infrastructure reality. Platform leaders need to be in the room when top-level objectives are being set, so they can advocate for enablement objectives at the organizational level. An objective like “increase engineering team autonomy and reduce cross-team dependencies” is just as strategically legitimate as “grow revenue by 20%,” and it needs a sponsor with enough authority to defend it in portfolio reviews.

Run platform retrospectives against platform metrics

End-of-quarter reviews for platform teams should center on platform outcomes: reliability, adoption, developer satisfaction, time-to-capability. If the review forces the team to narrate their quarter through revenue metrics they don’t control, the review process itself is the problem. Leadership can still ask how platform work connects to business goals (that is a legitimate and important question), but the primary evaluation should be against the outcomes the team set for itself, framed around the problems they were hired to solve.

Invest in tooling that supports strategic context

One of the anti-patterns that reinforces bad platform OKRs is the use of delivery tools as the primary system of record. When the team’s work lives in Jira tickets disconnected from objectives and product strategy, it is nearly impossible to see or communicate the strategic intent behind the work. A lean roadmapping tool that connects initiatives to objectives makes the strategic context visible by default. When leadership can open a roadmap and see that the platform team’s “Now” column is focused on reducing deployment friction, linked to an enablement objective with measurable key results, the need for narrative contortion disappears. The work speaks for itself because the system surfaces the intent.

How Platform Work Earns Its Place in the Product Portfolio

The organizations that get platform Product Management right share a common trait: they treat platform work as a legitimate product discipline, with its own users, its own outcomes, and its own accountability structure. They don’t force platform teams to borrow credibility from revenue metrics. They create space for enablement objectives to stand on their own, measured by the impact they have on the teams and systems they serve.

This is not a small shift. It requires CTOs who are willing to defend enablement objectives in executive reviews. It requires Heads of Product who design OKR frameworks with explicit room for systemic, non-customer-facing outcomes. It requires platform leaders who invest in measuring and communicating their impact with the same rigor they would apply to an external SaaS product. And it requires tooling that makes strategic context visible, so the connection between platform work and organizational outcomes is always clear.

The payoff is significant. When platform teams can write honest objectives and measure outcomes they directly influence, the quality of their work improves, the trust between platform and product teams deepens, and leadership gets a real view of where organizational investment is going. The OKR system starts doing what it was designed to do: create alignment through clarity, accountability through measurement, and learning through honest reflection.

Platform work is the foundation that makes everything else possible. The goal-setting model should reflect that, loudly and without apology.

The post Stop Making Platform Teams Pretend to Be Revenue Teams appeared first on ProdPad.