Words for Leaders: Stop Saying "Rework" When You Mean "New Requirement"
Watch the Video
Or watch it directly on YouTube: Click here
Video Description
You're in a product review meeting and you and your team are showing off your upcoming features. Your boss looks at the feature you just delivered and says "I don't like the green button, make it orange." The requirements don't say anything about button color. No one has ever mentioned anything about it before right now.
How would you handle this?
Option 1: "Ok. We missed that requirement. We'll hold that feature back and rework that in the next sprint."
Option 2: "Great feedback - we'll add that requirement to the backlog."
Here's why this frame matters. When you say "rework," you're subtly accepting blame for missing something that was supposedly already defined. You're framing it as failure - like you didn't do your job or messed up somehow.
But here's the thing: if the requirement wasn't clear enough for you to build it correctly, then it wasn't really a requirement yet.
"Rework" puts you on defense. "New requirement" puts you back in control. Now you can add it to the backlog and prioritize it against your other work.
Also, don't assume that new work automatically jumps to the front of the line just because someone calls it "rework."
It's never rework. It's always a new requirement to be prioritized.
Video Info
- Duration: 1:32
- Published: October 14, 2025