Open innovation problem template
A problem template is a structured description of a real company problem — written so that top startups can respond with solutions that already work. The point of the template is to make the problem specific enough that the company is not drowned in off-topic pitches.
What belongs in a problem template
- A one-sentence statement of the problem and who it affects.
- Explicit requirements and constraints the solution must meet.
- Success criteria and KPIs the company will use to judge a pilot.
The sections of a good problem template
On OpenClienting every published problem follows roughly the same shape, because peer-validated templates produce better-matched startup responses than free-form posts. A complete template has these sections:
- Description — a plain-language statement of the problem, what has been tried, and what success looks like. Written so a non-expert can follow it.
- Requirements — peer-submitted, upvoted constraints the solution must satisfy (integrations, compliance, data residency, performance).
- Pilot framework — the scope, duration, KPIs, and budget the company is willing to commit to a pilot.
- Tags and context — industry, function, company size, and problem category so startups can filter for the problems they can actually solve.
Frequently asked questions
Can I publish a problem anonymously?
Yes. OpenClienting's per-submission anonymity toggle lets you publish a problem without exposing your company name. Your identity is stored server-side for moderation but not shown to other users or startups.
How specific should the problem description be?
Specific enough that an off-topic startup pitch is obviously a mismatch, but not so narrow that it rules out creative solutions. A good test: could two engineers from different companies read the description and agree on what counts as a successful pilot?
Who writes the requirements?
Anyone on the platform can propose a requirement, and the community upvotes the ones that matter. The original author does not have to write every requirement — peer contributions usually surface constraints the author missed.
Can I reuse someone else's template?
That is the whole point of the knowledge base. Problems are published under an open license so you can fork the template, adapt it to your context, and publish your own version. Peer-validated templates beat drafting from scratch every time.