Startups sind im Wesentlichen Maschinen, die MVPs (Minimum Viable Products) bauen, die helfen, Fragen zu beantworten und das Wertversprechen des Unternehmens schrittweise zu mindern.
Der Schlüssel ist, dass jedes MVP, das ein Unternehmen erstellt, sich auf die Beantwortung einer ganz bestimmten Frage konzentrieren muss. Wenn Sie mehr als das tun, ist es verschwendete Zeit und Mühe. Meiner Erfahrung nach befürchten viele Startups, zu früh zu skalieren und Ressourcen für etwas zu verschwenden, das möglicherweise nie benötigt wird.
Dieser Trend zeigt sich besonders deutlich bei Start-ups, die von Personen aus Ingenieurdisziplinen in großen und skalierten Unternehmen gegründet wurden. Aber die Dinge, die Sie tun müssen, um Code auf Facebook, Netflix, Amazon oder Google einzureichen, gelten nicht in gleicher Weise für Startups in der Frühphase.
Startups in der Frühphase haben möglicherweise einige Hundert oder Tausende von Kunden, und jede Kundenliste hat ihre eigenen einzigartigen Herausforderungen.
Versteh das nicht falsch; Es ist immer am besten sicherzustellen, dass Ihr Code relativ sicher und so geschrieben ist, dass die Kundenerfahrung nicht beeinträchtigt wird. Aber technische Gründer machen oft einen Fehler und verbringen viel Zeit damit, den Code zu härten (dh ihn sicher zu machen) sowie ihn so zu schreiben und zu implementieren, dass er skalierbar ist.
Aber das funktioniert nicht ganz, wenn Sie sich im Proof-of-Concept-Modus befinden.
Unerfahrene Gründer werden bei solchen Dingen oft defensiv und machen sich zu viele Gedanken darüber, ob das Produkt oder die Funktion, die sie gerade erstellt haben, eine nahtlose Benutzererfahrung bieten, oder sich Sorgen darüber machen, ob es eine Million gleichzeitiger Benutzer bewältigen kann. Ja, diese Dinge sind wichtig, aber sie sind möglicherweise nicht genau in diesem Moment richtig.
Die Denkweise von Startups in der Frühphase sollte darin bestehen, MVPs zu erstellen, um Fragen zu beantworten. Denken Sie daran, dass MVP immer noch ein schrecklicher Begriff ist; es ist weder ein Produkt noch lebensfähig. Es ist in vielen Fällen auch nicht so „minimal“. Ein MVP ist die geringste Arbeit, die Sie leisten können, um eine Hypothese für Ihr Startup zu bestätigen oder abzulehnen.
Wenn die Hypothese lautet: "Können eine Million Kunden diese App gleichzeitig nutzen?" Das ist natürlich der richtige Zeitpunkt, um es bis auf einen Zentimeter seiner Lebensdauer zu optimieren. Aber wenn Sie in den frühen Tagen ein Unternehmen aufbauen, ist das selten die Frage, und es sei denn, Sie gehören zu bestimmten Kategorien von Apps, die einem beträchtlichen Verkehrsaufkommen standhalten müssen, ist es unwahrscheinlich, dass sich Investoren darum kümmern.
Bei einem der Start-ups, bei denen ich geholfen habe, hatte das Unternehmen ein Produkt, bei dem Zehntausende von Menschen in einen Warteraum gesetzt wurden und wenn ein Countdown-Timer abgelaufen war, jeder das Produkt betreten konnte. Das stellte sich als interessante Herausforderung heraus: Was passiert, wenn 10,000 Personen innerhalb einer Sekunde auf denselben Teil einer Webanwendung zugreifen?
Wie Sie sich vorstellen können, verursachten selbst kleine Ineffizienzen in der Plattform große Engpässe und potenzielle Serviceverschlechterungen. Kurzfristig „löste“ es das Problem, indem es ein paar zusätzliche Server einschaltete und dann innerhalb von Minuten Leute hereinließ; 500 Leute gleichzeitig auf den etwas ineffizienten Code zu drücken, war viel weniger ein Problem als 10,000 Leute, die sich alle gleichzeitig einloggen.
Elegant? Nein. Hat es funktioniert? Ja, und das war sinnvoll, weil es dem Unternehmen damals nicht explizit darum ging, ob der Service 100.000 Kunden gleichzeitig bedienen kann. Warnung: Es war nicht möglich, und zum erforderlichen Zeitpunkt war dieser Teil des Codes so umgestaltet worden, dass sichergestellt war, dass dies möglich war.
In der Anfangsphase lauten die Fragen eher: „Ist das, was wir vorhaben, möglich?“ oder "Werden die Leute dafür bezahlen?" oder "Können wir einen Unternehmenspartner davon überzeugen, dies zu integrieren?" oder "Können wir Kunden zu vertretbaren Kosten akquirieren?" oder "Können wir das zu einem vernünftigen Preis machen?" oder „Wie funktioniert die Einheitsökonomie dieses Produkts, wenn wir skalieren?“
Für ein Pre-Seed-Geschäft brauchen Sie kein perfektes Design und keine Skalierbarkeit; Sie müssen genug Produkt und Traktion schaffen, um Benutzerfeedback zu erhalten. Von dort aus können Sie iterieren und Mehrwert für Kunden schaffen. Sobald Sie beginnen, genügend Wert zu liefern, für den Kunden bereit sind zu zahlen, können Sie darüber nachdenken, mehr in Skalierbarkeit zu investieren.
Ein Produkt zu früh zu überarbeiten ist weder wichtig noch klug. Es ist ein Gegenindikator: Es sagt Investoren, dass Sie nicht wissen, was in der aktuellen Phase Ihres Startups wichtig ist.
Wenn die Aufmerksamkeit konzentriert ist, läuft der Lackmustest: Trägt Ihre aktuelle Aktivität zu Sicherheiten bei, die Ihnen bei Ihrer nächsten Fundraising-Runde helfen? Wenn nicht, arbeiten Sie wahrscheinlich an etwas, das sehr wichtig erscheint, aber für das Szenario nicht geeignet ist.
Das ist ein Problem – Sie könnten immer mehr Zeit damit verbringen, etwas Ausgefalleneres, Schnelleres, Hübscheres oder Skalierbareres zu bauen – aber das Mantra beim Start sollte lauten: „Gut genug ist gut genug“. Es ist erstaunlich, wie schnell man gehen kann, wenn das Unternehmen es verinnerlicht hat.
