Product Discovery vor dem Bau einer Anwendung

Discovery ist die Phase vor der Umsetzung, in der Problem, Nutzende, erwartete Wirkung, Grenzen des Umfangs, Risiken und technische Annahmen geklärt werden. Ihr Ergebnis sollte ein Dokument sein, das ausreicht, um Varianten zu vergleichen und eine Kostenschätzung vorzubereiten – in einem Umfang, der zur Größe des Projekts passt.

Discovery garantiert keine niedrigeren Projektkosten, senkt aber Unsicherheit: Sie macht widersprüchliche Erwartungen, fehlende Daten, schwierige Integrationen oder rechtliche Risiken sichtbar, bevor sie zu Abhängigkeiten vieler fertiger Funktionen werden.

Wozu, wenn ich schon weiß, was ich bauen will?

Weil eine Beschreibung der Idee von Auftraggebenden, Nutzenden und Umsetzungspartnern unterschiedlich verstanden werden kann. Drei Abweichungen, die Sie vor der ersten Codezeile prüfen sollten:

• Abweichung beim Umfang. Ein „Admin-Panel“ kann drei oder dreißig Screens bedeuten. Ohne Einigung darüber, welche Version kalkuliert ist, ist ein Konflikt nur eine Frage der Zeit.
• Abweichung beim Problem. Der Kunde möchte eine Anwendung zur Auftragsverwaltung, tatsächlich kommen Aufträge aber über fünf Kanäle herein und niemand sammelt sie. Eine Anwendung löst kein Problem, das sie nicht berührt.
• Abweichung bei den Nutzenden. Käufer und tatsächliche Anwender sind oft zwei unterschiedliche Personen mit unterschiedlichen Bedürfnissen. Eine für den Käufer entworfene Anwendung bleibt im Team dann womöglich ungenutzt.

Was in der Discovery geschieht

1. Geschäftsziele statt Funktionsliste

Die erste Frage lautet nicht „Was soll die Anwendung können?“, sondern „Was soll sich im Unternehmen ändern, wenn sie funktioniert?“ Die Antwort liefert das Kriterium, nach dem später Funktionen gestrichen werden: Dient etwas dieser Veränderung nicht, gehört es nicht in die erste Version.

Gute Antworten sind messbar: die Bearbeitung eines Auftrags verkürzen, Daten nicht mehr zwischen Systemen übertragen müssen oder Kundinnen und Kunden Einblick geben, ohne im Büro anrufen zu müssen.

2. Nutzende und ihre Aufgaben

Wer wird das nutzen, wie häufig, auf welchem Gerät – Schreibtisch oder Telefon – und was möchte die Person konkret erreichen? Ohne diese Antworten entsteht eine Anwendung, die für den Designer logisch, für Nutzende aber unbequem ist.

Die hilfreichste Frage in diesem Teil lautet: Wie wird das heute gemacht? Selbst wenn die Antwort ein Tabellenblatt und drei E-Mails lautet, beschreibt sie den Prozess, den die Lösung unterstützen muss.

3. Prozess „heute“ und „zukünftig“

Eine Karte des heutigen Ablaufs mit markierten Stellen, an denen etwas verloren geht, und eine Zielversion. Die entscheidende Frage bei jedem Schritt lautet: „Und was tun Sie, wenn die Daten nicht passen?“ Die Antworten darauf beschreiben den tatsächlichen Prozess – und sie bestimmen die Kosten.

4. Datenmodell

In der Discovery klären wir die zentralen Begriffe der Fachdomäne und ihre Beziehungen. Wir entwerfen nicht vorsorglich jede Tabelle, sondern prüfen, ob der Umfang auf widersprüchlichen Definitionen beruht. Eine spätere Änderung grundlegender Beziehungen kann Datenmigrationen und Aktualisierungen vieler Funktionen erfordern.

5. Einschränkungen und Integrationen

Systeme, die angebunden werden müssen, rechtliche Anforderungen, personenbezogene Daten, externe Termine und Budget. Eine solche Einschränkung kann die Kostenschätzung deutlich verändern – etwa wenn ein System keine benötigte Schnittstelle anbietet oder ein Vertrag eine bestimmte Form der Datenverarbeitung untersagt.

6. Umfang der ersten Version

Trennen Sie „muss vorhanden sein, damit es überhaupt funktioniert“ von „wäre gut“, und begründen Sie jeden Punkt. Für ein Produkt mit einem zentralen Weg kann der Leistungsumfang eines MVP in 4–6 Wochen ein Bezugspunkt sein.

7. Offen benannte Risiken

Eine Liste der Dinge, die schiefgehen können, mit Bewertung ihrer Wirkung. Ein Projekt ohne dokumentierte Risiken ist nicht sicherer – Sie entdecken sie nur später und teurer.

Was daraus entstehen sollte

Ein konkretes Dokument, keine Gesprächsnotizen. Bei uns enthält es:

• Beschreibung des Problems und messbarer Ziele,
• Nutzende und ihre Aufgaben,
• Zielprozess,
• Datenmodell und Lösungsarchitektur,
• Umfang der ersten Version samt bewusst zurückgestellter Punkte,
• Zeitplan nach Phasen und Kostenschätzung,
• Risiken mit Reaktionsplan.

Dieses Dokument gehört Ihnen und Sie können es mit uns oder an jedem anderen Ort umsetzen. Wenn Sie den Bau bei uns beauftragen, rechnen wir die Discovery-Kosten auf die Projektkalkulation an. Was in den folgenden Phasen geschieht, beschreiben wir in Wie man eine Anwendung von Grund auf baut.

Kosten und Dauer

Unsere Richtwerte für August 2026: ein Discovery-Workshop mit Richtungsdokument 3.000–8.000 PLN netto, vollständige Konzeption und Lösungsplanung mit Architektur, Roadmap und Schätzungen 8.000–25.000 PLN netto. Die Dauer hängt von Zahl der Stakeholder, Integrationen und der Verfügbarkeit von Materialien ab; meist reicht sie von einem Workshop bis zu etwa zwei Wochen.

Eine Kalkulation für ein in einem Absatz beschriebenes Projekt enthält auf beiden Seiten mehr Annahmen und Risiken. Ein ausgearbeiteter Umfang ermöglicht es, festzuhalten, was im Preis enthalten ist, welche Daten der Kunde liefern muss und was eine neue Kalkulation auslöst. Discovery kann den Unsicherheitspuffer senken, aber auch eine Anforderung sichtbar machen, die einen fairen Preis erhöht.

Wann Discovery nicht nötig ist

Das sagen wir offen, denn wir wollen keine unnötige Phase verkaufen:

• Wenn der Umfang wirklich klein und eindeutig ist. Eine Integration, ein Screen, ein Ablauf – dann ist Discovery überflüssige Zeremonie.
• Wenn Sie bereits eine gute Spezifikation haben. Das kommt vor, besonders wenn auf Ihrer Seite eine technisch versierte Person arbeitet. Dann reicht eine Prüfung.
• Wenn die Validierung der Idee das Problem ist, nicht ihr Umfang. Prüfen Sie dann zuerst, ob das überhaupt jemand will – notfalls manuell und ohne Anwendung. Discovery ist sinnvoll, wenn klar ist, dass das Problem real ist.

So bereiten Sie sich vor

Vier Dinge beschleunigen den Workshop und senken die Kosten:

1. Sammeln Sie reale Beispiele – konkrete Aufträge, Dokumente, E-Mails und Tabellen, die Sie tatsächlich verwenden.
2. Laden Sie die Person ein, die die Arbeit ausführt, nicht nur die, die sie beauftragt.
3. Notieren Sie, was heute nicht möglich ist, obwohl es möglich sein sollte.
4. Klären Sie, wer über den Umfang entscheidet. Eine nicht erreichbare entscheidungsbefugte Person ist eine häufige Ursache für Stillstand und widersprüchliche Absprachen.

Häufige Fragen

Kann Discovery remote stattfinden?

Ja, und so führen wir sie meist durch. Ein Online-Workshop von 2–3 Stunden, Arbeit auf unserer Seite und anschließend eine Runde ergänzender Fragen.

Müssen wir den Bau nach der Discovery bei Ihnen beauftragen?

Nein. Das Dokument gehört Ihnen und verpflichtet zu nichts. Wenn wir weitermachen, rechnen wir den Betrag nach den Angebotsbedingungen auf das Projekt an.

Worin unterscheidet sich das von einem KI-Audit?

Ein KI-Audit beantwortet die Frage „Wo lohnt sich KI in unserem Unternehmen?“. Discovery beantwortet „Was genau sollen wir bauen und wie?“. Manchmal geht ein Audit der Discovery voraus.

---

Wir führen eigene Projekte durch die Kette Discovery → Briefing → Plan → Umsetzung und haben auch den Umbau dieser Website auf diese Weise geführt. Deshalb können wir zeigen, wie unser Briefing aussieht, statt nur darüber zu erzählen. Sehen Sie sich Konzeption und Planung an oder beschreiben Sie Ihre Idee.