A real estate CEO asked me last month: "Okay, I get the Skunk Works idea. Where do we actually start?".

I spent an hour with him. By the end, I realized he already had 3 things wrong before they'd even begun.

Here's what I told him — and what I keep running into across real estate agencies, construction companies, and sales-led businesses trying to build something new internally.

1/ You don't need a committee. You need a mandate.

Most "innovation initiatives" I've seen die in week 2. The team had no real authority. They needed sign-off for every experiment, their output was reviewed by the same people who approved payroll, and half the team was borrowed from operations with their day job still waiting.

If your innovation team has to justify itself every week to the people who run the core business — it just becomes part of the core business. I've seen this happen maybe 6 or 7 times at this point.

The minimum viable structure I recommend: 2–4 people, a direct reporting line to the owner, a budget that doesn't require a committee vote, and a time horizon framed as "validate something meaningful" rather than "deliver feature X by Q3."

2/ You probably need different people than you think.

The instinct is to take your best performers and put them on it. The problem is — your best performers are optimized for the existing operation. They're great at making things reliable and consistent, which is almost the opposite of what early innovation work requires.

What you actually want: someone who has built something before with incomplete information. A startup, a new product, a process where there was no playbook. Someone who doesn't freeze when the answer is "we don't know yet."

In real estate, this is usually not your top broker or best ops manager. More often it's someone who thinks like an owner — can hold business context and technical thinking in their head at the same time.

3/ Give them a problem to diagnose — not a deliverable to build.

"Build us an AI assistant by Q3." — this is how most internal mandates are framed.

A deliverable without a diagnosis is just a guess. You've picked the solution before understanding the problem. I'd frame it differently: "Figure out which part of our customer journey wastes the most human time and kills the most deals."

The deliverable comes out of the work. When you define it upfront, you've already constrained the team to your own view of the problem — which, respectfully, is usually incomplete.

4/ You have to protect the team from the rest of the org.

The main organization will try to absorb the innovation team. Nobody does it on purpose — it's just how organizations work. They optimize for consistency, and new things are inconsistent.

You'll start getting requests: "Can they help with the CRM migration? Just for a week." "Can they join our all-hands?" Individually these are small. But they add up fast, and within a month you have an "innovation team" that spends 80% of its time on operational work.

Your job as a leader here: say no on their behalf. Make it explicit early that this team has a separate mandate.

—

Building a small innovation function inside an established business isn't technically complicated. The hard part is political will — being willing to say "this team runs differently" and actually holding that line when the pressure comes.

A real estate CEO asked me last month: "Okay, I get the Skunk Works idea. Where do we actually start?".

I spent an hour with him. By the end, I realized he already had 3 things wrong before they'd even begun.

Here's what I told him — and what I keep running into across real estate agencies, construction companies, and sales-led businesses trying to build something new internally.

1/ You don't need a committee. You need a mandate.

Most "innovation initiatives" I've seen die in week 2. The team had no real authority. They needed sign-off for every experiment, their output was reviewed by the same people who approved payroll, and half the team was borrowed from operations with their day job still waiting.

If your innovation team has to justify itself every week to the people who run the core business — it just becomes part of the core business. I've seen this happen maybe 6 or 7 times at this point.

The minimum viable structure I recommend: 2–4 people, a direct reporting line to the owner, a budget that doesn't require a committee vote, and a time horizon framed as "validate something meaningful" rather than "deliver feature X by Q3."

2/ You probably need different people than you think.

The instinct is to take your best performers and put them on it. The problem is — your best performers are optimized for the existing operation. They're great at making things reliable and consistent, which is almost the opposite of what early innovation work requires.

What you actually want: someone who has built something before with incomplete information. A startup, a new product, a process where there was no playbook. Someone who doesn't freeze when the answer is "we don't know yet."

In real estate, this is usually not your top broker or best ops manager. More often it's someone who thinks like an owner — can hold business context and technical thinking in their head at the same time.

3/ Give them a problem to diagnose — not a deliverable to build.

"Build us an AI assistant by Q3." — this is how most internal mandates are framed.

A deliverable without a diagnosis is just a guess. You've picked the solution before understanding the problem. I'd frame it differently: "Figure out which part of our customer journey wastes the most human time and kills the most deals."

The deliverable comes out of the work. When you define it upfront, you've already constrained the team to your own view of the problem — which, respectfully, is usually incomplete.

4/ You have to protect the team from the rest of the org.

The main organization will try to absorb the innovation team. Nobody does it on purpose — it's just how organizations work. They optimize for consistency, and new things are inconsistent.

You'll start getting requests: "Can they help with the CRM migration? Just for a week." "Can they join our all-hands?" Individually these are small. But they add up fast, and within a month you have an "innovation team" that spends 80% of its time on operational work.

Your job as a leader here: say no on their behalf. Make it explicit early that this team has a separate mandate.

—

Building a small innovation function inside an established business isn't technically complicated. The hard part is political will — being willing to say "this team runs differently" and actually holding that line when the pressure comes.