Wer ein SaaS-Pro­dukt ent­wi­ckelt – also ein Soft­ware-as-a-Ser­vice-Pro­dukt –, stellt schnell eines fest: SaaS-Ent­wick­lung ist mehr als Soft­ware-Ent­wick­lung. Es geht nicht mehr allein um sau­be­ren, gut funk­tio­nie­ren­den Code. Nicht nur dar­um, dass das Ergeb­nis tech­nisch funk­tio­niert. Ein erfolg­rei­ches SaaS-Pro­dukt, eine erfolg­rei­che Web-App braucht mehr.

Zum Bei­spiel eine Funk­tio­na­li­tät, die wirk­lich auf die Ziel­grup­pe abge­stimmt ist. Ein leicht ver­ständ­li­ches und intui­ti­ves Inter­face, für die per­fek­te User Expe­ri­ence. Ein nach­hal­ti­ges Busi­ness-Model, effek­ti­ves Pro­jekt-Manage­ment, eine durch­dach­te Brand etc. Kurz: Ein SaaS-Pro­dukt ist mehr als die Sum­me sei­ner vie­len Teile.

Das kann ent­mu­ti­gen. Aber es gibt ein paar ers­te Schrit­te, um in die Ent­wick­lung von digi­ta­len Pro­duk­ten hineinzufinden.

Schritt 1: Personas

Per­so­nas hel­fen her­aus­zu­fin­den, für wen ein Pro­dukt gedacht ist. Im Nor­mal­fall funk­tio­niert die Idee ja nicht für alle. Man über­legt sich dabei zwei bis fünf fik­ti­ve Per­so­nen, denen das Pro­dukt etwas brin­gen soll. Was wol­len sie? Wie ticken sie? Und: Wie hilft ihnen das Produkt? 

Schritt 2: Der Canvas

Der nächs­te Schritt ist ein Plan. Aber kein vol­ler Busi­ness­plan. Ein Busi­ness-Model-Can­vas reicht voll­auf. Das ist ein stark redu­zier­ter Busi­ness­plan, der bis­her unbe­dach­te Aspek­te eines Pro­dukts auf­zeigt. Das dau­ert viel­leicht, aber am Ende ist die SaaS-Idee rund­um beleuchtet.

Schritt 3: Ideen-Test

Zeit für Feed­back. Aber im klei­nen Rah­men für’s Ers­te. Am bes­ten stellt man sich vor, die App exis­tiert bereits, und schreibt eine Pres­se­aus­sen­dung dafür. Anstel­le sie aus­zu­schi­cken, gibt man sie aber nur Leu­ten, deren Mei­nung man ver­traut, und bit­tet um Feed­back. Natür­lich wird nicht alles gut sein. Aber das Feed­back macht das Pro­dukt besser.

Schritt 4: Prototyp-Bau

Der ers­te Pro­to­typ lan­det wahr­schein­lich in der Ton­ne. Es geht hier aber nicht um ein MVP, son­dern um ein Gefühl für das Pro­dukt. Emp­feh­lung: Ein Click-Dum­my-Pro­to­ty­pe. Kei­ne Soft­ware-Ent­wick­lung, statt­des­sen wird das Inter­face des Pro­dukts auf­ge­zeich­net und in Schritt 5 …

Schritt 5: Mehr Testen

… aus­pro­biert. Hier inter­agie­ren poten­ti­el­le Nut­zen­de mit dem Click-Dum­my. Ent­we­der auf Papier und sie sagen, wor­auf sie kli­cken wür­den, oder mit Design-Apps wie Mar­vel oder invi­si­on. Das Bes­te dar­an: Feh­ler sind so güns­ti­ger, weil noch nicht tau­sen­de Euro an Ent­wick­lungs­ar­beit im Pro­dukt stecken.

Schritt 6: Team-Findung

Alle — außer alles kön­nen­de, moder­ne Leo­nar­do da Vin­cis — brau­chen ein Team mit Skills in Sachen Busi­ness, Design, Mar­ke­ting, Deve­lo­p­ment und Dev-Ops. Wich­tig dabei ist, auf die Exper­ti­se der Men­schen zu hören und nicht nur Leu­te an Bord zu holen, die so den­ken und so aus­se­hen wie man selbst. Diver­se Teams sind kom­pe­ten­ter, sehen mehr und arbei­ten besser.

Schritt 7: Finanzierung

Jetzt geht es ums Geld. Irgend­wie soll ja alles finan­ziert wer­den. In Öster­reich funk­tio­niert das zum Bei­spiel in Inku­ba­to­ren, beim Aus­tria Wirt­schafts­ser­vice oder bei der FFG. Auch das kos­tet Kraft und Ener­gie. Aber viel­leicht ermög­licht es einem ja auch einen Traum.

Schritt 8: Die Entwicklung

Jetzt fehlt “nur noch” die Ent­wick­lung. Dafür gibt es zwar kei­ne One-Size-Fits-All-Lösung, aber zumin­dest ein paar Tipps: Auf Open Source zu set­zen für bewähr­te Lösun­gen, die einen aber nicht an einen Anbie­ter kop­peln. Shared Code für alle Platt­for­men zu ver­wen­den, für redu­zier­ten Ent­wick­lungs- und Main­ten­an­ce-Auf­wand. Qua­li­ty Assuran­ce und auto­ma­ti­sche Tests aus­zu­bau­en, damit das Pro­dukt so gut wie mög­lich wird.

Und noch ein letz­ter Tipp: Man muss nicht jedem Trend nach­lau­fen. Oft reicht es, auf den guten alten Haus­ver­stand zu hören.