Goodbye Product Desk. Hello Product Builder.

Was war der Product Builder vorher?

‍

Der alte Name des Produkts lautete Product Desk. Er sollte eine Komplettlösung für Produkt- und Projektmanagement sein. Inhaltlich sollte alles mit Bezug auf diese Themen auf einen Schlag angepasst und verbessert werden. Hier war es egal, ob es sich um die Arbeitsweise und das Toolset von Entwickler:innen handelte oder um die eines Mitglieds aus dem Top-Management. Es wurden also die strategische, taktische und operative Ebene des Projekt- und Produktmanagements im Produktumfang abgebildet.

Doch weil wir an kontinuierliche Verbesserung glauben und hier einiges an Verbesserungspotenzial erkannt haben, was durch eingehendes Feedback unterstützt wurde, haben wir das Produkt neu geschnitten. Sein Umfang wurde dabei stark reduziert. Im Folgenden stellen wir euch daher die sechs Gründe vor, warum wir uns für den Product Builder entschieden haben, und wie sich dieser zu seinem Vorgänger unterscheidet.

‍

1. Der Nutzen ist schneller erreicht

‍

‍

Reduziert man den Umfang eines Produkts, erfolgt natürlich auch seine Auslieferung schneller. Dadurch wird gleichzeitig der gewünschte Nutzen ebenfalls schneller erreicht. Wie viel schneller wir jedoch tatsächlich durch diese Veränderung sind, konnten wir selbst kaum glauben. Lieferzeiten sind zwischen 70 und 80 Prozent gesunken, je nachdem, wie man Start und Endzeitpunkt definiert. Unser Ziel ist es, diese Zeit auch weiterhin zu reduzieren, sodass euch der Nutzen innerhalb von vier Wochen nach dem ersten Workshop vollumfänglich zur Verfügung steht.

Der Vorteil hier liegt auf der Hand: Je schneller die Lösung ausgeliefert wird, desto eher kann sie ihren Zweck erfüllen. In einer Welt voller Innovation und Veränderung macht es daher nicht selten einen spürbaren Unterschied, ob die Lösung in einem Monat oder in einem halben Jahr verwendbar ist. 

‍

2. Eine kleinere Veränderung bedeutet weniger Stress

‍

‍

Wer sich mit Veränderungen beschäftigt, stößt früher oder später auf die sog. J-Curve. Sie repräsentiert den Erfolg einer Verbesserung ab dem Zeitpunkt ihrer Einführung. Je größer die Veränderung, desto länger benötigt diese in der Regel, um wirksam zu sein. Bis ihr Erfolg spürbar ist, wird es erstmal schlimmer. Den Tiefpunkt dieser Kurve bezeichnet man daher auch als Tal der Tränen.

Damit man sich also nicht über Wochen und Monate in einem endlos wirkenden Tal der Tränen aufhält, ist der Product Builder um einiges kleiner. Der Fokus auf die operative Ebene erlaubt eine einfachere Umsetzung mit weit weniger Stress. Das begrüßen sowohl wir - die Mitglieder der greenique - als auch Kund:innen, die mit der Lösung arbeiten wollen.

‍

3. Das Entwicklungsteam ist motivierter und performt besser

‍

‍

Wir haben uns viele Gedanken darüber gemacht, in welche Richtung wir den Schnitt des Produkts durchführen. Auch wenn unsere Ansprechpartner:innen primär Positionen wie z. B. Product Owner, das Project Management Office oder das Top-Management besetzen, hatten sie doch alle ein gemeinsames Problem: Ihnen fehlte eine gute Übersicht über Kapazitäten im Team und eine ordentliche Planungsmöglichkeit. Oft kam es dann zu einer von zwei Lösungen: 1.) Es gab neue Vorgaben zu Informationen, die von den Entwicklungsteams an das Management geliefert werden mussten oder 2.) Ihre Arbeitsweise wurde flächendeckend angepasst.

Am Ende des Tages musste immer eine Basis geschaffen werden, auf der aufgebaut werden konnte. In den wenigsten Fällen war das Entwicklungsteam darüber erfreut oder dadurch schneller. Wir setzen mit dem Product Builder daher genau dort an und schaffen eben jene Basis. Mehr noch, wir möchten dieser Ebene der Umsetzung auch die Möglichkeit geben, sie so zu gestalten, dass es ihnen damit besser statt schlechter als vorher geht. Das Reporting kann anschließend verbessert werden, denn ein motivierteres Team, das bessere Ergebnisse liefert, ist in jedem Fall ein Gewinn und sollte sich auch im bereits vorhandenen Reporting bemerkbar machen.

‍

4. Die Kosten sind geringer

‍

‍

Die Reduzierung des Produktumfangs hat auch einen finanziellen Charme. Durch den geringeren Aufwand kann ein geringerer Preis verlangt werden. Dazu kommt, dass die Lizenzkosten nicht länger für Jira Premium benötigt werden. Der Funktionsumfang von Jira Software reicht im Standard vollkommen aus und macht am Ende des Jahres mittlerweile einen nicht zu vernachlässigenden Kostenanteil aus.

‍

5. Weniger Funktionen, die gar nicht benötigt werden

‍

‍

Auch der Funktionsumfang des Product Builders wurde geschärft, sodass wenig bis nie genutzte Funktionen entfernt wurden. Das Ergebnis: Eine leichtgewichtige Lösung, die komplett ohne Apps genutzt werden kann. 

Doch nicht nur bei den Apps wurde Waste reduziert. Es gibt in jedem Produkt Features, die schlichtweg nicht von jedem benötigt werden. Diese kann ein Team daher bei Bedarf deaktivieren. Anleitungen dazu, wie eine von uns bereitgestellte Funktion deaktiviert werden kann, sind direkt mit enthalten. Admins erhalten eine Einweisung zu ihrer Nutzung. 

‍

6. Nachhaltiges Lernmaterial für künftige Nutzer:innen

‍

‍

Doch nicht nur das. Da weniger Schulungsbedarf besteht, haben wir die Möglichkeit, einen Teil des Lernmaterials schon jetzt als Videos zur Verfügung zu stellen. Diese können beliebig häufig in der eigenen Organisation geteilt und z.B. auch neuen Teammitgliedern zur Verfügung gestellt werden. Künftig wird auch dieses Material weiter ergänzt, sodass ein eigenständiges Onboarding nach dem initialen Erwerb deutlich einfacher wird. Vorbei sind die Zeiten, in denen alles über persönliche Trainings im Tempo der Gruppe gelernt werden musste.

‍

Lerne Andrej im Video kennen

In einem kurzen Interview hat Andrej Fragen zu den Änderungen am Product Builder beantwortet:

‍

Falls du Interesse hast, den Product Builder kennenzulernen...

... sag uns einfach Bescheid. Wir zeigen dir in einer Demo alles Relevante zum Produkt und seinen weiteren Ausbaumöglichkeiten. 

‍