The Two Loops That Never Touch

The meeting was called Q3 OKR review. We were in a small room with a projector that did not quite work. Twelve people, three different teams, one shared spreadsheet open on the screen behind the speaker.

Goal owner stands up. "We missed our OKR by 12 points. The team did a lot of good work this quarter. We learned. Let's carry it into Q4."

Everyone nodded. The next slide was already loading.

I had sat through versions of this meeting at three different companies. I knew the choreography. The CPO knew the choreography. The team knew it. We all played our parts. Then we went back to our desks and worked on the things we had actually planned to work on, which mostly were not the things on the slide.

That afternoon I was on a customer call. A long-term account told me, with the casual honesty that long-term accounts use, that the feature they actually needed had been on the wishlist for two years and was still not on any roadmap they had been shown.

Two meetings. Same day. Two loops, both running. Neither aware of the other.

The Bridge Is Usually Another Ceremony

Every org I have worked in has tried to bridge the gap. The bridges came with names. OKRs. Initiatives. North Star Metric. Now-Next-Later. PI Planning. Quarterly Business Reviews. Theme-based Roadmapping.

The pattern was the same every time. Somebody noticed that strategy and feedback were not talking. Somebody proposed a process to make them talk. The process became its own thing, with its own owner, its own template, its own cadence, its own review meeting.

Six months later the new ceremony was running, the two loops were still not touching, and the org had one more thing to maintain.

The mistake is treating the gap as a coordination problem. It is not. It is a structural one. Strategy and feedback do not connect because they speak different languages and live on different cadences. Strategy is annual or quarterly, written in goals and bets. Feedback is continuous, written in support tickets, demo recordings, and the third bullet of a sales call summary. You can put both into the same review meeting, but you have not actually connected them. You have only put them in the same room.

What Strategy and Feedback Are Actually Doing

If you look closely at a product org, the two loops are doing something more specific than people usually describe.

The top-down loop is making promises. Promises about direction, about which markets we will serve, about what kind of company we are becoming. Those promises live in strategy decks, OKRs, board reviews, and the careful language of "we want to be the leader in X by Y".

The bottom-up loop is collecting symptoms. Customer pain, churn signals, sales objections, the unmet need that shows up in three demos in a row. It is messy, partial, sometimes wrong, but it is the only data the team has about whether the promises are landing.

Strategy without feedback is belief. Feedback without strategy is chaos.

Most orgs end up running both loops cleanly and still shipping solution-driven work. Because between the promise and the symptom, there is a missing third thing. Without it, the team's only option when planning the quarter is to look at a list of feature requests, sort by something defensible, and call the top of the list "the roadmap".

That is the loop that actually runs. The strategy review is a quarterly performance. The feedback synthesis is a continuous chore. The thing that ships is whatever the loudest stakeholder pushed in the last sprint.

The Quiet Cost

What gets lost is the ability to answer a very simple question. Do we have the thing the customer is asking for, yes or no.

I started keeping informal track of how often I could answer that question without opening four tabs. The answer at multiple companies was almost never. Sales asked product. Product asked engineering. Engineering opened the codebase. The codebase had three answers depending on which module you opened. The original strategy bet that justified the work in the first place was nowhere in the chain.

The cost is not only operational. It is strategic. When you cannot honestly answer "do we have this", you cannot honestly answer "should we build this next". You end up either rebuilding things you already have, or shipping near-duplicates because nobody knew the first version existed, or worst, killing real opportunities because they were buried under feature requests that already had three workarounds shipped.

OKRs do not fix this. Neither do initiatives, north star metrics, or whatever acronym your org currently treats as the top-line truth. They all sit at the wrong altitude. They describe ambition. They do not describe what you have.

Capabilities Are the Bridge

The middle layer that has been missing is not another ceremony. It is a capability.

A capability is the part of the product that can actually do something. Not a feature, which is the surface. Not a strategy, which is the promise. Something in between. "We can ingest customer feedback from sales calls and surface clustered themes to a PM" is a capability. "We rank initiatives by impact and effort and align them to strategic pillars" is a capability. "We can answer 'do we have that' in under thirty seconds" is a capability.

Capabilities are the thing strategy is asking for and feedback is asking about. They are the only honest unit of inventory a product org has.

• Strategy points at the capability we want next.
• Feedback tells us which capability is missing or broken.
• Discovery turns a strategic bet plus a feedback signal into a capability hypothesis.
• Delivery ships the capability, and a thin set of features around it.
• The next loop starts with the capability already on the shelf, ready to answer the next question.

What changes is the conversation. Instead of "did we hit the OKR", the question becomes "what capability did we have at the start of the quarter, what capability do we have now, and what did the difference cost". That is a question you can answer without theater.

The Acronym Test

If you have run product in the last ten years, you have lived some version of this dance. You have probably invented or inherited an artifact meant to bridge strategy and feedback. There is a good chance it came with its own acronym.

Try this. Ask the most senior person on your product team to describe, in one sentence, the difference between your roadmap and your strategy. Then ask the most junior PM the same question. If the answers do not match, the bridge you are running is a ceremony, not a structure.

The product orgs that will look obvious in five years are the ones that figured out the bridge cannot be another meeting. It has to be the part of the product that can actually do something. The two loops will keep running, because they should. What changes is whether they end up looking at the same thing when they finally do meet.

That thing is not an OKR. That thing is the capability you already have, or the one you do not yet.