Wie Spotify Produkte baut und was Sie daraus lernen können

Avatar von Björn Schotte

 

Successful companies like Spotify only want to deliver products that people love. But they don’t know if people love until they’ve delivered it

How Spotify Builds Products (sehr lesenswert)

 

Sie haben eine Idee für ein Projekt. Eine neue Website (Relaunch). Ein Online-Shop Ihrer Produkte. Eine Verbesserung Ihrer bestehenden Online/Mobile Anwendung. Das ist wichtig für Sie. Sie wollen, dass die Nutzer dieses Projekts Ihr Projekt lieben. Damit Sie Ihren Zweck erfüllt bekommen.

Wie gehen Sie also vor? Die Fachabteilung baut das Fachkonzept. Man holt sich nochmal die Ergebnisse aus der Marktforschung oder den A/B Tests der vorhandenen Plattform. Der Vorstand möchte seine Vorstellungen mit eingeflossen haben.

Hören Sie auf damit! Fangen Sie an, Gewissheit darüber zu bekommen, ob, was und wie Ihre Kunden Ihre Plattform (Online-Shop, Reisebuchung, …) lieben. Erschaffen Sie eine Plattform anhand der Nutzerbedürfnisse, und nicht ausschließlich anhand dessen, was Sie sich so vorstellen.

Vergessen Sie, die Zukunft anhand dessen bestimmen zu wollen, was schon war. Was Ihre Nutzer schon immer mochten. Fangen Sie an zu antizipieren, wo Ihre Nutzer hin wollen. Der Blick in die Zukunft ist gefragt.

Dies geht nur mit Geschwindigkeit, kleinteiligen Releases, direkter Messung des Nutzerverhaltens, schnellen & flexiblen Entscheidungen und (Ver)Änderungen.

Wann fangen Sie damit für Ihr Online-Projekt an?

 

Avatar von Björn Schotte

Kommentare

6 Antworten zu „Wie Spotify Produkte baut und was Sie daraus lernen können“

  1. Vielen Dank für den Beitrag. Das finde ich sehr gut. Wir bei VersionEye arbeiten auch in sehr kurzen Zyklen und holen so schnell wie möglich Feedback von unseren Usern ein. Dazu gehen wir regelmäßig auf User Groups und MeetUps um möglichst viele persönliche Kontakte aufzubauen.
    Viele Features die Heute auf VersionEye implementiert sind, waren so niemals geplant. Das hoch laden von Projektdatein und die Überwachung von GitHub Projekten sind Features die nur existieren weil unser User danach gefragt haben.
    Customer Feedback ist absolut wichtig für die Entwicklung von modernen Online-Projekten.

    1. Hi Robert,

      danke für deinen Kommentar. Gerade noch die Werbekurve umschifft ;-)

      User Groups und Meetups vergleiche ich mit Marktforschung. Super nützlich. Manchmal nur Rückspiegel, denn bis Feedback dort ins Produkt einfliesst, kann schon mal ne Weile dauern.

      Messt Ihr direkt in der Plattform, welche Features von Nutzern gerne verwendet werden? Baut Ihr „Shadowfunktionalität“ ein, zB ein Button, hinter dem ein Overlay a la „Wir haben das Feature noch nicht geplant, aber wenn du jetzt dafür abstimmt, steigt die Wahrscheinlichkeit, dass wir es bald implementieren“ steht?

      Wie sind Eure Entwicklungszyklen? Wie habt Ihr die Entwicklung Eurer Plattform strukturiert? Ich und die Leser freuen sich, hier mehr dazu zu erfahren.

      Viele Grüße, Björn.

      1. Hallo Björn :-)

        User Groups und MeetUps sind super. Echt Gold Wert! Weil man dort gleich einen ganzen Haufen User/Kunden beisammen hat. Und man direkt in die Gruppe fragen was sie von einem bestimmten Feature halten. Was sie bisher cool fanden? Was sie in Zukunft haben wollen? Und man kriegt sofort Feedback.
        In der Regel setzen wir solche Feature Requests nach 1 bis 2 Monaten um.

        Wichtig dabei ist, das man nicht sofort alles umsetzt. Sonst hat man sehr schnell eine eierlegende WolfMilchSau! Ich halte mich hier an den Ratschlag von 37Signals aus dem Buch „Getting Real“. Darin wird empfohlen NICHT alle Features Requests schriftlich festzuhalten und zu analysieren. Und vor allem NICHT sofort umsetzen. Wenn ein Feature wichtig für die Community ist, dann wird man den selben Feature Request mehrmals von unterschiedlichen Leuten hören. Und die Features Requests die einem im Kopf bleiben, weil man sie ständig von unterschiedlichen Leute zu hören bekommt, sind wichtig! Die muss man dann umsetzen. Das coole an dieser Methode ist, man brauchst dafür kein teures Tool. Nur sein Gedächtnis :-)

        „Shadowfunktionalität“ haben wir bisher überhaupt nicht. Aus den oben genannten gründen. Stattdessen haben wir ein Feedback Formular. Ausserdem kommunizieren wir mit den Usern über Twitter und Facebook.

        Die größeren Features teilen wir uns immer so auf das wir sie in max. 2 Wochen implementieren und testen können. Jedes neue Feature wird in einem eigenen branch in Git verwaltet. So können wir jederzeit sehr schnell hot patches am Master branch vornehmen. Sobald ein Features abgenommen ist, wird es in den Master branch gemerged. Wenn dann alle Tests auf dem Master ebenfalls durchlaufen wird es auch gleich deployed.

        Wir haben keine festen deployment Zyklen. Wenn ein neues Features abgenommen ist und alle tests laufen durch dann geht es gleich produktiv. Continuous Deployment heist das Bassword hierzu :-) Das ganze funktioniert ohne down time. Die Anwendung ist zu jeder Zeit erreichbar. An manchen Tagen machen wir bis zu 5 produktive deployments.

        Dazu gibt es noch viel mehr zu sagen. Aber ich glaube der Kommentar ist schon lang genug :-)

        Beste Grüße,
        Robert @ VersionEye

        1. Klasse, Continuous Delivery ist natürlich nochmal eins oben drauf gesetzt. :-)

          1. Und was auch ganz wichtig ist, ist Continuous Updating :-) Am besten Tool gestützt und automatisiert.

  2. Wie Spotify Produkte baut und was Sie daraus lernen können http://t.co/FoXQ5dU0 via @mayflowerphp

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert


Für das Handling unseres Newsletters nutzen wir den Dienst HubSpot. Mehr Informationen, insbesondere auch zu Deinem Widerrufsrecht, kannst Du jederzeit unserer Datenschutzerklärung entnehmen.