Episoden

Platypus

Was uns Pareto über Produktdesign beibringen kann

027 – Ich wurde jetzt schon mehrfach gefragt, ob es nicht schon eine Community gäbe, gibt es und ob es micht mal ein Hörertreffen geben könnte. Können wir. Und zwar würde ich dazu gerne ein Medium mit Rückkanal nutzen, das jeder hat, die Email. Im Podcast kann keiner Antworten, ein Forum ist mir zu viel Overhead, also würde ich den Emailverteiler nutzen, um mal die Modaliäten für ein Hörertreffen für interessierte zu klären.

Dazu würde ich Sie bitten, Sich in den Emailverteiler einzutragen. Der Link ist in der Episodenbeschreibung und auf smarterentwickeln.de.

Weil nicht alle die Episoden sofort am Tag der Veröffentlichung hören, mache ich die erste Fragerunde in drei Tagen am Freitag.

Also, jetzt gleich einfach die Episodenbeschreibung anschauen, den Link klicken und eintragen. Bis bald im Emailverteiler.


Tragen Sie Sich hier für den Emailverteiler ein. Hier sende ich Ihnen wöchentliche Impulse, Terminankündigungen und Fragen und geben Ihnen die Chance, Themen für den Podcast vorzuschlagen und damit Ihrer Problemlösung näher zu kommen.


Name:

Email:





Und nun zu Pareto

Transkript der Episode

Vilfredo Federico Damaso Pareto hat von 1848 bis 1923 gelebt und ist heute für das 80/20 Prinzip in Erinnerung. Er hat damals die Einkommensverteilung untersucht und festgestellt, das wenige viel hatten und viele wenig. Er hat das damals am Zahlenverhältnis 20% der Leute haben 80% der Einkommen festgemacht.

Jetzt hat der Mann noch ein paar spannende andere Dinge getan, so war er einer der ersten, der die Ökonomie als Rechenexempel und nicht philosophische Argumentation begriffen hat, ein Trend, der sich mit allen Vor- und Nachteilen in die Gegenwart fortgesetzt hat.

Aber wir kennen ihn für das Pareto-Prinzip. Das Prinzip, dass wenige viel haben und viele wenig. Warum ist er gerade hierfür im Gedächtnis geblieben? Es kann daran liegen, dass 80/20 so schön griffig ist, aber sicher liegt es auch daran, dass die zugrundeliegende Verteilung sehr häufig zu beobachten ist und daher für das Verständnis der Welt essentiell ist.

Power-Law-distribution oder Potenzgesetz. Die Verteilung ist im deutschen auch gleich nach Pareto benannt: Die Pareto-Verteilung.

Die Pareto-Verteilung taucht mit unterschiedlichen Exponenten an vielen Stellen auf, von der Verteilung der Größen der Mondkrater (wenige große und viele kleine) hin zur Wortdichteverteilung usw.

So ist es auch nicht weiter verwunderlich, dass wir sie in der Produktentwicklung auch wieder finden. Nicht jedes Feature ist gleich viel Wert. Auch wenn wir den Nutzen eines Features gewichten mit dem Aufwand, den wir im Projekt dafür treiben, dann sehen wir eine starke Ungleichverteilung. Wenige Features tragen viel zum Nutzen des Produktes bei (und damit zum Wert der Produktentwicklung) und viele Features tragen nur wenig bei.

Wenn Sie jetzt die Gedanken etwas schweifen lassen und mal an Lastenhefte, Projektmeetings, Projektaufträge und Abwägungen, die Sie in Projekten machen, denken, dann fällt auf, dass wir sehr wenig über die Ungleichverteilung der Wertschöpfung reden. Weniger als gesund wäre.

Schauen Sie Sich Ihre Todo-Liste an. Ist dort eine Unterscheidung nach Wichtigkeit oder Impact gemacht oder steht da Milch kaufen neben Gespräch über Gehaltserhöhung vorbereiten. Mal ehrlich, wie viele Größenordnungen Abstand sind dazwischen? Drei, also Faktor tausend oder gar vier Größenordnungen also Faktor zehntausend?

Schauen Sie sich mal Ihr Lastenheft an. Gehen Sie mal die Liste der Anforderungen durch, die Ihr Produkt erfüllen soll. Steht das daneben, wie wichtig welche Zeile ist? Wenn Sie sich mal in Ihre Kunden hineinversetzen. Einen Kunden. Sind diesem einen Kunden alle Zeilen auf dem Lastenheft gleich wichtig? Wenn Sie das gewichten mit dem Aufwand, den sie treiben müssen, diese Ziele zu erreichen, sind dann immer noch alle gleichwichtig?

Seien wir mal großzügig und gehen nicht von drei oder vier Größenordnungen aus, sondern nur von zwei. Das hieße, dass es Zeilen im Lastenheft gibt, die dem Endkunden hundertmal so wichtig sind, wie andere. Kann das bei Ihnen auch sein? Ich bin da sicher, ich glaube auch eher an drei Größenordnungen, aber die Art und Weise, wie wir die Informationen aufbereiten und einfach als flache Liste darstellen, erzieht uns, diese Unterschiede nicht zu sehen.

Darüber wollt ich mit Ihnen heute mal reden.

Ein kleiner Teil der Arbeit in einem Projekt macht einen großen Teil des Nutzens aus. Nur uns fällt es schwer herauszufinden welcher Teil das ist. Dem Konstruktreur sagen wir es nicht. Also füllt er das Vakuum mit seinem eigenen Wertesystem und will ein guter Konstrukteur sein. So ein abstraktes “gut”. Zeichnungen Fehlerfrei, richtige Radien benutzt und bei den Gußschrägen auch nicht geschludert.

Sein Teamleiter weiß es nicht besser. Der liest zwar das Lastenheft, aber da steht es nicht drin. Schade, ich hielte es für wichtige Information, wo besondere Sorgfalt notwendig ist, und wo etwas zügiger gearbeitet werden kann. Nicht schlecht, aber eben auch nicht mit Perfektion, es kommt dem Kunden nicht so drauf an.

Ist jetzt das Produktmanagement Schuld? Da kommt doch das Lastenheft her. Die haben das geschrieben und sind doch die Brücke in den Markt rein. Wer, wenn nicht die, müsste das wissen? Was eigentlich? Na, was die Kunden wollen oder was der Kunde will? Das ist ein Unterschied.

Wenn wir alle glücklich machen wollen, dann kommt so ein Brei heraus. “Hoher Durchsatz ist wichtig und geringe Personalkosten, darf kaum Strom verbrauchen und der Ausschuss ist minimal.” Das hat ungefähr die Signalqualität von einem Brainstorming. Liegt aber eher daran, dass hier mehrere Interessen unter einen Hut gepresst werden und der dabei etwas gedehnt wird.

Wenn Sie hingegen eine enge Nische bedienen von Kunden, die das gleiche Problem mit sehr vergleichbaren Randbedingungen haben, dann können Sie sehr wohl eine Abwägung machen, welche Produktfeatures für Ihren Endkunden wichtig sind. Und dann kann das Produktmanagement diese Prioritäten auch artikulieren, dann kann die Information ins Lastenheft und die Mitarbeiter können diese Information in die Entscheidungen einfließen lassen, die sie tagein-tagaus fällen.

Sie brauchen also klar adressierbare Nichen um diese Fragen zu beantworten. Jetzt hinterfragen wir das Projekt nochmal. Brauchen wir wirklich dieses Feature, oder nicht? Wie sieht die wirtschaftlichkeit für dieses Feature aus (nicht für das Produkt, das Feature).

Machen wir doch nochmal einen Ausflug in die Softwareindustrie. Wie werden dort Features priorisiert?

Ich darf mich nochmal an Microsoft Word abarbeiten. Word ist eine Software, die allem widerspricht, was ich bisher erzählt habe. Eine Unmenge Features, ein riesiger adressierter Markt. Und viele Kunden, die auch nächstes Mal wieder Word kaufen würden.

Aber wie hat das angefangen? Die Zahl der Feature war mal viel kleiner. Die Dinge, die man mit Word und seinen Vorläufern tun konnte war nicht weit entfernt von den Fähigkeiten einer mechanischen Schreibmaschine. Die heutige Komplexität ist also gewachsen und über viele Jahre aufgebläht worden.

Und dennoch gibt es viele Nischentextverarbeitungen, die für bestimmte Zielgruppen das klar bessere Produkt sind.

Und wenn man heutzutage mit einer Textverarbeitung anfangen möchte und ein Geschäft aufziehen wollte, dann muss man sich auf so eine Nische konzentrieren, weil keiner die Investitionsmittel hat, um direkt in allen Märkten mit Microsoft Word zu konkurrieren. Zu riesig ist der Umfang, den man erstmal erschaffen müsste um ernsthaft als Ersatz für Word in der Breite akzeptiert zu werden. Die Nische ist der natürliche Freund des Angreifers.

Das gilt auch für den Maschinenbau. Wenn Sie in einem Segment die Marktführerschaft anstreben, dann bietet es sich an, dies in einer Nische zu tun, die klein genug ist, dass Sie es sich leisten können, dort Marktführer zu werden.

Aber einen Riesenunterschied gibt es. Für Microsoft kostet ein Feature mehr oder weniger an einen Kunden auszuliefern gerundet null cent. Wenn jemand Word kauft, dann kann es gleich alle Features haben, das ausliefern kostet ja nichts. Vielleicht noch etwas Marktsegmentierung, um die Einnahmenseite zu optimieren, aber die Kosten sind klar: null.

Das gilt für Sie nicht. Jedes Feature an Ihrem Produkt (Wir reden hier von Investitionsgüter im Maschinenbau) kostet Sie Geld in der Herstellung. Es ist eben nicht umsonst, einem Kunden, der nur Eier haben will die eierlegende Wollmilchsau hinzustellen. Nicht nur ist der Kunde dafür nicht bereit zu zahlen, sondern sie haben auch noch die Produktkosten.

Das ist der fundamentale Unterschied: Die ganzen Fähigkeiten Ihres Produktes erkaufen Sie Sich bei der Herstellung und bei der Entwicklung. Es kostet Sie einfach Geld.

Und so wie jeder Nutzer von Word nur einen Bruchteil der Features nutzt, so werden auch Ihre Kunden nur einen Teil der Fähigkeiten Ihres Produktes einsetzen aber für alle zahlen müssen, denn auch Sie haben ja die Herstellkosten.

Zu mächtige Produkte verschlechtern so schnell mal die Wirtschaftlichkeit für den Kunden, wenn er weniger gebraucht hätte.

Wenn Sie ein Feature mehr in Ihr Projekt unterbringen wollen, dann schauen Sie sich an, wieviel Entwicklungsaufwand das ist und welche Kundengruppen Sie Sich damit noch erschließen. So etwa: Wir brauchen EUR 50 000 mehr Entwicklungsbudget und dafür vergrößert sich der jährliche Markt um EUR 250 000. Machen? Nicht machen? Das hängt von Ihrere Marge und Ihrem Ziel-ROI ab. Konventioneller weise.

Microsoft darf so denken. Wenn die 5% mehr Markt erreichen durch ein Feature, dann haben die trotzdem nicht mehr Kosten für die anderen 95% der Kunden.

Im Maschinenbau ist das nicht so klar. Entweder sie machen das Feature echt optional und können alles weglassen, was die Kosten treibt, wenn das Feature vom Kunden nicht bestellt wird. Dann ist immer noch Ihr Baukasten komplexer geworden. Oder Sie haben tatsächlich auch für die anderen 95% der Kunden Mehrkosten. Und schmälern entweder Ihre Marge, oder, wenn Sie die Kosten durchreichen, schmälern Ihre Konkurrenzfähigkeit.

Komplexität kostet sie ganz direkt Geld. Sie verstehen, worauf ich hinaus will: Wenn der Markt Eier, Wolle, Milch und Steaks will, dann schauen Sie mal nach, ob Sie nicht Hühner, Schafe, Kühe und Schweine entwickeln wollen. Vor allem, wenn es nicht die gleichen Kunden sind, die die vier Dinge benötigen, sondern jeweils getrennte Kundengruppen sind.

Nur womit fangen wir an? Was ist das Projekt, das am vielversprechendsten ist? Wenn Sie Lust haben, dann hören Sie doch nochmal in die Folge Priorisieren mit COD3 rein. Darauf baue ich hier auf.

Wenn Sie Priorisieren müssen Sie entscheiden, wie Sie Ihre knappen Ressourcen optimal einbringen. Der Controller denkt sofort ans Geld und darauf bauen auch die ganzen Wirtschaftlichkeitsbetrachtungen auf. Wenn ich x von meinem knappen Geld einsetze, wieviel bekomme ich dann raus? Diese Frage wird durch den ROI beantwortet.

Die eigentliche knappe Ressource ist aber Ihre Entwicklungsmannschaft. Wenn die Produktidee gut ist, dann können Sie Sich Geld leihen, Kapital erhöhen, Gewinne reinvestieren. Auch mal doppelt so viel investieren wie letztes Jahr. Geld atmet hier viel mehr.

Sie haben aber eine Entwicklungsmannschaft und auch wenn wir das gerne hätten, können Sie nicht einfach durch Fingerschnipp doppelt so viel entwickeln wie letztes Jahr. Sie haben Anlaufprobleme mit neuen Mitarbeitern, Mehrkosten durch Dienstleister usw.

Das heißt, wenn Sie heute entscheiden, was sie machen sollten ist die Zeit, die Ihre Entwickler zur Verfügung haben die knappe Ressource. Also der Teiler. Und der Gewinn, den Sie mit dem Projekt erwirtschaften wollen ist der Nenner. In der eben zitierten Podcastfolge führe ich aus, warum der Cost of Delay die richtige Kennzahl für den Nutzen ist. Cost of Delay sind die Opportunitätskosten, also der nicht realisierte Gewinn, wenn Sie das Projekt verschieben.

Zusammen ist das Cost of Delay divided by Duration oder COD3. Duration, die Zeit Ihrer Entwickler, die mit der Entwicklung verbracht wird.

Jetzt können Sie die Projekte vergleichen. Und sie werden feststellen, dass die Projekte unterschiedlich guten Nutzen aus den Entwicklern ziehen.

Ein Projekt belegt Ihre Entwicklung 3 Monate und bringt Ihnen X Gewinn in den nächsten Jahren. Das zweite Projekt dauert 3 Jahre und bringt Ihnen 8X. Was machen Sie? Ist doch klar, oder? Sie nehmen das Kurze, das Projekt, dass in 3 Monaten zwar nicht so viel bringt, wie das große, aber pro Zeiteinheit dafür mehr. Und danach machen Sie entweder das lange Projekt oder Sie finden wieder etwas besseres.

Nicht schlecht. Aber es geht noch besser. Drei Jahre klingt lange. Kann man das Projekt unterteilen? Können Sie das Projekt unterteilen in eine Reihe von unabhängigen oder aufeinanderaufbauenden Miniprojekten. Was passiert dann? Werden die Projekte alle den gleichen Nutzen pro Zeiteinheit geben, oder wird es auch hier wieder eine Binnendifferenzierung geben? Wrid es einzelne Arbeitspakete geben, die besser sind als andere? Wenn Sie so durch die Arbeitspakete gehen, gibt es da welche, die besser dastehen als das kurze erste Projekt?

Also macht es Sinn doch am großen Projekt zu arbeiten. Also nicht an allen Aufgaben, aber an denen, die aus Ihrer Entwicklungszeit mehr rausholen als die anderen Projekte.

Die Pareto-Verteilung, also das mathematische Modell, hat eine Eigenschaft, die spannend ist. Sie ist skaleninvariant. Das Modell gilt auf unterschiedlichen Skalen gleichermaßen. Konkret: Sie können Projekt gegeneinander priorisieren. Und ein paar wenige Projekte und Projektideen sind viel wert und viele Projekte sind wenig wert.

Innerhalb eines Projektes gilt das genauso: Ein paar wenige Teilprojekte tragen den Großteil zur Wirtschaftlichkeit des Projektes bei, viele Teilprojekte tragen wenig bei. Und hier ist noch ein dreckiges Geheimnis: Projekte als ganzes müssen sich normalerweise einer Wirtschaftlichkeitsbetrachtung unterwerfen. Daher bleiben uns die Projekte mit negativer Wirtschaftlichkeit schon in der Planungsphase in gesunden Organisationen erspart. Das ist anders für Teilprojekte. Da die wenigsten ihre Projekte auch im inneren einer Priorisierung und Bewertung unterziehen sind in Projekten häufig Teilprojekte und Features zu finden, die eine negative Wirtschaftlichkeit haben. Also das Projekt stünde besser da, absolut und in Summe besser da, wenn man diese Teile weglassen würde. Wenn das keine Motivation ist, auch innerhalb der Projekte mal die Teile nach Wirtschaftlichkeit abzuklopfen, ach lassen wir das.

Und die Skaleninvarianz geht weiter, weil das Pareto-Prinzip auch innerhalb einzelner Arbeitspakete seine Anwendbarkeit behält. Man kann viele Arbeitsschritte unterschiedlich gründlich und unterschiedlich perfekt machen. Es ist unwahrscheinlich, dass die Effizienz hier gleichverteilt ist. Und wir kennen das alle, dass am Anfang eines Arbeitspaketes sehr schnell Fortschritte gemacht werden können, während später der Nutzen der eingesetzten Zeit fraglich ist. Auch hier ist es für eine Organisation wichtig, eine definition of done, eine gemeinsames Verständnis für “das reicht, nächste Aufgabe” zu finden. Damit hier nicht der Perfektionismus mit dem Arsch umschmeißt, was die Hände mühsam an Priorisierung und Effektivität auf der Ebene der Projekte und Teilprojekte aufgebaut haben.

Und ja, Pareto gilt auch für Kunden und Kundengruppen, die mal mehr mal weniger preissensibel sind und bei denen es mehr oder weniger Sinn macht sie sich als Nische auszusuchen.

Nur Nischen aussuchen sollten Sie sich, weil Produkte die alles können teurer sind und entweder Ihre Wirtschaftlichkeit – sie haben die Kosten, können die aber nicht weiterreichen, oder die wirtschaftlichkeit Ihrer Kunden – die zahlen für etwas, was sie nicht brauchen, verschlechtert.

Die Frage ist, was braucht Ihre Nische. Das müssen Sie liefern und nicht mehr. Hier steckt für Ihre Kunden und Sie der Wert drin. Alles andere hat, bezogen auf diese Nische, auch eine schlechte Wirtschaftlichtkeit. Der Fokus auf eine Nische beantwortet Ihnen also automatisch die Frage nach dem “Was soll ich machen”.

Sie wissen welche Features gefragt sind und können diese in Ihrem Produkt unterbringen. Die anderen lassen Sie weg. Und was dann? Dann schauen Sie nochmal aus der Sicht des Kunden drauf und fragen Sich, was Ihr Kunde noch braucht. Nicht selten ist es ja so, dass Ihr Kunde von Ihnen nicht alles bekommt, was sie zur Lösung Ihrer Probleme braucht. Da muss dann noch etwas drumherum gebaut werden. Das können Sie dann noch liefern. Das mag bisher nicht Ihre Kernkompetenz sein, aber wenn Sie so das Problem des Kunden besser lösen, dann ist das gut investierte Zeit, sich da zumindest einen Partner für zu suchen.

Also nach dem Pareto-Prinzip weniger machen, und nur die für Ihren Kunden und Sie wirtschaftlichen Dinge tun und die freien Ressourcen stecken in eine wirkliche Problemlösung für den Kunden. Damit heben Sie sich in der Nische dann ab.

Verteilen Sie das Wissen darüber, auf welche Produkteigenschaften es wirklich ankommt und welche eher orientierenden Charakter haben auf sinnvolle Weise im Haus. Mein Vorschlag ist es, die geforderten Werte des Lastenheftes zurückzubeziehen auf die Wirtschaftlichkeitsrechnung Ihres Kunden und dadurch – ich nenne sie – Wechselkurse zu bestimmen.

Machen Sie kleinere Projekte, die entsprechend schneller sind und einen schnelleren Mittelrückfluss haben und fokussieren Sie sich auf engere Kundengruppen.

Gehen Sie weg von einer Produktzentrierten Sicht in der Sie Sich fragen, was Ihr Produkt noch können muss um einen größeren Markt zu bedienen und nehmen Sie die Kundensicht ein, lassen Sie Ihr Produkt nur das können, was der Kunde braucht und erweitern sie ggfs. mit Partnern Ihr Portfolio so dass, Sie dem Kunden eine komplette Problemlösung anbieten können.

Ein kleines Wort zum Schluss. Haben Sie Sich schon in den Emailverteiler eingetragen? Mit Impulsen, Terminankündigungen und der Chance, Themen für den Podcast vorzuschlagen. Vor allem aber mit Aussicht auf das erste Hörertreffen? Noch nicht, jetzt ist der richtige Moment. Bis gleich per Email. Ich freue mich.