"I Think" Means "I Haven't Tested This"

I was on a dev call a while back, working through the build of a chatbot product with my team. We were going feature by feature - file uploads, Slack integration, the chatbot initialization flow, domain migration. Standard stuff.

About twenty minutes in, I started noticing something.

Every time we hit a rough edge - something that wasn't quite working, something that hadn't been fully wired up yet - one of my developers would say the same two words: I think.

"I think it's the greeting message."

"I think it will be seamless once we move it to the backend."

"That should be a day or two."

"I think it was included in the single file API."

I think is a confession.

Every time a developer says "I think," they mean: I have not tested this.

Every unverified feature in your build lives inside those two words. That's the insight.

Why Non-Technical Founders Get Burned

If you're a non-technical founder, you're in a difficult position. You're paying someone to build something you can't fully evaluate yourself. You're relying on them to tell you when things work and when they don't. And you want to trust them - especially if they're smart, experienced, and clearly working hard.

So when your developer says "I think this is working," your brain hears: "This is working." You nod and move on. It goes in the "done" column in your head.

And then three days later, a user messages you saying the text is unreadable. Or the AI initialization isn't firing. Or the embed on their landing page is completely broken.

And you go back to your developer and say what happened, and they say - and I guarantee you this - "I thought it was working."

There it is again. I think.

Founders who ship tight products learned to hear "I think" as a warning.

What Happened on That Call

Here's what this looked like in practice.

We were reviewing the chatbot creation flow. The developer showed me a button that was supposed to tell the user the AI was being set up. The label said "next notification."

I stopped him there. "I would change that to 'create chatbot' - that way the user knows it's going to take 30 seconds. 'Next notification' doesn't tell me anything."

He said, essentially, yeah, that makes sense. Then added: "Once we move this to the backend, it will be very seamless."

Will be. I think. Same family of words. The backend move hadn't happened yet. So whatever he was picturing - that seamless experience - was theoretical. Not verified.

We kept going. We hit the message display. The text was black on a black background. Completely unreadable. Nobody had caught it before the call because the team was doing testing in the same browser, with cached data loaded. The developer figured out the fix, but the point stands: something that had been "working" in development was broken in front of me in real time.

We hit the file upload and AI knowledge base. I asked about passing a URL directly into the assistant setup. One developer said something like - and I'm paraphrasing - "I'm not sure, I think it should be handled on the backend." Which, when we dug in, turned out to be correct. But notice what happened: we had to dig in. We had to ask the follow-up questions to get from "I think" to "here's the confirmed architecture."

We hit the domain migration. We'd moved from one domain to another for the product, and I asked whether that fixed a broken embed issue users had been experiencing. The response: "I don't think so... maybe. I'm not sure." Meaning: nobody had checked.

We hit the chatbot initialization failure - a user had reported that they couldn't get their AI set up at all. I asked about it. The developer said: "I'm aware of it. I will make sure." Meaning: it hadn't been fixed yet. It was known but neither resolved nor tested.

Over and over, on a single call: I think. I'm not sure. I'll have a look.

Each phrase is a flag. Each one marks what the team believes versus what they've confirmed.

The One Question to Ask on Every Dev Call

Fixing this doesn't require you to learn to code or become a QA engineer. It requires one question, asked every time you hear "I think."

Have you tested that?

Four words. The answer tells you whether the feature is done.

If the answer is yes, ask them to show you. Right now, on the call. Developers are not trying to deceive you - they believe the thing they built is probably working. But "probably working" and "I just confirmed it works" are two completely different things, and only one of them belongs on a shipped feature.

If the answer is no, you've just saved yourself a user complaint. Whatever was in the "I think" bucket goes back onto the task list with a specific test attached to it. Skip "look into it" and "make sure" - give it a specific, observable test: "Navigate to X, do Y, confirm Z happens."

The greeting message was blank. Fill it in and show me it renders.

The domain migration should fix the broken embed. Have you tested that navigating to the new domain loads the embed correctly? Show me.

The file character limit approach should work. Have you tested uploading a file at the limit and one above it? Show me.

The discipline of "show me" transforms your development process. Bugs live between "I think" and "confirmed."

The Character Limit Conversation (This Is How It Should Go)

I want to be fair here, because the same call that surfaced all of those "I thinks" also had a moment that went exactly right.

We were discussing how to limit how much data a user can feed into the chatbot's knowledge base. Someone suggested capping it by file size. One of the developers pushed back: file size isn't accurate, because a single page could contain a huge amount of text data. The right limit is by character count.

Here's what I liked about that exchange: instead of saying "I think character count would work," the developer explained the constraint. A single URL could contain fifty URLs' worth of content if someone wanted to game the system. File size wouldn't catch that. Characters would.

That's the difference between a hypothesis and an argument. A hypothesis is "I think this will work." An argument is "here's the constraint we're solving for, here's why this approach addresses it, here's how we'd implement it." You can test an argument. You can build on it. It earns a decision.

My response: "That's smart. Character limit is the only accurate way to calculate this. Do it." Decision made, task defined - everyone knew what came next.

That's what every "I think" conversation should resolve to. Not ambiguity. A decision with a test attached.

What This Looks Like at Scale

This is a management problem. And you'll see it in any team you build with.

It shows up when a salesperson says "I think I followed up with that prospect" - which means they probably didn't, or at least didn't log it. A marketer saying "I think that campaign is live" means they sent the request but didn't confirm delivery. It shows up when a contractor says "I think that was included in the scope" - which means check the contract, because nothing was confirmed.

In every case, the approach is the same. You hear "I think," you pause, and you ask: "Have you confirmed that? Can you show me?"

Build the habit - in yourself and in your team - of closing the loop between intention and verification. The people who work with me know that "I think" triggers a follow-up. That's a system. And over time, they start pre-empting the question. They don't say "I think the integration is working" anymore. They say "the integration is working - here's the test I ran."

That's the culture you're building when you train yourself to hear this phrase correctly.

The Founder's Blind Spot

There's a version of this problem that hits founders building their first technical product.

You hired someone because they know more than you. That's the trade you made. So when they say something with any degree of confidence - "I think this is working" - you defer to it, because they're the expert. So you don't challenge the expert.

They know the code they wrote. The architecture is theirs. They know what it's supposed to do. What they don't always know is whether it works in the production environment, with production data, accessed by users who didn't build it and don't know the shortcuts.

On my call, one of the developers figured out that a bug was happening because we were testing in the same browser with cached session data. The fix was simple: clear the storage, refresh the page. But that bug would have hit every new user who opened the product for the first time, because new users don't have that cache.

The developer wasn't wrong to miss it initially. That kind of thing is easy to overlook when you're deep in the build. Focus on what happens when it surfaces. Ask the question, find the root cause, fix it. Then test it again. That's the loop.

What doesn't work is accepting "I think it's fine now" as the end of the conversation.

Running a Dev Call Correctly

At the start of the call, you're looking for what's confirmed versus what's in progress. Not a status update. A binary: tested and working, or not yet.

When you demo a feature, you're watching someone use it, live, in the same way a user would. If there's a reason they can't do that - the environment isn't set up, they need special access, the integration isn't live - that's a flag. Figure out why the real test environment can't be used and fix that first.

When a bug appears during the call - and on that call, multiple did - you don't move on until you have a clear owner, a clear test condition, and a date. Skip "I'll have a look" and "fix it soon" - you need a specific person, specific confirmation criteria, and a specific date.

At the end of the call, the only things in the "done" column are things that were tested on the call or tested before and can be demonstrated right now.

This is faster, because you're not spending the next three calls revisiting things that were supposed to be finished two weeks ago.

A Note on "Day or Two" Estimates

While we're here: there's a cousin of "I think" that's equally important to learn to hear correctly, and it's the timeline estimate.

"I think that will be a day or two."

In software, "a day or two" is a median. It means: best case, a day or two. The likely case adds whatever we discover once we start. Worst case, a week.

Building anything complex works this way. The estimate is made based on what's known now, and the unknown unknowns - which are, definitionally, unknown - don't get factored in.

So when you hear a timeline estimate, add buffer, get a check-in cadence, and don't make customer promises off the back of it. On the call I was on, we agreed to check in the next day and on Monday to assess where things stood. That's the right move. Keep the cycle short, keep visibility high, and don't plan the launch party until the features are confirmed.

The Bigger Lesson

Everything I've built - and I've built and sold five software companies - has had moments like that call. Moments where things were closer to working than to not working, where progress was being made, but where every "I think" was hiding a pile of small disasters.

Founders who close that verification loop ship tighter products, keep users happier, and move faster. Founders who don't end up revisiting supposedly-finished work on every call.

You don't need to become technical to do this. You just need to build one habit: every time someone says "I think," ask whether they've tested it. If they have, great - move on. If they haven't, it goes back on the list.

Two words. One question. It's the simplest QA process available to a non-technical founder, and it works.

If you want to go deeper on how to run sales and operational processes with the same level of precision - asking the right questions at the right time, building systems that don't rely on assumptions - check out the Discovery Call Framework I put together. The same principles that apply to dev calls apply to sales calls. The goal in both cases is to replace "I think" with confirmed facts.

And if you're at the stage where you want live coaching on building out your operations, sales, or product - calls with direct feedback, not just posts - that's what Galadon Gold is for. Come work through the problems in your business.

But start today with the simple thing: the next time someone on your team says "I think" - write it down. By the end of the week, you'll have a map of every unverified assumption in your company. That's a valuable document.