Orchestrator/bahn/Projekt-KIQ-HP/SPEC.md

1. Executive Summary

Product / initiative name: Projekt-KIQ-HP
Interviewed stakeholder role: Project lead, founder, future provider
Product type: New product, with existing source materials and a possible template homepage as input
Goal in one sentence: Create a homepage that presents Projekt-KIQ in a compelling and trustworthy way so that relevant funding bodies and selected company partners can quickly understand the opportunity and move into their funding or evaluation process.
Short business context: Projekt-KIQ currently relies on scattered presentations, meetings, chats, and confidential concept material. The new homepage should consolidate relevant information into a structured public and restricted experience.
Primary target users: MBGs (Mittelständische Beteiligungsgesellschaften), startup funding programs, similar funding stakeholders
Secondary target users: Medium-sized companies that may participate as customers and investors
Core functional scope summary: A modern homepage with a public information area, an access-request process, a restricted investor/funder area for approved users, downloadable documents for approved users only, and an admin view for managing interested parties and monitoring usage.
In scope: Public landing experience, restricted information area, access request, human approval/rejection, document access for approved users, optional appointment selection after request, admin oversight, creation of initial content from existing source materials
Out of scope: Developer landing pages, customer landing pages, separate restricted experiences for MBGs and companies in version 1, multilingual support, press/news area, community/application functions, ongoing content production beyond initial setup
Main open questions: Whether optional interviews will be needed after the first draft to close content gaps; whether all approved users see the same restricted content in version 1; whether appointment selection is offered immediately to every requester or selectively; what “content request” means in the admin area
Main acceptance indicators: MBGs understand the project quickly and provide positive feedback; qualified access requests are submitted; meetings are requested; the content appears professional, trustworthy, and complete

2. Goal

One-sentence goal
The homepage should present Projekt-KIQ in a way that excites relevant funding bodies and selected company partners and enables them to directly proceed with funding-related next steps.

Detailed goal
The product should replace fragmented, manual communication of project information with a structured digital experience that supports trust-building, early evaluation, and movement toward funding conversations. It should give target audiences a clear first understanding in the public area and provide deeper investment-relevant material in a restricted area after invitation or approval.

Business value
The homepage reduces manual explanation effort, creates a more consistent external presentation, improves readiness for funding discussions, and supports lead qualification for serious and relevant interested parties.

Intended outcome for users and organization
Users should understand the problem, solution, USP, product, team, and business potential quickly. The organization should receive better-qualified requests, more efficient follow-up conversations, and a stronger basis for funding discussions.

3. Stakeholder Context

Respondent role
Project lead, founder, and future provider of the project

Perspective represented
Business owner / initiator perspective

Relevant organizational or customer context
The homepage is intended first for funding bodies such as MBGs and startup funding programs, and later also for medium-sized companies that may become both customers and investors.

Whether this spec reflects one interview only
Yes. This specification reflects one interview only.

4. Target Users

User groups

MBGs and similar funding organizations
Startup funding programs and comparable funding stakeholders
Medium-sized companies interested in participating as customers and investors

Their context
These users need enough confidence and structured information to decide whether Projekt-KIQ is relevant and whether they should continue with evaluation, document review, and follow-up discussions.

Their needs
They need a quick understanding of the project, its value proposition, current status, team credibility, market opportunity, investment need, and expected upside.

Their pain points
Today, information is scattered across presentations, meetings, chats, and confidential concept materials. This makes evaluation slow, inconsistent, and dependent on manual explanation.

Important differences between groups
Funding bodies are the first priority in version 1. Medium-sized companies are a secondary audience. VCs and classical financial investors are explicitly not current target users.

5. Current Situation / Current Process

How the process works today
Information is currently assembled and communicated through presentations and meetings. Relevant material is spread across confidential concept ideas, PowerPoint decks, PDFs, and chats.

Existing workaround or manual steps
Project information must be manually gathered and consolidated for each conversation or presentation. This appears to depend heavily on direct involvement from the project team.

Main gaps, bottlenecks, and failure points
There is no single structured external presentation of the project.
Investment-relevant information is fragmented.
Confidential and public information are not clearly separated in a reusable format.
The current process is inefficient and may not provide a consistent basis for evaluation.

What should remain unchanged, if applicable
Existing materials remain important as source inputs for the first version of the homepage content.

6. Functional Scope

The product must provide a modern homepage for Projekt-KIQ with two core areas: a public area and a restricted area.

Main capabilities
The public area should present the project clearly and persuasively for first-time evaluation.
The restricted area should provide deeper investment- and funding-relevant information for approved users.
Visitors should be able to request access to the restricted area.
The project team should be able to invite selected users or approve access requests.
Approved users should be able to download restricted documents.
The process should support movement from interest to conversation, including a possible appointment-selection step after request submission.
An admin perspective should provide oversight of interested parties, users, registrations, access metrics, and content requests.

Key user interactions
A public visitor lands on the homepage and reviews the core project information.
A relevant visitor requests access by providing required business information.
The project team reviews the request and either approves or rejects it.
An approved user accesses restricted content and downloads documents.
A user may request or select a meeting after expressing interest.
An admin monitors requests, users, registrations, and usage indicators.

Major functional areas
Public homepage content
Access request flow
Restricted content area
Document download for approved users
Admin oversight

Role-based differences in usage
Public visitors can only view public content.
Interested requesters can view public content and submit their own access request information.
Approved users can access the restricted area in addition to public content.
Admins have oversight and management visibility.

Relevant triggers, inputs, outputs, and outcomes
Trigger: A funding body or company partner wants to assess Projekt-KIQ.
Input: Public browsing or access request submission with required business details.
Output: Public understanding, access request, access decision, document access, possible meeting request.
Outcome: Qualified leads progress into evaluation and discussion.

7. Business Rules

Access to the restricted area is only possible through personal invitation or approval after a request.
Confidential content must never be visible in the public area.
Restricted documents must only be downloadable by approved users.
If a requester is not part of a relevant target group, the request must be rejected by a human, with a reason.
If access is denied, communication must be clear and polite, and handled by a human.
Incomplete or unsuitable requests lead to rejection.
The intended progression is: user becomes interested, requests or receives access, reviews documents, and then requests or schedules a conversation.
Version 1 does not require separate restricted experiences for MBGs and companies, although this may be added later.
The homepage must prioritize MBGs and similar funding bodies before other audiences.

8. Business Objects / Functional Data Objects

Projekt-KIQ public presentation
Represents the core public-facing information needed for first understanding and interest generation.

Restricted investment/funding content
Represents the deeper information needed for serious evaluation, such as investment need, market potential, and business case.

Access request
Represents a user’s formal request to enter the restricted area. It includes identifying and business-relevant information for manual evaluation.

Interested party
Represents a visitor who has expressed formal interest through a request.

Approved user
Represents a requester who has been invited or approved and can access restricted content.

Access decision
Represents the business outcome of reviewing a request: approval or rejection.

Restricted document
Represents downloadable materials intended only for approved users.

Meeting request / appointment selection
Represents the next-step interaction after interest has been established.

Admin overview data
Represents operational visibility into interested parties, users, registrations, access metrics, and content requests.

Source materials
Represents the existing business content used to produce the homepage content: PowerPoints, PDFs, chats/concept notes, and a template homepage.

9. In Scope
Public homepage for Projekt-KIQ
Public communication of problem and solution
Public communication of USP
Public communication of product
Public communication of team
Public communication of customer/market benefit
Public call-to-action for requesting access
Public display of references, partners, materials, and project status
Access request process for interested parties
Collection of requester business details
Invitation- or approval-based access to restricted content
Restricted area for approved users
Restricted presentation of investment need
Restricted presentation of market size and potential
Restricted presentation of return opportunities
Restricted presentation of use of funds
Restricted presentation of competitive analysis
Restricted presentation of business case
Restricted presentation of strategy
Download of restricted materials by approved users only
Human review and response to unsuitable, incomplete, or denied requests
Admin overview for interested parties, users, registrations, access metrics, and content requests
Initial content creation from existing materials
Optional appointment-selection step after request submission
10. Out of Scope
Dedicated landing pages for developers in version 1
Dedicated landing pages for customers in version 1
Separate restricted areas for MBGs and companies in version 1
Multilingual support in version 1
Press or news section
Community features
Application or recruitment-style functions
Ongoing content production beyond the initial setup
11. Requirements
The product must provide a public homepage for Projekt-KIQ targeted primarily at MBGs and similar funding stakeholders.
The public homepage must present the following information in this priority order: problem and solution, USP, product, team, customer/market benefit, call-to-action for access request, references/partners/materials/project status.
The product must provide a restricted area for approved users containing funding- and investment-relevant information.
The restricted area must present the following information in this priority order: investment need, market size/potential, return opportunities, use of funds, competitive analysis, business case, strategy.
The product must allow a visitor to request access to the restricted area.
The access request must collect at least the following information: name, company/organization, role, business email address, phone number for follow-up questions, reason for interest, and desired conversation purpose.
The product must support access to the restricted area only through personal invitation or approval after request.
The product must prevent confidential content from being visible in the public area.
The product must allow only approved users to download restricted documents.
The product must support a business process in which unsuitable or incomplete requests are rejected by a human, with a clear and polite response.
The product must support a business process in which a requester may be offered a next-step meeting request or appointment-selection option after submitting interest.
The product must provide an admin view that shows interested parties, users, registrations, access metrics, and content requests.
The product must support the use of existing PowerPoints, PDFs, chats/concept notes, and an existing template homepage as source material for the initial content.
The product must support a user journey in which relevant visitors can move from first interest to access request, document review, and conversation request.
The first version must focus on a shared core experience for the current target audiences and does not require separate landing pages or separate restricted experiences for additional audiences.
12. Open Questions / Items to Clarify
Are the existing source materials sufficient for the first version, or will optional short interviews be required to close content gaps after the first draft?
Should every requester be offered appointment selection immediately after submitting a request, or only selected requesters?
Do all approved users see the same restricted content in version 1, or is some level of differentiation already needed?
What exactly is meant by “content request” in the admin area?
What specific references, partners, and project-status elements are already confirmed and suitable for public display?
What exact wording or positioning should be used to communicate return opportunities in a way that matches the intended audience and business context?
In a later phase, how should dedicated landing pages for developers and customers differ from the investor/funder experience?
13. Risks and Ambiguities
Because source information is fragmented across presentations, chats, PDFs, and confidential concept material, important content may be inconsistent, incomplete, or difficult to validate.
Optional interviews being deferred to a later step may leave gaps in the first version’s messaging or factual completeness.
The public display of references, partners, and project status is not yet concretely defined, which may lead to overstatement or underuse of credibility signals.
The concept of return opportunities may be interpreted differently by different stakeholders unless the intended framing is aligned carefully.
The admin requirement includes “content requests,” but this object is not yet defined, which may create implementation ambiguity.
Not differentiating between MBGs and company partners in version 1 simplifies scope but may reduce relevance for secondary audiences.
The current acceptance vision depends partly on subjective perception, such as whether content feels professional, trustworthy, and complete.
14. Acceptance Perspective

From a business point of view, the product is successful when relevant MBGs and comparable funding stakeholders can quickly understand what Projekt-KIQ is, why it matters, and why it is worth evaluating further.
The public area must create confidence and interest rather than requiring immediate manual explanation.
The restricted area must provide enough depth for serious review once access has been approved.
Qualified access requests must start coming in from relevant target groups.
Users must begin requesting meetings or other follow-up conversations.
The overall content and presentation must be perceived as professional, trustworthy, and complete enough to support funding-related next steps.

15. Glossary
Original term	English explanation	Notes / context
Projekt-KIQ	Project-KIQ homepage initiative	Name of the homepage/product initiative
MBG	Medium-sized business investment company	Refers to Mittelständische Beteiligungsgesellschaften as a key target audience
Mittelständische Beteiligungsgesellschaften	Regional or specialized investment/funding bodies for SMEs	Important primary target group
Fördermittelgeber	Funding bodies / funders	Includes MBGs, startup funding programs, and similar entities
Start-up Förderprogramme	Startup funding programs	Part of the primary target audience
Mittelverwendung	Use of funds	How requested investment capital will be allocated
Wettbewerbsanalyse	Competitive analysis	Comparison of Projekt-KIQ against alternatives or competitors
Business Case	Commercial viability case	Business-oriented rationale for value and investment relevance
USP	Unique selling proposition	Distinctive value proposition that differentiates the project
geschützter Bereich	Restricted area	Area accessible only after invitation or approval
öffentliche Bereich	Public area	Public-facing homepage content visible without approval