Sprache ist wichtig, gerade für eine möglichst wenig missverständliche Kommunikation in Organisationen. Klienten, die sich auf den Agilen Weg begeben, kommen immer wieder mit verschiedensten Begriffen durcheinander, wenn es um die Beschreibung verschiedener Zustände eines Produktes geht. Daher will ich versuchen, heute mal meine Interpretation der Begriffe als Vorschlag für die Nutzung zu unterbreiten. Es geht im Detail um folgende produktbezogene Begrifflichkeit:

Prototyp

Ein Prototyp ist ein frühes Muster oder Modell eines Produktes oder Konzepts, das als Grundlage für eine spätere Produktion dient oder von dem gelernt werden kann. Es ist damit ein sehr allgemeiner Begriff. Gerade im Design Thinking findet er umfangreiche Verwendung und dient hier der sehr frühzeitigen Interaktion mit dem potenziellen Nutzern, gerade bei der Konzeptentwicklung. Ein Prototyp wird immer dann eingesetzt, wenn es darum geht, möglichst schnell und/oder kostengünstig Produkt-Ideen zur Problemlösung zu testen, mit dem potenziellen Kunden auszuprobieren, weiter Ideen zu generieren oder zwischen Alternativen Ideen auszuwählen. Prototypen gibts in den unterschiedlichsten Formen, wie z.B.:

Functional Prototype: Ein einfacher Prototyp, der die Funktionalität des Produktes in den Mittelpunkt stellt. Es wird noch kein Wert auf Design gelegt. So sind z.B. in der Elektronik Breadboard Schaltungen oder die Nutzung eines Arduino oder Raspberry Pi sehr beliebt, bevor dann eine individuelle integrierte Hardware entwickelt wird.
Critical Function Prototype: Dieser Prototyp fokussiert auf die vermeintlich kritischste Funktion des neuen Produkts oder Konzepts und dient der Überprüfung selbiger mit dem Nutzer, um weitere hinweise für das finale Produkt zu erhalten.
Design Prototype: Dieser hat im Gegensatz zum Functional Prototype keinerlei Funktion. Es geht vielmehr um die Überprüfung des Designs eines Produktes. Wer kennt nicht die aus Knetmasse gefertigten und mit Folie überzogenen Auto-Design-Prototypen, kleiner oder im 1:1 Maßstab erstellt werden, um das im Computer erstellte Design haitisch zu überprüfen.
Dark Horse Prototype: Hierbei gehts um die Umsetzung der verrücktesten/ gewagtesten Idee mit dem höchsten Gewinnpotenzial zu testen. Ähnlich wie beim Pferderennen auf das Pferd mit der geringsten Gewinnchance zu setzen und die höchste Quote zu bekommen.
Wizard of Oz Prototype: Test von Funktionalitäten, die noch nicht umgesetzt wurden. Ein Beispiel hierzu ist der Online-Schuhhändler “Zapfs”, der also Prototyp kein eigenes Schuhlager besaß, sondern bei jeder Bestellung, die von der Zappos-Website (per eMail) einging, die gewünschten Schuhe im nächstgelegenen Schuhgeschäft gekauft und an den Kunden versandt hat. So konnte mit minimalem Aufwand ein Proof-of-Concept für potenzielle Investoren erbracht werden, dass Online-Schuhhandel funktioniert und der vorgestellte Business Case realistisch ist.

Inkrement

Das Produkt Inkrement ist das Ergebnis eines SCRUM Sprints. Es sagt damit nichts über die Nutzbarkeit des gesamten Produktes aus, sondern dient vielmehr der Transparenz, was im Rahmen des Sprints geschaffen wurde und wie sich der aktuelle Produktstand darstellt. Es dient direkt dazu, Feedback vom Product Owner oder potenziellen Kunden einzuholen. Das Entwicklungsteam erhält hierdurch wertvolle Informationen über zur Validierung oder Anpassung der Spezifikation des Produktes. Andererseits erhalten wichtige Stakeholder ein Feedback vom Projektteam zur Umsetzung der Anforderungen, zum Projektfortschritt und zur technischen Machbarkeit. Inkremente können, müssen aber nicht vollständig funktionsfähig und/ oder vermarkter sein. Gerade in frühen Projektstadien können gerade in den ersten Sprints Inkremente entstehen, die für sich alleine noch keine funktionsfähigen Produkte darstellen. Das Inkrement ist somit vor allem ein Unternehmensinternes Artefakt.

Release

Unter Release versteht man kommend aus der Softwareentwicklung ein neues Produkt, das freigegeben und veröffentlicht wird. Hierbei werden in einem Release ein festgelegtes Set an neuen Features/ Funktionalitäten des Produktes gebündelt. Der Fokus liegt hier vor allem auf der Klarheit und Verbindlichkeit nach Richtung Entwicklungsteam aber auch in Richtung Kunde:

Ein Release-Plan bündelt verschiedene Produktfeatures zu einem definierten Release und legt einen entsprechenden Veröffentlichungstermin fest. Er hilft so im Produktentwicklungsprozess bei der Mittelfrist-Planung und der Koordination auch anderer Fachbereiche in einer Organisation. So werden Marketing- und Vertriebsaktivitäten auf einen Release-Termin abgestimmt, das Produktteam nutzt den Plan zum Abgleich von verfügbaren Ressourcen und Aufwand für die Gesamtliste an möglichen Features.
Auf der anderen Seite schafft ein Release auch auf der Kundenseite Klarheit, welche neuen Features nun das Produkt beinhaltet und welchen Mehrwert die neue Version bietet. Auch vermittelt es Sicherheit im Bezug auf Nutzbarkeit und Stabilität der neuen Funktionalitäten.

Ein schönes Beispiel für gelungene Release-Planung ist aus meiner Sicht Apple, die es perfekt schaffen, immer gerade so viele neue Features und Weiterentwicklungen in ein Produkt einzubauen, dass es für den Kunden zum Ersatz des vorherigen Releases animiert, aber gerade so wenige Features, dass es gelingt, diese auch im festgelegten Jahreszyklus mit der gewünschten Qualität und den vorhandenen Ressourcen auch umsetzen zu können. In der Softwareentwicklung wird häufig zwischen verschiedenen Releasetypen unterschieden:

Major Release: Diese “großen” Versionswechsel (1.0, 2.0, 3.0, …) umfassen signifikante Neuerungen/ Verbesserungen des Produktes. Viele Unternehmen sind dazu übergegangen, diese in einer festen Taktung, z.B. Jahreszyklus bei Apple Betriebssystemen oder Zwei-Jahres-Zyklus bei Apple iPhone (optische Designänderung).
Minor Release: Diese “kleinen” Versionswechsel (1.1, 1.2, 1.3, …) liefern kleinere Verbesserungen oder unkritische Fehlerbehebungen in einem Produkt nach. So wären Facelifts bei Autos oder die “s” Modell des iPhone ein mögliches Beispiel.
Emergency Release/ Hotfix/ Security Release: Dies sind kurzfristige Software-Versionen, die einzelne oder mehrere Fehler oder Sicherheitslücken beheben. Sie beinhalten in der Regel keine weiteren Funktionalitäten und stellen lediglich die Nutzbarkeit oder Sicherheit des Produktes wieder her.

MVx

Minimum Viable … beschreibt den Zustand des Gesamtproduktes aus Kundensicht. Es dient einerseits dazu, die Reihenfolge der zu entwickelnden Features festzulegen. Andererseits auch, Dabei werden unterschiedliche Zustände des Produkts im Hinblick auf Kundennutzen oder Vermarktbarkeit gelegt:

Minimum Viable Product (MVP): Dies ist ein Produkt in einem Zustand, das den geringsten möglichen Kundennutzen verspricht. Es ist somit das “erste” Produkt, das einer kleinen Menge an potenziellen Kunden zur Nutzung bereitgestellt werden kann. Es ist bereits “nutzbar” und liefert dem Anwender einen “Nutzen”, ist aber vom Funktionsumfang noch sehr eingeschränkt. In der Regel enthält es nur wenige Kernfeatures und entspricht damit nur den Anforderungen von “Early Adaptors”, die einen ersten Blick auf das Produkt werfen wollen und es für einen ganz spezifischen Zweck nutzen wollen. Es ist eine Art Prototyp in einem sehr frühen Entwicklungsstadium. Ziel ist es nicht, das Produkt in dieser Version bereits zu vermarkten, sondern vielmehr sehr frühzeitig Nutzerfeedback für den weiteren Entwicklungsprozess zu erhalten. So ist es in einer mobilen Bankensoftware vielleicht möglich, sich über die hinterlegte Telefonnummer einzuloggen und Kontobewegungen anzuzeigen, aber vielleicht noch nicht Überweisungen zu tätigen, das Passwort selbst zu ändern oder Daueraufträge einzurichten.
Minimum Marketable Product (MMP): Dies ist ein Produkt in einem Zustand, der es erlaubt, es am Markt zu präsentieren und zu vermarkten. Es enthält ein Minimal-Set an Marketable Features (MMF) und garantiert dem Kunden bereits einen signifikanten Kundennutzen. Bei der mobilen Bankensoftware könnte das das Einloggen, Ausloggen, Anzeigen des Kontostandes und das Tätigen von Überweisungen sein (einmal angenommen, dass keine anderen Wettbewerber am Markt wären). Vielleicht müsste man zur Passwortänderung noch den Kundensupport nutzen, der die Datenbankeinträge manuell vornimmt.
Minimum Convenient Product (MCP): Dies ist ein Produkt in einem Zustand, das beim Kunden einen signifikanten Mehrwert und Zufriedenheit erzeugt und sich von Konkurrenzprodukten bereits hinsichtlich der Features signifikant abhebt. Dies wäre z.B. das “Spaces” Feature bei der Online Bank N26.
Minimum Lovable Product (MLP): Ein Produkt, das im Gegensatz zum MVP, das vorrangig eher die Funktionalität bei der Nutzenbetrachtung im Blick hat, fokussiert das MLP auf alle Ebenen des Produkt, wie Funktionalität, Reliabilität, Usability und emotionales Design.

Beta

Eine Betaversion ist eine fast fertige Release-Version eines Produktes, die vielleicht noch den einen oder andere Fehler enthält, aber im Großen und Ganzen “fertig” ist und somit voll funktionsfähig und nutzbar. Ziel einer Beta ist das Testen im Echtbetrieb. Daher wird diese Version einem größeren Kreis an Test-Kunden bereitgestellt, die diese im Alltag nutzen. Im Gegensatz zum MVP ist der Vollständigkeits- und Nutzengrad höher. Im Gegensatz zu den Mvx generell, setzt der Begriff Beta eher auf das Testing eines Bestehenden Featuresets in der Fläche, als auf generelles Kundenfeedback zum Gesamtprodukt. Ein schönes Beispiel sind die Apple OS Public Betas. Hier stellt Apple in einem frühen Stadium einem breiteren Nutzerkreis eine Betaversion zur Verfügung. Sie kann fast vollständig genutzt werden, wobei die Stabilität noch nicht vollständig für den Produktivbetrieb gewährleistet ist. Neben Fehlerbehebungen werden i.d.R. nur noch kleine Designänderungen, wie Farben oder Button-Größen und Positionen angepasst. Die Features stehen bei der Veröffentlichung der Beta fest. Der Begriff entstammt dem Kontext der Entwicklungsstadien von Software, der sich in der Regel wie folgt darstellt: Pre-Alpha -> Alpha -> Beta -> Release Candidate/ Pre-Release -> Release (Release To Manufacturing/ Marketing, Stable, Final) -> GA (General Avaliability). Gerade im Agile Kontext ist auch die “Perpetual Beta”, die kontinuierliche Beat relevant. Diese zielt auf sehr kurze Weiterentwicklungszyklen und die parallele Integration und Release von Produkten ab. Hierbei verschwimmt das fertige Produkt mit der Beta version. Als Beispiel kann Google dienen, die z.B. vom Schlüsselservice “Suche” keine Releases entwickeln, sondern Weiterentwicklungen des Produktes parallel zum bestehenden Produkt bei einer kleinen Anzahl von Kunden automatisch einspielen und testen und so das Produkt völlig evolutionär weiterentwickeln.

Quellen:

Pfeffer, J. (2020). Produktentwicklung – lean und agile. Hanser: München

https://release-management.anracon.de/2018/10/25/spezielle-releases-mvp-mmp-mcp/

https://rubygarage.org/blog/minimal-marketable-product-vs-minimum-loveable-product

https://en.wikipedia.org/wiki/Prototype

https://de.wikipedia.org/wiki/Entwicklungsstadium_(Software)

https://www.designthinking-methods.com

https://t2informatik.de/wissen-kompakt/release/