Disruptive technology, clear market strategy and a strong team are not enough

Your disruptive technology is not enough.

Your clear market strategy is not enough.

Your strong team is not enough.

They matter.

Of course they matter.

Without them, the proposal probably has no chance.

But they are not what makes the proposal different.

Because many competitors also have strong science.

Many competitors also have ambitious technologies.

Many competitors also have credible commercial plans.

Many competitors also have excellent teams, partners, hospitals, pilots, customers, investors, advisors or research centres.

So the real question is not only:

The real question is:

That is where many applications lose power.

Not because the technology is weak.

Not because the market is irrelevant.

Not because the team lacks ability.

But because the proposal does not translate those strengths into an evaluator-proof case.

In EU funding, excellence is not evaluated in the abstract.

It is evaluated through the written application.

The evaluator does not score what the team knows.

The evaluator scores what the proposal proves.

And what the proposal proves depends on three things that are often underestimated:

These are not decorative qualities.

They are evaluation assets.

They determine whether the reader can understand the project, trust the reasoning and justify a high score.

The obvious strengths are only the starting point

When applicants ask what makes a proposal win, the first answers are usually predictable.

Disruptive technology.

Strong market need.

Clear commercialisation strategy.

Excellent consortium.

Experienced management team.

Relevant pilots.

Convincing impact potential.

All of these matter.

But in competitive programmes such as Horizon Europe, the EIC Accelerator, EIC Pathfinder, EIC Transition and Eurostars, these strengths are often the entry ticket.

They are not always the differentiator.

A proposal can describe a genuinely innovative technology and still fail.

A proposal can target a large market and still fail.

A proposal can include excellent partners and still fail.

Why?

Because evaluation is not a beauty contest of isolated strengths.

It is an assessment of whether the full case holds together.

The evaluator needs to see a coherent chain from problem to solution, from methodology to work plan, from team capacity to implementation, and from outputs to impact.

If that chain breaks, the proposal becomes vulnerable.

Even when the project itself is strong.

We have discussed a similar issue before in Most EU proposals do not fail because of evaluators. In many cases, the Evaluation Summary Report only makes visible weaknesses that were already present in the draft.

The evaluator did not create the weakness.

The proposal exposed it.

What really makes the difference

Three qualities usually separate strong projects from strong proposals.

Consistency.

Transparency.

Credibility.

They sound simple.

They are not.

Each one requires discipline before writing, during drafting and during review.

Consistency means the proposal follows one clear logic from beginning to end.

Transparency means the proposal gives evaluators the information they need to understand and assess the project.

Credibility means the proposal supports claims with evidence, specificity, references, baselines and realistic assumptions.

Together, they make the project evaluable.

That word matters.

A proposal does not only need to be impressive.

It needs to be evaluable.

The evaluator must be able to extract the argument, test the claims and defend the score.

If the proposal makes that difficult, it creates evaluation risk.

Consistency: decide the proposal logic before writing

Consistency starts before the first paragraph is drafted.

Before writing, the team should decide the core logic of the proposal.

What is the problem?

Why does it matter now?

Why are existing alternatives insufficient?

What exactly will the project do?

What will be validated?

Why is the approach novel?

Which risks remain?

Which partners are needed?

Which work packages produce which outputs?

How do those outputs create impact?

This is the backbone of the proposal.

Once that backbone is defined, the proposal should stay loyal to it.

Many applications do not.

They start with one logic and end with another.

The ambition grows.

The work plan expands.

The impact section adds new promises.

The market section introduces a different user group.

The technical section uses different terminology.

The risk table manages risks that do not match the real uncertainty.

The consortium section presents partner roles that do not fully align with the work packages.

Each section may sound reasonable in isolation.

But together, the application starts to drift.

Evaluators notice this.

Not always as one dramatic contradiction.

Often as friction.

Something feels unclear.

Something does not fully align.

Something requires interpretation.

Something makes the project harder to trust.

That is why consistency is not only a writing issue.

It is a scoring issue.

Where inconsistency usually appears

Inconsistency often hides in places that applicants do not review carefully enough.

For example, the proposal may present one target user in the excellence section and another in the impact section.

It may define the product as a clinical decision-support tool in one place, an AI platform in another, and a hospital workflow engine somewhere else.

It may claim a TRL progression that is not reflected in the work plan.

It may describe a regulatory pathway that does not match the validation activities.

It may promise market entry in one segment while the pilots validate performance in another.

It may present the consortium as essential, while several partner roles remain generic.

It may include milestones that do not support real go or no-go decisions.

None of these issues need to destroy a proposal alone.

But together, they weaken confidence.

They make the evaluator ask:

That is a dangerous question.

A strong proposal should avoid creating it.

A simple consistency test

Before submission, read the proposal as if you know nothing about the project.

Then ask:

• Does the same problem drive the entire application?
• Does the same solution appear throughout the proposal?
• Are the same target users, customers or beneficiaries used consistently?
• Do the objectives match the work packages?
• Do the deliverables support the expected outcomes?
• Do the milestones help manage uncertainty?
• Do the risks reflect the real technical, regulatory, clinical, commercial or operational challenges?
• Do partner roles match the work plan and budget?
• Does the impact section depend on outputs that the project actually delivers?

If the answer is not clearly yes, the proposal is not ready.

Not because it lacks content.

Because it lacks alignment.

Consistency makes the proposal easier to read.

But more importantly, it makes the proposal easier to believe.

Transparency: do not make the evaluator guess

The second differentiator is transparency.

Many applicants hide too much.

Sometimes this happens because they are protecting intellectual property.

Sometimes because the technology is complex.

Sometimes because the team assumes the evaluator will understand the missing context.

Sometimes because uncomfortable risks are easier to soften than explain.

But evaluation does not reward hidden strength.

Evaluators cannot score what they cannot see.

If the technology has been validated, say how.

If customers have been interviewed, say who, how many and what was learned.

If pilots are planned, say where, with whom and under which conditions.

If agreements exist, explain their status.

If access to data is secured, describe the access, governance and limitations.

If risks remain, make them visible and show how they will be reduced.

If the regulatory pathway is uncertain, explain the current understanding and the next decision points.

Transparency does not mean revealing every confidential detail.

It means giving evaluators enough information to assess the project without guessing.

That distinction is important.

The European Commission has also made clear that proposals and the information they contain are treated confidentially once submitted, and that Commission staff and evaluators are bound by confidentiality obligations.

So applicants should be careful.

But they should not use confidentiality as a reason to make the proposal vague.

A proposal can protect sensitive information and still be specific.

It can describe what matters without disclosing trade secrets.

It can explain validation design, performance indicators, partner roles, evidence status, data access and risk management without exposing protected know-how.

The danger is not transparency.

The danger is opacity.

What transparency looks like in practice

Weak transparency sounds like this:

Better transparency sounds like this:

The second version does not need to reveal the full technical method.

But it gives the evaluator something to assess.

A setting.

A result.

A benchmark.

A next validation step.

A partner role.

The same applies to market evidence.

Weak transparency sounds like this:

Better transparency sounds like this:

Again, this does not need to disclose sensitive customer names if they cannot be disclosed.

But it makes the evidence visible.

The evaluator can understand what was tested, with whom, when and what it means.

That is transparency.

Transparency is especially important for risk

Many proposals treat risk as a formal table to complete at the end.

That is a mistake.

Risk is one of the clearest places where evaluators judge maturity.

A weak proposal hides uncertainty.

A strong proposal manages it.

For example, do not write:

This is generic.

It does not tell the evaluator what could go wrong.

It does not explain how the team will know.

It does not describe what will change if the risk materialises.

A stronger version would say:

Now the risk is visible.

The test is defined.

The threshold is clear.

The mitigation is connected to the work plan.

The proposal becomes more credible because it does not pretend uncertainty does not exist.

Credibility: generic statements kill trust

The third differentiator is credibility.

This is where many proposals lose points.

Not because they lack ambition.

Because they make claims that are too generic to evaluate.

For example:

This sounds professional.

But it says almost nothing.

Which hospitals?

In which countries?

How many patients?

Which study design?

Which endpoints?

Who coordinates the validation?

Which approvals are needed?

Which comparator will be used?

Which success threshold matters?

A stronger version would be:

This is more credible because it is more evaluable.

Names.

Numbers.

Countries.

Responsibilities.

Endpoints.

Design logic.

That is what evaluators can assess.

Credibility is not created by sounding confident.

It is created by giving the evaluator reasons to trust the statement.

Evidence beats adjectives

Many proposal drafts rely too much on adjectives.

Innovative.

Scalable.

Transformative.

Unique.

Robust.

Breakthrough.

World-class.

High-impact.

These words are not forbidden.

But they create a burden of proof.

The stronger the adjective, the stronger the evidence should be.

If the proposal says the technology is innovative, it must explain the state of the art and the novelty.

If the proposal says the solution is scalable, it must explain the scaling logic, operational constraints and business model.

If the proposal says the market need is urgent, it must show evidence.

If the proposal says the consortium is strong, it must connect expertise to tasks and outcomes.

If the proposal says the performance is superior, it must define the benchmark.

A claim without a credible basis is not an evaluation argument.

It is an opinion.

And opinions do not score well.

This is why evidence is not something to add at the end.

Evidence should sit close to the claim it supports.

If a claim matters for scoring, the proof should be easy to find.

Why “not sufficiently justified” is such a dangerous comment

One of the most common and frustrating comments in Evaluation Summary Reports is:

Applicants often interpret this as a request for more text.

Usually, it is not.

It is a request for better reasoning.

Better evidence.

Better traceability.

Better connection between claim and proof.

We covered this in detail in Not sufficiently justified in EU proposals: why evaluators need evidence, not more words. A proposal does not become stronger because a weak claim becomes longer.

It becomes stronger when the claim becomes justified.

For example, this is weak:

This is stronger:

The second version gives the evaluator a reasoning chain.

Market segment.

User group.

Current alternative.

Pain point.

Evidence.

Validation.

That is what credibility looks like.

Credibility also depends on restraint

A credible proposal is not the proposal with the biggest promises.

It is the proposal where the promises match the evidence.

This requires restraint.

Do not claim the project will transform an entire industry if the work plan only validates a prototype with two pilot users.

Do not claim immediate market adoption if procurement cycles, regulation, reimbursement, certification or integration barriers remain unresolved.

Do not claim superiority over the state of the art without a defined comparator.

Do not claim low implementation risk when key dependencies remain open.

Do not claim a mature commercial strategy if the buyer, pricing logic, sales cycle and adoption barriers are not defined.

Ambition is good.

Unsupported ambition is fragile.

The evaluator does not need the proposal to pretend that every question is solved.

The evaluator needs to see that the team understands what remains uncertain and has a credible plan to reduce that uncertainty.

That is maturity.

The three qualities reinforce each other

Consistency, transparency and credibility are not separate boxes.

They reinforce each other.

A consistent proposal is easier to make transparent because the team knows what information matters.

A transparent proposal is easier to make credible because the evaluator can see the evidence.

A credible proposal is easier to keep consistent because claims are constrained by proof.

The opposite is also true.

An inconsistent proposal usually becomes opaque.

An opaque proposal usually becomes less credible.

A less credible proposal often starts compensating with stronger language.

That stronger language then creates new claims that are not fully supported.

This is how proposal weakness accumulates.

Not through one catastrophic mistake.

Through small gaps in logic, evidence and alignment.

By submission, the project may still be strong.

But the proposal has become difficult to defend.

How evaluators experience these weaknesses

Applicants often read proposals as authors.

Evaluators read them as evidence.

That difference matters.

The author remembers the meetings, the lab results, the customer calls, the partner discussions and the strategic decisions.

The evaluator only sees the page.

The author knows why the work plan makes sense.

The evaluator needs the work plan to prove it.

The author knows why a partner is essential.

The evaluator needs the role, task ownership and added value to be visible.

The author knows why the market need is urgent.

The evaluator needs sources, numbers and adoption logic.

The author knows why the technology is novel.

The evaluator needs the state of the art comparison.

That is why strong projects still fail.

The internal understanding is not enough.

The proposal must externalise the logic.

A practical checklist before submission

Before submitting, test the proposal against three sets of questions.

Consistency

• Does the proposal follow one core logic from beginning to end?
• Are the problem, solution, methodology, work plan, team and impact clearly connected?
• Are key terms used consistently?
• Do the objectives match the tasks?
• Do the deliverables and milestones support real progress assessment?
• Do the risks match the real uncertainties?
• Does the budget support the work described?
• Do partner roles match expertise and responsibilities?

Transparency

• Is the technology described clearly enough to be assessed?
• Are validation results visible?
• Are pilot conditions, datasets, sites, users or cohorts described where relevant?
• Are agreements, commitments or access rights explained with sufficient precision?
• Are remaining risks openly described?
• Are sensitive details protected without making the proposal vague?
• Can the evaluator understand what is already proven and what still needs to be tested?

Credibility

• Are key claims supported by reputable sources?
• Are benchmarks identified?
• Are baselines clear?
• Are KPIs measurable?
• Are assumptions visible?
• Are numbers traceable?
• Are commercial claims linked to evidence?
• Are technical claims linked to validation?
• Are impact claims proportional to project outputs?

If the answer is no, the proposal may still describe a good project.

But it may not yet be a fundable proposal.

What this means for Horizon Europe and EIC proposals

Horizon Europe and EIC proposals are often complex by design.

They may combine advanced science, industrial validation, regulatory questions, commercialisation strategy, policy relevance, stakeholder engagement and multidisciplinary implementation.

That complexity is not the problem.

The problem is uncontrolled complexity.

A complex project needs a clearer proposal, not a more complicated one.

For EIC Accelerator proposals, this means the innovation, market, traction, business model, team capacity, financing need and scale-up logic must tell the same story.

For EIC Pathfinder proposals, the high-risk research vision, breakthrough ambition, methodology, interdisciplinary logic and expected scientific advance must be tightly aligned.

For EIC Transition proposals, the route from research result to validated innovation opportunity must be explicit, credible and evidence-based.

For collaborative Horizon Europe proposals, the expected outcomes, destination logic, work packages, partner roles and impact pathways must fit together.

In all cases, the question is the same:

If not, the project strength may never fully convert into score.

Where Ruthless Evaluator fits

This is exactly why we built Ruthless Evaluator.

Not to flatter applicants.

Not to replace expert judgement.

Not to generate polished but unsupported language.

Ruthless Evaluator is designed to help applicants, consultants, universities, research centres, startups and innovation teams detect where a proposal becomes weaker under evaluator-style scrutiny.

It helps identify issues such as:

• Inconsistent proposal logic
• Unclear links between problem, solution, work plan and impact
• Generic claims
• Missing evidence
• Weak baselines
• Unclear validation design
• Hidden assumptions
• Vague risk mitigation
• Poorly justified partner roles
• Misalignment with call expectations
• Claims that sound stronger than the proof supports

The goal is not to make the proposal sound better.

The goal is to make the proposal harder to reject for avoidable reasons.

Because a strong project is not enough.

The proposal must make that strength impossible to miss.

Better to fix the weakness before the ESR does

Technology matters.

Market strategy matters.

Team matters.

But in a competitive EU funding evaluation, they are not enough by themselves.

The proposal must be consistent enough to follow.

Transparent enough to assess.

Credible enough to defend.

That is what turns strength into score.

Before submission, ask:

• Where does the proposal drift?
• What information is hidden that evaluators need to assess?
• Which claims are generic?
• Which numbers lack a source or derivation?
• Which risks are softened instead of managed?
• Which partner roles sound interchangeable?
• Which sections would require evaluator goodwill?
• Which arguments are still opinions rather than evidence?

If those weaknesses remain in the proposal, the Evaluation Summary Report may find them later.

And at that point, the opportunity is already gone.

Better to meet Ruthless Evaluator before submission than inside the ESR.

app.ruthlessevaluator.ai