Work anyway: a methodology for when the tech changes before you're done

Agile was built for a specific kind of uncertainty — scope uncertainty. You don't know exactly what to build, so you work in short cycles, inspect, adapt. It's a good answer to that problem.

It is not a good answer to a different problem: technological substrate uncertainty. The condition where the implementation layer itself is being reinvented faster than your sprint cycles. Where a decision you make in week two about what's technically feasible can be invalidated by week six — not because you were wrong, but because the world moved.

This is the situation now. And most organizations have no operating model for it.

Three things break first.

Prototyping was built on the idea that fidelity is a proxy for commitment. You sketch rough to stay cheap, increase fidelity as confidence grows. That logic collapses when a Claude Code session can produce a production-grade interactive application in an afternoon. The fidelity gradient is gone. What replaces it is a different axis: replaceability. Not how finished is this — but how hard would it be to throw this away. A prototype is now a high-fidelity, zero-attachment artifact. The prototype is a question with a UI.

Validation assumed a stable thing being tested against stable criteria. Define success metrics upfront, run the test, read the results. But the capability floor keeps rising during the validation period — by the time you get results, what's possible has changed. And users can't accurately report preferences for experiences they haven't had yet. Which means classical user research can actively mislead you. The output of a validation cycle is no longer go/no-go. It's a ranked list of what you still don't know, updated by the evidence.

Customer-centricity was built on a foundational assumption: the customer is the authority on their own needs. Listen hard enough and the answer is in there. That holds when the solution space is bounded by what already exists. It stops holding when you can build things that fundamentally change what's possible for the customer — faster than the customer can update their mental model. Deep customer empathy can produce precisely the wrong answer. What remains durable is friction. Friction is stable even when solutions aren't.

The framework below — Adaptive Signal Layers — is an attempt to name a way of working that actually fits this situation. It takes the best of agile, innovation practice, and journey management, and reorganizes them around a single substitution: signal thresholds instead of time boxes.

Three layers run concurrently, at their own cadence. They sync at signal gates — not calendar events. The future is held as three horizons: Now, Near, and Open — replacing the backlog with structured optionality.

This is version 0.1. The framework will sharpen as it gets used — particularly around how the Drift Gate gets triggered in practice, and how teams calibrate the Now/Near boundary without slipping back into backlog thinking.

The underlying claim is simple: the problem isn't that teams are bad at Agile. The problem is that Agile was designed for a world that no longer exists.