No problem, no grant

Proposal tip: No problem, no grant. The problem section is not decorative. It is the foundation of the evaluation case. It explains why the project exists, why the innovation matters, why the market opportunity is relevant, and why public funding is justified. Without a clearly defined problem, the evaluator has to reconstruct why the solution is necessary. Evaluators do not fund solutions in isolation. They fund solutions that solve problems that matter.

The problem gives meaning to everything else

A proposal is not strong because it describes an impressive solution. It is strong because it explains why that solution is needed. The problem defines the current limitation, the affected user, the weakness of existing alternatives, and the reason the market opportunity exists. It also gives the methodology, work plan, impact pathway, and innovation claim a clear reference point. The evaluator may understand what the technology does, but not why it matters. A clever solution can still look unnecessary if the problem is not clear.

The hidden trap in EU templates

Some EU funding templates do not include a section explicitly called “The Problem”. They may think that if the template does not ask directly, the problem can remain implicit. The evaluation logic still depends on the need being clear. The evaluator still needs to understand the current limitation, why the market cares, why the project matters now, and why the innovation is necessary. A proposal can answer the template and still fail the evaluation logic if the problem is missing.

What “integrate the problem” actually means

Integrating the problem does not mean adding one generic sentence near the beginning. It means making the problem visible wherever it supports evaluation. The innovation should be connected to the limitation it overcomes. The market section should connect demand to the unmet need. The value proposition should connect benefits to customer pain. The impact section should connect expected effects to the problem being solved. The methodology should show how the project will validate the solution against that problem. The problem should act as the reference point for the whole proposal.

The evaluator should not have to reconstruct the need

Proposal teams often know the problem so well that they stop explaining it. They assume the evaluator will understand the context, market pain, and impact logic. But evaluators only see the text. They do not have access to customer calls, pilot lessons, internal discussions, technical history, or failed alternatives unless the proposal explains them. If the need is not explicit, the evaluator may ask why the project matters, who needs it, what happens without funding, and why current solutions are insufficient. Those questions should be answered before the evaluator has to ask them.

A solution without a problem has no scale

A solution that is not connected to a problem has no evaluation scale. A proposal may say that a technology increases efficiency by 20%. That sounds useful, but it is incomplete. Compared to which baseline, in which process, for which user, under which conditions, and against which cost, delay, error, emission, or failure? The problem provides the scale of relevance. A metric is stronger when the problem explains why the metric matters.

The problem is not the same as the topic

Many proposals confuse the topic area with the problem. Climate change, healthcare efficiency, food security, digital transformation, cultural heritage, industrial competitiveness, and energy resilience are important contexts. A problem identifies a concrete limitation, pain point, failure mode, inefficiency, unmet need, barrier, or risk. “Healthcare efficiency” is a topic. “Emergency departments lose critical time because triage teams manually collect fragmented patient information from multiple systems before specialist review” is a problem. The topic tells the evaluator where the project sits. The problem explains why it is necessary.

The problem must be specific enough to evaluate

A broad problem is difficult to score. “SMEs need better digital tools” is weak because it leaves too many questions open. Which SMEs, which sector, which workflow, which limitation, which cost, which alternatives, and why are those alternatives insufficient? A specific problem gives the evaluator a concrete reference point. It also sharpens the solution, objectives, impact, and work plan. In competitive EU funding, specificity is part of credibility.

The problem must be evidenced

A problem statement needs evidence. It is not enough to say that users struggle, markets are inefficient, hospitals are under pressure, or current systems are inadequate. The evaluator needs to understand how the team knows this. Evidence may include:

• customer interviews
• pilot partner data
• operational metrics
• scientific literature
• market research
• regulatory pressure
• procurement evidence
• benchmark studies
• failure rates
• cost data
• workflow analysis
• stakeholder consultation
• industry reports
• clinical or technical validation

The type of evidence depends on the project. A problem is stronger when it is supported.

The problem must not be exaggerated

Some teams try to make the problem stronger by overstating it. A mature proposal does not need to claim that all current solutions fail or that all competitors are irrelevant. It should explain the specific gap that remains unsolved. Current alternatives may work in controlled environments but fail in the field. They may serve large enterprises but remain too expensive for SMEs. They may perform well under normal demand but fail under peak load. Nuanced problem framing is more credible because it shows that the team understands the market and the technical context.

The problem should create necessity

A fundable problem creates necessity. It explains why the project is not merely interesting, but needed. Necessity can come from a technical limitation, regulatory change, customer pain point, clinical gap, operational inefficiency, environmental constraint, scientific bottleneck, or policy priority. If the problem is minor, rare, already solved, or poorly evidenced, fundability weakens. If the problem is specific, validated, urgent, and strategically relevant, the proposal becomes stronger. Evaluators need to see that necessity directly. They should not be asked to infer it.

A simple example: turbine blade materials

Consider this sentence:

The claim sounds advanced, but incomplete. The evaluator may ask why temperature resistance matters, what fails today, how often it fails, and what cost it creates. Now add the problem:

Now the 40% improvement has context. It responds to a defined operational limitation.

The problem changes how the evaluator reads the solution

The same solution can be interpreted differently depending on the problem framing. A new material that improves high-temperature resistance may sound technically interesting. A new material that reduces repeated shutdowns, maintenance cost, and energy loss becomes more relevant. Problem framing is strategic because it explains value. A proposal that starts with the solution forces the evaluator to search for the reason. A proposal that starts with the problem prepares the evaluator to understand the solution.

The problem should guide the innovation claim

Innovation should not be presented as novelty in isolation. It should be presented as a response to a specific limitation. Instead of writing:

The proposal should explain which limitation the architecture overcomes. For example:

This connects novelty to need. That is the logic behind Innovation does not equal fundability.

The problem should guide the market section

The market section should not begin and end with market size. A large market does not prove that the problem is real. A growing market does not prove that users will adopt the solution. The market section should show how the problem creates demand. Which segment feels the pain most strongly, how is it handled today, who pays, who decides, and what evidence shows urgency? This is why arbitrary market share assumptions are risky. As discussed in Does your project have a higher market share than Tesla?, market share should come from problem, segment, adoption logic, pricing, capacity, and sales pathway. No problem, no credible market.

The problem should guide the impact pathway

Impact is not a list of benefits. Impact is the consequence of solving a problem. If the problem is unclear, the impact pathway becomes vague. The evaluator needs to understand what changes, who benefits, which indicator improves, how it is measured, and what scale is realistic. If the problem is repeated turbine shutdowns, impact can connect to reduced downtime, lower maintenance cost, improved energy output, and longer component lifetime. If the problem is generic, impact becomes generic. Specific problem, traceable impact.

The problem should guide the work plan

A work plan should not be a list of activities. It should be a structured response to the problem. Each work package should help prove, develop, validate, or de-risk the solution. If the problem is technical, the work plan should test the critical technical constraint. If the problem is adoption-related, it should validate user needs, integration, and willingness to adopt. If the problem is regulatory, it should address compliance evidence and decision points. If the problem is scale-up, it should test production, delivery, or deployment constraints. The problem tells the work plan what matters.

The problem should guide risk management

Risk management also depends on the problem. A generic risk table is weak because it could apply to any project. A stronger risk analysis asks what could prevent the project from solving the problem. Which assumption is most uncertain, which performance target is critical, which user behaviour could block adoption, which regulatory step could delay market entry, and which technical dependency could fail?

The problem should guide customer value

A value proposition is only strong when it connects directly to customer pain. A proposal may claim that the solution is faster, cheaper, smarter, safer, more sustainable, or easier to use. But the evaluator needs to know why the customer cares. What pain exists today, how severe is it, how often does it occur, what does it cost, who owns it, who has budget, and which alternative is currently used? A strong value proposition is the value created by solving a specific problem.

The problem should guide public funding need

Public funding need also depends on the problem. It is not enough to say that the project is innovative. The proposal should explain why the problem requires this project, why the risk is too high for private funding alone, and what evidence must be generated before investment, adoption, procurement, or scale-up becomes realistic. If the problem is weak, the funding need becomes weak. A strong problem helps justify public funding because it connects the project to users, markets, society, industry, science, or European priorities.

The problem should not disappear after the introduction

Some proposals define the problem well at the beginning, then abandon it. The rest of the application becomes solution-driven. That is a missed opportunity. The problem should remain visible throughout the proposal. In the objectives, it should define success. In the methodology, it should define what must be tested. In the work plan, it should define priorities. In the impact section, it should define expected change. In the market section, it should define customer urgency. In the risk section, it should define what could go wrong. The evaluator should feel that every section responds to the same need.

Problem framing can reveal proposal weakness early

A weak problem statement is often a warning sign. It may show that the project is not focused enough, the target user is unclear, the market segment is too broad, the impact pathway is immature, demand is not validated, or the project is misaligned with the call. This is why problem framing should happen before writing. If the team cannot define the problem clearly in a few sentences, the evaluation case is not yet controlled. Fixing the problem statement early can sharpen objectives, methodology, impact, risk, and market logic.

A weak problem creates weak objectives

Objectives should follow from the problem. If the problem is vague, the objectives often become vague too. For example:

This is difficult to evaluate. What industrial efficiency, which process, which baseline, and which target? A problem-driven objective is stronger:

A weak problem creates weak differentiation

Differentiation also depends on the problem. A proposal may compare the solution with competitors in broad terms: faster, cheaper, more accurate, more sustainable, or more scalable. But differentiation only matters if it addresses the limitation that users care about. Speed may not matter if reliability is the real barrier. Accuracy may not matter if integration is the adoption blocker. Sustainability may not matter if switching cost prevents uptake. A strong proposal shows that the difference matters because it solves a validated problem.

A weak problem creates weak storytelling

Proposal storytelling is not about making the application dramatic. It is about making the logic clear. A good story has a reason for action. The problem creates that reason. Without it, the proposal becomes a sequence of disconnected claims: technology, market, impact, team, and work plan. A strong problem gives the proposal momentum. It explains why the current situation is not acceptable, why existing solutions fall short, and why the project is needed now. This prepares the evaluator to understand the innovation.

Problem framing should be honest

A strong problem statement should be persuasive, but honest. Do not claim that all current solutions fail if some work well in certain contexts. Do not claim that no competitor exists if alternatives exist. Do not claim that the market is desperate if evidence is limited. Honest framing is more credible. It can say that current tools work in controlled conditions but not in the field. Or that current workflows work for large hospitals but not for regional centres with fewer staff. It also makes the project more fundable because it targets a defined gap.

The problem should be proportionate to the project

The problem should match the scale and maturity of the project. If the proposal claims to solve a Europe-wide industrial challenge, but the project only validates a small prototype with one pilot user, the framing may be too broad. If the project is early-stage research, the problem may be a scientific or technological bottleneck. If the project is near-market, the problem should connect to customer need, adoption, and commercialisation. The best proposals define a problem that is specific enough to be credible and important enough to justify funding.

The problem is also an evaluator fatigue tool

A clear problem reduces evaluator fatigue. It gives the reader a reference point. The innovation responds to the problem. The methodology tests the solution. The market section explains who needs it. The impact section explains what changes. The work plan explains how the project will deliver. The risks explain what could prevent success. When the problem is unclear, the evaluator must connect too many pieces manually. That creates friction. A clear problem makes the proposal easier to evaluate and easier to trust.

A simple problem test

Before submission, every proposal team should test the problem statement with simple questions.

• Can we state the problem in one clear sentence?
• Who experiences the problem?
• What evidence proves it?
• Why are current alternatives insufficient?
• What is the cost, risk, delay, inefficiency, or missed opportunity?
• Why does the problem matter now?
• Which part of the problem will the project address?
• What will remain unresolved after the project?
• How does the problem connect to the call objectives?
• How does the problem connect to the market opportunity?
• How does the problem connect to impact?

If the team cannot answer clearly, the proposal is not ready. The solution may still be strong. But the evaluation case is weak. No problem, no grant.

A practical structure for problem writing

A useful problem section can follow a simple structure. First, define the current situation. What happens today? Second, define the limitation. What does not work well enough? Third, define the affected group. Who experiences the limitation? Fourth, define the consequence. What cost, risk, delay, inefficiency, or missed opportunity results? Fifth, define the evidence. How do we know the problem is real? Sixth, define the gap in current alternatives. Why are existing solutions insufficient? Seventh, define why the project is needed now. This structure does not need to be long. It needs to be explicit.

Where Ruthless Evaluator fits

This is exactly the kind of weakness Ruthless Evaluator is designed to detect. It does not follow the template blindly. It tests whether the proposal makes sense under evaluation logic. If the template does not ask directly for “the problem”, Ruthless Evaluator still checks whether the problem is visible where it matters. It helps identify issues such as:

• weak problem framing
• vague unmet need
• missing evidence
• broad topic presented as a problem
• unclear target user
• problem and solution mismatch
• market opportunity without customer pain
• impact claims without a problem reference
• objectives disconnected from the need
• work plan not aligned with the real uncertainty
• overclaimed or exaggerated problem statements

These are not minor writing issues. They affect how evaluators understand the necessity of the project. And necessity is central to fundability.

Better to define the problem before evaluators define it for you

If the proposal does not define the problem, the evaluator may define it for you. They may define it too broadly, too narrowly, or incorrectly. They may not see the urgency, understand the customer pain, or connect the innovation to impact. They may conclude that the solution is interesting but not necessary. That is one of the most avoidable ways to lose points. Before submission, ask what problem we solve, for whom, based on what evidence, why now, why this solution, why this project, and why this funding instrument. If those answers are not clear, the proposal is exposed.

Better to meet Ruthless Evaluator before submission than inside the Evaluation Summary Report.

app.ruthlessevaluator.ai