To connect your roadmap to OKRs, write objectives about customer outcomes, pick key results you can measure in your product or business, and tag every roadmap item with the key result it is meant to move. Customer feedback tells you which problems deserve an objective and which items are likely to move a key result. It is evidence for the plan, not the scoreboard.

TL;DR: An objective names a customer problem worth solving this quarter. A key result is a measurable change that proves you solved it, like retention, activation or support volume, never "ship X" or "get N votes." Tag each roadmap item with the key result it supports, and re-rank the roadmap mid-quarter when new feedback shows a better bet.

OKRs (Objectives and Key Results) started at Intel under Andy Grove and were spread widely by John Doerr, who brought them to Google. The idea is simple: one qualitative goal, a few numbers that tell you whether you reached it. This post is about the specific problem product teams run into: how to make OKRs and customer feedback point at the same work.

What is the difference between an objective and an activity?

An objective describes a change you want to see in the world. An activity describes work you plan to do. Most weak product OKRs are activities written in objective clothing.

  • Activity: "Launch the new reporting module."
  • Objective: "Finance teams can close the month without exporting to spreadsheets."

The first one is done the day you ship, whether anyone uses it or not. The second one is done when finance teams actually stop exporting, which might take the reporting module, a CSV fix and better onboarding. Writing the objective this way leaves room for the team to find the cheapest path, and it gives customer feedback a clear question to answer: are finance teams still complaining about month-end?

A quick test: if the objective could be marked complete by merging a pull request, it is an activity.

What do feedback-backed key results look like?

Each example below starts from a theme that showed up in feedback, turns it into an objective, and picks key results that measure the outcome. All three are hypothetical; the numbers are there to show the shape, not to suggest targets for your team.

Example 1 (hypothetical): onboarding friction

Feedback theme: New accounts keep asking how to invite teammates, and several trial users say they gave up before seeing value.

Objective: New teams get to their first useful result in their first session.

  • KR1: Share of new workspaces that invite at least one teammate within 7 days goes from 35% to 50%.
  • KR2: Median time from signup to first completed core action drops from 3 days to 1 day.
  • KR3: Support tickets tagged "onboarding" per 100 new signups drop by a third.

Example 2 (hypothetical): a blocking request from key accounts

Feedback theme: A small number of large accounts say missing SSO is blocking wider rollout. Few votes, high pain.

Objective: Larger customers can roll the product out company-wide without security exceptions.

  • KR1: Number of accounts with 50+ seats that have SSO enabled goes from 0 to 10.
  • KR2: Expansion revenue from accounts that flagged SSO as blocking reaches a set amount.
  • KR3: Zero open security-review blockers in active expansion deals by quarter end.

Example 3 (hypothetical): repeated complaints about reliability

Feedback theme: Comments mention slow load times and failed syncs across many posts, but no single request has many votes.

Objective: Customers trust that their data is current.

  • KR1: Sync failures per 1,000 syncs drop by half.
  • KR2: 95th percentile dashboard load time is under 2 seconds.
  • KR3: Posts and tickets tagged "sync" or "slow" per month drop by half.

Notice what example 3 shows: some of the most important themes never become a single popular request. They show up as a pattern across tags and comments. That is why feedback needs to be tagged consistently, as covered in our guide to the customer feedback system.

Why are votes evidence, not key results?

It is tempting to write a key result like "close the top 10 most-voted requests" or "reach 500 votes on the new board." Both are bad key results.

Votes measure how many people asked. They do not measure whether the thing you built solved their problem. If you ship the top request and nobody uses it, the vote-based key result says you won.

Vote-based key results also invite gaming. Teams start pushing customers to vote, or ship the most-voted item instead of the most valuable one. The key result goes green while the product gets no better.

Use votes, comments and requests the way a lawyer uses evidence: to argue that a problem is real and that a particular piece of work will move the outcome. The outcome itself (retention, activation, expansion, fewer tickets) is the key result. To weigh that evidence fairly across customer types, see prioritizing feature requests by customer segment.

How do you tag roadmap items to OKRs?

Every item on the roadmap should answer one question: which key result is this supposed to move? If the answer is "none," the item is either a deliberate bet outside the OKRs (fine, but say so) or something that should not be there.

FeatureOS does not have a dedicated OKR feature. Tagging roadmap items to OKRs is a process you run with the boards, tags, custom fields and roadmap it already has. Here is a setup that works:

  1. Create one tag per key result for the quarter, with a short, consistent name, like Q1-KR-onboarding-invites or Q1-KR-sso-accounts. Use the same naming every quarter so old tags sort cleanly.
  2. Tag each request that supports a key result. When a post is approved for the roadmap, the PM adds the matching key-result tag. One item can support more than one key result, but if it supports all of them, it probably supports none clearly.
  3. Build a roadmap view per objective. Save a filter for each objective's tags and use it to populate a roadmap, or filter your main roadmap by tag during planning. Anyone can then see every item aimed at one objective in one place.
  4. Keep the evidence on the post. The votes, comments and customer links already sit on the request. Do not copy them into a separate OKR doc where they go stale.
  5. Mark the bets. For roadmap items with no customer evidence, add a tag like bet-no-feedback. It keeps the team honest about how much of the quarter rests on conviction.

If you also record segment or plan on each request with board custom fields, you can filter one objective's items by segment to check that you are not building only for one group.

For the full path from request to roadmap to changelog, see how to turn feedback into a roadmap.

How do you re-rank the roadmap mid-quarter?

OKRs are set once a quarter. Feedback does not wait. A mid-quarter review keeps the two in line without throwing out the plan.

Around week six, the product lead and the feedback owner look at three things:

  • Are the key results moving? If a KR has not moved at all, the items tagged to it may be the wrong ones.
  • What came in since planning? Look at new themes and any request whose weighted evidence jumped. Check which of those posts are already tagged to an objective, and which are not.
  • Did anything change the objective itself? Occasionally feedback shows the objective was aimed at the wrong problem. That is worth knowing early.

Then decide. Usually the answer is to swap one or two items: drop something tagged to a stalled KR and pull in a request with stronger evidence for the same KR. Keep the objectives fixed unless the evidence is overwhelming; changing goals every few weeks defeats the point of having them.

Tell customers when you change course. If an item they voted for moves off the roadmap, update its status and write a short note on the post. Closing the feedback loop applies to "not now" as much as to "shipped."

What are the honest limits?

  • Feedback lags. Customers react to what exists. A key result about a brand new capability will have little feedback behind it at the start.
  • Some KRs are not customer-facing. Infrastructure cost or hiring goals will not show up on a feedback board, and that is fine.
  • Tags drift. If nobody owns the key-result tags, they go stale within weeks. Make the feedback owner responsible for them.
  • FeatureOS will not compute KR progress for you. Product and revenue metrics live in your analytics and billing tools. FeatureOS holds the evidence and the roadmap.

Try it on your next quarter

FeatureOS gives you boards, tags, custom fields, a roadmap and a changelog that notifies voters, which covers the feedback side of this process. Pricing is seat bundles: Starter $60/month for 5 seats, Growth $120/month for 10, Business $250/month for 15, and $15 per extra seat. There is no free plan. See pricing.

Start a 14-day FeatureOS trial (we can extend it to 30 days if you need more time), create one tag per key result for next quarter, and tag the requests you plan to build. If you want the wider program around this, read our guide to running a voice of customer program.