In two decades of building products, the process has evolved from encyclopedic product requirements documents to lightweight Agile backlogs, yet one tension has remained stubbornly constant: the demand for fixed dates on inherently uncertain work. My own career has stretched across these paradigms, and throughout that time, product managers, engineers, and marketers have wrestled with the same dilemma. Sales leadership insists that concrete dates win deals, while delivery teams quietly recognize that those dates often rest on a foundation of hopeful conjecture rather than reliable evidence. The result is a familiar cycle of overpromising, missed commitments, strained trust, and technical shortcuts that compound risk over time.

This cycle is not a local failure of discipline or talent. It is a structural feature of how most organizations still think about planning in complex software environments. Standish Group’s long-running CHAOS studies on IT project outcomes are an uncomfortable mirror: even with decades of accumulated experience and tooling, only about a third of software projects in recent samples are delivered successfully on time and on budget, with roughly half overrunning and a nontrivial share failing outright. Earlier cohorts showed even more dramatic overruns, with average time slippage measured in hundreds of percent for challenged projects. These are not the numbers of an industry that can consistently make precise, multi-quarter commitments at the feature level. Yet those same organizations often cling to the illusion that a roadmap populated with exact dates will somehow impose order on this uncertainty.​

From the perspective of marketing and sales, the pressure for dates is understandable and, in its own way, rational. Enterprise buyers plan budgets and roadmaps of their own, align regulatory and operational milestones, and need to know when a critical capability will exist in production. Sales teams, in turn, must offer some projection of when a promised solution will be available, especially when competing against vendors that are willing to offer specific dates. Internally, leadership demands clear forecasts to guide revenue projections, staffing plans, and investor communication. In this worldview, a roadmap without dates appears weak and indecisive. It feels like a refusal to commit, and that refusal, they fear, will translate into lost deals and a perception that the company lacks direction.

On the product and engineering side, those same dates often look less like commitments and more like bets placed with incomplete information. The discovery work is rarely finished when dates are requested. Dependencies across teams, external integrations, technical debt, and changing regulatory or competitive landscapes all introduce variability that is difficult to quantify. Research on software estimation consistently shows that accuracy degrades sharply as scope and time horizons expand, which means that a feature penciled in nine or twelve months from now sits squarely in the least reliable part of the estimation curve. Teams know that when reality inevitably diverges from the plan, they will be asked to absorb the consequences through overtime, scope cuts, or quality compromises. Studies on time pressure in software development further highlight that unrealistic deadlines lead to lower quality, increased defects, and rework, ultimately delaying delivery and eroding user trust. What appears to be a sales enabler in the short term often becomes a drag on velocity and reputation in the long term.​

This clash of perspectives is exacerbated by a conceptual confusion between roadmaps, timelines, and deadlines. A roadmap is fundamentally a strategic communication artifact that describes how a product is expected to evolve to meet market needs and achieve business objectives. It should emphasize outcomes and problem spaces rather than a granular schedule. A timeline or project plan, by contrast, is an execution tool that sequences work, allocates resources, and sets delivery expectations. When executives and customers treat a roadmap as a contractual delivery schedule, it ceases to be a strategic guide and becomes a brittle list of promises. Practitioners and thought leaders have increasingly argued that this misuse undermines the very purpose of roadmapping and traps organizations in a cycle of managing dates instead of managing value.​

A more pragmatic way forward preserves what each side genuinely needs while acknowledging the limits of prediction. Outcome-based and time-bucketed roadmaps provide one such path. Rather than attaching specific calendar dates to every line item, the roadmap organizes initiatives into broad horizons, such as now, next, and later, or into half-year or annual windows for external audiences. Productboard and other product management practitioners, for example, encourage sharing higher-level timeframes like seasonal or half-year buckets publicly, while reserving more specific internal timelines for coordinating cross-functional work. This approach gives marketing and sales enough temporal context to plan campaigns and account strategies without committing the organization to a level of precision that the data cannot support.​

Internally, narrow date ranges still have a role, but they should be tied to validated scope and shared assumptions rather than aspirational targets. Once discovery is sufficiently mature, cross-functional teams can establish forecast ranges for particular milestones, making explicit what must be true for those ranges to hold and what risks could cause divergence. Roman Pichler and others suggest that internal roadmaps benefit from clear timeframes to coordinate stakeholders, provided that these are understood as forecasts that help balance goal achievement with timely delivery, not as immutable commitments. Where external, non-negotiable deadlines genuinely exist, such as regulatory mandates or contractual obligations, they should be surfaced as explicit constraints and managed with ruthless clarity about trade-offs in scope and quality. By differentiating between forecast ranges and true deadlines, leadership can reserve its political capital for the dates that truly matter.​

The argument for this model is strengthened by pairing industry data with an honest examination of local history. When an organization analyzes its own track record, it often finds that a significant fraction of date-driven commitments slip, sometimes repeatedly. The downstream costs include escalations, emergency reprioritizations, rushed releases, technical debt, and, paradoxically, lost deals or discounts granted when promises are not met. These are not abstract harms. They can be measured in support volume, churn, net promoter scores, and the opportunity cost of pulling teams off strategic work to fight fires. Framing these impacts explicitly helps leadership see that insisting on single-point dates is not a neutral preference. It is a policy choice with financial and reputational consequences that can be quantified.

As a product leader who has lived through multiple generations of planning dogma, from carefully bound PRDs to kanban boards and outcome-based frameworks, the pattern is clear. The tools change, but the need behind the conflict does not. Sales, marketing, and leadership want confidence, coherence, and credibility in front of customers and investors. Product and engineering want truthfulness about uncertainty and the space to make sound technical and design decisions. The path to a more sane future is not to declare one side right and the other wrong. It is to adopt planning practices that reflect how complex software actually behaves, backed by data from both the broader industry and the company’s own history.

A roadmap that uses time buckets externally and realistic ranges internally, that anchors initiatives in outcomes rather than features, and that exposes assumptions and risks instead of burying them, can satisfy the core needs of both groups. It will not eliminate tension, nor will it guarantee perfect foresight. What it will do is shift the conversation from defending arbitrary dates to jointly managing uncertainty in service of clear business goals. That shift requires courage, skillful communication, and a willingness to confront comforting illusions with uncomfortable evidence. Yet for organizations serious about building resilient product strategies, it is the only sustainable way forward.