Unser Ideenprozess

Eine wichtige Säule, um dies zu erreichen, ist die Entwicklung und Veröffentlichung eigener Produkte.

Machen wir uns nichts vor, das ist ein Vorhaben, das leichter gesagt als getan ist. In der Vergangenheit haben wir uns jedenfalls schwer damit getan.

Die Gründe dafür waren vielfältig, es gab aber einige Gemeinsamkeiten, die wir ausmachen konnten und die wohl nicht ganz unüblich sind.

Zum einen müssen wir natürlich Geld verdienen, weshalb die Arbeit für unsere Kunden immer einen hohen Stellenwert hat und zu wenig Zeit blieb, um an unseren eigenen Ideen zu arbeiten.

Gerade weil die Zeit knapp war und wir schnell loslegen wollten, haben wir zu oft zu früh mit der Entwicklung gestartet, uns um Tech-Stacks und Set-ups gekümmert, bevor das zu lösende Problem überhaupt vollends verstanden war.

Wenn wir das bemerkten, neigten wir zur Überkompensation, nahmen uns vor, diesmal richtig und ausführlich zu planen und verfielen dabei schließlich in ein Muster, in dem wir es erfolgreich schafften, jede unserer Ideen kaputt zu denken. Gründe, warum etwas nicht funktionieren wird, findet man schnell, wenn man nur will.

Wir funktionieren in agilen Arbeitsweisen, folgen Prozessen und verfeinern diese in unseren Retros, trotzdem sind wir immer wieder in eines dieser beiden Extreme gerutscht. Zeit sich diesem Problem zu stellen, dachten wir und entwickelten während unseres letzten Team-Wochenendes einen Plan dafür.

Unser Ziel: Eine Umgebung schaffen, in der Ideen die nötige Zeit bekommen, um evaluiert und prototypisch umgesetzt werden können.

Dazu sind wir den recht radikal Schritt gegangen, uns Zeit zu schaffen und starten in das 2023 ohne Kunden, ohne Auftrag, ohne doppelten Boden. Das ist riskant und wird auch dauerhaft so nicht haltbar sein, bietet uns aber zunächst die Möglichkeit einer Neuorientierung.

Um aus den Ideen, die wir ins Team hineintragen, schließlich Produkte zu machen, gehen wir nach der Design Thinking Methode vor, die wir marginal für unseren Rahmen angepasst haben und vermutlich künftig weiter anpassen werden.

In einer intensiven Session haben wir bekannte Methoden diskutiert und schließlich geschaut, welche dieser Methoden am besten mit unseren Stärken und Schwächen vereinbar ist. Das Ergebnis ist der besagte konzentrische Design-Thinking-Ansatz, mit klarem Fokus auf die für uns schwierigste Phase: der Ideenvalidierung.

Dieses Validieren erfolgt im besten Fall ohne Programmierarbeit, was unserem Naturell widerspricht und bei dessen Einhaltung wir uns sicherlich gelegentlich auf die Finger hauen müssen.

Wir wissen aber, dass wir in späteren Produktphasen noch genug Zeit in die Entwicklung investieren werden und dass zu Beginn des Prozesses der Fokus eben auf anderen Prozessen liegen muss.

Unser Prozess beginnt mit dem Offensichtlichen: Die Idee muss dem Team bekannt gemacht werden. Hier haben wir uns auf einen wesentlichen Aspekt geeinigt: Die Idee muss von allen verstanden werden und sie wird in dieser ersten Phase nicht kritisiert oder hinterfragt! Wir wollen erst einmal alle dasselbe Verständnis haben und im besten Fall kann jeder von uns die Idee mit eigenen Worten wiedergeben.

Erst in der nächsten Phase gehen wir etwas detaillierter vor. Wir versuchen das Kernproblem zu erkennen und mögliche Lösungsansätze, die vielleicht schon in den Köpfen schwirren, rauszufiltern. Nur wenn das Problem für sich allein steht, schauen wir uns an, warum es da ist und wer davon betroffen ist.

Schließlich ist es Zeit für erste Lösungsansätze. Da wir vermutlich in vielen Situationen keine (externen) Betroffenen aus den Problemdomänen einbeziehen können, einfach, weil entsprechende Kontakte fehlen, zwingt uns dies, Methodiken wie die EmpathyMap anzuwenden, um uns den Personas zu näheren.

Das gilt auch für nachfolgende Schritte. Wir haben das Rüstzeug für schnelle und einfache Verifikationen im Team, es ist jedoch davon auszugehen, dass wir in den Diskussionen keine Expertinnen oder Betroffenen dabei haben werden. Ein Punkt, an dem wir arbeiten wollen, um erstellte Prototypen (in welcher Form auch immer) auch von außen validieren zu können.

Das Ergebnis dieses Prozesses, ist eine theoretische, aber validierte Lösung für das Problem. Wir betrachten das als unser QualityGate bevor wir weiter in die Entwicklung gehen.

Wie wir den Prozess an dieser Stelle weiter gestalten, haben wir uns zunächst offen gelassen und machen das auch abhängig vom zu lösenden Problem. Hier ziehen wir dann bekannte Methodiken heran, wie das Story-Mapping, MVP, PoC, das Business Model Canvas, Produkttreppen und Ähnliches.

Mit einer unserer Ideen stehen wir bereits an diesem Punkt und werden uns ab kommenden Jahr intensiv damit beschäftigen und sicherlich auch darüber schreiben. Für uns eine spannende neue Zeit, auf die wir uns schon freuen.