There's a question I come back to more often than any framework or mental model: am I creating new knowledge here, or am I working with something someone else has already figured out?

The answer changes everything about how you spend time and money on the problem.

If it's genuinely new, a product hypothesis nobody's tested, a technical approach without precedent – treat it like an experiment. Small bets, fast feedback, accept that most attempts won't work.

If someone's already solved it, your job is to find that person and learn from them. Not reinvent. Not "adapt to our context" as a justification for starting from scratch. Find the answer, bring it in, spread it.

At Kiwibank, we built shared CI/CD pipelines with regulatory controls baked in, a .NET telemetry library, a React design system. None of these were original inventions. The patterns existed. The value was packaging them so that every team didn't have to figure it out independently. One team solves it, forty teams benefit.

This is what innersource is really about. Knowledge that exists in one team's head, made available to everyone through code, libraries, templates, and golden paths.

I've seen the same dynamic work at a larger scale with community-style knowledge sharing – something like how SIGs operate in the Kubernetes community. You identify the people who've already solved specific problems, give them a platform to share, and suddenly the whole organisation accelerates. Not because anyone got smarter. Because knowledge that was stuck in one place started moving.

Peter Thiel's Zero to One draws a clean line: creating something original versus scaling something that exists. His argument is that founders should aim for the first. Fair enough.

But most of the time, even inside companies built on a genuinely original idea, the daily work is spreading existing knowledge. Educating the market. Figuring out which segments care. Refining the sales motion. Scaling internal processes. The breakthrough got you started. Distribution is what keeps you alive.

The trap is treating a "spread" problem like a "create" problem. I've watched teams spend months building internal tooling from scratch when a 30-minute conversation with someone who'd done it before would have saved them the entire effort. And the opposite trap exists too — importing best practices for a problem that's genuinely unique to your context and needs original thinking.

When we were doing niche research for SecretNiche cohorts, we learned this the hard way. You can spend months on desk research, surveys, data analysis – or you can buy an industry expert a bottle of good wine and ask them directly. One evening conversation with someone who's spent fifteen years in the space can save you months of work and hundreds of thousands of dollars in wrong bets.

The skill isn't knowing the answer. It's knowing whether the answer already exists somewhere — and having the honesty to go find it instead of recreating it yourself.