Planning needs public evidence, not confident forecasts

Product planning often fails politely. Nobody says the forecast is certain, yet the roadmap behaves as if it is. A team says enterprise demand will arrive in Q4, activation will improve after a redesign, or a partner channel will cover the pipeline gap. The claim is written once, wrapped in confidence language, and then slowly becomes infrastructure. Hiring, sequencing, launch dates, and promises start depending on it.

The problem is not that product teams make forecasts. They have to. The problem is that many forecasts do not have an update mechanism. They are born in a planning deck and die in a postmortem. In between, teams discuss velocity, scope, and stakeholder alignment, while the original assumption escapes review.

Planning needs public evidence, not confident forecasts. Confidence can help a team act, but only if it is attached to a ritual that makes confidence move when new evidence arrives.

Forecast confidence is not evidence

A forecast is a claim about a future condition. It might be about market pull, customer behavior, sales capacity, technical feasibility, regulatory timing, or internal adoption. A confident forecast is still only a claim. If the team treats confidence as proof, planning becomes theater: the roadmap looks disciplined, but the discipline is concentrated in formatting rather than learning.

The useful question is not whether the team feels certain. The useful question is whether the forecast is exposed to information that did not come from the same room. Banca d’Italia Working Paper No. 1532 studied how firms formed inflation expectations and found that providing reliable public information on current inflation improved forecast accuracy and reduced the effect of overconfidence. Product planning is not inflation forecasting, but the lesson transfers well: outside evidence does not make forecasts perfect, it gives teams a way to correct beliefs before the cost of being wrong compounds. See Banca d’Italia Working Paper No. 1532.

That distinction matters for founders and product leaders. A roadmap is a portfolio of conditional bets. If the conditions change and the roadmap does not, the plan has stopped being a plan. It has become a memory of a meeting.

This is why a forecast should sit next to the kind of ledger thinking described in Roadmaps need bet ledgers. A bet ledger tracks what the team believed when it committed. A forecast-update ritual goes one step earlier and asks: what would make us believe less, believe more, or change the decision before the commitment hardens?

What belongs in a forecast-update ritual?

A ritual does not need to be heavy. In fact, if it requires a full strategy offsite, it will not survive. The practical version is a small ledger attached to every material roadmap assumption.

Start with the claim. Write it as a sentence that can be wrong. Not “customers want better reporting”, but “at least five of our top twenty accounts will commit to the new reporting workflow before the renewal cycle starts.” Not “self-serve will grow”, but “new teams can reach first value without sales assistance in less than one business day.” A vague claim protects the plan. A concrete claim protects the company.

Then record current confidence. Use a simple scale, such as low, medium, high, plus one sentence explaining why. The sentence is more important than the label. It forces the owner to reveal whether confidence comes from customer evidence, internal intuition, executive pressure, competitor movement, or a spreadsheet assumption.

Next, add outside evidence. This does not mean a grand research project. It can include recent win-loss notes, support tickets, observed product usage, sales cycle data, public market behavior, regulatory documents, procurement feedback, or customer interviews conducted after the original plan. What matters is that the evidence has a source and a date. “Everyone is asking for this” is not evidence. “Seven expansion calls in the last thirty days mentioned this blocked workflow” is closer.

Add update triggers. A trigger is a condition that forces review. Examples: fewer than three qualified design partners by September 15, activation below the agreed threshold after two cohorts, a competitor shipping a comparable workflow to the target segment, legal review extending beyond a named date, or integration effort exceeding the estimate by a defined amount. A trigger turns uncertainty into a calendar and a decision rule.

Finally, name the owner and the next review date. Ownership matters because forecasts are social. If nobody owns the update, everyone owns the original optimism. The owner is not responsible for making the forecast come true. The owner is responsible for bringing evidence back into the decision.

What should make confidence change?

The ritual only works if confidence is allowed to move. Many teams collect evidence but use it as decoration. They add customer quotes to a deck, update a dashboard, and still protect the old roadmap because changing direction feels expensive.

A better rule is to define confidence movement before new evidence arrives. For example: one enterprise customer asking for a feature may not change confidence. Five customers in the same segment describing the same blocked workflow might raise it. A large prospect requesting a feature during procurement may not be enough. A signed design partnership with implementation access might be. A promising prototype demo may not reduce technical risk. A measured failure in a realistic environment should.

This is where forecast updating connects to kill criteria. In Product bets need kill criteria, not optimism, the point is not to become negative. It is to decide in advance what evidence would stop a bet from consuming more time. The same logic applies before the bet is fully funded. If a roadmap item needs three assumptions to hold, each assumption should have a confidence level and a trigger.

The trigger does not automatically cancel the work. It opens a decision. The decision might be continue, narrow scope, change segment, delay, add discovery, replace the bet, or reduce investment. The value is not that every forecast becomes correct. The value is that the team stops pretending the original forecast is still fresh.

Where public evidence beats internal certainty

Internal certainty has a place. Founders often see weak signals before the market names them. Product leaders often combine fragments that no dashboard can summarize. But internal certainty is dangerous when it cannot be confronted by public or external information.

Public evidence has three advantages. First, it is harder to rewrite after the fact. A dated report, customer call, benchmark, market document, or usage cohort creates a trace. Second, it lowers the status cost of changing your mind. The conversation becomes “the evidence changed” rather than “the leader was wrong.” Third, it makes disagreement productive. Instead of debating who has better instincts, the team can debate which evidence should move the plan.

For roadmap decisions, public does not always mean available to the whole internet. It means visible beyond the private conviction of the planning group. A customer transcript, a procurement note, a usage cohort, or a support trend can be public inside the company if it is stored, dated, and available for review.

This is especially important when the plan crosses functions. Sales may believe demand is urgent. Engineering may believe complexity is understated. Customer success may believe adoption risk is higher than the roadmap admits. Finance may believe the timing assumption is fragile. A forecast-update ledger gives those functions a shared object instead of a hallway argument.

Audit one roadmap assumption this week

Do not redesign the whole planning system first. Pick one roadmap assumption that would hurt if it were wrong. Choose something that affects staffing, sequencing, revenue timing, launch commitment, or strategic focus.

Write the claim in one sentence. Add the current confidence and the reason behind it. Add at least one external evidence field with source and date. Define one trigger that would force review. Name the owner. Put the review date on the calendar.

The result should feel slightly uncomfortable. That discomfort is useful. It shows that the assumption has left the safety of confident language and entered the discipline of evidence.

Planning will still involve judgment. Forecasts will still miss. Teams will still have to act before certainty arrives. The aim is not to remove uncertainty from product leadership. The aim is to stop uncertainty from being hidden under confident forecasts.

A roadmap that updates with evidence is not weaker than a roadmap that stays fixed. It is more honest about the conditions under which the company is choosing to move.