When a platform feature slips, do not let it take your roadmap with itWhen a platform feature slips, do not let it take your roadmap with it

The rebuilt Siri moved repeatedly, with reporting through early 2026 focused on when rather than whether. For anyone who had planned around the original timeline, the interesting question is not Apple's schedule but their own exposure to it.

How a dependency becomes load-bearing

It rarely starts as a bet. It starts as an assumption inside a design: this flow will be easier once the assistant can do X. The flow gets designed for that world, other decisions get made around the flow, and by the time the delay is announced the dependency is three layers deep.

The tell is that nobody can say what the feature does if the platform capability never arrives. If that question has no answer, it is not a dependency - it is a bet.

What makes this hard to catch is that nobody ever decides to take the bet. The assumption enters in a design review, where it is a reasonable thing to say, and it is never revisited because it was never a decision. Six months later it is load-bearing and undocumented at the same time.

The question we ask in planning

For every feature that leans on something unreleased: what ships if this never arrives?

• If the answer is a worse but functional version, proceed - build that version first.
• If the answer is nothing, it is not a roadmap item. It is a research task with an unknown completion date, and it should be named that way.
• If the answer is we would rethink the product, escalate it now rather than in six months.

This is not pessimism about platform vendors. Announced dates slip everywhere, including in our own estimates. It is about knowing which parts of a plan are load-bearing.

The third answer is the one worth dwelling on. A product whose premise depends on an unreleased capability is a legitimate thing to build, but it is a different kind of project with a different risk profile, and it should be funded and explained as one. Discovering that in month six is what damages a relationship; agreeing it in week one rarely does.

A feature with no fallback is not a plan. It is a hope with a Gantt chart.

Grade the evidence, not the excitement

Not every unreleased thing carries the same risk, and teams routinely treat a stage demonstration and a shipping API as the same kind of fact. They are not close.

• Shipped and documented. Build on it. The remaining risk is deprecation, which is slow and announced.
• In a current beta with documentation. Reasonable to build on, with the expectation that details move before release.
• Announced with a date, nothing to test against. Design for it, do not schedule around it.
• Reported, rumoured or demonstrated but not released. Interesting. Not an input to a plan.

The line that matters is whether you can run it. Anything you cannot put on a device today is a forecast, however confident the source, and a forecast belongs in a risk section rather than a sprint.

Write the assumption down where the client can see it

The practical safeguard is boring: a short list of external things the plan depends on, maintained alongside the plan itself, each with the fallback named next to it.

It takes ten minutes a month and changes the conversation entirely when something slips. Instead of explaining why a quarter evaporated, you are pointing at a line written before the work started that says what happens in exactly this case. The client usually already agreed to it.

It also has a useful second effect. Assumptions that look fine in a design review often look reckless once written in a numbered list that somebody outside the team will read. Several get removed at that point, which is the cheapest moment to remove them.

The version that ships is the version that exists

The practical discipline is to build the unglamorous version first and treat the platform capability as an enhancement. Teams that do this ship something either way. Teams that do the reverse have a beautiful design and nothing running.

In practice this means the fallback is not a fallback at all. It is the product, shipped, with a seam where something better can attach later. A manual flow that works today and gets faster when the assistant arrives is worth more than an elegant flow that is waiting for permission to exist.

If it has already happened

Sometimes you inherit the problem rather than create it, and the capability is already three layers into a design. The recovery is not to redesign everything at once.

• Find the narrowest place the dependency actually enters the code. It is usually one function behind three layers of intent.
• Put the manual path behind the same interface. The rest of the product stops caring which one is live.
• Ship the manual path. Availability is the thing users notice; the mechanism is not.
• Leave the integration work in the backlog with the evidence grade attached, so the next planning round treats it honestly.

That sequence usually costs less than a fortnight, and it converts an open-ended delay into a feature that exists now and improves later. The alternative is waiting, which costs a quarter and produces nothing to show for it.