8 questions from the RFI stage, free
These come from the module as sold. The workbook adds follow-ups, a response format, a weight and a score column to each.
1. Describe your customer-facing product roadmap. Your description should include: a) How customers can access it (e.g., under NDA, public portal); b) The typical time horizon it covers (e.g., 6, 12, 24 months); and c) How you distinguish between different commitment levels (e.g., 'committed,' 'planned,' 'exploratory').
Why it matters. A roadmap with defined commitment levels shows the buyer what the vendor plans to build and how firmly it has committed to each item. Blurring committed deliverables with aspirational ideas, or hiding the roadmap entirely, exposes the buyer to risk from surprise strategic shifts or features that never ship.
- Roadmap is accessible to customers under NDA via a portal or document.
- Clearly defines the time horizon (e.g., 12 months).
- Uses an explicit taxonomy for commitment levels (e.g., 'committed', 'planned', 'exploring').
- No roadmap is shared with customers, even under NDA.
- Roadmap is purely verbal or exists only in marketing materials.
- Refusal to commit to any timeframes.
2. What percentage of total company headcount and operating expenditure was allocated to research and development in the most recent completed fiscal year?
Why it matters. R&D share of headcount and spend shows how much of the company is building the product, and a multi-year trend shows whether that is growing or shrinking.
- Specific percentages given for both headcount and opex
- Numbers consistent with publicly filed accounts if applicable
- Trend across multiple fiscal years provided
- Refusal to provide any figures
- Claims of 'majority R&D' without numeric backing
- Numbers inconsistent with company size or stated team
3. State your top three strategic product priorities for the next 12-24 months, in priority order.
Why it matters. A ranked list shows what the vendor says it will fund first.
- Exactly three priorities, ranked
- Each priority concrete enough to evaluate against the buyer's needs
- Priorities tied to specific roadmap items elsewhere in the response
- More than three items listed because 'all are critical'
- Vague priorities ('customer success', 'innovation')
- Priorities that contradict marketing positioning
4. Do you publish an end-of-life (EOL) policy for features, APIs, and product versions, and if so, what notice period does it guarantee?
Why it matters. Without a published EOL policy, buyers have no protection against a vendor removing a depended-upon capability on short notice. The notice period is the time the buyer has to plan a migration.
- Published, customer-accessible EOL policy referenced by URL or document name
- Specific minimum notice period stated for major capabilities
- Separate notice tiers for APIs, features, and entire products
- No published EOL policy
- Notice periods determined case-by-case
- EOL decisions communicated only through release notes
5. How are material changes to the roadmap (delayed, descoped, or canceled items) communicated to customers, and within what timeframe of the decision being made?
Why it matters. Buyers need to understand whether they will be told promptly when a feature they planned around is delayed or canceled.
- Documented notification policy with the vendor's own committed number of days from decision to customer notice
- Notification channels named (account team, portal, email, release notes)
- Distinction between proactive notification for committed items vs. directional items
- Customers learn of cancellations from release notes or absence thereof
- No defined notification SLA
- Vendor cannot recall a recent example of a roadmap change communication
6. How many full-time engineers and researchers are dedicated to the product being proposed, separated by function (e.g. core platform, ML/research, applied AI, infrastructure, security)?
Why it matters. Headline R&D spend can mask thin coverage of the actual product the buyer is purchasing. A functional breakdown surfaces whether the engineering depth matches the product's complexity.
- Specific FTE counts per function
- Distinction between staff working on the proposed product vs. shared platform
- Identification of research staff with relevant publication record where applicable
- Single aggregate number with no breakdown
- Counts that include contractors or third parties without labeling
- Numbers that contradict publicly available headcount information
7. Describe which customer segments (by size, industry, geography, or use case) are your strategic focus, and which segments are explicitly outside that focus.
Why it matters. Buyers need to know whether they sit in the vendor's strategic core or its long tail.
- Specific segments named (e.g. 'large enterprise financial services in North America and EU')
- Honest acknowledgment of segments that are not the focus
- Distribution of current revenue across segments provided
- Claims of focus on 'all segments'
- Focus stated in marketing but contradicted by customer base
- Vendor cannot describe its ideal customer profile
8. Describe your policy for end-of-life of underlying foundation models exposed through your product, including notice periods and migration support.
Why it matters. Foundation model providers retire models on their own schedules, sometimes with limited notice. The vendor's job is to insulate buyers from that churn or, where they cannot, to communicate it well in advance with a migration path.
- Stated notice period for model deprecation distinct from feature EOL
- Migration tooling or compatibility guidance offered
- Acknowledgment that upstream provider timelines may compress notice
- Model deprecation passed straight through to customers with no buffer
- No distinction between vendor-owned EOL and upstream-driven EOL
- Migration described as customer responsibility with no assistance
What the audit changed
A language model drafted these questions and a second model critiqued them. Three audit passes followed and made 141 changes. Three examples:
Wrong or outdated citation
Draft: Can a slipped roadmap commitment trigger termination for convenience without penalty?
Now: Can a slipped roadmap commitment give the buyer a right to terminate without penalty?
Termination for convenience means termination without cause. A right to terminate because a committed item slipped or a relied-upon capability was retired is an event-triggered termination right, not termination for convenience. Same correction as the commercial module.
Wrong or outdated citation
Draft: release frequency, average lead time from commit to production, change-failure rate, and mean time to recovery for significant incidents over the trailing 12 months.
Now: deployment frequency, change lead time from commit to production, change fail rate, and failed deployment recovery time over the trailing 12 months, plus the mean time to recover from significant incidents.
DORA (DevOps Research and Assessment) renamed 'time to restore service'/MTTR to 'failed deployment recovery time' in 2023; it measures recovery from failed deployments, not all incidents. Incident recovery kept as a separate figure. Source: https://dora.dev/insights/dora-metrics-history/
Wrong or outdated citation
Draft: Reports concrete DORA-style metrics (deployment frequency, lead time, change-failure rate, MTTR).
Now: Reports concrete DORA metrics (deployment frequency, change lead time, change fail rate, failed deployment recovery time).
Current DORA metric names. Source: https://dora.dev/guides/dora-metrics-four-keys/ (DORA added a fifth, deployment rework rate, in 2024).
