Before You Move the Roadmap Date

In December, objecting to an untested premise can carry a social cost that agreeing doesn’t. Agreeing lets the meeting end. Objecting asks everyone to reopen a decision they wanted settled. If sales then puts the release in a customer proposal, changing it carries an external cost too. The engineering forecast has become something another person is relying on.

You need to know what justified that reliance. A mobile commitment might depend on reusing the existing server interface, a new hire being available, and the customer approving the security design. The feature list can stay exactly the same while any of those assumptions fails.

An inspection with no confirmation

Suppose the mobile app must let field staff submit an inspection where coverage drops. The plan assumes it can reuse the web application’s submission behavior. That’s a claim you can examine before building all the screens.

Consider what happens if the server saves an inspection, but the connection drops before the phone receives confirmation. The phone can’t tell whether the save succeeded. If it retries and the server treats each submission as new, the same inspection gets recorded twice. A working online form has established nothing about that failure path.

Now the assumption is specific: retrying that submission must leave one inspection. Exercise the interrupted save against the existing server, resend the same submission, and read the stored records back. The app’s success message can’t show whether the server stored a duplicate.

A failure means the plan needs work on how the phone and server recognize a repeated submission. A pass supports reuse for the case you exercised. It leaves other questions open, including whether an inspection survives the app closing before it can be sent.

Finishing more screens leaves this question untouched. If server reuse fails the check, keeping the promised behavior requires work the plan didn’t include. A failed check alone can’t tell you whether that was a planning omission or a later change in scope.

If offline use was part of the brief all along and nobody tested submissions, discovering the problem late exposes a planning omission. If the customer added offline use after agreeing to an online-only workflow, the scope changed. The technical work may look identical; responsibility for the surprise does not.

Test the assumption while the answer still matters

In Shape Up’s To-Do Groups case, Ryan Singer describes a Basecamp proposal to group unfinished tasks. The sketch left completed tasks unresolved: should they sit under each group, or stay together below the list? Changing that display, Singer writes, had implications for navigation and performance.

Basecamp chose to leave completed items where they were and add the group name to each one. The proposal kept grouping unfinished work and explicitly gave up a tidier display of finished work.

The roadmap implication is that a feature name can conceal a decision about which behavior stays and which gets rebuilt. If that decision waits until after you promise the more elaborate design, choosing the simpler version changes the commitment. The opportunity to simplify depends partly on what you’ve already told someone to expect.

Return to the mobile example. Before sales offers offline inspections, establish whether customers need to finish the inspection without connectivity or only to retain a draft until they reconnect. Those requirements permit different solutions, but both still have to handle an interrupted upload. A draft could be sufficient for the customer, or it could defeat the reason they’re buying. Customer acceptance tells you what can be simplified; it doesn’t remove the technical check.

Put the assumption beside the deliverable, with the evidence supporting it and the person responsible for checking it. For the submission behavior, attach the actual test result. For customer acceptance, record who confirmed which workflow. Also record what a failed check would change: more server work, narrower scope, or a decision to defer the release.

The evidence can stay in the test report or customer note where it already belongs. Link it rather than creating another version to maintain. Name who can act on a failed check as well as who will run it: the engineer who finds a duplicate may have no authority to change what sales promised.

A risk column that says mobile integration won’t do that job. It names a topic without saying what must be true. And a test performed after everyone has committed can explain a miss, but arrives too late to inform the original promise.

Some unknowns require substantial implementation to resolve. In that case, make the unresolved behavior and the exposure explicit before accepting the bet. Early investigation earns its cost when an answer could change what you fund or promise. It gives you no reason to prototype every routine task.

Keep the reason when you change the date

In Shape Up’s discussion of progress, Singer separates work whose approach is unresolved from work whose approach is understood. He also warns that thinking an approach will work differs from validating it by building. You can use that distinction in an existing roadmap without adopting Basecamp’s process or buying its software.

At the March review, keep the December version available. If an assumption failed, show the evidence that invalidated it, when that evidence became available, and what changed as a result. If a check was available earlier and nobody owned it, acknowledge the omission. A written assumption makes that failure easier to locate; it doesn’t excuse it.

An assumption first written down in March can help with the next decision. By itself, it can’t establish that the risk was disclosed or accepted in December.

If the recorded premises still hold, inspect execution. A sound technical approach may require more work than the plan allowed. Work may also have waited for review, required rework, or been displaced by a priority leadership added. Those explanations need their own evidence. A single release can contain both a changed premise and a delivery failure, so don’t let the first discovery end the investigation.

A customer commitment also survives an internal replan. If a contractual date or required workflow is fixed, a failed check doesn’t make either optional. Changing a spreadsheet leaves the customer’s expectation intact. The revised plan needs an explicit decision about what can still be delivered under the agreement and, if that has to change, a negotiation with the person affected.

The December version belongs in the record. It doesn’t have to keep running the quarter.