The Strategy to Product Gap

Strategy travels down to teams every quarter. Reality rarely travels back up.

5 minute read

Product leaders spend enormous energy translating strategy down, turning an executive narrative into a roadmap teams can actually build against. Almost none of that energy runs the other direction. In many organizations, nobody owns translating what teams learn while building (this feature didn’t move the metric, that segment doesn’t behave like the strategy assumed) back up into a change in investment allocation.

The result isn’t that strategy is wrong on day one. It’s that investment remains allocated the same way for two more quarters after the teams executing it already know it’s off, because there’s no structural path for that knowledge to travel upward and get acted on.

I made this case at a previous employer more than once, arguing for reallocating investment in a room where reallocation wasn’t the expected agenda item. It’s a harder pitch than it sounds, not because the data is unconvincing, but because there’s no standing mechanism for that conversation (“the money is already spent”), so I had to manufacture the moment every time.

Breaking the Loop

Atlassian’s State of Product 2026 survey of more than 1,000 product professionals found that nearly half of product teams don’t have enough time for strategic planning, roadmap development, or the data analysis that might tell them whether the current allocation is working. Eighty percent of product teams don’t involve engineers during ideation or problem definition, the people with the clearest read on what’s actually buildable.

 
Plenty of orgs I’ve watched adopt “product-led” as a mentality without building the mechanism that makes it real. The label changes. The flow of information doesn’t. Technical constraints, design trade-offs, customer pain points, whatever teams learn while building rarely makes it back into the data analysis that’s supposed to drive the next strategy cycle.

Neither number above is direct evidence of a reallocation gap on its own. Atlassian measured time constraints and how late engineers get pulled in, not whether anyone revisits a spending decision once it’s made. Together, though, they describe conditions where that kind of gap could persist. Teams too stretched for planning and analysis are less likely to catch a bad bet early, and teams that build without their engineers lose the people best positioned to flag that the plan isn’t buildable as assumed. Neither finding says anything about a mechanism for that signal to travel back up into a reallocation decision. I haven’t found research that measures one. That’s my read of the structural version of the gap, built from watching it happen more than from these two numbers alone.

Why Reality Doesn't Travel Back Up

49%
of product teams lack enough time for strategic planning or data analysis
80%
don't involve engineers during ideation or problem definition

Source: Atlassian State of Product 2026

Translation Only Runs One Way

I’ve written before about the translation layer product leaders build between rooms, translating the same strategy differently for executives and for the team actually building it. That skill tends to get built early in a PM career, because the org rewards it visibly, in the planning meeting everyone remembers. Nobody applies the same discipline to translating backward, turning what a squad learned about a segment or a feature into a specific, dated recommendation to shift budget.

ProductPlan’s 2026 State of Product Management report, a survey of nearly 250 product professionals, found respondents most commonly cite resource and capacity constraints as a source of misalignment (49.2%), with 47.5% citing shifting short-term priorities (respondents could select more than one). My read is that’s execution pressure overriding intent, not an allocation-specific problem, though that framing is mine, not ProductPlan’s.

Misalignment often isn’t a strategy-clarity problem so much as a stale-allocation problem wearing a strategy-clarity costume. Teams usually know a bet isn’t paying off well before the next roadmap cycle admits it. What’s missing isn’t the signal. It’s a standing place for that signal to turn into a reallocation ask instead of getting absorbed into “we’ll revisit next quarter.”

 
A quarterly roadmap review is not a feedback loop. It reports on execution against last quarter’s allocation. It rarely asks whether last quarter’s allocation was the right one, and almost never with enough lead time to change the next one.

Building What’s Missing

The fix I’ve used isn’t a new meeting. It’s a standing question added to a review that already exists, a quarterly roadmap review the organization already runs, with one difference: a named person is accountable for answering it, and it’s asked before the review moves on to the next agenda item. That person isn’t deciding the reallocation. Their job is to turn what the team learned into a specific ask and put it in front of whoever actually controls the budget, every quarter, whether or not anyone asked for it.

What did we learn this quarter that should move a dollar or a headcount somewhere else, and who’s putting that in front of the person who controls the budget?

 
If nobody can answer who owns the reallocation recommendation, the loop doesn’t exist yet. A dashboard showing the data isn’t the same as a person accountable for acting on it.

That single ownership question changed how those teams talked about allocation more than any strategy offsite I’ve run. Starting it didn’t need executive permission, just one person willing to be the name attached to the recommendation and the discipline to bring it every quarter. Getting the reallocation approved is a different step, the same room-manufacturing I described earlier, and that one does need budget authority or the chain of command behind it. Naming and documenting the question is free. Selling the answer still takes work.

Iterating It

The part I haven’t solved is cadence. Move too fast and the reallocation chases noise, a bad week mistaken for a bad investment thesis. Move too slow and the two-quarter lag that created this problem in the first place comes right back. I’ve hit and missed this a few times, though I’ve thankfully had great teams that made it easy to act fast once a reallocation was approved. The review cadence should match how fast the team can actually act on a change, not how fast the data happens to arrive.

What would you have reallocated last quarter if someone had asked you the question in time?