The third engagement model at xlabs is the one most people don't ask about. xlabs Studio ships software for clients. xlabs Ventures partners with founders. And xlabs Labs — the third — builds for nobody but us.
Labs gets 15% of our studio capacity, ring-fenced and funded from Model 1 margins. It's where we run our own ideas. It's where we test the things we'd never get permission to test on a client engagement. It's where the IP we eventually license, productise, or spin out gets born.
It's also where most ideas go to die.
We treat that as a feature, not a failure. A serious R&D engine produces more dead ideas than live ones — by design. The discipline isn't in keeping ideas alive. It's in killing them fast, killing them cheaply, and killing them for the right reasons.
This is what running that discipline at xlabs has taught us.
Most of what makes it into Labs doesn't survive Stage 3
Our Labs lifecycle has five stages. Pool, Review, Explore, Build, Decide. The Explore stage — roughly four weeks of rapid prototyping, smokescreens, user conversations, and demand-signal testing — is where most ideas end. By design.
The honest pattern across our Labs work: the majority of ideas that clear our monthly Review don't survive Explore. The ones that do survive aren't usually the ideas the team was most excited about going in. They are the ideas where the demand signal was clear and the team was willing to look at the evidence honestly.
The ideas that get killed in Explore are not failures of imagination. They are successes of cheap learning. Every one of them taught us something we would otherwise have spent months — or years — learning the hard way.
Lesson one: enthusiasm is not signal
The most expensive mistake an innovation team can make is to treat the team's own enthusiasm as evidence that the market will be enthusiastic too.
We've watched it happen inside Labs more than once. An idea catches fire internally. The team can't stop talking about it. The slack thread runs hot for a week. Everyone is convinced this is the one.
Then the smokescreen goes live, and the market doesn't show up.
The lesson, learnt and re-learnt: internal conviction is fuel for getting started. It is not validation. It is not a substitute for an external signal. Some of the best ideas we ever had inside the team turned out to be solutions to problems that only the team had. The market, politely, did not care.
We now treat internal enthusiasm with deliberate suspicion. If the team is wildly excited and the smokescreen is flat, we trust the smokescreen.
Lesson two: the cheapest kill is the one done early
Every idea has a price. The price of a kill at Stage 2 — Review — is a few hours of conversation. The price at Stage 3 — Explore — is two to four weeks of focused work. The price at Stage 4 — Build — is months and serious capital.
The decision-rights structure inside Labs is engineered around that price gradient. The earlier in the lifecycle, the lower the bar to kill. The later, the higher the bar to keep going. This is the inverse of the natural human tendency, which is to grow more attached to an idea the more time you've put into it.
The teams that ship are the teams who fight the sunk-cost reflex hardest at Stage 4. The teams that drown are the teams who promote weak Stage 3 ideas into Stage 4 because someone is too invested to let go.
We've made that mistake. We try not to make it twice.
Lesson three: a clean kill is more valuable than a slow drift
The worst outcome inside Labs isn't a fast death. It's a slow zombie.
A zombie idea is one nobody is willing to kill but nobody is willing to fully fund either. It sits in the backlog. Someone keeps poking at it. It absorbs hours that should be going somewhere else. It never gets a real test, because a real test would force a decision.
We've learnt to recognise zombies early and to put them down. Either it gets a real four-week Explore sprint with a clear success bar, or it gets removed from the pool. There is no "we'll come back to it." We never do, and the half-life of a backlog item is shorter than anyone wants to admit.
A clean kill, with a documented reason, returns capacity to the engine. A zombie quietly leaks capacity until the engine slows down.
Lesson four: the reason for killing matters as much as the kill itself
Every dead idea inside Labs gets a one-page kill memo. What was the idea, what was the hypothesis, what did the test show, why are we stopping, what did we learn.
This sounds bureaucratic. It is not.
The memo is the asset. The idea itself is gone, but the learning persists. We've had ideas die in Year 1 whose kill memos directly informed a winning idea in Year 2. We've had founders walk into Ventures conversations with proposals that we could engage with intelligently because someone in Labs had killed an adjacent idea two years earlier and written down why.
A kill without a memo is a wasted death. The memo turns the death into compound interest.
Lesson five: the success metric for Labs is learning, not shipping
This took us the longest to internalise.
The natural instinct is to evaluate an R&D engine on what it shipped. Did we get a product out of it? Did we monetise it? Did we spin something out?
That metric punishes the wrong things. It encourages teams to push weak ideas through to Build because Build is what gets credit. It punishes the disciplined act of killing. It rewards motion over learning.
We now evaluate Labs on a different question: did we learn something useful? Did the test produce a clear signal — even a negative one? Did we walk away knowing more about the market, the technology, the customer, or ourselves than we did at the start? If yes, the project was a success regardless of whether anything shipped.
This is the same logic that runs through our validation work for Ventures clients. The job of an experiment is not to confirm the hypothesis. It is to resolve the hypothesis — yes or no. A clean no is as valuable as a clean yes.
Why we keep doing it
It would be cheaper, in the short run, to kill Labs. Every hour of Labs capacity is an hour we could have billed at studio rates. The financial argument against keeping it is straightforward and tempting.
We keep it because the engine wouldn't be the same engine without it.
Labs is where we get the licence to be wrong. It's where we test the techniques, the workflows, the agent patterns, the validation tools — including Smokescreen itself, which was a Labs project before it became internal infrastructure — that eventually shape what we deliver to clients. It's where the team gets to build for the long-term IP of the studio rather than the short-term invoice.
If we only ran Studio and Ventures, the engine would stay sharp on execution but slowly dull on novelty. Labs is the sharpening. It's expensive. It produces more dead ideas than live ones. And it's one of the highest-leverage things we do.
The unglamorous good news, again
The lesson that surfaces most reliably in our Labs work is the same lesson we tell every Ventures founder, every Studio client, every internal team:
Most ideas don't survive contact with a real test. That is not a failure. That is the test working.
The teams that build the best products are not the ones with the best initial ideas. They are the ones who run the most disciplined process for killing the bad ones — fast, cheaply, and with a memo at the end.
Inside Labs, we run that discipline on ourselves. It hurts every time. It makes everything else we ship sharper.