3 Patterns Where the 'Problem → Solution' Logic Breaks Down in Korean Startup Grant Business Plans

#

Written reviews for KISED-affiliated programs (the Pre-Startup Package, Early Startup Package, and similar tracks) process dozens of applications in a limited window. Reviewers quickly check whether 'problem → cause → solution' forms a single continuous thread. If that thread breaks, the credibility of every section that follows collapses with it.

Most founders focus on proving that the problem is real. But that's not the question reviewers are actually asking. Theirs is: 'Does this team's proposed solution actually target the root cause of the problem?' Proof that the problem exists, analysis of its cause, and the design logic of the solution all need to connect into a single flow.

The three patterns below are distinguished by where exactly the link breaks. Pattern 1 breaks between problem and cause. Pattern 2 breaks between cause and solution. Pattern 3 is when the solution's design rationale is missing entirely.

#

This is the most common pattern. Founders list social trends or market statistics, then jump straight to 'therefore, our solution is needed.' The problem is presented as large in scale, but there's no analysis of why it actually occurs. From a reviewer's seat, the impression is: 'I get that the problem is big, but I have no idea what point this team is actually trying to fix.'

When cause analysis is missing, as in the 'before' version, there's no basis for explaining why the solution takes the form it does — no matter how sophisticated it is. Only when the cause is stated explicitly, as in the 'after' version, does the solution's design direction start to look inevitable.

#

The second pattern is when the problem and cause analysis are both solid, but the solution doesn't actually target that cause. The plan names A as the cause, then delivers a tool that solves B instead. This is where reviewers conclude that 'the cause analysis and the solution are talking past each other.'

One version of this shows up constantly: the cause analysis states that 'information asymmetry between doctor and patient is the problem,' while the solution is 'an automated hospital booking platform.' Information asymmetry and booking convenience are different problems. Even if the cause analysis is accurate, the link breaks the moment the solution doesn't actually touch that cause.

The main reason this pattern occurs is that founders design the product first, then work backward to fit a problem and cause to it when they sit down to write the business plan. When the solution is already fixed and the cause gets written afterward, the solution's actual features and the stated cause tend to drift apart.

1. Write the cause-analysis sentence first. Compress 'why does this problem actually occur' into a single sentence.
2. Carry that cause sentence directly into the first line of your solution description. Connect them with a structure like 'to address this cause, we designed ___.'
3. List your solution's core features, and match each one, in a single line, to the specific aspect of the cause it resolves.
4. If any feature doesn't connect to the stated cause, move it out into a separate 'differentiator' or 'additional value' section.
5. Finally, read the three sentences — problem, cause, solution design logic — out loud back to back, and confirm they hold together logically.

#

The third pattern is when the problem-cause-solution flow looks connected on the surface, but the solution never explains why it works the way it does. Classic phrasing looks like 'we provide AI-based personalized recommendations' or 'we solve the problem through big data analysis.' The technology is named, but the link explaining how that technology actually resolves the cause is missing.

To state a design rationale explicitly, write one line on why the existing approach fails to resolve the cause, then follow it with how your approach handles it differently. Describing how something actually works is far more effective for logical connection than naming the technology behind it.

#

The five-step checklist below is a sequence for checking your own logical connections before you submit a business plan. If any step fails, rewrite that section before moving to the next one.

1. Does the problem section give concrete figures or interview evidence for who experiences this problem, under what circumstances, and how often?
2. Is the cause analysis compressed into one structural reason, rather than just restating the symptom? If there are three or more causes, narrow them down to the single core one.
3. Does the first sentence of the solution description directly reuse the key words from the cause analysis?
4. Is it explicit which aspect of the cause each major feature of the solution resolves?
5. Reading the problem, cause, and solution paragraphs in order, would a third party with no prior knowledge of the business be convinced of 'why this particular approach'?

Even after passing all five steps, it's genuinely hard for the author to spot their own logic gaps. Because you already know the full context of the business, you unconsciously fill in connections the writing actually omits. That's why a third-party review is the necessary last step before submission.

#

Q. If I define the problem narrowly, won't the market look too small?

A. As a rule, problem definition and market size belong in separate sections. In the problem section, writing narrowly and precisely about 'whose problem, exactly' works in favor of the logical chain. Market size can be addressed later, in terms of how many people have that problem and what the economic scale is. A narrow, precise problem statement that completes the causal chain scores better than a broad one that breaks it.

Q. What should I do when there are multiple causes?

A. If there are multiple causes, you need to identify a single one that your solution actually resolves. Mention the remaining causes briefly, as background that explains the problem's overall complexity, but explicitly designate the one core cause that connects directly to your solution. If there are three causes and your solution only touches one, stating clearly that the other two are 'outside our current scope' actually builds more trust.

Q. Every application template has a different section structure — does the causal-chain principle still apply the same way?

A. Section names and length vary by template — the Pre-Startup Package, Early Startup Package, and Startup Growth Package all differ. But the act of a reviewer checking the problem-cause-solution connection is the same regardless of the template. Even when the sections are physically separated, your cause-analysis sentence needs to function as the bridge connecting them.

#

The three patterns covered here — a problem with no cause, a solution misaligned with its cause, and a solution with no stated design rationale — are hard for the author to catch on their own. You already know the full context of the business, so you mentally fill in whatever connections the text leaves out. Reviewers have no such context; they read only the text.

Finding a logic gap requires eyes that don't already know the business. A third party should be able to look at the document alone and be convinced of why this particular solution follows from this particular cause. Running that check before submission is far more efficient than trying to diagnose it after a rejection.