Du hast deinen AdBlocker an?

Es wäre ein Traum, wenn du ihn für t3n.de deaktivierst. Wir zeigen dir gerne, wie das geht. Und natürlich erklären wir dir auch, warum uns das so wichtig ist. Digitales High-five, deine t3n-Redaktion

t3n 15

Erfolgsstrategien, Designprinzipien und Geschäftsphilosophie: Getting Real – Der Weg der 37signals

In puncto Produktivität und Agilität hat ihr Framework Ruby on Rails die Weichen neu gestellt. Die Einfachheit ihrer Webanwendungen gilt als stilprägend. Kaum jemand hat das Web 2.0 nachhaltiger beeinflusst: Das Team des Unternehmens 37signals ist Vorbild für eine ganze Generation junger Webdesigner und Internet-Entrepreneure. Was lässt sich aus dem Erfolg und Vorgehen der Chicagoer lernen?

Wie entwickelt man in einem kleineren Team schneller bessere Software? Das komplette Buch „Getting Real“­ steht frei verfügbar im Netz.
Wie entwickelt man in einem kleineren Team schneller bessere Software? Das komplette Buch „Getting Real“­ steht frei verfügbar im Netz.
Die Methode, die sie erfolgreich gemacht hat, nennen sie Getting Real. Sie steht für Fokussierung, Reduktion, das Nein-Sagen im Allgemeinen. 37signals ist Weltmeister darin. Auf den rätselhaften Firmennamen angesprochen, erklärt 37-Chef Jason Fried, die Idee dazu wäre während eines TV-Berichts auf dem Discovery-Channel entstanden. Demnach würde das SETI-Programm (Search for Extraterrestrial Intelligence) 37 Signale aus dem All nicht erklären können und daher mit möglicherweise intelligentem Leben verbinden. Ein Name war gefunden [1].

Heute, zehn Jahre später, zählt die ehemalige Designagentur zwölf Köpfe und lebt von vier sehr erfolgreichen Bezahldiensten. Das bekannteste Produkt dürfte ihre Projektmanagementsoftware Basecamp [2] sein, aus der auch Ruby on Rails entstand. Im Jahre 2006 erschien das zunächst im Selbstverlag verkaufte PDF-Buch über Getting Real. Sechs Monate und 23.000 verkaufte E-Books später, schrieben sie in ihrem extrem einflussreichen Firmen-Blog Signal vs. Noise [3], dass 23.000 Leser einfach nicht genug wären. Man wünschte sich, dass Millionen von Menschen das Buch lesen und stellte die Essay-Sammlung kostenlos online [4].

Weniger ist mehr

Je mehr Masse ein Objekt hat, desto mehr Energie wird benötigt, um seine Richtung zu ändern. Dies gilt in der Physik genauso wie im Business, wiederholt Jason Fried gerne als Geschäftsmantra. Daher leisten die eigenen Produkte bewusst weniger als vergleichbare Dienste. So paradox die Idee zunächst klingen mag: Man möchte die Konkurrenz im Wettbewerb gezielt unterbieten, um dem Teufelskreislauf des Wettrüstens um „mehr Features“ zu entkommen. Es sei besser, ein halbes Produkt zu bauen als ein halbherziges – klein und rund statt groß und voller Ecken.

Man nehme eine Produktidee und teile sie durch zwei – denn Zeit, um Features nachzureichen, ist später immer. Das Geheimnis, um die Hälfte eines Produkts zu bauen, ist Nein sagen zu können. Die Innovation kommt vom Weglassen. Tausend Ideen müssen sich das Nein anhören, damit eine das Ja-Wort bekommen kann, wird auch Steve Jobs zitiert. Häufig mögen wir die Dinge gerade für das, was sie eben nicht sind. Eine wichtige Frage lautet daher: Was ist die 50%-Lösung für unser Problem?

Das Prinzip „Build Less“ lässt sich fast universell anwenden und führt, im Gegensatz zum zuvor erwähnten Teufelskreislauf, zu einer positiven Rückkopplung: Weniger Features bedeuten weniger Software. Weniger Code wiederum kostet auch weniger Geld, ist leichter verständlich, leichter änderbar und hat weniger Bugs und Support-Anfragen zur Folge. Ebenfalls hilfreich ist es, nach den verdeckten Kosten von Features zu suchen. Insbesondere Feature-Loops, also Features, die weitere Features nach sich ziehen, können sehr schnell sehr teuer werden.

Bitte beachte unsere Community-Richtlinien

Schreib den ersten Kommentar!

Du musst angemeldet sein, um einen Kommentar schreiben zu können.

Jetzt anmelden

Finde einen Job, den du liebst