Commercial
The Single Biggest Change That Determines Whether an RFP Succeeds or Fails
The Single Biggest Change That Determines Whether an RFP Succeeds or Fails
The Single Biggest Change That Determines Whether an RFP Succeeds or Fails
The Single Biggest Change That Determines Whether an RFP Succeeds or Fails
The single biggest change that determines whether an RFP succeeds or fails
Most RFPs fail for many reasons.
They run late, they consume more internal effort than planned, suppliers over-promise, delivery falls short and commercial discussions become adversarial within months of contract signature.
But in our experience across media, OTT, broadcast and digital publishing organisations, RFPs nearly always fail in the same place, long before vendors are selected, and often before the document is even issued.
They fail in how the requirements are written.
If there is one change an RFP author can make that has a disproportionate impact on outcome, it is this:
Stop asking suppliers to describe capabilities, and start forcing them to prove them through clear, unambiguous, measurable requirements.
Everything else in the RFP process is secondary.
Why RFPs feel fair but produce poor decisions
Most poorly performing RFPs do not look broken on the surface. In fact, they often appear thorough, structured and reasonable.
They contain sensible questions such as:
Describe your search capability within the CMS
Explain how your platform supports localisation
Tell us about your approach to scalability and performance
These questions feel open, collaborative and vendor-friendly. They also feel informative.
In practice, they create three systemic problems.
First, they invite interpretation. Each supplier answers a subtly different question.
Second, they reward marketing strength rather than product truth. Narrative responses sound convincing even when capability is partial, roadmap-based or assumed.
Third, they make objective comparison impossible. Evaluation discussions quickly drift from evidence to opinion, and scoring becomes an exercise in persuasion rather than assessment.
At this point, the RFP process is already compromised - even if every other step is run perfectly.
The moment everything goes wrong: subjective requirements
The most common failure pattern we see starts with a single word:
“Describe.”
For example:
“Describe the search feature in the CMS.”
This requirement cannot be scored objectively. There is no shared definition of success, no measurable threshold, and no way to determine compliance with confidence.
Every supplier can respond positively without committing to anything verifiable.
What follows is predictable:
Evaluators fill gaps with assumption
Workshops are used to clarify basic capability
Contract negotiations attempt to retroactively lock down scope
Delivery reveals mismatched expectations
The RFP did not fail because suppliers were dishonest. It failed because the requirements allowed them to be vague.
What great RFP authors do differently
Strong RFP authors approach requirements very differently.
Instead of asking suppliers to explain how something works, they start by defining what must be true for the solution to be acceptable.
They take a high-level product need or user story and decompose it into a set of atomic, testable statements.
Each statement is:
Clear
Unambiguous
Measurable
Independently assessable
Crucially, each statement allows only one of two responses: True or False.
For example, instead of asking about search capability:
The solution SHALL support search across all metadata attributes stored within the CMS for any given object.
The solution SHALL support search across all languages defined within a multi-language article.
The solution SHALL return results within two seconds for datasets of up to X million objects under normal operating conditions. (And don't forget to define what normal operating conditions are!)
There is no room for interpretation. Either the capability exists, or it does not.
This approach changes the nature of the RFP entirely.
Why binary requirements transform outcomes
When requirements are written as objective statements rather than narrative prompts, several things happen immediately.
Supplier responses become shorter and more precise. Marketing language disappears because it no longer helps.
Capability gaps surface early. Suppliers are forced to be explicit about limitations, dependencies or roadmap items.
Scoring becomes faster and defensible. Evaluation discussions are grounded in evidence rather than opinion.
Workshops become about validation and depth, not basic clarification.
Most importantly, contracts become easier to negotiate. The requirements matrix already defines minimum acceptable capability, reducing ambiguity and dispute risk.
This is the single most effective way to reduce downstream change requests, commercial friction and delivery disappointment.
Translating user stories into requirements, without locking the future
One of the most common concerns with writing highly specific, measurable requirements is that they will over-constrain the solution.
This concern is valid - but it is not a reason to accept vague requirements. It is a signal that requirements must be written with intent.
Specific and objective requirements should not describe how a solution is built. They should define behaviour that must be true, while deliberately leaving room for evolution, reconfiguration and future change.
This distinction is critical.
Poorly written requirements hard-code today’s assumptions:
Prescribing internal architectures
Mandating implementation patterns
Embedding current organisational constraints as permanent truths
Well-written requirements do the opposite. They define outcomes that support an architect-for-change approach.
For example:
Instead of:
The solution SHALL use technology X to support multilingual search.
Prefer:
The solution SHALL support search across all languages defined within a multi-language article, without requiring custom development for each additional language.
Instead of:
The CMS SHALL be configured with a fixed content model defined at implementation.
Prefer:
The CMS SHALL allow authorised users to extend and modify content models without code changes or platform re-deployment.
In both cases, the requirement is still binary and testable, but it preserves freedom to adapt.
This is how future change is managed responsibly. You are not predicting what the platform must become. You are ensuring that it can become something else when the business inevitably changes.
High-level user stories still play an important role. They express intent and direction. But the evaluative mechanism remains the requirement set, written to test behavioural capability, not design preference.
This balance is difficult to achieve. It requires experience to know which constraints protect the business and which merely protect current thinking.
That judgement is the difference between requirements that age well and requirements that become obsolete before the contract is signed.
Why writing great requirements is genuinely hard
There is a reason this approach is rarely executed well.
Writing requirements that are specific, clear, measurable and objective is not a clerical task. It is an analytical discipline that sits at the intersection of product thinking, systems engineering, operational reality and commercial risk.
In most organisations, we simply don't see many people who can do this consistently.
This is why organisations running complex media and platform programmes often bring in specialist RFP and tendering expertise when the decision carries long-term risk.
Requirements authors must be able to:
Understand user needs without copying user stories verbatim
Translate abstract business goals into concrete system behaviour
Anticipate scale, edge cases and failure modes
Remove ambiguity without over-constraining delivery
Write statements that are testable, defensible and contract-ready
That combination of skills is rare. As a result, requirements are often written by committee, diluted through compromise, or delegated to teams without the necessary experience. The outcome is predictable: well-intentioned documents that fail to protect the business.
This is also why strong requirements often feel uncomfortable internally. They force decisions earlier than many organisations are used to making. They expose uncertainty. They remove the safety blanket of vague language.
Why everything else still matters…..just not as much
Timelines matter. Governance matters. Communication matters. Fairness matters.
But none of these can compensate for weak requirements.
A perfectly run RFP process built on ambiguous requirements will still produce a poor outcome. A less elegant process built on rigorous, objective requirements often succeeds despite imperfections elsewhere.
This hierarchy is uncomfortable, particularly in procurement-led environments. But it reflects reality.
If you change one thing, change this
If you are about to issue an RFP, review it with one question in mind:
Can every requirement be scored objectively without debate?
If the answer is no, that is where to focus your effort.
Getting this right takes time and discipline. It requires resisting vague language and forcing clarity earlier than feels comfortable.
The payoff is significant.
Spicy Mango maintains extensive RFP frameworks and requirement libraries for OTT, streaming and digital publishing platforms, built from real delivery experience. We license reference material that has translated hundreds of high level functional and non-functional requirements into thousands of distinct, clear and measurable statements. This depth is one of the reasons Tier 1 media organisations engage us to shape and deliver strategic transformation programmes, not simply to run procurement, but to define what success actually looks like at a requirements level. If you want to accelerate this work without sacrificing rigour, get in touch to see what good looks like in practice.
The single biggest change that determines whether an RFP succeeds or fails
Most RFPs fail for many reasons.
They run late, they consume more internal effort than planned, suppliers over-promise, delivery falls short and commercial discussions become adversarial within months of contract signature.
But in our experience across media, OTT, broadcast and digital publishing organisations, RFPs nearly always fail in the same place, long before vendors are selected, and often before the document is even issued.
They fail in how the requirements are written.
If there is one change an RFP author can make that has a disproportionate impact on outcome, it is this:
Stop asking suppliers to describe capabilities, and start forcing them to prove them through clear, unambiguous, measurable requirements.
Everything else in the RFP process is secondary.
Why RFPs feel fair but produce poor decisions
Most poorly performing RFPs do not look broken on the surface. In fact, they often appear thorough, structured and reasonable.
They contain sensible questions such as:
Describe your search capability within the CMS
Explain how your platform supports localisation
Tell us about your approach to scalability and performance
These questions feel open, collaborative and vendor-friendly. They also feel informative.
In practice, they create three systemic problems.
First, they invite interpretation. Each supplier answers a subtly different question.
Second, they reward marketing strength rather than product truth. Narrative responses sound convincing even when capability is partial, roadmap-based or assumed.
Third, they make objective comparison impossible. Evaluation discussions quickly drift from evidence to opinion, and scoring becomes an exercise in persuasion rather than assessment.
At this point, the RFP process is already compromised - even if every other step is run perfectly.
The moment everything goes wrong: subjective requirements
The most common failure pattern we see starts with a single word:
“Describe.”
For example:
“Describe the search feature in the CMS.”
This requirement cannot be scored objectively. There is no shared definition of success, no measurable threshold, and no way to determine compliance with confidence.
Every supplier can respond positively without committing to anything verifiable.
What follows is predictable:
Evaluators fill gaps with assumption
Workshops are used to clarify basic capability
Contract negotiations attempt to retroactively lock down scope
Delivery reveals mismatched expectations
The RFP did not fail because suppliers were dishonest. It failed because the requirements allowed them to be vague.
What great RFP authors do differently
Strong RFP authors approach requirements very differently.
Instead of asking suppliers to explain how something works, they start by defining what must be true for the solution to be acceptable.
They take a high-level product need or user story and decompose it into a set of atomic, testable statements.
Each statement is:
Clear
Unambiguous
Measurable
Independently assessable
Crucially, each statement allows only one of two responses: True or False.
For example, instead of asking about search capability:
The solution SHALL support search across all metadata attributes stored within the CMS for any given object.
The solution SHALL support search across all languages defined within a multi-language article.
The solution SHALL return results within two seconds for datasets of up to X million objects under normal operating conditions. (And don't forget to define what normal operating conditions are!)
There is no room for interpretation. Either the capability exists, or it does not.
This approach changes the nature of the RFP entirely.
Why binary requirements transform outcomes
When requirements are written as objective statements rather than narrative prompts, several things happen immediately.
Supplier responses become shorter and more precise. Marketing language disappears because it no longer helps.
Capability gaps surface early. Suppliers are forced to be explicit about limitations, dependencies or roadmap items.
Scoring becomes faster and defensible. Evaluation discussions are grounded in evidence rather than opinion.
Workshops become about validation and depth, not basic clarification.
Most importantly, contracts become easier to negotiate. The requirements matrix already defines minimum acceptable capability, reducing ambiguity and dispute risk.
This is the single most effective way to reduce downstream change requests, commercial friction and delivery disappointment.
Translating user stories into requirements, without locking the future
One of the most common concerns with writing highly specific, measurable requirements is that they will over-constrain the solution.
This concern is valid - but it is not a reason to accept vague requirements. It is a signal that requirements must be written with intent.
Specific and objective requirements should not describe how a solution is built. They should define behaviour that must be true, while deliberately leaving room for evolution, reconfiguration and future change.
This distinction is critical.
Poorly written requirements hard-code today’s assumptions:
Prescribing internal architectures
Mandating implementation patterns
Embedding current organisational constraints as permanent truths
Well-written requirements do the opposite. They define outcomes that support an architect-for-change approach.
For example:
Instead of:
The solution SHALL use technology X to support multilingual search.
Prefer:
The solution SHALL support search across all languages defined within a multi-language article, without requiring custom development for each additional language.
Instead of:
The CMS SHALL be configured with a fixed content model defined at implementation.
Prefer:
The CMS SHALL allow authorised users to extend and modify content models without code changes or platform re-deployment.
In both cases, the requirement is still binary and testable, but it preserves freedom to adapt.
This is how future change is managed responsibly. You are not predicting what the platform must become. You are ensuring that it can become something else when the business inevitably changes.
High-level user stories still play an important role. They express intent and direction. But the evaluative mechanism remains the requirement set, written to test behavioural capability, not design preference.
This balance is difficult to achieve. It requires experience to know which constraints protect the business and which merely protect current thinking.
That judgement is the difference between requirements that age well and requirements that become obsolete before the contract is signed.
Why writing great requirements is genuinely hard
There is a reason this approach is rarely executed well.
Writing requirements that are specific, clear, measurable and objective is not a clerical task. It is an analytical discipline that sits at the intersection of product thinking, systems engineering, operational reality and commercial risk.
In most organisations, we simply don't see many people who can do this consistently.
This is why organisations running complex media and platform programmes often bring in specialist RFP and tendering expertise when the decision carries long-term risk.
Requirements authors must be able to:
Understand user needs without copying user stories verbatim
Translate abstract business goals into concrete system behaviour
Anticipate scale, edge cases and failure modes
Remove ambiguity without over-constraining delivery
Write statements that are testable, defensible and contract-ready
That combination of skills is rare. As a result, requirements are often written by committee, diluted through compromise, or delegated to teams without the necessary experience. The outcome is predictable: well-intentioned documents that fail to protect the business.
This is also why strong requirements often feel uncomfortable internally. They force decisions earlier than many organisations are used to making. They expose uncertainty. They remove the safety blanket of vague language.
Why everything else still matters…..just not as much
Timelines matter. Governance matters. Communication matters. Fairness matters.
But none of these can compensate for weak requirements.
A perfectly run RFP process built on ambiguous requirements will still produce a poor outcome. A less elegant process built on rigorous, objective requirements often succeeds despite imperfections elsewhere.
This hierarchy is uncomfortable, particularly in procurement-led environments. But it reflects reality.
If you change one thing, change this
If you are about to issue an RFP, review it with one question in mind:
Can every requirement be scored objectively without debate?
If the answer is no, that is where to focus your effort.
Getting this right takes time and discipline. It requires resisting vague language and forcing clarity earlier than feels comfortable.
The payoff is significant.
Spicy Mango maintains extensive RFP frameworks and requirement libraries for OTT, streaming and digital publishing platforms, built from real delivery experience. We license reference material that has translated hundreds of high level functional and non-functional requirements into thousands of distinct, clear and measurable statements. This depth is one of the reasons Tier 1 media organisations engage us to shape and deliver strategic transformation programmes, not simply to run procurement, but to define what success actually looks like at a requirements level. If you want to accelerate this work without sacrificing rigour, get in touch to see what good looks like in practice.
The single biggest change that determines whether an RFP succeeds or fails
Most RFPs fail for many reasons.
They run late, they consume more internal effort than planned, suppliers over-promise, delivery falls short and commercial discussions become adversarial within months of contract signature.
But in our experience across media, OTT, broadcast and digital publishing organisations, RFPs nearly always fail in the same place, long before vendors are selected, and often before the document is even issued.
They fail in how the requirements are written.
If there is one change an RFP author can make that has a disproportionate impact on outcome, it is this:
Stop asking suppliers to describe capabilities, and start forcing them to prove them through clear, unambiguous, measurable requirements.
Everything else in the RFP process is secondary.
Why RFPs feel fair but produce poor decisions
Most poorly performing RFPs do not look broken on the surface. In fact, they often appear thorough, structured and reasonable.
They contain sensible questions such as:
Describe your search capability within the CMS
Explain how your platform supports localisation
Tell us about your approach to scalability and performance
These questions feel open, collaborative and vendor-friendly. They also feel informative.
In practice, they create three systemic problems.
First, they invite interpretation. Each supplier answers a subtly different question.
Second, they reward marketing strength rather than product truth. Narrative responses sound convincing even when capability is partial, roadmap-based or assumed.
Third, they make objective comparison impossible. Evaluation discussions quickly drift from evidence to opinion, and scoring becomes an exercise in persuasion rather than assessment.
At this point, the RFP process is already compromised - even if every other step is run perfectly.
The moment everything goes wrong: subjective requirements
The most common failure pattern we see starts with a single word:
“Describe.”
For example:
“Describe the search feature in the CMS.”
This requirement cannot be scored objectively. There is no shared definition of success, no measurable threshold, and no way to determine compliance with confidence.
Every supplier can respond positively without committing to anything verifiable.
What follows is predictable:
Evaluators fill gaps with assumption
Workshops are used to clarify basic capability
Contract negotiations attempt to retroactively lock down scope
Delivery reveals mismatched expectations
The RFP did not fail because suppliers were dishonest. It failed because the requirements allowed them to be vague.
What great RFP authors do differently
Strong RFP authors approach requirements very differently.
Instead of asking suppliers to explain how something works, they start by defining what must be true for the solution to be acceptable.
They take a high-level product need or user story and decompose it into a set of atomic, testable statements.
Each statement is:
Clear
Unambiguous
Measurable
Independently assessable
Crucially, each statement allows only one of two responses: True or False.
For example, instead of asking about search capability:
The solution SHALL support search across all metadata attributes stored within the CMS for any given object.
The solution SHALL support search across all languages defined within a multi-language article.
The solution SHALL return results within two seconds for datasets of up to X million objects under normal operating conditions. (And don't forget to define what normal operating conditions are!)
There is no room for interpretation. Either the capability exists, or it does not.
This approach changes the nature of the RFP entirely.
Why binary requirements transform outcomes
When requirements are written as objective statements rather than narrative prompts, several things happen immediately.
Supplier responses become shorter and more precise. Marketing language disappears because it no longer helps.
Capability gaps surface early. Suppliers are forced to be explicit about limitations, dependencies or roadmap items.
Scoring becomes faster and defensible. Evaluation discussions are grounded in evidence rather than opinion.
Workshops become about validation and depth, not basic clarification.
Most importantly, contracts become easier to negotiate. The requirements matrix already defines minimum acceptable capability, reducing ambiguity and dispute risk.
This is the single most effective way to reduce downstream change requests, commercial friction and delivery disappointment.
Translating user stories into requirements, without locking the future
One of the most common concerns with writing highly specific, measurable requirements is that they will over-constrain the solution.
This concern is valid - but it is not a reason to accept vague requirements. It is a signal that requirements must be written with intent.
Specific and objective requirements should not describe how a solution is built. They should define behaviour that must be true, while deliberately leaving room for evolution, reconfiguration and future change.
This distinction is critical.
Poorly written requirements hard-code today’s assumptions:
Prescribing internal architectures
Mandating implementation patterns
Embedding current organisational constraints as permanent truths
Well-written requirements do the opposite. They define outcomes that support an architect-for-change approach.
For example:
Instead of:
The solution SHALL use technology X to support multilingual search.
Prefer:
The solution SHALL support search across all languages defined within a multi-language article, without requiring custom development for each additional language.
Instead of:
The CMS SHALL be configured with a fixed content model defined at implementation.
Prefer:
The CMS SHALL allow authorised users to extend and modify content models without code changes or platform re-deployment.
In both cases, the requirement is still binary and testable, but it preserves freedom to adapt.
This is how future change is managed responsibly. You are not predicting what the platform must become. You are ensuring that it can become something else when the business inevitably changes.
High-level user stories still play an important role. They express intent and direction. But the evaluative mechanism remains the requirement set, written to test behavioural capability, not design preference.
This balance is difficult to achieve. It requires experience to know which constraints protect the business and which merely protect current thinking.
That judgement is the difference between requirements that age well and requirements that become obsolete before the contract is signed.
Why writing great requirements is genuinely hard
There is a reason this approach is rarely executed well.
Writing requirements that are specific, clear, measurable and objective is not a clerical task. It is an analytical discipline that sits at the intersection of product thinking, systems engineering, operational reality and commercial risk.
In most organisations, we simply don't see many people who can do this consistently.
This is why organisations running complex media and platform programmes often bring in specialist RFP and tendering expertise when the decision carries long-term risk.
Requirements authors must be able to:
Understand user needs without copying user stories verbatim
Translate abstract business goals into concrete system behaviour
Anticipate scale, edge cases and failure modes
Remove ambiguity without over-constraining delivery
Write statements that are testable, defensible and contract-ready
That combination of skills is rare. As a result, requirements are often written by committee, diluted through compromise, or delegated to teams without the necessary experience. The outcome is predictable: well-intentioned documents that fail to protect the business.
This is also why strong requirements often feel uncomfortable internally. They force decisions earlier than many organisations are used to making. They expose uncertainty. They remove the safety blanket of vague language.
Why everything else still matters…..just not as much
Timelines matter. Governance matters. Communication matters. Fairness matters.
But none of these can compensate for weak requirements.
A perfectly run RFP process built on ambiguous requirements will still produce a poor outcome. A less elegant process built on rigorous, objective requirements often succeeds despite imperfections elsewhere.
This hierarchy is uncomfortable, particularly in procurement-led environments. But it reflects reality.
If you change one thing, change this
If you are about to issue an RFP, review it with one question in mind:
Can every requirement be scored objectively without debate?
If the answer is no, that is where to focus your effort.
Getting this right takes time and discipline. It requires resisting vague language and forcing clarity earlier than feels comfortable.
The payoff is significant.
Spicy Mango maintains extensive RFP frameworks and requirement libraries for OTT, streaming and digital publishing platforms, built from real delivery experience. We license reference material that has translated hundreds of high level functional and non-functional requirements into thousands of distinct, clear and measurable statements. This depth is one of the reasons Tier 1 media organisations engage us to shape and deliver strategic transformation programmes, not simply to run procurement, but to define what success actually looks like at a requirements level. If you want to accelerate this work without sacrificing rigour, get in touch to see what good looks like in practice.
The single biggest change that determines whether an RFP succeeds or fails
Most RFPs fail for many reasons.
They run late, they consume more internal effort than planned, suppliers over-promise, delivery falls short and commercial discussions become adversarial within months of contract signature.
But in our experience across media, OTT, broadcast and digital publishing organisations, RFPs nearly always fail in the same place, long before vendors are selected, and often before the document is even issued.
They fail in how the requirements are written.
If there is one change an RFP author can make that has a disproportionate impact on outcome, it is this:
Stop asking suppliers to describe capabilities, and start forcing them to prove them through clear, unambiguous, measurable requirements.
Everything else in the RFP process is secondary.
Why RFPs feel fair but produce poor decisions
Most poorly performing RFPs do not look broken on the surface. In fact, they often appear thorough, structured and reasonable.
They contain sensible questions such as:
Describe your search capability within the CMS
Explain how your platform supports localisation
Tell us about your approach to scalability and performance
These questions feel open, collaborative and vendor-friendly. They also feel informative.
In practice, they create three systemic problems.
First, they invite interpretation. Each supplier answers a subtly different question.
Second, they reward marketing strength rather than product truth. Narrative responses sound convincing even when capability is partial, roadmap-based or assumed.
Third, they make objective comparison impossible. Evaluation discussions quickly drift from evidence to opinion, and scoring becomes an exercise in persuasion rather than assessment.
At this point, the RFP process is already compromised - even if every other step is run perfectly.
The moment everything goes wrong: subjective requirements
The most common failure pattern we see starts with a single word:
“Describe.”
For example:
“Describe the search feature in the CMS.”
This requirement cannot be scored objectively. There is no shared definition of success, no measurable threshold, and no way to determine compliance with confidence.
Every supplier can respond positively without committing to anything verifiable.
What follows is predictable:
Evaluators fill gaps with assumption
Workshops are used to clarify basic capability
Contract negotiations attempt to retroactively lock down scope
Delivery reveals mismatched expectations
The RFP did not fail because suppliers were dishonest. It failed because the requirements allowed them to be vague.
What great RFP authors do differently
Strong RFP authors approach requirements very differently.
Instead of asking suppliers to explain how something works, they start by defining what must be true for the solution to be acceptable.
They take a high-level product need or user story and decompose it into a set of atomic, testable statements.
Each statement is:
Clear
Unambiguous
Measurable
Independently assessable
Crucially, each statement allows only one of two responses: True or False.
For example, instead of asking about search capability:
The solution SHALL support search across all metadata attributes stored within the CMS for any given object.
The solution SHALL support search across all languages defined within a multi-language article.
The solution SHALL return results within two seconds for datasets of up to X million objects under normal operating conditions. (And don't forget to define what normal operating conditions are!)
There is no room for interpretation. Either the capability exists, or it does not.
This approach changes the nature of the RFP entirely.
Why binary requirements transform outcomes
When requirements are written as objective statements rather than narrative prompts, several things happen immediately.
Supplier responses become shorter and more precise. Marketing language disappears because it no longer helps.
Capability gaps surface early. Suppliers are forced to be explicit about limitations, dependencies or roadmap items.
Scoring becomes faster and defensible. Evaluation discussions are grounded in evidence rather than opinion.
Workshops become about validation and depth, not basic clarification.
Most importantly, contracts become easier to negotiate. The requirements matrix already defines minimum acceptable capability, reducing ambiguity and dispute risk.
This is the single most effective way to reduce downstream change requests, commercial friction and delivery disappointment.
Translating user stories into requirements, without locking the future
One of the most common concerns with writing highly specific, measurable requirements is that they will over-constrain the solution.
This concern is valid - but it is not a reason to accept vague requirements. It is a signal that requirements must be written with intent.
Specific and objective requirements should not describe how a solution is built. They should define behaviour that must be true, while deliberately leaving room for evolution, reconfiguration and future change.
This distinction is critical.
Poorly written requirements hard-code today’s assumptions:
Prescribing internal architectures
Mandating implementation patterns
Embedding current organisational constraints as permanent truths
Well-written requirements do the opposite. They define outcomes that support an architect-for-change approach.
For example:
Instead of:
The solution SHALL use technology X to support multilingual search.
Prefer:
The solution SHALL support search across all languages defined within a multi-language article, without requiring custom development for each additional language.
Instead of:
The CMS SHALL be configured with a fixed content model defined at implementation.
Prefer:
The CMS SHALL allow authorised users to extend and modify content models without code changes or platform re-deployment.
In both cases, the requirement is still binary and testable, but it preserves freedom to adapt.
This is how future change is managed responsibly. You are not predicting what the platform must become. You are ensuring that it can become something else when the business inevitably changes.
High-level user stories still play an important role. They express intent and direction. But the evaluative mechanism remains the requirement set, written to test behavioural capability, not design preference.
This balance is difficult to achieve. It requires experience to know which constraints protect the business and which merely protect current thinking.
That judgement is the difference between requirements that age well and requirements that become obsolete before the contract is signed.
Why writing great requirements is genuinely hard
There is a reason this approach is rarely executed well.
Writing requirements that are specific, clear, measurable and objective is not a clerical task. It is an analytical discipline that sits at the intersection of product thinking, systems engineering, operational reality and commercial risk.
In most organisations, we simply don't see many people who can do this consistently.
This is why organisations running complex media and platform programmes often bring in specialist RFP and tendering expertise when the decision carries long-term risk.
Requirements authors must be able to:
Understand user needs without copying user stories verbatim
Translate abstract business goals into concrete system behaviour
Anticipate scale, edge cases and failure modes
Remove ambiguity without over-constraining delivery
Write statements that are testable, defensible and contract-ready
That combination of skills is rare. As a result, requirements are often written by committee, diluted through compromise, or delegated to teams without the necessary experience. The outcome is predictable: well-intentioned documents that fail to protect the business.
This is also why strong requirements often feel uncomfortable internally. They force decisions earlier than many organisations are used to making. They expose uncertainty. They remove the safety blanket of vague language.
Why everything else still matters…..just not as much
Timelines matter. Governance matters. Communication matters. Fairness matters.
But none of these can compensate for weak requirements.
A perfectly run RFP process built on ambiguous requirements will still produce a poor outcome. A less elegant process built on rigorous, objective requirements often succeeds despite imperfections elsewhere.
This hierarchy is uncomfortable, particularly in procurement-led environments. But it reflects reality.
If you change one thing, change this
If you are about to issue an RFP, review it with one question in mind:
Can every requirement be scored objectively without debate?
If the answer is no, that is where to focus your effort.
Getting this right takes time and discipline. It requires resisting vague language and forcing clarity earlier than feels comfortable.
The payoff is significant.
Spicy Mango maintains extensive RFP frameworks and requirement libraries for OTT, streaming and digital publishing platforms, built from real delivery experience. We license reference material that has translated hundreds of high level functional and non-functional requirements into thousands of distinct, clear and measurable statements. This depth is one of the reasons Tier 1 media organisations engage us to shape and deliver strategic transformation programmes, not simply to run procurement, but to define what success actually looks like at a requirements level. If you want to accelerate this work without sacrificing rigour, get in touch to see what good looks like in practice.
The single biggest change that determines whether an RFP succeeds or fails
Most RFPs fail for many reasons.
They run late, they consume more internal effort than planned, suppliers over-promise, delivery falls short and commercial discussions become adversarial within months of contract signature.
But in our experience across media, OTT, broadcast and digital publishing organisations, RFPs nearly always fail in the same place, long before vendors are selected, and often before the document is even issued.
They fail in how the requirements are written.
If there is one change an RFP author can make that has a disproportionate impact on outcome, it is this:
Stop asking suppliers to describe capabilities, and start forcing them to prove them through clear, unambiguous, measurable requirements.
Everything else in the RFP process is secondary.
Why RFPs feel fair but produce poor decisions
Most poorly performing RFPs do not look broken on the surface. In fact, they often appear thorough, structured and reasonable.
They contain sensible questions such as:
Describe your search capability within the CMS
Explain how your platform supports localisation
Tell us about your approach to scalability and performance
These questions feel open, collaborative and vendor-friendly. They also feel informative.
In practice, they create three systemic problems.
First, they invite interpretation. Each supplier answers a subtly different question.
Second, they reward marketing strength rather than product truth. Narrative responses sound convincing even when capability is partial, roadmap-based or assumed.
Third, they make objective comparison impossible. Evaluation discussions quickly drift from evidence to opinion, and scoring becomes an exercise in persuasion rather than assessment.
At this point, the RFP process is already compromised - even if every other step is run perfectly.
The moment everything goes wrong: subjective requirements
The most common failure pattern we see starts with a single word:
“Describe.”
For example:
“Describe the search feature in the CMS.”
This requirement cannot be scored objectively. There is no shared definition of success, no measurable threshold, and no way to determine compliance with confidence.
Every supplier can respond positively without committing to anything verifiable.
What follows is predictable:
Evaluators fill gaps with assumption
Workshops are used to clarify basic capability
Contract negotiations attempt to retroactively lock down scope
Delivery reveals mismatched expectations
The RFP did not fail because suppliers were dishonest. It failed because the requirements allowed them to be vague.
What great RFP authors do differently
Strong RFP authors approach requirements very differently.
Instead of asking suppliers to explain how something works, they start by defining what must be true for the solution to be acceptable.
They take a high-level product need or user story and decompose it into a set of atomic, testable statements.
Each statement is:
Clear
Unambiguous
Measurable
Independently assessable
Crucially, each statement allows only one of two responses: True or False.
For example, instead of asking about search capability:
The solution SHALL support search across all metadata attributes stored within the CMS for any given object.
The solution SHALL support search across all languages defined within a multi-language article.
The solution SHALL return results within two seconds for datasets of up to X million objects under normal operating conditions. (And don't forget to define what normal operating conditions are!)
There is no room for interpretation. Either the capability exists, or it does not.
This approach changes the nature of the RFP entirely.
Why binary requirements transform outcomes
When requirements are written as objective statements rather than narrative prompts, several things happen immediately.
Supplier responses become shorter and more precise. Marketing language disappears because it no longer helps.
Capability gaps surface early. Suppliers are forced to be explicit about limitations, dependencies or roadmap items.
Scoring becomes faster and defensible. Evaluation discussions are grounded in evidence rather than opinion.
Workshops become about validation and depth, not basic clarification.
Most importantly, contracts become easier to negotiate. The requirements matrix already defines minimum acceptable capability, reducing ambiguity and dispute risk.
This is the single most effective way to reduce downstream change requests, commercial friction and delivery disappointment.
Translating user stories into requirements, without locking the future
One of the most common concerns with writing highly specific, measurable requirements is that they will over-constrain the solution.
This concern is valid - but it is not a reason to accept vague requirements. It is a signal that requirements must be written with intent.
Specific and objective requirements should not describe how a solution is built. They should define behaviour that must be true, while deliberately leaving room for evolution, reconfiguration and future change.
This distinction is critical.
Poorly written requirements hard-code today’s assumptions:
Prescribing internal architectures
Mandating implementation patterns
Embedding current organisational constraints as permanent truths
Well-written requirements do the opposite. They define outcomes that support an architect-for-change approach.
For example:
Instead of:
The solution SHALL use technology X to support multilingual search.
Prefer:
The solution SHALL support search across all languages defined within a multi-language article, without requiring custom development for each additional language.
Instead of:
The CMS SHALL be configured with a fixed content model defined at implementation.
Prefer:
The CMS SHALL allow authorised users to extend and modify content models without code changes or platform re-deployment.
In both cases, the requirement is still binary and testable, but it preserves freedom to adapt.
This is how future change is managed responsibly. You are not predicting what the platform must become. You are ensuring that it can become something else when the business inevitably changes.
High-level user stories still play an important role. They express intent and direction. But the evaluative mechanism remains the requirement set, written to test behavioural capability, not design preference.
This balance is difficult to achieve. It requires experience to know which constraints protect the business and which merely protect current thinking.
That judgement is the difference between requirements that age well and requirements that become obsolete before the contract is signed.
Why writing great requirements is genuinely hard
There is a reason this approach is rarely executed well.
Writing requirements that are specific, clear, measurable and objective is not a clerical task. It is an analytical discipline that sits at the intersection of product thinking, systems engineering, operational reality and commercial risk.
In most organisations, we simply don't see many people who can do this consistently.
This is why organisations running complex media and platform programmes often bring in specialist RFP and tendering expertise when the decision carries long-term risk.
Requirements authors must be able to:
Understand user needs without copying user stories verbatim
Translate abstract business goals into concrete system behaviour
Anticipate scale, edge cases and failure modes
Remove ambiguity without over-constraining delivery
Write statements that are testable, defensible and contract-ready
That combination of skills is rare. As a result, requirements are often written by committee, diluted through compromise, or delegated to teams without the necessary experience. The outcome is predictable: well-intentioned documents that fail to protect the business.
This is also why strong requirements often feel uncomfortable internally. They force decisions earlier than many organisations are used to making. They expose uncertainty. They remove the safety blanket of vague language.
Why everything else still matters…..just not as much
Timelines matter. Governance matters. Communication matters. Fairness matters.
But none of these can compensate for weak requirements.
A perfectly run RFP process built on ambiguous requirements will still produce a poor outcome. A less elegant process built on rigorous, objective requirements often succeeds despite imperfections elsewhere.
This hierarchy is uncomfortable, particularly in procurement-led environments. But it reflects reality.
If you change one thing, change this
If you are about to issue an RFP, review it with one question in mind:
Can every requirement be scored objectively without debate?
If the answer is no, that is where to focus your effort.
Getting this right takes time and discipline. It requires resisting vague language and forcing clarity earlier than feels comfortable.
The payoff is significant.
Spicy Mango maintains extensive RFP frameworks and requirement libraries for OTT, streaming and digital publishing platforms, built from real delivery experience. We license reference material that has translated hundreds of high level functional and non-functional requirements into thousands of distinct, clear and measurable statements. This depth is one of the reasons Tier 1 media organisations engage us to shape and deliver strategic transformation programmes, not simply to run procurement, but to define what success actually looks like at a requirements level. If you want to accelerate this work without sacrificing rigour, get in touch to see what good looks like in practice.
More insights you may enjoy
More insights you may enjoy
More insights you may enjoy
More insights you may enjoy
Stay on the journey - with some further related insights we think you may like.
Stay on the journey - with some further related insights we think you may like.
Stay on the journey - with some further related insights we think you may like.
Get in touch
Contact us - we don't bite
To get in touch, email hello@spicymango.co.uk, call us on +44 (0)844 848 0441, or complete the contact form below to start a conversation.
Get in touch
Contact us - we don't bite
To get in touch, email hello@spicymango.co.uk, call us on +44 (0)844 848 0441, or complete the contact form below to start a conversation.
Get in touch
Contact us - we don't bite
To get in touch, email hello@spicymango.co.uk, call us on +44 (0)844 848 0441, or complete the contact form below to start a conversation.
Get in touch
Contact us - we don't bite
To get in touch, email hello@spicymango.co.uk, call us on +44 (0)844 848 0441, or complete the contact form below to start a conversation.
Get in touch
Contact us - we don't bite
To get in touch, email hello@spicymango.co.uk, call us on +44 (0)844 848 0441, or complete the contact form below to start a conversation.