In den meisten Projekten wird Software auf eine von zwei Arten gebaut. Entweder entscheidet jemand nach bestem Wissen, was der Kunde braucht, und setzt es um. Oder, in den selteneren, datengetriebeneren Fällen, richtet man sich nach Kennzahlen: Conversion-Raten, Klickpfade, Verweildauer. Beide Wege haben ihren Platz. Und beide verfehlen erstaunlich oft das, worauf es ankommt.
Der erste Weg verwechselt die eigene Vorstellung vom Kunden mit dem Kunden. Der zweite misst, was passiert, aber selten, warum. Es gibt einen dritten Weg, den eine ganze Industrie seit Jahrzehnten perfektioniert hat und der in der klassischen Softwareentwicklung fast nie vorkommt: den Playtest.
Was ein Playtest wirklich ist
In der Spieleentwicklung ist ein Playtest kein Fragebogen und kein Fokusgruppengespräch. Man setzt einen echten Spieler vor eine echte Version des Spiels und sieht zu. Man fragt nicht, ob das Tutorial verständlich ist. Man beobachtet, ob der Spieler an Stelle X hängen bleibt, ob er den Ausgang findet, ob er an der gewollten Stelle lacht oder an der falschen Stelle frustriert aufgibt.
Der Grund für diese Disziplin ist eine unbequeme Wahrheit: Menschen können erstaunlich schlecht sagen, was sie wollen, aber ihr Verhalten verrät es zuverlässig. Ein Spieler, der im Interview sagt, der Level sei fair gewesen, kann im aufgezeichneten Playtest vierzehn Mal an derselben Stelle gestorben sein. Die Beobachtung gewinnt immer gegen die Aussage.
Genau das ist der Kern der Playtest-Strategie, wenn man sie auf Software überträgt: Beobachten statt Befragen. Nicht den Kunden fragen, welches Feature er sich wünscht, sondern zusehen, wo er in seiner täglichen Arbeit hängen bleibt, welche Schritte er umgeht, wo er zum Notizzettel oder zur Excel-Tabelle neben dem System greift, obwohl das System genau das eigentlich können sollte.
Das grenzt die Strategie von Dingen ab, die oberflächlich ähnlich klingen. Eine Umfrage sammelt Meinungen. Ein A/B-Test misst Ergebnisse, ohne die Ursache zu erklären. Ein klassischer Usability-Test prüft eine fertige Oberfläche gegen vorab definierte Aufgaben. Der Playtest dagegen ist die laufende, geduldige Beobachtung echten Verhaltens in echten Situationen - und er ist keine Phase, sondern eine Haltung.
Valve als Beweis
Das überzeugendste Beispiel ist Valve. Die Spiele des Studios funktionieren nicht, weil dort die cleversten Designer der Welt sitzen, die im stillen Kämmerlein die perfekte Mechanik erdenken. Sie funktionieren, weil Valve sich radikal und fast ausschließlich an direktem Spieler-Feedback orientiert. Über Iteration, beobachtete Playtests und kontinuierliche Anpassung wird das Produkt Schritt für Schritt besser gemacht.
Das Know-how im Haus ist die eine Hälfte. Die andere, entscheidende Hälfte ist die Bereitschaft, die eigene Annahme dem zu unterwerfen, was man tatsächlich sieht. Counter-Strike, Dota und Team Fortress wurden nicht entworfen und dann veröffentlicht. Sie wurden veröffentlicht und dann über Jahre beobachtet, justiert, neu ausbalanciert.
Und hier zeigt sich ein zweiter Effekt, der oft übersehen wird. Valve genießt bei Spielern enormes Vertrauen und Goodwill - nicht trotz, sondern wegen dieser Haltung. Wer spürt, dass auf sein tatsächliches Verhalten reagiert wird, fühlt sich ernst genommen. Die Playtest-Strategie zahlt also nicht nur auf das Produkt ein, sondern auch auf den Ruf. Ein Unternehmen, das sichtbar auf seine Kunden eingeht, baut sich einen Vorsprung, den kein Marketingbudget kaufen kann.
Die sechs Bausteine der Playtest-Strategie
Die Strategie lässt sich auf sechs Bausteine herunterbrechen. Jeder übersetzt ein Prinzip aus der Spieleentwicklung in die Welt der Geschäftssoftware, und gemeinsam beschreiben sie, wie ein Product Owner sein Produkt an echtem Verhalten ausrichtet statt an Vermutungen.
1. Den Playtest aufsetzen
Ein guter Playtest braucht drei Dinge: eine echte Aufgabe, einen echten Nutzer und eine realistische Situation. Nicht "Schau dir das mal an und sag, was du denkst", sondern "Erledige deine nächste reale Aufgabe wie immer, ich sehe nur zu". Je näher die Situation am echten Arbeitsalltag liegt, desto ehrlicher das Verhalten. Das künstliche Labor-Setting erzeugt künstliches Verhalten.
2. Beobachten, nicht fragen
Das ist das Herzstück. Während der Nutzer arbeitet, achtet man auf die Stellen, an denen die Realität von der eigenen Annahme abweicht. Wo entsteht Friction? Wo stockt der Flow? An welcher Stelle zögert jemand, scrollt zurück, öffnet ein zweites Fenster, sucht nach etwas, das eigentlich offensichtlich sein sollte? Diese Momente sind Gold. Sie zeigen nicht, was sich der Nutzer wünscht, sondern wo das Produkt seiner Aufgabe im Weg steht. Wichtig ist die Disziplin zu schweigen: Jede vorschnelle Erklärung des Product Owners zerstört das Signal.
3. Signal vom Rauschen trennen
Beobachtung liefert Rohmaterial, keine fertigen Antworten. Nicht jede Irritation ist ein Designfehler, und nicht jeder geäußerte Wunsch ist relevant. Hier liegt die eigentliche Arbeit des Product Owners: aus vielen Beobachtungen das Muster herauszulesen. Wenn fünf von sechs Nutzern an derselben Stelle stocken, ist das ein Signal. Wenn einer ein bestimmtes Feature fordert, ist das eine Hypothese über ein dahinterliegendes Problem, nicht die Lösung selbst. Die Kunst ist, hinter den Wunsch zu schauen und das echte Bedürfnis zu finden.
4. Iterieren im Rhythmus
Playtesting funktioniert nur in kurzen Schleifen. Ein großes Release nach zwölf Monaten ist ein einziger, riesiger Playtest mit maximalem Risiko und minimaler Lernchance. Stattdessen: beobachten, anpassen, wieder vorlegen, erneut beobachten. Der Product Owner wird in dieser Rolle zum Game Director - jemand, der nicht jedes Detail selbst entwirft, sondern den Kurs hält, Beobachtungen einordnet und entscheidet, welche Anpassung als nächstes getestet wird. Der Rhythmus selbst ist das Werkzeug.
5. Wann Kennzahlen, wann Beobachtung
Beobachtung und Kennzahlen sind keine Gegner, sie ergänzen sich. Kennzahlen sagen, dass etwas passiert, und sie skalieren: Sie zeigen, an welcher Stelle im Prozess viele Nutzer abbrechen. Beobachtung sagt, warum es passiert, und liefert die Erklärung, die eine Zahl niemals geben kann. Die kluge Reihenfolge ist meist: Die Kennzahl zeigt, wo man hinschauen soll. Der Playtest zeigt, was dort wirklich los ist. Wer nur misst, optimiert im Blindflug. Wer nur beobachtet, verliert den Überblick.
6. Der Playtest endet nie
Der wichtigste Baustein zugleich. Ein Release ist keine Ziellinie, sondern ein Speicherpunkt - der Moment, ab dem man unter echten Bedingungen beobachten kann. Software ist kein abgeschlossenes Projekt, sondern ein laufender Playtest. Genau das macht Valve vor: Die Spiele werden Jahre nach Veröffentlichung weiter beobachtet und justiert. Diese Haltung hat eine direkte Parallele zu der Idee, Prozesse wie Produkte zu behandeln: Es braucht jemanden, der dauerhaft verantwortlich ist, ob das Produkt funktioniert - nicht nur am Tag des Release, sondern auf Dauer.
Warum gerade jetzt
Es gab eine Zeit, in der Software so generisch war, dass Beobachtung kaum lohnte. Ein Standardprodukt für alle, nimm es oder lass es. Diese Zeit ist vorbei. Software wird zunehmend nischiger, usability-getrieben und kundenindividuell. Sie kann heute präzise auf einen konkreten Arbeitsablauf, eine Branche, ein einzelnes Team zugeschnitten werden.
Genau dadurch steigt der Wert echter Beobachtung. Je spezifischer das Produkt, desto weniger helfen allgemeine Best Practices und desto mehr zählt, wie genau dieser Kunde in seiner Realität arbeitet. Wo früher ein generisches Design ausreichte, entscheidet heute die Passung im Detail. Und diese Passung findet man nicht im Anforderungsworkshop, sondern indem man zusieht.
So arbeite ich
Für mich ist die Playtest-Strategie keine Technik, die man bei Bedarf hervorholt, sondern die Grundhaltung, mit der ich als Product Owner an Software herangehe. Anforderungen sind Hypothesen. Releases sind Speicherpunkte. Und die ehrlichste Quelle der Wahrheit ist nicht das Meeting, sondern der Nutzer bei der Arbeit.
Der Nebeneffekt ist der, den auch Valve erntet: Wer sichtbar auf seine Kunden eingeht, baut nicht nur bessere Software, sondern auch Vertrauen. Kunden merken, wenn sie ernst genommen werden, und das bindet stärker als jedes einzelne Feature. Bessere Produkte und ein besserer Ruf sind am Ende dieselbe Bewegung, nur von zwei Seiten betrachtet.