A roadmap dependency decision determines whether one tender requirement can be satisfied when the proposed solution relies on product behavior that is not verified in the offered release today. Its work product is a roadmap_dependency_decision. The record fixes the procurement, lot, bidder, product edition and deployment model; identifies the controlling requirement, evaluation treatment and required event; proves the current baseline; classifies the proposed change; models its release and acceptance path; records permitted alternatives, price and contract effects; and names every required authority. It does not turn an idea, backlog item, target quarter, prototype or engineering forecast into a customer commitment. It also does not approve funding, change the product roadmap, contact the buyer, accept contract terms or authorize submission.
Roadmaps compress unlike facts into one reassuring picture. A feature can be requested, researched, designed, budgeted, scheduled, under development or ready for controlled release. “On the roadmap” does not say which state applies. Nor does it identify the offered edition, security boundary, integration, customer dependency or acceptance test. A sales team may only need the feature at service start next year, while a pass or fail response asks whether it exists at the bid deadline. Another buyer may score the proposed delivery method and permit a later milestone. When the team answers both cases with the same future-tense promise, it either abandons a viable bid or makes a commitment the product organization never approved.
Anchor the decision to the buyer’s required state, not to the internal roadmap label. First decide whether the requirement must be true at submission, demonstration, award, contract signature, implementation acceptance, go-live or a later service phase. Then establish what the offered product can prove now. If a change is still required, expose the complete path from product decision through build, assurance, release, deployment and buyer acceptance. A positive result needs more than technical possibility: the work must be approved, resourced, compatible with other commitments, priced, contractually expressible and supported by a fallback or stop point. An agent may assemble this evidence and test the logic. The named product and commercial authorities own the promise.
Tender meaning
Find the event at which the feature must be true
The first question is temporal. Read the requirement beside the response instruction, evaluation method, demonstration script, implementation schedule, acceptance schedule and draft contract. “The system shall support offline inspections” can mean present compliance at submission, a capability evaluated in a bid demonstration, a deliverable due during implementation or an operating obligation from go-live. Each meaning creates a different decision. Record both the capability event and the evidence event, because a buyer may evaluate a written method now and test the delivered function later.
The procurement’s governing words set the boundary. Article 56 of Directive 2014/24/EU links award to a tender that complies with the requirements, conditions and criteria in the procurement documents. Under the UK Procurement Act 2023, section 19 describes the most advantageous tender as one that satisfies the authority’s requirements and best meets the award criteria; section 23 also requires the assessment method to say whether failure on a criterion disqualifies a tender. Neither rule answers every product-roadmap case. They make the current tender pack, procedure and applicable law decisive.
Classify the requirement before discussing a future build. A pass or fail field marked “available now” cannot safely inherit a go-live date from the implementation plan. A scored solution design may invite a credible development approach. A contract schedule may create an enforceable milestone after award. A permitted variant can open another route, while an unannounced qualification can make the offer non-compliant. If the documents point to incompatible events, return `source_conflict`. If their legal effect is uncertain, use `legal_review_required` or prepare a clarification through the official channel.
| Tender event | Question to answer | Evidence that may be relevant |
|---|---|---|
| Submission | Must the offered product already have the feature? | Current release evidence and exact response instruction |
| Evaluation or demonstration | What behavior will evaluators inspect? | Demonstration rules, environment and test script |
| Award or signature | What promise becomes binding? | Offer, clarifications, award terms and contract schedule |
| Implementation acceptance | Which observable result must pass? | Acceptance criteria, data, environment and remedy |
| Go-live or service phase | When must the capability operate at contracted scale? | Service commencement rule, volumes and operating conditions |
Current capability
Prove what the offered release can do today
Use the product that would be named in the bid, not a corporate capability statement. Fix edition, release, deployment boundary, region, language, device, tenant settings, licensed modules and required third parties. Run the relevant behavior with representative data and keep the result, date, environment and tester. Product documentation can support the record, but a version-specific test often reveals limits hidden by a broad feature name. Record constraints such as batch limits, latency, supported identity providers or manual operator steps.
Classify the route before calling anything a roadmap dependency. `available_verified` means the offered release passes the requirement under the stated conditions. `configuration_required` uses supported settings without changing product code. `existing_integration_required` relies on a released and supportable interface. `custom_delivery_work` creates deal-specific implementation outside the reusable product. Only a change to product behavior belongs in the roadmap path. This separation matters because configuration, customer data work and product engineering have different owners, prices and acceptance evidence.
Give the product item a factual internal state: `idea_recorded`, `discovery_active`, `solution_approved`, `funded_unscheduled`, `release_scheduled`, `in_development`, `release_candidate`, `limited_availability` or `generally_available`. The names may be mapped to the company’s own lifecycle, but their meanings must stay distinct. A date without an approved scope is weak evidence. Code in a branch is not released behavior. Limited availability may carry customer, scale or support restrictions. Preserve the dated source and owner for every state instead of importing a green color from a planning board.
| Observed state | What it proves | What it does not prove |
|---|---|---|
| Idea or discovery | A problem is being examined | Approved scope, priority or delivery |
| Solution approved | Product authority accepted a defined approach | Funded capacity or release date |
| Funded and scheduled | Capacity and target window are assigned | Successful build, release or acceptance |
| In development | Implementation work has started | Completion, quality or customer availability |
| Release candidate | A candidate build reached named gates | Production approval or tender acceptance |
| Generally available | Released scope is supportable for stated users | Fit for every edition, region or buyer condition |
Delivery proof
A ship date is only one link in the commitment
Build the dependency graph from the buyer’s accepted outcome backwards. Start with the acceptance test, operating environment and latest permitted date. Before that may sit buyer configuration, migration, integration, documentation, training and deployment approval. Product release may depend on design closure, engineering, third-party interfaces, test data, performance work, security and privacy review, accessibility checks, localization, support readiness and release governance. Include only the gates that apply, but do not erase one because it belongs to another team.
Each milestone needs a responsible owner, predecessors, dated evidence, earliest finish, latest credible finish and proof of completion. Use ranges where uncertainty exists. A dependency controlled by a platform vendor or the buyer should retain the external party, notice period and adverse scenario. Shared engineering capacity also belongs in the graph: an approved item can still be displaced if two contractual promises depend on the same people. The date that matters is the latest end-to-end path, not the earliest code-complete estimate.
Release readiness must match the promised context. NIST SP 800-218 describes secure software development practices that can be integrated into a software lifecycle. It is not a general certificate that a feature is ready, but it is a useful reminder that software release includes defined security work and retained evidence. Add the product’s other applicable gates and the buyer’s acceptance method. A passed unit test cannot prove usability at contracted scale; a successful internal pilot cannot prove compatibility with the buyer’s identity provider. Define the evidence before approving the promise.
| Field | Required value | Decision use |
|---|---|---|
| Owner | Person or accountable function | Names who can confirm progress |
| Predecessors | All gates that must finish first | Exposes the actual critical path |
| Date range | Earliest and latest supported finish | Prevents one optimistic date from controlling |
| Completion proof | Test, approval, release or accepted artifact | Defines what closes the milestone |
| Adverse branch | Delay, failed test or dependency loss | Shows the consequence and fallback |
| Expiry trigger | Fact that invalidates the estimate | Forces a timely re-decision |
Promise control
Approve the words together with the obligation they create
Draft the buyer-facing statement after the evidence review. “We are considering,” “we target,” “we offer,” and “we will deliver by 30 April” carry different commitments. Keep the sentence next to the supporting decision, required event and expiry. If the response asks for yes or no, use the tender’s prescribed mechanism for explanation, qualification or deviation. Do not hide a future dependency behind an unconditional yes or add a condition in a place the evaluator is not required to read.
Approval follows the exposure. Product authority owns reusable scope and priority. Engineering confirms the release path and capacity. Delivery owns customer-specific work and buyer dependencies. Security, privacy or regulatory owners approve relevant gates. Commercial authority accepts cost, opportunity cost and remedies. Legal review addresses the offer, warranty, liability, intellectual property and deviation mechanism. One meeting attendee cannot silently approve on behalf of every function. Record the exact statement each authority saw.
Test safer routes before relying on new code. The current product may satisfy the buyer’s outcome through supported configuration. An existing integration may be acceptable. The tender may invite variants, phased delivery or a declared alternative. A clarification can ask which event controls or whether an outcome-equivalent method is permitted, without revealing private strategy. Every route keeps its own tender basis, evidence, cost and approval. Silence from the buyer never converts an unpermitted exception into compliance.
| Buyer-facing position | Minimum support | Decision limit |
|---|---|---|
| Current capability | Verified offered release and applicable scope | Describe only observed behavior |
| Target or intention | Approved disclosure of a non-binding direction | Do not imply contractual availability |
| Future offer commitment | Approved scope, path, date, price and acceptance | Bind only through authorized wording |
| Permitted alternative | Tender basis and complete alternative response | Keep differences visible to the evaluator |
| Contract obligation | Authorized contract schedule, remedies and dependencies | Reconcile every related document |
Worked case and agent contract
Example: an offline inspection feature is funded but not ready
A fictional regional transit authority requests a mobile inspection service. Tenders close on 14 October 2026, scripted demonstrations take place in November and service acceptance is scheduled for 17 May 2027. The response matrix scores the proposed offline method; it does not require the feature in the demonstration. The acceptance schedule, however, requires an inspector to work without connectivity for eight hours, capture photographs and timestamps, then resolve conflicting edits during synchronization. These dates and facts do not describe an active procurement.
The offered release can cache inspection forms but cannot store photographs offline or resolve edit conflicts. Product records show an approved design and funded engineering window ending in February 2027. The mobile database vendor has not yet confirmed one encryption behavior, no test device matrix is approved, and the buyer has not supplied its identity configuration. The team’s earliest path reaches acceptance in April; its adverse path reaches June. The current decision is `roadmap_dependency_unresolved`, even though the target quarter precedes go-live. The unresolved external behavior and late adverse path prevent an authorized delivery promise.
The work product carries procurement and lot identifiers, source versions, bidder and product fingerprint, requirement text, evaluation treatment, capability and evidence events, current-state tests, item status, dependency graph, date ranges, acceptance test, alternatives, affected price and contract terms, proposed statement, approvals, contrary evidence, next action and expiry triggers. Allowed results are `bid_on_current_capability`, `bid_with_approved_product_commitment`, `bid_with_permitted_alternative`, `clarification_required`, `roadmap_dependency_unresolved`, `no_bid_dependency`, `source_conflict`, `legal_review_required` and `authority_missing`. An agent may retrieve clauses, compare product evidence, calculate the path, test consistency and draft an internal recommendation or authorized clarification. It must stop before changing priority, allocating budget, publishing roadmap detail, committing a date, accepting an exception, contacting the buyer or submitting the tender.
What good looks like
Useful outcomes from bid with future product feature
- One procurement, lot, bidder, product edition, deployment model, requirement and observation time define the decision.
- The requirement’s evaluation treatment and required event are quoted from the current tender source chain.
- Current standard, configurable and integrated behavior is separated from any product change.
- Idea, discovery, planned, funded, approved, in-development, release-candidate and generally available states remain distinct.
- Every future dependency has an owner, predecessor, evidence, date range, adverse branch and expiry trigger.
- The release forecast includes security, privacy, accessibility, localization, operations and support where they affect acceptance.
- Buyer acceptance criteria are mapped before the team commits to a delivery date.
- Alternative configurations, variants, deviations and clarifications are used only when the tender permits them.
- The exact external statement is approved together with its price, implementation and contract consequences.
- No agent changes a roadmap, promises a feature, contacts the buyer or submits the tender without separate authority.
Operating model
How to run the work
- 01
Freeze the decision scope
Record the authority, procedure, lot, bidder, offered product edition, deployment model, current document versions and checked time.
- 02
Locate the required state
Capture the exact requirement, instruction verb, mandatory or scored treatment, proof requested and event at which the capability must exist.
- 03
Prove the current baseline
Test the offered release under representative conditions and record configuration, integrations, limitations, evidence owner and validity.
- 04
Classify the proposed change
Separate configuration, integration and supported extension from a product change, then give the product item its evidenced internal state.
- 05
Model the release path
Link product approval, design, engineering, assurance, release, deployment and acceptance milestones with owners and date ranges.
- 06
Test permitted routes
Check current capability, an allowed configuration, alternative solution, variant, declared deviation, clarification or future commitment separately.
- 07
Reconcile the whole offer
Carry the dependency into implementation, price, service levels, warranty, acceptance, remedies, support and every affected response.
- 08
Approve the exact promise
Require named product, engineering, delivery, commercial and legal authority appropriate to the exposure before releasing buyer-facing words.
- 09
Watch and expire
Reopen the decision after any tender amendment, scope change, slipped dependency, failed test, competing roadmap commitment or contract change.
Evaluation
Questions that change the decision
- What exact outcome does the requirement ask the offered solution to produce?
- Is the requirement a submission condition, demonstration gate, scored promise, implementation deliverable, acceptance test or service obligation?
- At which event must the capability exist, and when must evidence of it be supplied?
- What does the offered product edition and deployment model demonstrably do at the checked time?
- Can supported configuration, an existing integration or a permitted alternative meet the outcome without new product code?
- What internal state does the future feature occupy, and which dated evidence proves that state?
- Which design, engineering, assurance, third-party, release and buyer dependencies control availability?
- What test will prove the buyer’s requirement rather than merely prove that code shipped?
- How does the commitment change price, implementation, service, warranty, remedies and other customer promises?
- What wording is accurate now, and who may authorize that exact future commitment?
- Which event or latest safe date changes a conditional bid into a stop?
Failure modes
Where teams lose control
A roadmap quarter is quoted as a guaranteed customer delivery date.
A prototype or feature flag is described as generally available in the offered product.
The feature exists in another edition, region or deployment model and is attributed to this offer.
Engineering feasibility is mistaken for approved priority, budget and capacity.
A code-complete date omits security review, accessibility, localization, operations, documentation and support readiness.
The requirement applies at bid or demonstration, but the plan assumes it is only needed at go-live.
A workaround changes the buyer’s required behavior and is submitted without an allowed variant or deviation.
The roadmap promise appears in the technical answer but not in price, implementation, contract or acceptance terms.
One customer commitment displaces another roadmap obligation that used the same engineering capacity.
Confidential roadmap detail, source code, vulnerability information or customer data is exposed to an unauthorized agent or buyer.
Measurement
Measure the finished job
Measure the completed workflow, including review effort and exceptions. Output volume on its own is not evidence of a better process.
- roadmap-dependent requirements with a fixed source, evaluation treatment and required event
- current product baselines supported by version-specific test or product evidence
- future items carrying an evidenced internal state rather than a generic roadmap label
- critical-path milestones with owner, dependency, earliest date, latest date and completion proof
- future commitments mapped to buyer acceptance tests before approval
- approved dependencies reconciled across response, price, implementation and contract
- conditional decisions reopened before their expiry event
- positive future-feature decisions with named product and commercial authority
- unsupported product promises, unauthorized roadmap changes and submissions; target zero
Questions
Common questions
Is a feature on the roadmap enough to answer yes in an RFP?
No. Establish the item’s approved state, release path, required buyer event, acceptance proof, offer wording and commitment authority. A roadmap label alone proves none of those facts.
Can we bid if the feature is due only at go-live?
Possibly. Confirm that the tender permits future delivery, model the complete path to the go-live requirement, obtain the required approvals and reflect the dependency consistently in price, implementation, acceptance and contract terms.
Does code complete mean the roadmap risk is closed?
No. Assurance, release approval, deployment, support readiness, customer dependencies and the buyer’s acceptance test may remain. Close the dependency only with the completion evidence defined for the promised state.
Should the bid disclose that the feature is not available yet?
The response must remain accurate and follow the tender’s format. Use the permitted explanation, variant or deviation route and obtain legal and commercial review where the wording can affect compliance or contract interpretation.
Can an AI agent approve a roadmap commitment?
No. An agent can build a cited decision record and identify missing proof. Named humans with product, delivery, commercial and legal authority must approve the commitment and any external action.
Sources
Primary references
- Directive 2014/24/EU, consolidated text, Articles 42, 56, 67 and 70 EUR-Lex
- Procurement Act 2023, section 19 UK Legislation
- Procurement Act 2023, section 23 UK Legislation
- Guidance on assessing competitive tenders, updated 17 August 2026 UK Cabinet Office
- Secure Software Development Framework version 1.1 National Institute of Standards and Technology
About the author
Tony Kim
Tony writes about applied AI, dependable product engineering and the systems that turn complex response work into controlled delivery.
Zelius
Managed tender intelligence and bid execution for teams that want the commercial outcome.
Suppliers, founders and commercial teams pursuing public or private opportunities. Start with the workflow, constraints and evidence you already have.