Why We Must Decouple Feature Testing from Code Delivery

The fastest teams don’t ship more—they learn faster. They validate features before code is written. And they know something many teams still forget: Code is a liability!

The obsession with “significant” or “minimum releasable” features ignores that features are shots at value. Value testing should be our focus! Here’s how.

In product development, there’s a persistent—and costly—confusion: we treat code as the first step in testing ideas. That’s backwards. And it’s the root of a lot of unnecessary complexity, delay, and waste.

Which is why Rodrigo Sperb’s recent article on the Layers of Delivery struck a chord(1). His framing—of operating, enabling, and strategic layers—gives language to the multiple kinds of work product teams juggle every day. These layers do exist, and naming them matters—but not in the way we would expect.

Let’s explore these layers

Rodrigo Sperb’s Layers Are Real—and Helpful

Rodrigo Sperb’s article does something I deeply appreciate: it brings structure to the lived experience of product teams. Dividing product work into Operating, Enabling, and Strategic layers—isn’t just a clever framework. It reflects the mental juggling act that many teams face daily.

• The Operating Layer captures the here-and-now: What’s shipping? What’s broken? What do customers need today?

• The Enabling Layer is about supporting the work—think platform improvements, process tweaks, or research investments that might not show value immediately, but unlock capability down the line.

• The Strategic Layer zooms out to focus on where we’re going. What’s our north star? Are we working on the right problems in the first place?

By explicitly naming these layers, Sperb gives voice to the quiet work that often goes unseen—especially in engineering-heavy environments where only shipped features get attention. His framing also helps explain some of the tensions between product, tech, and leadership—because each group may be working in a different layer, speaking a different language.

And that’s important. Because naming things is the first step to changing how we collaborate.

But as much as I love this framing… it’s time to talk about where the model falls short.

---

⭐️⭐️⭐️⭐️ This post is sponsored by The Global Agile Summit, where you can find the most advanced ideas on Software, Product Development and Agile! Join The Global Agile Summit, the most forward looking Agile event of 2025

Alice, The Pragmatic Innovator Visits Tallinn, Estonia. Where the future of Software and Product Development is being shared by a community of dedicated practitioners

---

But Layers Are Not Silos: We Must Switch Between Layers Constantly

While Sperb’s model is useful, it implies a level of separation that simply doesn’t hold up in real teams doing real work. And it might even push us to create gaps between teams working on the different layers.

In practice, product development isn’t a neatly layered cake—it’s a swirl. A messy, delicious swirl of discovery, delivery, and strategy happening all at once, often inside the same meeting… sometimes even the same conversation. See my article on this (2).

You don’t get to “pause” the operating layer to make space for strategic work. Nor can you cleanly exit strategy mode before diving into execution. You switch. Constantly. And the better your team gets at that switching—at moving between high-level direction, enabling investment, and day-to-day execution—the faster and more effectively you discover, and deliver value.

This switching isn’t dysfunction. It’s the necessary rhythm of adaptive teams. It’s what Agile Software Development is all about. As agilists, we embrace the full stack!

And trying to hold these layers apart—treating strategy as something upstream or enabling work as something “we’ll do when we have time”—is where the real friction starts. Especially when it comes to how we test and validate the features we think are worth building.

That’s where we hit the real bottleneck.

The Real Bottleneck: Confusing Feature Delivery with Feature Testing

Here’s where we finally start to understand how software development works in reality, not just the neat layered models we were taught in school.

Too often, teams operate under the assumption that testing a feature means releasing it to production. That the only way to know if something “works” is to build it, ship it, and see what happens.

That logic creates a bottleneck. A big one.

When testing is tied to code delivery, every insight comes too late. Every adjustment costs more. And the feedback and learning cycle—the thing we should be optimizing for—slows to a crawl. We don’t just risk building the wrong thing; we risk learning the right thing way too late.

Feature testing is not the same as feature delivery. And it shouldn’t depend on it. Feature testing must be decoupled from feature delivery.

And, I mean feature testing as in: “does this feature help our users/customers the way we expected it to? Does it deliver the value we need it to deliver?”

Testing should happen before a single line of production code is written. That means exploring with prototypes, validating with customers, simulating experiences—even running concierge-style experiments if that’s what it takes. The goal is to answer this question early: “Should we build this at all?”, and “How can this feature deliver value in practice?”

If we test features for value with only running software, we’re already behind!

Because here’s the truth we don’t say enough:
Testing for value with code is the most expensive, slow and error prone strategy!
And the best teams are the ones who learn the most while coding the least.

The Shape Up Mistake: “Significant Features” Are a False Constraint

There’s a deeply ingrained belief—popularized by models like Shape Up(3)—that “significant” features/projects (as ShapeUp calls them) deserve extended timelines. That meaningful product work happens in neat 6-week cycles, with just enough time to build something users will love.

But here’s the problem: that constraint is imposed by the focus on delivery! Even before we know if the feature delivers any value at all!

The assumption is that you can’t learn if something is valuable/significant until you’ve built and shipped it. Which leads to teams investing weeks—or months—on features they haven’t tested for value, simply because the structure says, “This is the timebox where significance lives.”

That’s backwards.

“Significance” doesn’t come from the length of the cycle, as ShapeUp seems to argue. It comes from how early—and how well—you validate the idea.

The real constraint isn’t time. It’s the inability to test ideas without code.

And that’s a solvable problem.

When teams embrace low-fidelity testing, early customer signals, and lightweight validation methods, they stop chasing “big” features and start delivering true value—sometimes in a day, sometimes in a week, sometimes without writing code at all.

With my clients, I often run the “24h experiment workshop”, where in 3 days, we go from high level goals (strategy layer) to experiment design (enablying layer), to experiment delivery and feature value testing (operational layer) several times!

The higher the risk, the faster we should go through the Strategy→Feature planning→Feature value testing cycle!

The idea that “significant” work must take longer is a myth born from the inability to take advantage of a native aspect of software: we help people achieve something with software—and we can test if our assumption is correct in less than 24h. The software should be a natural outcome of learning about what works for our users and customers!

Decouple Feature Testing For Value from Feature Delivery

The teams that move the fastest aren’t the ones shipping the most code. They’re the ones writing the least unnecessary code.

Why? Because code is slow and expensive, and not just in the cost to deliver either! Code is also very expensive in the long-term. Every new line brings maintenance overhead, potential bugs, and constraints you’ll have to unwind later. Code is is a liablity. And you don’t want to take a liability that has no upside! (Aka Return.)

That’s why I’ve been advocating for years:
👉🏽 Feature testing must happen before code is written.

The reason is simple: We’re not in the business of writing code. We’re in the business of solving business problems, that have a positive impact for both customers, users, and ourselves!

And often, the fastest way to solve a problem isn’t to build—it’s to learn. Talk to users. Click through an interactive prototype. Fake the backend with a spreadsheet. Test the reaction to a pitch before you code a flow.

Every time you learn something without writing code, you win twice:

• You reduce waste

• And you free up time for the work that truly matters.

In a world that rewards speed, learning early is your unfair advantage. And that only happens when you stop making validation depend on delivery.

Releasing Often Is Technical Hygiene, Not Product Strategy

Releasing software frequently is a technical/engineering practice. It reduces risk, tightens feedback loops, and makes quality sustainable. It’s not optional—it’s the foundation of modern software engineering. Period.

But somewhere along the way, we confused frequent releases with frequent delivery of user value.

And then we went one step further—tying that delivery to feature significance. ShapeUp, unfortunately does that—therefore, imposing the idea of 6 week cycles.

That’s how we ended up in this mess where:

• Engineers feel pressure to “release” even when the feature isn’t ready

• Product teams feel forced to bundle validation into the release

• And everyone argues over what’s “done” instead of asking what we’ve learned.

Here’s the fix:

👉🏽 Release working software as often as technically feasible.
👉🏽 Test value early—long before you get to code.

When you decouple feature testing from feature delivery, the pressure disappears:

• Engineers ship clean, safe, tested builds—without the burden of proving value with every deploy.

• Product teams validate ideas through discovery, research, and small bets—without waiting on a release train.

Releases should be boring. Because learning should be constant.

Let’s Stop Pretending These Dimensions Are Separate

If there’s one thing I hope you take from this, it’s that entanglement is not the enemy.
Strategy, discovery, delivery—they’re not three separate layers, dimensions, or activites. They’re the same work, viewed from different perspectives, depending on where you're standing and what you’re trying to solve.

So let’s stop organizing our work around false divides:

• Between “thinking” and “doing.”

• Between “significant” and “practical.”

• Between “tested” and “shipped.”

The real magic happens when teams build the muscle to move fluidly—to learn before they code, to code without overcommitting, and to release without ceremony.

And yes, it’s messy sometimes. You’ll have strategy questions in the middle of a standup. That’s great!
You’ll prototype a feature, only to learn the real value is something else entirely. This saves you HUGE amounts of time (and grief).
You’ll “release” something quietly while the real learning is happening over a Zoom call with a user who says, “Wait… what if it worked like this instead?”

That’s not a breakdown. That’s the job.

So let’s build teams that can hop seamlessly between dimensions—teams that are fast not because they ship “significant projects”, but because they learn constantly, and discover what code NOT to deliver!

And maybe—just maybe—we can stop writing code that never needed to exist in the first place.

Ok. That’s my view. But what do you think? Leave a comment, or shoot me an email at: vasco@oikosofy.com. Let’s talk

---

At the Global Agile Summit we create the space for you to meet likeminded individuals, and form a community of pragmatic innovators! Get inspired, take action!

Join us in Tallinn, and help define a better way to develop and deliver software

The Global Agile Summit takes place in Tallinn, Estonia. May 19, and 20 . Join us, get your ticket at GlobalAgileSummit.Com

References

(1)

Layers of delivery of (product) work

(2)

(3) ShapeUp method: https://basecamp.com/shapeup