PSST Solution section: turn a problem into a testable response

The Solution section is the bridge between a customer problem and a plan a reviewer can examine. It should not become a product brochure. A reviewer needs to see the response, the user, the delivery boundary and the test that would show whether the response works.

Start with the problem already defined

Use the same customer and situation from the Problem section. If the problem described a Korean retailer losing time while onboarding foreign customers, the Solution section should explain the workflow that reduces that specific delay. Changing the customer here breaks the logic of the plan.

A solution claim is stronger when it names the mechanism. “We improve onboarding” is broad. “The service collects the required customer fields once, checks missing items, and gives the operator a review queue” tells the reader what changes.

Show the response as a chain

The useful chain is problem, response, user action and observable result. The customer encounters the failure, uses the proposed workflow, and produces an output that can be checked. That output might be a completed application, a verified record, a shorter manual step or a documented decision.

This does not require a claim that the solution will succeed. It requires a clear claim that can be tested. State what the first version includes and what it does not include. A narrow boundary gives the reviewer a way to challenge the plan constructively.

Keep the first version narrow

The official KISED programme pages describe commercialization support alongside business-plan submission, documentary evidence, mentoring and programme support. They do not turn every product idea into a universal template. The current notice decides the exact form and supporting documents for the programme you name.

Avoid putting the whole company roadmap into the Solution section. A future marketplace, international expansion plan or advanced automation may matter later, but it can hide whether the first response is feasible now. Put later stages in the section that the current form provides for them.

Connect the solution to evidence

The Problem section carries evidence about the present failure. The Solution section should say what evidence will test the proposed response. A prototype walkthrough, pilot record, completed workflow, user interview or measured task result can all be useful when dated and labelled accurately.

Do not call interest proof of performance. An interview can show that a problem is understood. It does not prove that the proposed workflow saves time. A prototype test can show usability. It does not prove broad demand. Keep observed results, planned tests and assumptions visibly separate.

Use the current form, not a remembered PSST template

KISED’s programme overview identifies a business plan and documentary evidence as application materials, while the K-Startup portal maintains notices and a reference library. Those pages are useful starting points, but a named programme’s current attachment can add, remove or rename fields.

That distinction matters for foreign founders. The Solution section can explain the product response in English, but the application still follows the current notice, applicant definition, submission route and required evidence. Confirm each field before submission.

Continue with the PSST assistant, carrying the same customer and evidence trail from the Problem section into the Solution section.