What I Ve Been Meaning To Tell You Actually Is
It sounds like a casual phrase you'd leave on a sticky note, but in practice it refers to a specific kind of unsolicited disclosure that shows up in project management, client work, and team handoffs. People use it when they realize — usually too late — that they've been omitting critical context from a report, an email thread, or a ticket comment. The term gained traction in tech project circles around 2019 when a mid-sized SaaS company started using it as an internal label for retroactive clarification requests. Here's what it looks like in the wild. You ship a release. Two weeks later someone slides into a group channel and says, "Hey, I've been meaning to tell you — the API we referenced in the docs actually only returns null for region code DE." Nobody asked for that. It wasn't in the pull request. It wasn't in the testing notes. It just existed in one person's head and sat there until it became a production issue. The pattern repeats across departments. Engineering hands off a feature to support without documenting an edge case. Marketing sends a press asset to the design team and forgets to mention the brand guidelines changed last quarter. A freelance contractor finishes a task and realizes they never told the stakeholder that the deliverable has a licensing restriction attached.
It's not gossip. It's not drama. It's deferred communication, and it costs real money in remediation time.
How to Catch Your Own I Ve Been Meaning To Tell You Moments
The workaround I use is brutal but effective. I keep a running document called the "Late Disclosure Log." Every time someone tells me something they should have said upfront, I log it with a timestamp, the project name, and what was omitted. After six weeks I had about forty entries. The top three omissions were: environment-specific behavior, data retention policy, and third-party rate limits. Those three accounted for roughly sixty percent of post-launch fire drills at my last place. If you want to operationalize this, set up a lightweight template in your project management tool. I use a simple Notion database with five fields: who, what was omitted, which project, when it was discovered, and impact level. Tag everything with late-disclosure. Review the tag twice a sprint. You'll start seeing patterns in who consistently withholds information and why.
Get the Full Details
Preventing It Before It Happens
Most late disclosures come from one of three root causes. First, people don't know what the recipient actually needs. Second, they assume the information is obvious. Third, they're afraid the news will slow things down. The fix for cause one is a handoff checklist. Not a corporate fifty-item form. Five questions maximum. "What could break?" "What did we skip testing?" "What assumption are we making?" "Who needs to know this before Friday?" "What would you want someone to tell you if you were picking this up cold?" Put those on every ticket that crosses a boundary. Engineering to QA. Marketing to design. Vendor to internal team. For cause two, the simplest intervention is a one-line prompt in your standup template: "Did you withhold anything that would change how this team plans?" It sounds repetitive. It is. But the first time someone says "actually yes, we didn't validate the schema on this endpoint" instead of letting it surface during a customer call is when you know it's working.
Cause three is the hard one. Fear of bad news doesn't go away with a checklist. What helped my team was establishing a rule: bad news delivered early is free. Bad news delivered late costs the project timeline. We put that on a whiteboard. It's still there. People reference it when they're about to stay quiet.
A Real Case Where This Almost Tanked a Launch
Last year I was managing a migration for a client moving their payment processing from Stripe to a hybrid Stripe-Adyen setup. The engineering lead had built the integration, run it through staging, and declared it ready. Two days before go-live, the QA analyst messaged me privately and said, "I've been meaning to tell you — the Adyen sandbox doesn't simulate declined cards the same way production does. We didn't test the decline path properly." We caught it forty-eight hours out. We couldn't retest the full pipeline in time, so we pulled in a contractor who specialized in payment gateway edge cases. He wrote a targeted decline-simulation script that covered the critical paths we couldn't verify. Launch happened on schedule. It was not comfortable. It was also avoidable. The QA analyst had noticed the sandbox discrepancy three weeks earlier. She just didn't escalate it because she assumed the engineering lead would have already checked. After that, we made it a hard requirement: any tester who spots a gap between test environment and production behavior must file a late-disclosure ticket within twenty-four hours. No side conversations. No Slack DMs to managers. A ticket with a deadline. The volume of tickets dropped by roughly seventy percent over the next quarter, and zero launch-critical issues emerged from undisclosed test-environment differences.
When the Phrase Is Being Used As a Weapon
Not every "I've been meaning to tell you" is innocent. Sometimes it's a power move. A teammate delays sharing a concern until after a decision is made, then drops it in a meeting to undermine the original plan. Or someone withholds a constraint during planning so the project gets committed, then reveals it during execution when there's no room to adjust scope. If you're on the receiving end of that pattern, document it. Track the timing between when the information was known and when it was shared. If someone consistently discloses facts two weeks after a commitment is locked in, flag it in your one-on-ones. The conversation is usually: "I notice this pattern and it's creating rework. Can you share concerns earlier next time?" Most people don't realize they're doing it. A few do. Those are the ones who need a different kind of conversation entirely.
Tools That Help
There isn't a single tool designed specifically for this, but several workflows reduce late disclosure naturally. Confluence has a "pending review" status you can apply to pages. Jira supports blocked and awaiting-info transitions that surface gaps visually. Even a shared Slack channel named #unsaid-things works if your team actually uses it. The medium matters less than the habit of making withheld information visible before it becomes damage. If you want something lightweight, I recommend a simple Google Sheet shared across the team with columns for "Withheld Item," "Discovered On," "Project," "Impact," and "Root Cause." Fill it in anonymously if needed. Review it monthly. The data alone changes behavior faster than any policy memo.
Bottom Line
I've been meaning to tell you is either a symptom of poor communication habits or a deliberate delay tactic. There's no middle ground where it's harmless. The people who treat it as a measurable risk — logging it, tracking it, building checklists around it — tend to have fewer post-launch emergencies. The ones who ignore it accumulate technical and relational debt until something breaks loudly.
