The Idea Nobody Could Steal

Every now and then I remember a conversation I had years ago with a friend who had spent much of his career working for Colombia's tax authority.

He knew the construction and infrastructure sectors very well, and through his work he had learned a lot about the ways some companies avoided paying taxes. He believed he had developed a methodology that could help the government identify some of those practices and potentially recover significant amounts of unpaid taxes.

He wanted to turn that knowledge into software.

I was interested, so I asked him to explain how the methodology worked. He wouldn't.

His concern was that once I understood the idea, I could build the software myself and move ahead without him.

At the time, I thought there was a fairly straightforward solution. I proposed that we sign a non-disclosure agreement. If his concern was that I might use what he shared, putting the confidentiality terms in writing seemed like a reasonable way to protect him while allowing us to explore whether the idea could actually become a product.

He still wasn't comfortable sharing it.

So there wasn't much else I could do, and the conversation ended there.

I didn't think much about it afterward. But the years passed, the software was never built, and as far as I know, the methodology was never tested with the government. There was no prototype, no pilot and no evidence showing whether his approach could actually improve tax collection.

What stayed with me is that nobody ever rejected his idea.

The government didn't say it was bad. A customer didn't choose a competitor. The technology didn't fail.

It simply never got far enough for any of those things to happen.

I've thought about that conversation differently as I've spent more years building software and working with founders. I've seen people invest months and sometimes significant amounts of money developing products based largely on what they believe customers need, only to discover after launch that the assumptions they started with weren't quite right.

Sometimes the problem exists, but isn't painful enough for people to pay to solve it. Sometimes the problem is real, but the workflow works differently than expected. Sometimes users like the idea but aren't willing to change their behavior. And sometimes what looked like a great opportunity from the inside looks much less compelling once actual customers are involved.

This is why I no longer think my friend's story was mainly about someone stealing an idea.

I think it was about risk.

His instinct was to reduce risk by protecting what he knew. That's understandable. If you've spent years developing specialized knowledge, giving it away to someone who might use it without you doesn't sound particularly smart.

The problem was that protecting the idea addressed only one possible risk while leaving a much larger one untouched: nobody knew whether the idea actually worked.

There was a methodology, but no evidence that it would identify more tax evasion than the government's existing processes. There was a potential customer, but no evidence that the government would adopt it. There was an idea for software, but no evidence about what that software would actually need to do in a real workflow.

All of those questions were still unanswered.

And the only way to answer them was to expose at least part of the idea to reality.

This is something I think founders often misunderstand about validation. Validation isn't necessarily about telling the world everything you've invented, nor does it mean ignoring legitimate intellectual property concerns. There are situations where confidentiality, patents or other protections make perfect sense.

But you can protect sensitive parts of an idea and still test whether the underlying assumptions are true.

You can talk to potential customers about the problem without revealing the solution. You can test a workflow with a simple prototype. You can run a limited pilot. You can measure whether the outcome you expect actually occurs.

The point isn't to prove yourself right. It's to find out what you're wrong about before being wrong becomes expensive.

That distinction has become more important to me over the years.

Building software creates a feeling of progress because something tangible is happening. Screens appear. Features work. The product starts looking real. But none of that necessarily tells you whether you've made the right decision.

A working product can still be built around the wrong assumptions.

I've seen that happen enough times that today I would rather discover an uncomfortable truth in a conversation or a small experiment than after six months of development.

In my friend's case, even a small test could have changed everything. Perhaps the methodology would have worked remarkably well and created the evidence needed to get the government's attention. Perhaps the government would have liked the concept but identified constraints he hadn't considered. Perhaps the test would have shown that the approach didn't work at all.

Any of those outcomes would have been useful.

Instead, he was left with something that couldn't really improve because it couldn't be challenged.

I also wonder whether there's another reason people sometimes hold ideas so tightly.

When an idea exists only in our heads, it's easy to imagine its potential. We know all the reasons it should work. We can picture the customers using it and the problem disappearing. Once other people become involved, things get messier. They ask questions we didn't anticipate. They don't react the way we expected. They care about things we thought were unimportant and ignore things we considered essential.

That's uncomfortable, but I've come to see it as part of the work.

An idea usually changes considerably between the moment someone first describes it and the moment it becomes a useful product. The learning that happens in between isn't a distraction from execution. It is part of execution.

My friend's idea was never stolen. Nobody copied the methodology and beat him to market. The outcome he was trying so hard to prevent never happened.

But neither did the outcome he wanted.

Years later, that's what I find interesting about the story.

We tend to think of risk as something that comes from taking action: sharing an idea, showing an unfinished prototype, letting a customer question our assumptions. Yet there is also risk in avoiding those things, and it is much harder to see because nothing dramatic happens.

You just don't learn.

And when you're building something new, not learning may eventually become more expensive than being wrong.

If I had that conversation with my friend again today, I wouldn't try to convince him to reveal everything. I would probably ask a different question:

What is the smallest thing we could test without giving away what you need to protect?

Because after years of building software, I've learned that an idea doesn't need to be exposed recklessly.

But it does need to meet reality.