eterdis-protoloop

name

eterdis-protoloop

description

Track Two / internal innovation system for running small, fast experiments outside the core business. Runs in three modes — Diagnostic for designing the full Protoloop from scratch (intake channels, loop structure, team, exit paths), Review for running the monthly heartbeat meeting (loop-by-loop decisions, forward-loading, portfolio health), and Alert Triggers for defining tripwires that protect, feed, and maintain momentum in the system. Updates company-context.md after every run. Triggers on questions about innovation pipelines, intrapreneurship, Track Two strategy, experimentation systems, handling ideas that don't fit the core business, or building systematic exploration alongside exploitation. Based on 20 years of practice by Eterdis (eterdis.com).

Protoloop: Track Two Innovation System

Think of your business as a boxer and a marathon runner at the same time. Track One is the marathon — your core business, optimised, disciplined, efficient. Track Two is the boxer — fast, experimental, willing to take a hit and learn from it. Most companies are all marathon runner. They can grind, but they can't punch. Protoloop is how you build the boxer without breaking the marathon runner.

The problem isn't that companies lack ideas. It's that they lack a system for ideas that don't fit. The weird ones. The ones that make the planning committee uncomfortable. Without a system, those ideas either die in someone's inbox or get forced into the core business where the antibodies kill them.

Antibodies always win. That's the first law of corporate innovation. The immune system of the existing business will reject anything foreign — not because people are malicious, but because the core business is designed to reject variance. That's what makes it good at what it does. You can't blame the immune system for doing its job. You have to build a protected space.

That's what Protoloop is. A protected space with a heartbeat.

---

Loading Company Context

Before starting, look for a company-context.md file. Read it if available.

Check specifically for:

• Track Two history: Has this company tried internal innovation before? What happened? (If there's a graveyard of past innovation initiatives, that tells you everything about the antibody strength.)
• Previous innovation attempts: Incubators, hackathons, intrapreneurship programmes, skunkworks. What worked, what died, and why.
• Available resources: Budget flexibility, people who could be freed up, physical or digital space for experimentation.
• Leadership context: Who has real authority? Who's the likely sponsor? How much air cover exists at the top?
• Existing Protoloop section: If one exists, load active loops, intake channels, team setup, and session history. Don't rebuild what's already there.

If no context is available, ask:

• What business are we designing this for?
• Has the company tried any kind of structured innovation or experimentation before? What happened?
• Who's the most senior person who genuinely wants this to work? (Not "supports innovation" in a speech — actually wants it.)
• What resources could realistically be freed up without triggering a budget war?

---

Determine the Mode

Ask: "Are we designing a Protoloop from scratch, running a monthly review of active loops, or setting up alert triggers?"

Then follow the appropriate track below.

---

Mode 1: Diagnostic (Full Session)

Time guidance: Plan for 45 minutes minimum. This is a design session, not an analysis exercise. You're building an engine — intake channels, loop structure, team composition, exit paths. If you rush it, you'll build a beautiful engine with no fuel line, or a fuel line with no engine. Every piece matters. Take the time.

This is the full design session. Run it when building a Protoloop for the first time, or when a previous one has died and you need to understand why before rebuilding.

---

Before You Begin

Four questions that determine whether this is worth doing right now:

1. Do you have executive air cover? Not "the CEO thinks innovation is important." Do you have a specific person, with budget authority, who will protect this system when the antibodies attack? Because the antibodies will attack. They'll attack the budget first, then the people, then the mandate. If nobody's willing to take a political hit for this, stop here. Come back when you have a sponsor. Antibodies always win without a host defence.

2. Can you name what Track One can't do? Protoloop isn't for improving the core business — that's Track One's job. This is for the things that don't fit. The adjacent markets. The weird customer requests. The technology that's five years from maturity. If you can't articulate the gap between what Track One handles and what falls through the cracks, you don't have a design brief yet.

3. Are you willing to run experiments that might fail publicly? Not "we're okay with failure" — that's a poster on the wall. Are you willing to fund something for 6 months, have it produce nothing commercially viable, and call that a success because you learned something real? If the answer is "yes, but we'd need to show ROI," you're not ready.

4. Can you protect 2-3 people's time? Not their evenings. Not their "20% time" that's really 0% time. Actual, defended, calendar-blocked time where they work on Track Two and nobody pulls them back into the marathon.

If all four answers are solid, proceed. If not, note the gaps and address them before designing the system. A Protoloop built on weak foundations doesn't just fail — it inoculates the organisation against trying again.

---

Phase 1: Design the Intake

The intake is how ideas get into the system. Most innovation programmes die here — either the intake is too narrow (only "strategic" ideas from senior people) or too wide (suggestion box chaos). You need four channels, each serving a different purpose:

Channel 1: Internal Misfits

These are ideas that already exist inside the company but don't have a home. The engineer who keeps prototyping something on weekends. The sales rep who heard a customer ask for something that's "not what we do." The operations person who sees a process that could be a product.

"Walk through the building and ask: who's working on something they shouldn't be, and loving it? That person is your first intake."

How to activate: Make it known that Track Two exists and is looking for ideas that don't fit Track One. No forms. No business cases. Just: "Tell us what you'd build if nobody told you to stop."

Channel 2: Technology Scanning

Systematic watching of technologies that are 2-5 years from maturity. Not the hype cycle — the stuff that's quietly getting cheaper, smaller, faster, or more reliable. Your job isn't to predict which technology wins. Your job is to notice when something crosses a threshold that makes a new experiment possible.

How to activate: Assign someone to spend 2-4 hours per month scanning. Not reading newsletters — actually talking to researchers, attending niche conferences, following patent filings in adjacent spaces. Feed findings into the monthly heartbeat.

Channel 3: External Signals

Customer requests you said no to. Competitor moves that surprised you. Regulatory changes that create new spaces. Market shifts that don't map to your current strategy. These are all signals that Track One filters out because they don't fit the plan. Track Two catches them.

How to activate: Create a simple log (can be a shared document, a Slack channel, whatever the team actually uses) where anyone can drop an external signal. Review monthly. The bar for entry is low — "I noticed something interesting" is enough.

Channel 4: Strategic Overflow

Ideas from strategy sessions, board meetings, and planning processes that were "interesting but not now." In most companies, these get written on a whiteboard, photographed, and forgotten. Track Two catches the overflow.

How to activate: After every strategy session, ask: "What did we discuss that doesn't fit the current plan but shouldn't be lost?" Feed it into Track Two's intake.

Intake Design Questions

For each channel, define:

• Who owns it?
• How often is it reviewed?
• What's the minimum bar for an idea to enter the loop? (Keep it low. The loop itself is the filter.)
• How does it feed into the monthly heartbeat?

---

Phase 2: Design the Loop

This is the core of Protoloop. A loop is a single experiment — a time-boxed attempt to learn something specific. Not to build a product. Not to prove an ROI. To learn.

The Monthly Heartbeat

The heartbeat is a monthly meeting. 30 minutes. Non-negotiable. This is where loops get reviewed, killed, advanced, or archived. Without the heartbeat, loops drift into hobby projects or get quietly abandoned. The heartbeat is what makes this a system instead of a side project.

"A Protoloop without a heartbeat is just a collection of good intentions slowly suffocating."

Loop Structure

Every loop has exactly seven elements. No more, no less. If you can't define all seven, the loop isn't ready to run.

1. The question: What are we trying to learn? Not "what are we building" — what are we learning? If the answer is "whether customers want X," that's a question. If the answer is "we're building X," that's Track One thinking leaking into Track Two.

2. The time box: How long does this loop run? Default is 4-8 weeks. Shorter is usually better. If a loop needs 6 months, you either have the wrong question or you need to break it into smaller questions.

3. The budget: What does this cost? Track Two budgets should be small enough to not need committee approval and large enough to actually test something. If you need a business case to fund a loop, your approval process is killing your speed.

4. The team: Who's running this? 1-2 people maximum per loop. Not a committee. Not a cross-functional task force. Someone who can move fast.

5. The success criteria: What would we need to see to believe the question has been answered? Define this before starting, not after. And define what "answered negatively" looks like too — a loop that proves an idea is bad is just as valuable as one that proves it's good.

6. The kill criteria: What would tell us to stop early? If after week 2 we see [X], we kill the loop and move on. This isn't failure — it's efficiency.

7. The next question: This is the forward-loading principle. Before you start a loop, define what the next question would be if this one succeeds. This is the secret sauce. It's what separates a system from a one-off experiment. Forward-loading means you never finish a loop and then spend three months figuring out what to do next. The next move is already loaded.

"Forward-loading is the secret sauce of Protoloop. Without it, you get a series of disconnected experiments. With it, you get a learning trajectory. Each loop builds on the last one. The system develops momentum. And momentum is the one thing the antibodies can't easily kill."

The Portfolio View

At any given time, you want to see all active loops in one view:

Loop name	Question	Stage	Time remaining	Next question (forward-loaded)	Status

Healthy portfolios have:

• 3-5 active loops (more than that and you're spreading too thin, fewer and you're not feeding the system)
• Loops at different stages (not everything starting at once)
• At least one loop that makes you uncomfortable (if everything feels safe, you're not experimenting — you're extending Track One)
• Forward-loaded next questions for every active loop

---

Phase 3: Design the Team

Intrapreneurs

Start with 2-3 people. Not more. These need to be people who:

• Can tolerate ambiguity (most people can't — this isn't a character flaw, it's a fit question)
• Move fast without being told what to do
• Can work without the validation structure of Track One (no KPIs, no quarterly reviews, no promotion path tied to this work)
• Are respected enough in the organisation that the antibodies can't dismiss them as "the weirdos in the corner"

"You're looking for people who are slightly annoyed by how things work. Not angry — annoyed. Angry people burn out. Annoyed people build alternatives."

Budget

Define a Track Two budget that is:

• Separate from Track One. This is non-negotiable. The moment Track Two competes with Track One for budget, Track One wins. Always. The marathon runner always beats the boxer in a budget meeting because the marathon runner has revenue numbers.
• Small enough to be invisible. If the Track Two budget is big enough to trigger a reallocation debate, it's too big. Start small. Prove the system works. Grow later.
• Controlled by the sponsor. Not by finance, not by the planning committee, not by Track One leadership. The sponsor holds the budget and defends it.

Protection from Antibodies

This is the part most innovation programmes skip, and it's why most innovation programmes die. The antibodies are real and they take predictable forms:

• "That's not in the plan." Correct. That's the point.
• "We tried that before." Maybe. But you tried it inside Track One, where the antibodies killed it. That's different from testing it in a protected space.
• "Where's the business case?" Track Two doesn't have business cases. It has questions and time-boxed experiments. The business case comes later, if the loops produce something worth scaling.
• "Those people should be working on [core business priority]." This is the most dangerous antibody because it's often right in the short term. Defending Track Two time requires a sponsor who understands the difference between short-term efficiency and long-term optionality.

Design your defence:

• Who responds to each antibody type?
• What's the escalation path?
• What happens if the sponsor leaves? (Have a backup. Always have a backup.)

---

Phase 4: Design the Exit Paths

Here's the thing about exit paths: you can't fully design them in advance. If you could have planned the exit, the idea probably shouldn't have been in Protoloop in the first place. Protoloop is for the emergent stuff — the things where the path only becomes visible after you've been walking for a while.

"If you could have planned it, it probably shouldn't have been in Protoloop."

But you can design the categories of exits and the decision process:

Exit Categories

1. Scale into Track One. The loop produced something with clear commercial potential. It's ready to graduate from experimentation to execution. This requires a handoff process — Track Two hands over the learning, Track One takes over the building. Design this handoff carefully. Many good ideas die in the transition because Track One applies its standards to something that isn't ready for Track One standards yet.

2. Spin out. The loop produced something valuable that doesn't fit the core business. Could be a new business unit, a partnership, a licensing deal, or even a separate company. This exit path requires the organisation to be comfortable with value creation that doesn't show up on this year's P&L.

3. Archive with learning. The loop answered the question and the answer was "not now." This isn't failure. This is a deposit in the knowledge bank. Archive the learning in a way that's findable. Tag it with the conditions under which it should be revisited.

4. Kill. The loop answered the question and the answer was "no, and probably never." This is also not failure. This is the system working correctly. Kill it, note why, move on.

5. Merge. Two or more loops converge on something larger. This often produces the most interesting outcomes — things nobody planned.

The 7-Year Example

I've seen a Protoloop that ran for seven years before it produced a viable business unit. Seven years of monthly heartbeats, small loops, forward-loaded questions. The first three years looked like waste to anyone watching from outside. By year four, the loops started converging. By year five, a pattern emerged that nobody could have designed from a blank sheet. By year seven, it was a business unit generating revenue. The total Track Two spend over seven years was less than one quarter of what the business unit now generates annually.

That's the point. You can't compress this. You can't plan it. You can build the system, run the heartbeat, and let emergence do what planning can't.

---

After the Design

Before closing the diagnostic, hit the pressure test:

Three Questions

1. What scares you about this design? Not what's risky — what actually scares you? The thing you're hoping I won't ask about. That's where the real vulnerability is.

2. What would tell you it's working in 6 months? Not revenue. Not products. What would tell you the system is working? (Good answers: "We have 3-4 loops running and I can see the forward-loaded questions." "People are voluntarily submitting ideas to the intake." "The sponsor hasn't had to defend the budget yet because nobody's noticed it.")

3. What's the most likely way this dies? Name it specifically. "The sponsor moves to another role." "Q3 budget cuts hit Track Two first." "The two intrapreneurs get pulled back into a product launch." Now design the countermeasure.

---

Update company-context.md

After the diagnostic, update company-context.md:

Track Two / Protoloop Section

If this section doesn't exist, create it. Structure:

Intake Channels:

Channel	Owner	Review frequency	Current status
Internal Misfits
Technology Scanning
External Signals
Strategic Overflow

Active Loops:

Loop name	Question	Stage	Time box	Forward-loaded next question	Status	Started

Team:

• Intrapreneurs: [names and allocation]
• Sponsor: [name and role]
• Backup sponsor: [name]
• Track Two budget: [amount and source]

Protection Design:

• Primary antibody risks: [list]
• Defence mechanisms: [list]
• Escalation path: [description]

Add a row to the Session log:

Date	Skill(s) run	Key finding	Action taken	Next review
[today]	Protoloop (Diagnostic)	[primary finding]	[what was decided]	[date of first monthly heartbeat]

---

Mode 2: Review (Monthly Heartbeat Meeting)

Time guidance: 30 minutes. This is the heartbeat. It happens monthly. No exceptions. If you start skipping months, the system is dying and you just haven't admitted it yet. Treat it like a board meeting for Track Two — short, structured, decisive.

This is the monthly meeting itself. Not preparation for a meeting. Not analysis. The actual decision-making session.

Load Active State

Read company-context.md. Pull up:

• All active loops
• Intake channels and recent entries
• Team status
• Any triggered alerts

For Each Active Loop

Walk through every active loop. For each one:

1. Report results. What did we learn this month? Not what did we do — what did we learn? If the answer is "we're still working on it," that's a yellow flag. Loops should produce learning continuously, not just at the end.

2. Kill / Scale / Archive decision. Every loop gets one of three verdicts at every heartbeat:

   • Continue: The question isn't answered yet, the time box hasn't expired, and learning is happening. Keep going.
   • Kill: The question has been answered negatively, or the time box expired without meaningful learning, or conditions changed and the question is no longer relevant. Kill it. Record the learning. Move on.
   • Scale: The loop produced something worth graduating. Initiate the exit path.
   • Archive: The answer is "not now, but maybe later." Tag it with the conditions for revisiting.

3. Forward-load the next question. If the loop is continuing, confirm or update the forward-loaded next question. If this loop ended, is the forward-loaded question still worth pursuing as a new loop? This is where the momentum lives. Don't skip this step.

"If you leave a heartbeat meeting without knowing what the next question is for every active loop, you've built a beautiful engine with no fuel line. Forward-loading is the fuel line."

Review Intake

• Any new entries in any of the four channels since last meeting?
• Are the channels active or going dry? A channel with no entries for two months is either not visible enough or not valued. Diagnose which.
• Any entries ready to become loops? (Remember: low bar for intake, higher bar for loop.)

Review Portfolio

Look at the portfolio view:

• Healthy distribution? Loops at different stages, different risk levels, different time horizons.
• Too concentrated? All loops in the same domain means you're not exploring broadly enough.
• Too thin? Fewer than 3 loops means the system is starving. Feed it.
• Too thick? More than 5-6 active loops means nothing is getting enough attention. Kill something.

Review Team

• Do the intrapreneurs have what they need? Time, budget, access, tools?
• Is anyone getting pulled back into Track One? (The first sign of antibody attack.)
• Is the sponsor still engaged? Still attending heartbeats? Still defending the budget?
• Does anyone need to be rotated in or out?

Update company-context.md

After the heartbeat:

• Update loop statuses (continue / kill / archive / scale)
• Add new loops from intake decisions
• Archive dead loops with learning notes
• Update team section if anything changed
• Log the session:

Date	Skill(s) run	Key finding	Action taken	Next review
[today]	Protoloop (Review — Monthly Heartbeat)	[primary finding]	[decisions made]	[next month's heartbeat date]

---

Mode 3: Alert Triggers

These are the tripwires that tell you something needs attention before the next heartbeat. Define them once, update them as the system evolves. When a trigger fires, act — don't wait for the scheduled meeting.

Protection Triggers (The Antibodies Are Attacking)

The immune system is activated. Something is threatening the protected space.

• Budget under threat. Track Two budget included in a reallocation discussion, mentioned in a cost-cutting exercise, or being questioned by anyone outside the sponsor chain. Fire: immediately escalate to sponsor. If sponsor can't defend, the system is in critical condition.
• Sponsor leaving. The executive sponsor is moving roles, leaving the company, or losing authority. Fire: activate backup sponsor immediately. If no backup exists, this is an emergency — the system has weeks, not months.
• Antibodies attacking people. Intrapreneurs being pulled back to Track One "temporarily" (there is no temporarily), being told their Track Two work "doesn't count" for performance reviews, or being socially pressured by Track One colleagues. Fire: sponsor intervention within one week.
• Mandate erosion. Track Two being asked to "align with" Track One priorities, submit to Track One approval processes, or produce Track One deliverables. This is assimilation, not alignment. Fire: sponsor reaffirms the separation or the system dies.

Starvation Triggers (The System Is Hungry)

The system isn't being fed. Ideas aren't flowing in, and the pipeline is drying up.

• No new intake entries for 2+ months. The channels are blocked or invisible. Diagnose: are people aware Track Two exists? Have the channels become too bureaucratic? Has the organisation decided (implicitly) that innovation isn't valued right now?
• Intake channels going one-directional. Only one channel producing entries while others are silent. This means you're only seeing one type of opportunity. Reactivate the dead channels.
• All intake coming from the same 1-2 people. The system isn't distributed — it's dependent on individuals. Broaden participation or accept the single-point-of-failure risk.
• No loops starting from intake. Ideas are entering but nothing is being converted to loops. Either the bar is too high, or nobody's doing the conversion work, or the heartbeat isn't functioning.

Momentum Triggers (The Engine Is Stalling)

The system exists but isn't producing learning or movement.

• Loops stalling. A loop has been "in progress" for more than 1.5x its time box with no learning to report. Either the question is wrong, the team is blocked, or the loop has become a zombie. Kill or redesign.
• Forward-loading not happening. Loops are ending without next questions defined. This means each loop is an isolated event, not part of a learning trajectory. The system is running but not compounding. This is the most subtle and most dangerous momentum problem.
• Gap between heartbeats growing. Monthly slipping to every-6-weeks, then quarterly, then "we should really schedule that." The heartbeat is the system's vital sign. If it's slowing, the system is dying. Non-negotiable: monthly means monthly.
• No kills happening. If nothing has been killed in 6+ months, either you're not experimenting aggressively enough or you're emotionally attached to loops that should be dead. Healthy systems kill regularly.
• All loops in the same stage. Everything stuck in early exploration, or everything in late validation. No flow through the pipeline.

Exit Triggers (Something Wants to Graduate)

A loop is producing results that suggest it's ready to leave Track Two, but there's nowhere for it to go.

• Loop has answered its question positively but no exit path exists. The experiment worked, but Track One doesn't want it, there's no spin-out mechanism, and it's stuck in Track Two limbo. This kills motivation faster than failure does.
• Loop has been in "ready to scale" status for 2+ heartbeats. The decision to graduate isn't being made. Either the exit process is broken, or nobody wants to take ownership on the Track One side.
• Multiple loops converging. Two or more loops are pointing at the same opportunity. This is the merge signal — and it often produces the most valuable outcomes. Don't let it happen accidentally; design the merge.

Recording Triggers

Add triggers to the Active assumptions table in company-context.md:

Assumption	Confidence	Trigger type	What fires it	Last checked
Track Two budget is protected for FY	High	Protection	Budget included in reallocation discussion	[date]
Intake channels are active	Medium	Starvation	No new entries for 2 months	[date]
Forward-loading is happening	High	Momentum	Loop ends without next question	[date]
Exit paths exist for mature loops	Medium	Exit	Loop in "ready to scale" for 2+ heartbeats	[date]

When a trigger fires, run a Review (if it's a single-loop or single-channel issue) or escalate to the sponsor (if it's a protection trigger).

---

Connection to Other Skills

Protoloop doesn't operate in isolation. It sits inside a strategy system where each skill reinforces the others.

First Principles

Track Two work emerges from first-principles gap analysis. When you strip a problem down to its fundamentals and find that the current business model can't address it, that gap is Track Two territory. First Principles identifies the gaps. Protoloop fills them with experiments.

Strategy Map

In the strategy map, there's always a gap between the resources you have and the resources you need. Track One closes the gap through incremental improvement. Track Two closes it through experimentation and emergence. Protoloop is the mechanism that turns "we need a capability we don't have" into a series of learning loops rather than a single large bet.

VRIO

Successful loops may create new resources that pass VRIO analysis. When a loop graduates from Track Two, run VRIO on whatever it produced. If it passes all four tests — valuable, rare, inimitable, organised — you've created a new competitive advantage through experimentation. That's the ultimate Protoloop outcome. If it doesn't pass VRIO, it might still be useful, but it's not a moat.

Culture

Protoloop needs specific cultural traits to survive. Tolerance for failure (real tolerance, not poster-on-the-wall tolerance). Speed over perfection. Comfort with ambiguity. Respect for learning as an outcome, not just revenue. If the culture skill has been run, check whether those traits exist. If they don't, Protoloop will be fighting the culture as well as the antibodies — and that's a war on two fronts.

---

Framework References

• Protoloop System: Developed through 20 years of Eterdis consulting practice across multiple industries and company sizes. Not an academic framework — a practitioner system refined through repeated application.
• Track Two Concept: Inspired by the diplomatic concept of Track II diplomacy (unofficial, parallel channels for problem-solving), adapted for organisational strategy.
• Ambidextrous Organisation: Draws on O'Reilly & Tushman (2004), "The Ambidextrous Organization," Harvard Business Review, and subsequent work on managing exploration alongside exploitation.

Protoloop, applied through Eterdis consulting practice. This skill is the exploration engine — it produces the experiments and emergent insights that planning alone can't generate. To connect this to competitive positioning, resource assessment, and strategic direction, visit eterdis.com or book a conversation at eterdis.com/contact.