Foodicious ist eine App gegen die Lebensmittelverschwendung, die uns daran erinnert, wann unsere eingekauften Lebensmittel ablaufen und uns zeigt, wie wir diese kreativ verwerten können. In unserem ersten Blogartikel haben wir beschrieben, wie wir die Kern-Schmerzpunkte unserer Zielgruppe mittels qualitativer Interviews identifiziert und anschließend eine Lösungsidee in Form einer Food-App entwickelt haben. In diesem Blogartikel wird es um die ersten Umsetzungsversuche eines Minimum Viable Products (MVP) und die daraus entstandenen Learnings gehen.
Das Value Risk
Nachdem wir viele Feature-Ideen zusammengetragen hatten, stellte sich recht schnell die Frage: Wie beginnen wir konkret mit der Umsetzung? Worin stecken die größten Projektrisiken? Nachdem wir das „Value Risk“ (schaffen wir Mehrwerte für eine Zielgruppe?) bereits in Teilen validiert hatten (ja, das Problem existiert), stellte sich weiterhin die Frage, wie wir die identifizierten Schmerzpunkte der Nutzer:innen adressieren können. Die Food-App war dabei nur eine von vielen Möglichkeiten; eine smarte Kamera mit Bilderkennung im Kühlschrank oder eine Nachbarschafts-Cooking-Plattform sind ebenso denkbare Ansätze, um der Lebensmittelverschwendung entgegenzuwirken. In anderen Worten: es musste geklärt werden, ob die von uns erarbeitete Produktidee tatsächlich das Problem löst. Folgt man Steve Blank, so besteht der sogenannte „Customer Development Process“ aus vier Phasen: Die ersten beiden Phasen „Customer Discovery“ (was ist das Problem?) und „Customer Validation“ (löst die Idee das Problem?) befassen sich mit der Suche nach einem tragfähigen, skalierbaren Businessmodell. Die letzten beiden Phasen „Customer Creation“ (Skalierung des Geschäftsmodells) und „Company Building“ (Organisationsgründung) drehen sich um die Umsetzung des identifizierten Geschäftsmodells.
Demnach standen wir mit unserer Idee in den Startlöchern der zweiten Phase. Ganz nach Blanks Motto there are no facts inside the building, so get outside galt es nun, unsere Produktidee mit ersten Usern herauszufordern und gegebenenfalls anzupassen.
Das Feasibility Risk
Ebenso kristallisierte sich heraus, dass das „Feasibility Risk“ (ist es technisch überhaupt machbar?) nicht zu vernachlässigen war. Um nur zwei Beispiele zu nennen: Es muss ein recht genaues Verfallsdatum der eingekauften Lebensmittel errechnet werden, um sicherzustellen, dass der Reminder noch rechtzeitig verschickt wird. Jedoch war an dieser Stelle die Umsetzung unklar, denn beispielsweise halten sich grüne Bananen deutlich länger als bereits vorgereifte, geschälte Stücke. Eine weitere Herausforderung war die Eingabe der Produkte in den Bestand. Ist dies per Kassenbon-Scan machbar oder bedarf es an dieser Stelle einer anderen Lösung?
Die ersten Schritte der Umsetzung und das „Minimum Viable Product“
Um schnellstmöglich das Feasibility Risk zu reduzieren, starteten wir zeitgleich verschiedene Experimente unter der Verwendung möglichst einfacher Mittel.
Manuelle Zutateneingabe und Rezeptsuche
Zunächst versuchten wir, kostenlose Lebensmittel- und Rezeptdatenbanken ausfindig zu machen, um die Eingabe „sinnvoller“ Zutaten sowie darauf basierender Rezeptvorschläge zu ermöglichen. Da unsere initiale Suche erfolglos blieb, gingen wir nochmals einen Schritt zurück und suchten nach einem einfacheren Weg, der schnell zu finden war. Wir erstellten manuell ein Spreadsheet, in dem wir die Daten pflegten, die wir glaubten zu benötigten: 500 Einträge mit dem Namen der Zutat, typischer Menge und geschätztem Verfallsdatum. Die Idee war, dass, sobald ein User eine Zutat eingibt, diese erkannt und dem Bestand hinzugefügt wird, inklusive ihrer typischen Menge sowie Verfallsdatum. Nachdem wir mit dem Aufbau der Datenbankstruktur begannen, stellten sich einige technische Fragen, besonders zum Umgang mit den Mengeneinheiten. Ein Beispiel: wie viel kg sind typischerweise in einem Netz Zwiebeln enthalten? Wie sollte das verrechnet werden, wenn im Rezept 1 Zwiebel benötigt wird? Die ursprüngliche Idee war, dass die Menge von der Bestandsmenge abgezogen wird, wenn ein User ein Rezept kocht. Beispielsweise wenn ein halber Liter Milch benötigt werden, dann bleibt bei einem Liter Bestand noch ein halber Liter übrig. Auch an dieser Stelle gingen wir einen Schritt zurück: Warum hatten wir die Menge berücksichtigt? Wir hatten nie verifiziert, dass diese Granularität benötigt wird. Demnach beschlossen wir, die Komplexität zu reduzieren, indem wir Nutzer:innen primär die Information „Zutat vorhanden/nicht vorhanden“ kommunizierten und optional ermöglichten, eine Menge manuell hinzuzufügen. Durch das Wegfallen der Menge (Einheit, Anzahl) wurde die technologische Umsetzbarkeit immens vereinfacht.
Um auszuprobieren, ob eine zutatenbasierte Rezeptsuche machbar ist, erstellten wir auch hier ein Spreadsheet mit Rezepten. Mit nur fünf Beispielen konnten wir feststellen, dass unsere Rezeptsuche im Grundsatz funktioniert.
Automatisierte Zutateneingabe
Parallel starteten erste Experimente zur automatisierten Eingabe von Zutaten durch den Scan des Kassenbons.
Viele Apps der Branche, wie etwa Foodtracker, nutzen Barcodes, um mehr oder weniger automatisiert Lebensmittel zu erkennen. Das bringt aber Nachteile mit sich, allen voran benötigt man dafür passende Daten. Es ist außerdem müßig, alle gekauften Lebensmittel vor dem Einräumen in den Kühlschrank zu scannen. Normal bekommen wir eine Liste mit allen Dingen, die wir gerade eingekauft haben, in kompakter, analoger Form – den Kassenzettel.
Analogen Text digitalisieren wir per „Optical Character Recognition“ (OCR), einer Möglichkeit, automatisiert Text innerhalb von Bildern zu erkennen. Für bessere Ergebnisse empfiehlt es sich, die Lesbarkeit des Textes zu erhöhen – korrektes Ausschneiden des Bons, Glättung und Kontrasterhöhung sind effizient anwendbar. Wenn wir jetzt den Bon digitalisiert haben, stehen wir vor der eigentlichen Aufgabe: Wie unterscheiden wir unsere Lebensmittel von anderen Dingen, die wir gekauft haben, wie Putzmittel oder Küchenrollen? Den ersten Hinweis kann die vermerkte Umsatzsteuer geben (7% für Lebensmittel wie Brot, Butter, Kaviar und 19% für Luxusgüter wie Kleidung, Hafermilch, Süßkartoffeln), aber das deutsche Steuersystem stellt sich schnell als nicht sonderlich hilfreich heraus.
Wir wollen außerdem nicht nur Lebensmittel erkennen, sondern köstliche Gerichte vorschlagen, die man damit kochen kann. Also entschieden wir uns dazu, unsere Zutatenliste als Basis zu verwenden. Einfach schauen, ob in den Ergebnissen der OCR Reis, Mais und Käse sind – fertig. Damit auch kleinere Fehler der OCR nicht ins Gewicht fallen (Milch als Mi7ch erkannt), erlauben wir dabei auch ein paar Fehler – je nach Länge des Wortes. Mit zwei Fehlern erkennt ihr das Wort Spaghetti sicher noch, zwei Fehler im Wort Mais werden da schon schwieriger.
Ganz fertig sind wir leider noch nicht, da sich die verschiedenen Einzelhändler nicht ganz einig sind, was sie wie auf ihre Bons drucken – Umlaute? Keine Umlaute? Kann vielleicht noch die Herstellermarke mit reingequetscht werden? Schreiben wir besser „Cocktailtomaten“ oder „Tomate Cocktail“? Die Ideen scheinen grenzenlos zu sein.
Damit wir alle gängigen Schreibvarianten eines Wortes erkennen können, erstellen wir uns ein Wörterbuch: Weißwürste werden als Weisswürste, Weißwuerste und so weiter abgespeichert. Dank deutscher Rechtschreibung hat sich die Anzahl an Zutaten auf einmal verdoppelt. Da der Zeitaufwand für das Iterieren durch diese Liste für jedes Wort leider unverhältnismäßig hoch ist, arbeiten wir hierarchisch:
Nur wenn eine Position vom Bon nicht genau mit einer Zutat übereinstimmt, checken wir die Rechtschreibfehler, oder besser gesagt die Ähnlichkeit zu den Zutaten mittels der Levenshtein-Distanz. Dabei schauen wir, ob es einen Treffer gibt, der uns ähnlich genug erscheint. Wenn das immer noch keinen Match ergibt, prüfen wir, ob Teilworte einer unserer Zutaten entsprechen. Blattspinat und Babyspinat sind ja irgendwie beide als Spinat einsetzbar – zumindest, wenn man nicht nochmal einkaufen gehen will. Wenn wir jetzt keinen Treffer haben, müssen wir einsehen, dass es sich wohl um keine unserer Zutaten handelt, oder sie zu kryptisch dargestellt wurden.
Damit wir in Zukunft immer besser im Erkennen von Zutaten werden, gibt es die Möglichkeit, neue Einträge ins Wörterbuch vorzunehmen – wenn die Saitenwurst nicht erkannt wird, die Wiener Wurst aber bekannt ist, kann ich einfach einen kleinen Eintrag hinzufügen. Beim nächsten Mal erkennt Foodicious dann auch die Saitenwurst.
Das Minimum Viable Product
Um das Value Risk zu minimieren, setzen wir uns das Ziel, zeitnah ein „Minimum Viable Product“ oder „MVP“ mit Usern zu testen. Der Begriff des Minimum Viable Products hat sich in den letzten Jahren verstärkt zu einem beliebten Buzzword in der Produktentwicklungsszene entwickelt. Unter der Vielzahl definitorischer Ansätze, die sich im Laufe der Zeit entwickelt haben, besinne ich mich gerne auf dessen Wortstamm zurück: minimum und viable.
Randnotiz: Ich habe leider häufig das Gefühl, dass ein MVP mit Minimum oder Prototyp gleichgesetzt und zeitgleich vernachlässigt wird, dass ein Mehrwert für Nutzer:innen gestiftet werden soll. Demnach ist die Hemmschwelle, ein MVP mit Kunden zu erproben, an mancher Stelle – zurecht – noch sehr hoch. Aber das ist eine andere Diskussion.
Eine schöne Erläuterung und Visualisierung des Kerngedanken eines MVPs findet man bei Henrik Kniberg:
Unser „Fahrrad“ oder die erste Produktversion, von der wir ausgehen, dass sie einen Mehrwert stiftet, der ausreicht, um erste Nutzer:innen zu gewinnen, ist die folgende: Nutzer:innen sollen Zutaten auf die Einkaufsliste setzen können, welche nach dem Kauf in den Bestand übergehen und für die eine automatisierte Erinnerung vor dem Verfallsdatum verschickt wird. Mit dieser Funktionalität adressierten wir zwei der drei wichtigsten User Pain Points: Was ist in meinem Kühlschrank und wie lange halten sich diese Lebensmittel noch? (Mehr dazu in unserem ersten Blogartikel).
Das MVP wurde Anfang April 2019 fertiggestellt und als interne Beta freigegeben.
Next Steps
Zusammenfassend haben wir einen ersten technologischen Durchstich für die wichtigsten Funktionalitäten erreicht und somit das Feasibility Risk stark reduziert. Jedoch fehlen noch weitere Experimente zur Reduktion der verschiedenen Produktrisiken. Beispielsweise muss geklärt werden, wie ein genaueres Mindesthaltbarkeitsdatum berechnet werden kann (z.B. auf Basis von Benutzereingaben) und auch die Rezeptsuche ist noch nicht optimal auf den Usecase der Resteverwertung abgestimmt (z.B. Evaluierung einer Substitut-Suche, wenn anstatt Zucchini auch Aubergine verwendet werden kann).
Das Feedback aus der Beta-Phase wird die Entscheidungsgrundlage für die nächsten Schritte sein. Löst unsere App tatsächlich das Problem? Adressieren wir die richtige Zielgruppe? Wie kommt die Usability der App an? Mit diesen und weiteren Fragen befassen wir uns in unserem nächsten Blogartikel.
Key Takeaways
- Ausprobieren: In der Produktentwicklung gibt es zu Beginn viele Fragezeichen und Annahmen. Wie sich beispielsweise an unserem Versuch, eine technologische Basis zu schaffen, gezeigt hat, ist frühes Ausprobieren essentiell. Wenn man zeitnah validiert hat, dass etwas im Grundsatz möglich ist, kann man danach immer noch entscheiden, wie etwas umgesetzt wird. Wer stattdessen die Zeit mit Pläne schmieden verbringt, wie man etwas machen würde, läuft Gefahr, diese Zeit verschwendet zu haben, weil sich eine Grundannahme als falsch herausstellt.
- Keep it simple: In regelmäßigen Abständen sollte man einen Schritt zurückgehen, sein Ziel nochmals schärfen und sich fragen, ob es nicht auch einen einfacheren Weg gibt, dieses Ziel zu erreichen. In unserem Fall hat sich herausgestellt, dass man mit sehr simplen Mitteln (z.B. einer Lebensmitteldatenbank bestehend aus einem Spreadsheet und Fleißarbeit) einen großen Schritt vorankommen kann.
- Fokus: Je tiefer man sich ein Thema einarbeitet, desto mehr Möglichkeiten und Unsicherheiten kommen zum Vorschein. Neben der Vision, die als übergeordneter Leuchtturm fungiert (mehr dazu in unserem ersten Blogartikel), muss man auch kleinere Wegpunkte wie ein MVP definieren, um den Fokus bei der Arbeit nicht zu verlieren. Dabei ist jeder Wegpunkt aber auch eine Kreuzung, die uns die Möglichkeit bietet zu entscheiden, ob wir diesen Weg weitergehen wollen (z.B. richtige Zielgruppe? Richtiger Lösungsvorschlag?) oder besser die Richtung ändern (z.B. andere Features?), um unsere Vision zu erreichen.
