Zugang statt Features

Aber natürlich ist es so, dass über Wohl und Wehe jeder Online-Community allein die Features entscheiden, die Features sind das Alleinstellungsmerkmal und damit der Hebel für den Erfolg.

Falsch, ganz ganz falsch.

Es liegt an der Menge an Medienkanälen, über die ich Zugang zu einem Dienst habe. Sagt Tara Hunt und benutzt den aktuellen Fall von "Twitter" als Beispiel: Hier hat man sich (im Gegensatz zum Konkurrenten Jaiku) bei den Features extrem zurückgehalten und hat "Daten-Auffahrten" erzeugt: Man kann den Presence-Dienst Twitter per Web, IM und Handy sowohl "füttern" als auch abrufen und durch die API können Dritte weitere "digitale Auffahrten" zu dem Dienst erzeugen - und darauf sogar Geschäftsmodelle aufbauen.

Tara Hunts Fazit: Thinking about it in the way of 'On Ramps' could lead you to asking these types of questions:

1. Is there another web app that we can integrate with? (...)
2. How does my app interact with various interfaces? How simple would it be to have it work in more? What would the minimal functionality be while still being useful? [If you are a time tracking app, could you build SMS integration?]
3. How simple have I made life for those using my API? (...)
4. What is the users offline experience?
5. Have you designed your app to be simple enough to adapt to a text adventure?

Bei Punkt 1 ist die Frage zu stellen, ob man sich nicht einem anderen Anbieter zum Datenaustausch öffnet oder Widgets anbietet.

Punkt 5 spielt darauf an, ob man den Dienst auch als einfache Datenabfrage in einer Kommandozeile darstellen könnte - sofern es komplizierter ist, ihn mit Daten zu "füttern" hat der Dienst ein Problem.