(1) Ein technologiegetriebener Pivot
(2) Kein einfaches Geschäftsmodell aufrechterhalten zu haben
(3) Lean Startup zu kennen und trotzdem dem Handwerksgeist zum Opfer gefallen zu sein
(1) Ein technologiegetriebener Pivot
(2) Kein einfaches Geschäftsmodell aufrechterhalten zu haben
(3) Lean Startup zu kennen und trotzdem dem Handwerksgeist zum Opfer gefallen zu sein
4 Kommentare
Ich dachte erst, plötzlich wären die Aufrufe meines Blogs gestiegen, aber das ist wohl GeekNews zu verdanken, haha.
Wenn ich jetzt darüber nachdenke, habe ich mit dem Schreiben dieses Blogbeitrags angefangen, mich mehr für SaaS zu interessieren, und dieses Interesse hat sich ganz natürlich in Richtung No-Code verlagert.
In letzter Zeit habe ich mir No-Code-Tools angesehen und sie auch im Rahmen einer Study Group untersucht, und dabei wurde mir klar, dass in nur wenigen Jahren wohl niemand mehr App-Prototyping durch Coding machen wird.
Vielen Dank für den guten Artikel! Ich halte den No-Code-Bereich ebenfalls für vielversprechend ;)
Wenn man Punkt 2 und 3 aus dem Artikel zusammen betrachtet,
scheint es darauf hinauszulaufen, dass es wichtig ist, ein MVP (Minimum Viable Product) mit einem klaren Ziel zu bauen.
Wenn ein Entwickler meiner Meinung nach gründet, sind die folgenden zwei Dinge wichtig, um ein MVP zu erstellen.
Das sind Bereiche, die Entwickler oft nicht tun oder nicht gut können.
Auswahl und Fokus: zuerst ein Produkt bauen, das einen einzelnen, einfachen, aber wichtigen Pain Point löst
Mash-up: Um schnell zu entwickeln, bei allem, was nicht zum Kern gehört, möglichst gut Dinge anderer nutzen (Frameworks, SaaS)
Für Punkt 1 muss man wohl Marktanalyse, Trendanalyse, vorhandene Technologien usw. breit berücksichtigen,
und bei Punkt 2 halte ich es für wichtig, zu vielen verschiedenen Tools zumindest ein „oberflächliches Wissensniveau“ zu haben und sie dann bei Bedarf passend einzusetzen.
Wenn man sie gar nicht kennt, entwickelt man es am Ende einfach selbst oder braucht schon lange, um überhaupt herauszufinden, dass es so etwas gibt. Verbringt keine Zeit damit, nicht zum Kern gehörende Funktionen selbst zu entwickeln.
Deshalb stelle ich über GeekNews verschiedene SaaS- und Framework-Themen mit kurzen Erklärungen vor.
Wenn ihr nur Titel und Beschreibung lest, wird es irgendwann später sicher einmal nützlich sein.
Deshalb empfehle ich auch Leuten, die mich zu Business-Themen ansprechen, häufig andere Tools oder Business-Fälle, die sich für Dinge außerhalb des Kerns einsetzen lassen.
Selbst bei Side Projects oder persönlichen Projekten scheint man, damit am Ende ein Produkt mit einem realistisch umsetzbaren Zeitplan herauskommt, außer beim Schlüsselwert alles nur mit minimalen Kosten angehen zu müssen. Vielen Dank für die guten Worte.