17 KiB
- 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
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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
- 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
- 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.
- 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?
- 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.
- 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.
- 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