13 March 2026
Tech Culture

As we Reach the Feature Event Horizon, our Processes Start to Collapse

We find ourselves at a singular moment of time. As an industry we’re starting to reach what I call The Feature Event Horizon. The point at which the time it takes to ship an idea is almost the same as the time it takes to come up with the idea in the first place. As we get closer to the threshold, time dilates. reality warps and we start to experience process collapse. What happens on the other side is anybody's guess, but it’s going to be bumpy. Let me explain. But first, let me start with a story.  

A few years ago, I was asked to help a design tooling company I’ll call Tally. Not their real name.

The leadership team brought me in because they felt their product delivery process was broken. Features were taking too long to ship. Ideas were piling up faster than the team could deal with them. When we did the maths, we realised they had something like five years’ worth of work sitting in the backlog at their current delivery rate.

As the CMO explained to me, ideas were effectively going into the backlog to die.

The leadership team had lost faith in the organisation’s ability to deliver. Fingers were being pointed in every direction. Engineering blamed product. Product blamed leadership and engineering. It was that spiderman meme writ large. Morale was so low it felt like the product team might walk out en masse at any moment.

They wanted me to come in, review the situation, and give them an honest opinion. Could the team be saved, or did they need to admit defeat and rebuild the function from scratch?

As I dug in, the shape of the problem became clear.

The company was led by a charismatic founder whose brain moved a mile a minute, constantly generating ideas he believed would solve major business problems. Product quality wasn’t good enough, which was feeding churn. Growth wasn’t fast enough to satisfy investors. New competitors were entering the market and starting to overtake them. His concerns weren’t wrong. So at the weekly planning meeting, the founder would brainstorm a dozen new features or initiatives to tackle these issues, then ask the product team to ship them as fast as possible.

However the product team had a fundamental problem. The leadership team could generate ideas far faster than the engineering team could ship them.

Every planning meeting produced dozens of new requests. Each one needed estimation, which pulled engineers away from the work they were already doing. Each one had to be turned into a PRD. It had to go through design, who would understandably ask whether the idea had been validated with users, or complain that they hadn’t been brought in earlier. Then product would have to somehow jam the new initiative into the backlog, which usually meant reorganising everything  again (which in itself could take weeks). That often meant stopping work mid-flight. Or changing direction halfway through. Or asking engineers to drop one priority and pick up another because this week’s executive anxiety had overtaken last week’s.

Engineering found this hugely frustrating.

What they wanted was not just fewer interruptions and plenty of focus time (although they wanted that as well). What they really wanted was a product vision. They wanted to know where the product might be in eighteen months so they could make sensible architectural decisions now. Put the right foundations in place. Build the right hooks. Make future shipping easier rather than harder.

So the product team started asking leadership for a clearer vision. More discovery. Workshops. Space to think.

Leadership hated this.

From their perspective, the product team couldn’t even ship what they already had. Now they wanted to spend months putting together some grand plan. This was exactly the opposite thing leadership felt they should be doing. Product passed that frustration on to engineering. Engineering pushed back because the constant shifting was making good technical planning impossible. Arguments flared up. Feelings got hurt. People walked out. 

No wonder everybody was blaming everybody else.

While this may sound like an extreme situation, it really isn’t. In most companies, it is simply much faster to come up with ideas than it is to ship them. And whether we realise it or not, the processes we’ve come up with over the last twenty years have been designed to manage this imbalance. 

Customer discovery exists to test whether an idea is worth pursuing. Prototyping exists to avoid burning expensive engineering time on something that won’t work. Prioritisation exists because not everything can be done at once. Backlog management exists to ration finite capacity. Lean and agile methods, for all their flaws, exist in part to reduce waste, limit work in progress, and stop teams from thrashing around.

In many ways, the whole discipline of modern software delivery has been built around this one problem: ideas are cheap, shipping is expensive.

That was what I was brought in to fix. Part of the solution was process improvement. Part of it was cultural. And yes, part of it was about talent. I think I did a pretty good job. 

However something fundamental has changed over the last few months.

AI has shortened the distance between idea and reality.

Now leadership teams can not only come up with an idea in a meeting, they can prototype it.

Now product managers don’t just have to write a PRD. They can vibe-code a working version.

Now engineers don’t have to spend months building elaborate scaffolding before features can go live.

Suddenly, things are starting to fly off the backlog.

So what happens when an idea that emerges on Monday can be prototyped on Tuesday, presented on Wednesday, refined on Thursday and shipped on Friday?

What happens is process collapse.

We no longer seem to need the processes that design, product and software teams have spent the last twenty years refining. The systems intended to make sure we don’t push costly, poorly thought-through work into production start to look slow, fussy and unnecessary. Because the cost of production, and arguably even the cost of being wrong, appears to have dropped through the floor.

And when that happens, the old playbook stops making sense.

The processes we were trained to trust, and which have guided us for the last two decades, no longer feel obviously valid. And the people who have made their careers out of knowing that process inside out, start to get nervous (and rightly so).

The way I like to frame it is through the world of games.  

We were raised in a chess mindset. Each game involved a huge investment. Every move mattered. A single mistake could cost the whole game. So we better be careful. To offset the risk, we studied. We planned. We deliberated. We tried to make the right move, because recovering from the wrong one was painful. And we loved it. It made us feel knowledgeable, valued and important. It became our identity. 

But what happens when the speed of play suddenly accelerates?

Instead of chess, we start playing poker.

It is no longer about playing the perfect game. It is about cycling through as many hands as possible in the shortest amount of time, hoping eventually you get dealt the right cards. And when that happens, knowing how to take advantage and double down (apologies for the mixed card game metaphors but you get what I mean).

As an industry, we are no longer trying to play the perfect move. We are trying to maximise throughput.

And that changes everything.

So as we reach the feature event horizon—the point at which a feature can be shipped almost as quickly as it can be imagined—everything changes. The process collapses. The need for craft breaks down. We start talking about ephemeral things like taste and product sense. As space and time dilates, reality shifts. Founders become product managers, product managers become engineers, engineers become designers and designers become PMs. Roles merge. Dogs and cats living together... mass hysteria!