q_r1_001 Usage

In welchem konkreten Moment im Workflow nutzt Johannes den Scope Compressor (z.B. nach Idea-Dump, nach Deep-Dive, vor erstem Ticket) und wie oft pro Woche realistisch?

q_r1_002 Problem

Welche konkreten Situationen/Probleme in Johannes’ Alltag soll das Tool lösen (inkl. 2–3 typische Beispiele aus echten Projekten)?

q_r1_003 Workflow

Welche konkreten Aufgaben aus Johannes’ Workflow soll das Tool automatisieren (von Input bis Output, inkl. Abgrenzung zu manuellen Schritten)?

q_r1_004 Output

Welche Pflicht-Outputs müssen in jedem Lauf entstehen (Felder + Reihenfolge) und in welchem Format (z.B. Ziel in 1 Satz, 3–5 Core-Features, 3 Cuts, Erfolgskriterium, No-Gos)?

q_r1_005 MVP

Welche 3 kritischsten Features sind für den MVP zwingend (jeweils mit einer Beispielausgabe, wie sie am Ende aussieht)?

q_r1_006 ScopeControl

Welche Funktionen/Erweiterungen sind im MVP explizit tabu, auch wenn sie naheliegend sind (z.B. Task-Management, Roadmaps, Research/Market-Analyse, Auto-Architektur, Multi-User)?

q_r1_007 ScopeControl

Welche Funktionalitäten sollen bewusst ausgeschlossen werden, um Overengineering zu verhindern (konkret als Liste, nicht als Prinzipien)?

q_r1_008 BehaviorGuardrails

Welche drei wiederkehrenden Overengineering-Muster bei Johannes soll das Tool aktiv unterbinden (und wie erkennt das Tool sie am Input)?

q_r1_009 Interaction

Kann das Tool aus einem Roh-Input automatisch bis zu 7 präzise Rückfragen generieren, und welche Regeln/Constraints sollen diese Fragen erfüllen (z.B. keine Suggestivfragen, max. 1 Minute beantwortbar)?

q_r1_010 UX

Soll die Interaktion als geführter 10–15-Minuten-Wizard oder als Single-Prompt mit sofortigem Ergebnis stattfinden (oder Hybrid), und wie „streng“ darf das Tool sein (z.B. erzwungene Cuts, harte Budget-/Zeit-Limits)?

q_r1_011 UX

Wie viel Zeit pro Nutzung ist maximal akzeptabel (von Start bis exportiertem Brief), damit es im Alltag tatsächlich genutzt wird?

q_r1_012 Input

Welche Eingabeformate müssen im MVP unterstützt werden (Minimum) und welche sind explizit später (z.B. Plain Text/Markdown/Links jetzt; Screenshots/Voice später)?

q_r1_013 Output

Welche Ausgabeform ist für Johannes am wenigsten kognitiv belastend (strukturierter Text vs. Cards vs. anderes) und wie soll die Ausgabe konkret strukturiert/visualisiert sein für maximale Klarheit?

q_r1_014 Platform

Auf welcher Plattform soll das Tool alltagstauglich laufen (CLI/Web/Desktop/Mobile) und warum — inkl. minimaler Technik-/Integrationsanforderungen?

q_r1_015 Architecture

Soll das Tool lokal oder webbasiert laufen (oder beides) — und was ist der entscheidende Grund (z.B. Datenschutz, Latenz, Installationsaufwand)?

q_r1_016 Integrations

Mit welchen bestehenden Systemen/Tools muss es integriert oder kompatibel sein (z.B. FORGED, Second Brain, Notion/Obsidian, Linear, Slack) und was ist jeweils die minimale Integration (Import/Export/Deep-Link)?

q_r1_017 Export

Soll das Ergebnis als „Project Brief“ exportierbar sein (wenn ja: Ziel-Format und Ziel-Systeme wie Markdown, Notion, Linear-Ticket)?

q_r1_018 Stakeholders

Wer außer Johannes nutzt das Werkzeug (Rollen) und in welchen konkreten Szenarien, und welche Unterschiede im Output/UX ergeben sich daraus (wenn überhaupt)?

q_r1_019 UX

Soll das Interface minimalistisch auf schnelle Bedienbarkeit ausgelegt sein, und welche 2–3 UI-Elemente sind dann maximal erlaubt (z.B. 1 Inputfeld + 1 Outputpanel + Export)?

q_r1_020 Constraints

Welche möglichen Ergänzungen sind strikt ausgeschlossen (z.B. keine Cloud-Speicherung, kein Tracking, keine Team-Kollaboration) und warum jeweils?

q_r1_021 Adoption

Welche Einzelfunktion muss sofort (unter 30 Sekunden) sichtbaren Nutzen liefern, damit Johannes das Tool wieder benutzt?