Rebuild, Work Around or Leave It: A 10-Minute Backlog Sort
Emily Goh ยท 2026-11-05
It's Thursday afternoon. You have a free half hour before your next call, and a backlog of 40 items that all look like they matter. A lead source picklist with 31 values. A territory rule that breaks every time someone changes region. An attribution report Marketing stopped trusting in the spring. A field called "Deal Type (new)" sitting right next to "Deal Type."
You could start on any of them. That's the problem.
Here is a simple RevOps prioritization framework you can run in 10 minutes. For each item, ask two questions. Is it still creating new bad records? Does anyone make a decision on what it feeds? Two yeses mean rebuild. A yes on decisions but no new damage means work around. Two nos mean leave it, on purpose and in writing. The goal is not a perfect ranking. It's to stop treating every item as a rebuild.
Why most backlogs only have one setting
Ops people tend to be fixers. When you see something broken, the instinct is to fix it properly: new field, clean migration, updated reports, documentation. That's a rebuild, and it's the most expensive thing you can do.
When every item gets the same treatment, the backlog never shrinks. You finish one careful rebuild and five new requests have arrived. Meanwhile the items actively damaging your pipeline wait in the same line as the ones nobody would notice.
A backlog needs three settings, not one. If you've already sorted your tickets by what they break (we covered that in Your RevOps Backlog Is Lying to You About What's Urgent), this is the next step: deciding how much to do about each one.
Two questions, three piles
Question 1: Is it still making new bad records? Some problems are a leak. Every new lead, deal or account gets the wrong value, and the cleanup grows each day. A routing rule sending leads to the wrong team is a leak. Other problems are a stain. The damage happened once, in an old import or a retired process, and it isn't spreading. A messy picklist nobody uses anymore is a stain.
Question 2: Does someone make a decision on what it feeds? Follow the field to where it ends up. If it feeds pipeline, forecast, comp, a board slide or a report leadership reads every week, the answer is yes. If it feeds a report nobody has opened since last year, the answer is no.
The answers sort into three piles.
Rebuild: leaking and feeding decisions. This is where your real project time goes. Patching a problem that creates new bad records every day just moves the mess downstream. Say your stage definitions let reps log "Proposal" before pricing is agreed, so every week a few more deals inflate pipeline. Fix the root cause.
Work around: feeding decisions, but not leaking. The damage is real but contained, and a full fix can wait a quarter. Do something small that stops people being misled: a note on the report, a filter that excludes the bad records, a one-time correction, a weekly check. Two rules keep a workaround safe. Give it an owner. Give it an end date. A workaround with neither becomes permanent, and soon nobody remembers why it exists.
Leave it: not feeding decisions. Old fields, legacy reports, a picklist nothing reads. Leaving these alone is a decision, not a failure. Write one line next to each: "Left on purpose, [date], nothing downstream uses it." That line saves the next person from rediscovering it and starting a rebuild.
There's a fourth combination: leaking, but not feeding any decision yet. Usually that goes to work around. A leak tends to reach something important eventually, so stop it cheaply and revisit.
The 10-minute version
Set a timer. Really.
- Minute 0 to 1. Pull your top 30 or 40 items into a list or sheet. Add two columns: "Leaking?" and "Feeds a decision?"
- Minutes 1 to 7. Go down the list fast. Yes, no or unsure for each. Don't debate. Don't open the CRM. Gut answers are fine on a first pass.
- Minutes 7 to 9. Put each item in a pile: Rebuild, Work around, Leave it, or Check (for the unsures).
- Minute 10. Count the Rebuild pile. If it has more than three or four items, you were too generous. Move the weakest ones to Work around.
Don't be surprised if most of the list lands in Work around or Leave it. That's the point. Your project time should go to the few items that are both leaking and feeding decisions.
What makes the sort go wrong
Treating "someone asked for it" as "feeds a decision." A request is not a decision. A field someone wants is not the same as a number someone acts on.
Skipping the end date on workarounds. This is how a backlog fills up with permanent patches.
Sorting arguments as if they were bugs. If Sales and Marketing want opposite changes to the same field, none of the three piles fits. That's a definition nobody has agreed yet. Send it to the person who decides before you build anything. The Definition Nobody Writes Down Is the One That Breaks Your Forecast explains why this matters so much.
Keeping the piles to yourself. The sort works better when stakeholders can see why their item moved. "Left on purpose, nothing downstream uses it" ends more debates than silence does.
If you're new in the role and still working out where to start, What Experienced RevOps Leaders Fix First (It's Not the Dashboard) pairs well with this. The rebuild, work around or leave it question is also the theme of our November Fireside, What Experienced RevOps Leaders Know That the Playbooks Don't Tell You.
What to do this week
- Run the 10-minute sort on your current backlog.
- Give every workaround an owner and an end date. Write both next to the item.
- Give every Leave it a one-line reason and today's date.
- Check your Rebuild pile properly. Open the reports those items feed and confirm who actually uses them.
- Share the three piles with your stakeholders by Friday.
Where Gohvio fits
The hardest question in the sort is "is it still making new bad records?" Gohvio helps you answer it with evidence instead of gut feel. You upload your own guardrails, the definitions your teams actually use, as a document. A person approves them, and each change is recorded with who changed it and when. Gohvio then checks your CRM data against those guardrails and shows what is broken, what it does to pipeline and forecast, and the rows behind every finding. It is read-only.
Stop debating your data. Start making evidence-based decisions.
Frequently asked questions
What is a simple RevOps prioritization framework?
Ask two questions of every backlog item. Is it still creating new bad records? Does anyone make a decision on what it feeds? Two yeses mean rebuild, feeding decisions without new damage means work around, and two nos mean leave it on purpose.
When should RevOps rebuild instead of working around a problem?
Rebuild when the problem keeps creating new bad records every day and those records feed pipeline, forecast, comp or leadership reports. Patching a problem that is still leaking just moves the mess downstream.
How do you keep a RevOps workaround from becoming permanent?
Give every workaround a named owner and an end date, and write both next to the item. A workaround with neither tends to stay forever, and eventually nobody remembers why it exists.
Is it okay to leave a broken CRM field alone?
Yes, if nothing downstream uses it to make a decision. Leaving it is a choice, not a failure. Write a one-line note with the date and the reason so the next person does not start a rebuild by mistake.