Migrate all repos into monorepo context folders
Bahn: aisupport, Analyse-O2C-C2S, awesome-bahn-mcp-servers, beam-mcp,
Confluence_Bot, db-planet-mcp-server, O2C-Harness, project-audit,
Projekt-KIQ-HP, teamlandkarte-mcp
Dhive: Jury-Voting
Privat: CV, NoteGraph (NOTE: NoteGraph needs complete redo after consolidation)
Shared: AI-Orchestrator, OrgMyLife, power_skills_and_more
Shared/references: symphony (read-only)
Bahn repos remain available as independent remotes - this monorepo
pulls them in via subtree, the originals are untouched.
This commit is contained in:
@@ -0,0 +1,252 @@
|
||||
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
|
||||
Reference in New Issue
Block a user